【小ネタ】Red Hat Enterprise LinuxのAMIの調べ方 - サーバーワークスエンジニアブログ
本記事ではEC2でRed Hat Enterprise Linux(RHEL)を用いたい場合のAMIの調べ方について、2019/6/18時点で「こうやったら良さそうという方法・留意点」についてご案内します。 8系が最近リリースされて、EC2の作成ウィザードのクイックスタートで表示されるRHELについても8系が表示されるようになりましたが、まだもうちょっと7系を利用したい・あれ過去verのAMIってどう調べたらいいんだろうと思っている方も多いはず。この記事はそんなあなたのための記事です。 なお、Cent OSのAMIの調べ方につきましては弊社の城が過去に記事を書いておりますので併せてご参照ください。 RHELの公式AMI一覧 AWSの公式ページにRHELの利用案内はあるのですが、こちらのページの[今すぐ購入する]から遷移するマーケットプレイスでは2019年6月18日時点では8系や7.6系等の
新機能「WorkSpace image」をさっそく検証してみた - サーバーワークスエンジニアブログ
こんばんは、秋になりおでんが美味しくなってきましたね、がんも（佐竹）です。 遂に！Amazon WorkSpacesでカスタムイメージが作成できるようになりましたね！ というわけでさっそく検証してみました。 WorkSpace Imageを作成しよう Best Practices for Image Creation Imageから自分のBundleを作ろう カスタムBundleからWorkSpaceをLaunchしてみよう WorkSpacesに接続してみよう まとめ WorkSpace Imageを作成しよう いきなりですが、既にWorkSpacesを1台Launchしてあるとします！これをさっそくImageにします！ ImageにしたいWorkSpaceを選んで、Create Imageを押しましょう。 すると、イメージ名と説明を入れろと言われます。 ちなみにどちらも必須項目なのでさ
【速報】AWS EC2におけるShellShockの対応状況について - サーバーワークスエンジニアブログ
bashの脆弱性「ShellShock」に関するEC2の対応状況をお知らせします。 脆弱性情報 CVE-2014-6271 CVE-2014-7169 Amazon Linux AMI Security Advisory: ALAS-2014-418 Amazon Linux AMI Security Advisory: ALAS-2014-419 EC2上にて利用できる対策済みパッケージ ディストリビューション CVE-2014-6271 CVE-2014-7169 Amazon Linux i686 bash-4.1.2-15.19.amzn1.i686 bash-4.1.2-15.21.amzn1.i686 Amazon Linux x86_64 bash-4.1.2-15.19.amzn1.x86_64 bash-4.1.2-15.21.amzn1.x86_64 RHEL5 i
初期アカウントのパスワード設定をAMIを通して持続させる方法 - サーバーワークスエンジニアブログ
最近マジカルミライに行って来た小室です。扉を開けるとそこは天国でした（違 さて今回は以下の記事の続きを書きたいと思います。 初期アカウントがパスワード無しでsudo出来るのが気持ち悪いという貴方へ « サーバーワークス エンジニアブログ この記事は特定のインスタンスがリブートをしてもパスワードが変わらないですよーという記事だったのですが、上記の方法だけですと、インスタンス-> AMI化して別のインスタンスを作った時にcloud-initが起動し初期化されてパスワードが消えてしまいます。 そのような場合対応方法の紹介をします。 そもそも上書きをしてしまうcloud-initの自動起動を停止する方法もあるのですがそれではクラウドのメリットが半減するのでお勧めしません。 起動するときに 毎回UserDataを入れる AMIから起動する際に以下の方法でパスワード設定をします（これは上記ブログ記事で
AWS News Blog
Add your Ruby gems to AWS CodeArtifact Ruby developers can now use AWS CodeArtifact to securely store and retrieve their gems. CodeArtifact integrates with standard developer tools like gem and bundler. Applications often use numerous packages to speed up development by providing reusable code for common tasks like network access, cryptography, or data manipulation. Developers also embed SDKs–such
AutoScalingも怖くない、Zabbix自動登録 - サーバーワークスエンジニアブログ
4月から劇団サーバーワークスに加わりました。伊藤です。 社内ではくりゅーと呼ばれております。 AWS環境では、わずか数クリックでサーバーができたり、AutoScalingで自動的にサーバーが増えたり、 オンプレミスの監視運用のスピードでは全く追いつけません。 そこで、今回はAuto Scalingなどで監視対象のインスタンスが自動で増えたり減ったりしても、Zabbixで常に対象インスタンスを自動登録し、監視対象にする方法をご紹介します。 自動構成ツールなどには依存しないので、どんな方法で（マネージメントコンソール、SDK、CLI、API、Elastic Beanstalk等々）構築、運用していても適用できます。 監視対象インスタンスのAgent側設定 zabbix_agentd.confにおいて、以下の点を設定します。 Server=127.0.0.1 #Zabbix-serverのIPも
AWSに簡単に構築できるクラウドストレージ対応ファイルサーバ『MagFS』を試用してみた - サーバーワークスエンジニアブログ
MagFSは米Maginatics社が開発するクラウドストレージ対応広域共有ファイルサーバです。 ファイルサーバといってもハードはなく、仮想ソフトウェアアプライアンスで提供されています。 VMwareもしくはAmazon EC2に対応し、今回、Amazon EC2版を試用する機会を得ましたので、サーバ構築・導入から実際にファイルをMagFSに置いてみるまでをレポートいたします。 MagFSの特徴を以下に挙げます。 クラウドストレージで広域同期ファイル共有を実現 メタデータサーバと独自キャッシュ技術によりアクセスが高速 非同期に、各拠点やクライアント間でデータを共有できる AES256ビット暗号化処理でデータ保護はセキュア Active Directoryとも連携でき、アクセス制御の一元管理が可能 ストレージはAmazon S3に対応 クライアントは、Windows、Mac OSX、Linu
Amazon EC2 G2インスタンスをWindowsでつかってみる
AWSブログにて発表されたとおり、高速なグラフィック処理を可能にするG2インスタンス（g2.2xlarge）がAmazon EC2で利用可能になりました。g2.2xlargeは64bit HVMで動作し、以下のスペックを利用することができます。 NVIDIA GRID™ (GK104 "Kepler") GPU (Graphics Processing Unit), 1,536 CUDA コアと4 GB ビデオ(フレームバッファ) RAM. Intel Sandy Bridge プロセッサ(2.6 GHz, Turbo Boost 有効), 8 vCPU (Virtual CPUs). 15 GiB のメモリ. 60 GB のSSD ストレージ NVIDIAがWindowsとAmazon Linux向けにGPUドライバインストール済みのAMIを提供しているため、AWS Marketplac
AWSのEC2でAmazon Linux AMIを使うかどうか？ - プログラマでありたい
最近、微妙に気になっているテーマがあります。EC2でインスタンスを使う際に、Amazon Linux AMIを使うかどうかという点です。何を言っているのだ、お前というような悩みなので背景を簡単に書いておきます。 Amazon Linux AMIを使わないようにしようかなと思った理由 そもそものキッカケは、Chefを使うようになったことです。Chefで環境をコードで記述するようになると、ローカルの開発環境であろうが、検証・本番環境でも基本的にはコマンド１つで構築できます。しかし、気が付いてしまいました。ローカルの開発環境に、Amazon Linuxをインストール出来ないことに。このことはChefを使い出すと同時に、VirtualBox+Vagrantを使いだしたことで顕著に感じるようになりました。 また私の所属しているチームの特性上、様々なプロジェクトに関与してプラットフォームもAWSだけで
Public AMIを公開する場合のお作法 - プログラマでありたい
一般的にPublic AMIとして公開する必要があるケースは少ないです。そのため、AMIを公開する際の情報は少なく、どうしたものかなぁとなります。私も試しにしてみたかったので、公開してみたことがあります。その際の注意点をまとめておきます。今回の手順は、Redhat系OSを想定しています。 ※実際、一度目は手順としてまとめておかなかったので、抜け・漏れが発生しました。 自分の痕跡を消す 公開鍵の消去 これ必須です。忘れるとAWSから注意が来ることもあるそうです。私は来たことありませんが。。。 echo "" > /root/.ssh/authorized_keys echo "" > /home/*/.ssh/authorized_keys ログの消去 接続元情報などが漏れるので、消去しておいてください。ここのログは稼働しているサービスによって可変ですので、任意のものを消してください。 ec
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
