投稿

6月, 2013の投稿を表示しています

EC2でVolumesがなぜか増えていく

イメージ
AWSのEC2でCentOSのAMIを使ったり削除したりしていると、Management Consoleから確認できるEC2のVolumesの数がだんだん増えていく事に気付くと思います。 AMIの設定には詳細設定でAMI削除時にボリュームを削除するか(Delete on Termination)というオプションがあるんですが、コミュニティ提供版のCentOS AMIではこれがfalseで提供されているんですねー。なので、インスタンスを立ち上げる→terminateするを繰り返していると、インスタンスは消滅しするんですがVolumeが残っていってしまいます。 terminate時にインスタンスのボリュームも一緒に削除したい場合は、AMI作成時に下のように設定するとよいです。 インスタンス起動時のボリュームオプションで設定する インスタンスをAMIから立ち上げる時の設定(Storage Device Configuration)でボリュームのDelete on Terminationオプションをtrueにセットしてから起動しましょう。Delete on Terminationのオプションにチェックを入れてSaveを押すと設定が反映されます。 AMI作成時のオプションでDelete on Terminationをtrueにする。 上のやり方だとインスタンスを立ち上げるたびに設定する必要がありますが、AMIのデフォルト設定としておくと何度も立ち上げる必要がある場合に便利です。元となるインスタンスからAMIを作成するときにオプションのDelete on Terminationのチェックを入れてSaveしてからCreateしましょう。このAMIから作成されるインスタンスはDelete on Terminationがtrueの状態で立ち上がってきます。 Amazon LinuxのAMIはtrueに設定されているんですが、CentOSはなんでfalseで作っちゃったんでしょうね?

ubuntuで不要な設定の削除

ubuntuのdpkg-queryコマンドの行の先頭に出てくる rc という文字は何の意味だろうと調べたところ、「削除されているけども設定ファイルは残っているパッケージ」というものらしいですね。俄然不要なのでまとめて消してしまいました。 # for i in `dpkg-query -l | grep ^rc | awk '{print $2}'`; do; sudo apt-get purge $i -y; done スッキリ。

Chef Serverを立ててみる

イメージ
最近はやりのDevOpsとやらに乗っかって、Chefでもインストールできるようになってみたいと思います。 chef serverのセットアップ パッケージのダウンロード Opscode からパッケージをダウンロードします。server立てるだけならchef serverのみ必要ですが、serverを操作するためにどうせclientパッケージも必要になるのでchef server,chef clientどっちも取ってきましょう。 パッケージのインストール ダウンロードしたパッケージをインストールします。 # yum install chef-server-11.0.8-1.el6.x86_64.rpm chef serverのセットアップ chef serverの初期設定をします。コマンド一発です。rpm版が用意される前のものを使ったことがないのですが、昔に比べてだいぶ楽になったと感涙モノだそうです。 # chef-server-ctl reconfigure 下のようなエラーでコケるときはネットワーク周りの設定をミスってる可能性大です。 Recipe: chef-server::bootstrap * execute[verify-system-status] action run ================================================================================ Error executing action `run` on resource 'execute[verify-system-status]' ================================================================================ (中略) ---- Begin output of curl -sf http://127.0.0.1:8000/_status ---- STDOUT: STDERR: ---- End output of curl -sf http://127.0.0.1:8000/_status ---- Ran curl -sf http://127.0.0.1:8000/_s

AMIを作るときsshのauthorized_keysってどうしてるんでしょうね。

AWSを使うときによく使うOSをAMI化しといてそのAMIから複数環境立ち上げる、ってなことを最近よくやっています。いやはや便利ですね。 で、まあそれはいいんですが、AMI作るときに ~/.ssh/authorized_keys 削除しておかないと情報残ったままになるんですよね。公開鍵見られたところでなにか問題があるわけじゃないんで別に残したままでいいっちゃいいんですが、、、例えばAMIを公開して使ってもらうってなった場合はどうしてるんだろなどとふと思いました。 AMI作成時、OS停止のタイミングで消すようなスクリプトを仕込む → 作業やり直したくなってOS起動してもログインできなくなるのでNG 毎度手作業で消す → めんどくさい。というか消し忘れ多発。(←私がそう) う〜ん。手作業で消すしか手段がないような気がしますがなんかいい方法があるんでしょうか。 ま、自作AMIを公開することなんてないんで気にするだけ無駄といえば無駄なんですけどー。。。

s3syncの初期設定

AWS上でs3syncを利用するための設定方法メモ。 ruby関連パッケージのインストール # yum install ruby rubygems s3syncのインストール # gem install --no-ri --no-rdoc s3sync 設定ファイルの作成 # mkdir /etc/s3conf/ # vi /etc/s3conf/s3config.yml 設定ファイルの中身はこんな感じ 。 AWS_ACCESS_KEY_ID : [AWSのアクセスキー] AWS_SECRET_ACCESS_KEY : [AWSのシークレットキー] AWS_CALLING_FORMAT : "SUBDOMAIN" 動作確認 以下のコマンドでバケットのリストが取得できればOK。 # s3cmd listbuckets