Vagrant-AWSでうまくいかない時の調べ方
環境変数 VAGRANT_LOG を設定する
$ export VAGRANT_LOG=debug $ vagrant up
すると詳細な動作ログを読むことができるので原因特定できるはず。
"[default] Waiting for SSH to become available..."で止まる
AWSプロバイダーを使って vagrant up した時に"[default] Waiting for SSH to become available..."で止まってしまうのは
ERROR warden: Error occurred: There are errors in the configuration of this machine. Please fix the following errors and try again: vm: * The host path of the shared folder is missing: /Users/username/aws/cookbooks
ということでVagrantfileのあるディレクトリ直下にcookbooksディレクトリが存在しないため mkdir すれば直る。
mkdir -p '/vagrant' が失敗する
INFO interface: error: The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! mkdir -p '/vagrant' The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! mkdir -p '/vagrant'
Amazon Linux の /etc/sudoers でsudoにTTYを要求するため。失敗メッセージが表示されたら
$ vagrant ssh
してEC2インスタンスにログインし、requirettyの行をコメントアウトすればOK。
$ sudo visudo #Defaults requiretty
EC2インスタンスをexitしたら改めてプロビジョニングを実行する。
$ vagrant provision
Vagrant でEC2にChef-SoloするときのChefはいつインストールしたらいいんだ?
The chef binary (either `chef-solo` or `chef-client`) was not found on the VM and is required for chef provisioning. Please verify that chef is installed and that the binary is available on the PATH.
vagrant provision する前にvagrant sshして、必要パッケージを手作業で yum install してあげるしかないのかな・・・
$ vagrant ssh $ sudo yum -y install git rubygems make gcc ruby-devel $ sudo gem install chef --no-ri --no-rdoc $ exit $ vagrant provision
とあるJAWSUG懇親会で聞かせてもらった地方インフラエンジニアの働き方についての話
Q.クラウドやAWSの知名度は?
東京での知名度は高い。大阪でも知らない人はいたりする。
東京で勉強会開くとすぐに席が埋まる。クラウド熱はやっぱすごい。
Q.AWSはどんなお客さんが使ってる?
ソーシャルゲームとか。
東芝が開発した医療カルテをS3へ保存するとか
http://aws.amazon.com/jp/solutions/case-studies/toshiba-medicalsystems/
最近システム開発するときは「まずはAWSで構築する」ことを前提に考えるようになってきた。
お客さんから「AWSで」と指定されることも増えてる。
Q.個人情報とかセキュリティ的には問題ないの
S3は暗号化されて管理されているし。
医療カルテのケースでは東芝の独自暗号化されたものが保存されている。
（上記URLで紹介されているDICOMのこと）
Q.課金は?突然予定外の支払いとか怖くない?
ある程度支払い予測ができる規模なら問題ない。
リスク分を月々多めにもらっておいて月定額にするってビジネスはいいかも。でも顧客数ある程度多くないと（リスク分散として）厳しいと思う。
Q.クラウドっていうと他にもさくらやニフティなんかあるけどAWSとの違いは
EC2とか仮想マシンだけで比べたら変わらない。
AWSの強みはその周辺の多数のサービスが充実していること。SESとかメール配信にすごく便利。
Q.AWSになることでエンジニアには何が必要になる
基本的なサーバ管理の知識はいままでと変わらない。いろんなサービスをどう組み合わせるかって知識は必要。
Q.ハードが不要になりクラウドでサーバを持つってことは現地常駐開発がなくなるってこと? 地方のエンジニアの仕事は東京にとられちゃうの?
東京でも地方のインフラが管理できるので東京に仕事を持ってかれる可能性はあるだろう。
けど逆に地方で東京の仕事ができって考えることもできるよね。実際に地方にいながら東京の仕事やってるよ。
神戸の会社（※デジタルキューブ https://www.digitalcube.jp/）の社員は地方に点在して仕事してる。
（たぶんこのこと→ http://bloggingfrom.tv/wp/2012/05/13/7504 ）
Q.エンジニアとして技術向上の意識を高く持つためには?
東京方面にアンテナをはって、自分のいる位置を意識すること。
AWSが流行ってるから使わなきゃいけないわけじゃなく、そういう事を知りつつ自分の立ち位置を知ることが大事だと思う。
刺激を受けることが大事。
刺激を受けることが大事。
刺激を受けることが大事。（大事なことなのでｒｙ
Q.刺激どうやって受けよう?
勉強会に参加したり。セミナーに参加したり。
QPstudyはいいよ。適度にゆるくて。
https://sites.google.com/site/qpstudy/
今度あるJAWS Daysにでてみるのがいいと思う。LT枠30くらいあって、まだ空きあるよ。
結論：地方のエンジニアのみんな！JAWS Days 行こうぜ！！
AWS EC2でaws-sdk-rubyとvim使う時に最低限設定しておくもの・・・をchefで設定してみた
Cookbookとかレシピを作成する
$ sudo gem install chef $ knife config （すべて初期値のままで良いのでエンターキーを押していく） （~/.chef/knife に設定が書き出されるのでパスを追記する） $ cat >> ~/.chef/knife.rb file_cache_path "/tmp" cookbook_path "/home/ec2-user/chef-solo/cookbooks" $ knife cookbook create ec2_config ** Creating cookbook ec2_config ** Creating README for cookbook: ec2_config ** Creating CHANGELOG for cookbook: ec2_config ** Creating metadata for cookbook: ec2_config
ひとまず、いまの設定ファイルをままテンプレートとして置いておきます。設定ファイルの拡張子は ".erb" になります。
$ cp -pi ~/.screenrc cookbooks/ec2_config/templates/default/screenrc.erb $ cp -pi ~/.vimrc cookbooks/ec2_config/templates/default/vimrc.erb
レシピはまずは簡単に2種類だけ設定してみます。
- yum を使っていくつかのパッケージをインストールする
- 上でコピーしたファイルをec2-userのホームディレクトリに展開する
レシピを書くにあたって AWS OpsWorks のgithubリポジトリにある opsworks_bundler を参考に（ほぼ丸パクリ）させてもらいました。
https://github.com/aws/opsworks-cookbooks
$ vi cookbooks/ec2_config/recipes/default.rb
# # Cookbook Name:: ec2# Recipe:: default # # Copyright 2013, Kazuki Ueki # # All rights reserved # ec2_user = 'ec2-user' ec2_group = 'ec2-user' if node[:bundler][:manage_package] gem_package "Installing Bundler #{node[:bundler][:version]}" do gem_binary node[:dependencies][:gem_binary] retries 2 package_name "bundler" action :install version node[:bundler][:version] end end %w[libxml2-devel libxslt-devel libffi-devel git rubygems ruby-devel].each do |pkg_name| package pkg_name end template "/home/#{ec2_user}/.screenrc" do source 'screenrc.erb' user ec2_user group ec2_group mode 0644 end template "/home/#{ec2_user}/.vimrc" do source 'vimrc.erb' user ec2_user group ec2_group mode 0644 end
うまく動くかテストしてみましょう。
$ sudo chef-solo -j ~/.chef/chef.json -c ~/.chef/knife.rb
特にエラーなく動いたらgithubにpushして別のEC2インスタンスでクリーンな状態で動かしてみます。
$ cd ~/chef-solo/cookbooks $ git init . $ git add . $ git commit -m "Initial commit" $ git remote add origin https://github.com/uekikazuki/ec2_config.git $ git push -u origin master
別のEC2インスタンスに適用してみる
chefを入れるにもrubygemsやmakeパッケージが必要という鶏と卵な関係なので、そこは仕方なく手作業でインストールします。
$ sudo yum -y install git rubygems make gcc ruby-devel $ sudo gem install chef --no-ri --no-rdoc
githubから作っておいたCookbookを取り寄せます。pull後のディレクトリは ~/.chef/cookbooks/ec2_config になります。
$ mkdir -p ~/.chef $ cd .chef $ git clone https://github.com/uekikazuki/ec2_config.git cookbooks
chef-solo を実行するためにファイルを2つ作成します。"chef-solo.rb" はgitで取ってきたCookbookのパスなどが書かれたコンフィグファイル、"ec2_config.json" はとってきたCookbookの中からどのレシピを実行するか(run_list)を指示したファイルです。
2つのファイルをchef-soloコマンドのオプションとして指定し実行します。
$ cat >> ~/.chef/chef-solo.rb
file_cache_path "/tmp"
cookbook_path "/home/ec2-user/.chef/cookbooks"
$ cat >> ~/.chef/ec2_config.json
{
"run_list":["recipe[ec2_config]"]
} さあ！設定開始です！！パッケージをインストールするのでsudoで実行します。
$ sudo chef-solo -j ~/.chef/ec2_config.json -c ~/.chef/chef-solo.rb
画面に表示されるログにエラーがなければ成功です！
ホームディレクトリにドットファイルが作成されているか確認してみましょう。
$ ls -1a ~/.*rc /home/ec2-user/.bashrc /home/ec2-user/.screenrc /home/ec2-user/.vimrc
成功しました！あとはchefを開発しているopscodeのドキュメント（特にPackagesのドキュメント）を読みながらレシピの書き方を覚えていきましょう。
2013-03-04 23:31 追記
- chef のインストールには ruby-devel も必要なので yum の対象に追加
- chef インストール時は --no-ri --no-rdoc でドキュメントはインストールしないように変更
AWS EC2でaws-sdk-rubyとvim使う時に最低限設定しておくもの
毎回毎回設定するたびに忘れるので。それこそchef使って自動化したいよね・・・
開発に必要なパッケージをインストールする。
$ sudo yum -y update $ sudo yum -y groupinstall "Development tools" $ sudo yum -y install libxml2-devel libxslt-devel libffi-devel $ sudo yum -y install git rubygems ruby-devel $ sudo gem install bundler
gitの設定をする。
$ git config --global user.name "Kazuki Ueki" $ git config --global user.email ueki.kazuki@XXXXX.com
vimの設定をする。タブ幅=2と、コメント行で改行した時も次の行がコメントにならないようにだけしておきます。
$ cat ~/.vimrc
set softtabstop=2 set tabstop=2 autocmd FileType * setlocal formatoptions-=ro
追記(2013-02-26 23:00)
しばらく操作しないとsshが切られてしまうので時刻表示用にscreenも必要。
$ cat .screenrc
escape ^t^t
shell /bin/bash
defencoding UTF-8
defhstatus "^E:^Et"
defscrollback 8195
term screen-256color-bce
zombie ^[
hardstatus alwayslastline "%{= rw} %H %{= wk}%-Lw%{= bw}%n%f* %t%{= wk}%+Lw %{= wk}%=%{= gk} %y/%m/%d %c "
AWS hands-on の内容をコマンドラインでやってみる aws-api-tools
Phase-0 AWSコマンドラインツールの準備をする
普段使っているパソコンに aws-api-tools の実行環境を作成しても良いのですが、ec2で提供されているAmazon Linuxなら最初からコマンドがインストールされていて簡単です。
コマンド操作用ec2インスタンスを立ち上げる
AWS Management Consoleからec2インスタンスを起動しましょう。t1.micro タイプで問題ありません。
（以降、このインスタンスを作業用インスタンスと呼ぶことにします）
秘密鍵とX.509証明書をダウンロードする
ツールを使用してAPIにアクセスするためには秘密鍵とX.509証明書が必要になります。
AWSコンソールを開いて、画面右上の自分の名前をクリックして出てくるプルダウンメニューから "Security Credentials" をクリックします。
アクセス証明書のところにある "X.509証明書" で新しい証明書を作成します。小さいウインドウが開くので、"Private Key"と"X.509 Certifiate"をダウンロードします。
ダウンロードした秘密鍵と証明書を作業用インスタンスにコピーしてください。ここではec2-userのホーム下の aws ディレクトリに保存します。
まず作業用インスタンスにsshでログインしホームディレクトリ下に aws ディレクトリを作成しておきます。
$ mkdir aws
次にローカルPCにダウンロードした秘密鍵と証明書を作業用インスタンスにコピーします。
$ scp -i uekikazuki.pem ~/Downloads/cert-XXXXXXXXXX.pem ec2-user@ec2-54-248-176-167.ap-northeast-1.compute.amazonaws.com:~ec2-user/aws $ scp -i uekikazuki.pem Downloads/pk-XXXXXXXXXX.pem ec2-user@ec2-54-248-176-167.ap-northeast-1.compute.amazonaws.com:~ec2-user/aws
コマンドを実行する際にはコピーした秘密鍵と証明書のパスをコマンドラインオプションで指定するのですが、毎回パスを指定するのは手間なので、環境変数に設定しましょう。
あわせてEC2とRDSで使用するアベイラビリティゾーン(AZ)もTokyo(ap-northeast-1)に設定しておきます。(ここで指定するURLをエンドポイントを呼びます)
$ export EC2_PRIVATE_KEY=~/aws/pk-XXXXXXXXXX.pem $ export EC2_CERT=~/aws/cert-XXXXXXXXXX.pem $ export EC2_URL=https://ec2.ap-northeast-1.amazonaws.com $ export RDS_URL=https://rds.ap-northeast-1.amazonaws.com
Phase-1 EC2インスタンスを立ち上げる
sshとhttpで繋がるようにSecurity Groupを作成する
次にセキュリティグループを作成します。セキュリティグループとはいわゆるファイアウォールのことです。
まず cms-app というセキュリティグループを作成し、次にその作成したセキュリティグループに通信を許可したいポート(tcp/22とtcp/80)を追加していきます。
$ ec2-create-group cms-app -d "SG for cms app (port 80 and 22)" GROUP sg-e1bacee0 cms-app SG for cms app (port 80 and 22) $ ec2-authorize cms-app -P tcp -p 22 GROUP cms-app PERMISSION cms-app ALLOWS tcp 22 22 FROM CIDR 0.0.0.0/0 ingress $ ec2-authorize cms-app -P tcp -p 80 GROUP cms-app PERMISSION cms-app ALLOWS tcp 80 80 FROM CIDR 0.0.0.0/0 ingress
AMIからEC2インスタンスを作成する
ハンズオンで使用したAMI（Amazon Machine Images: EC2インスタンス作成時のひな形となるもの）を指定してインスタンスを作成します。今回使うAMIのIDは ami-d170f5d0 です。作成する際、セキュリティグループは先ほど作成した cms-app を使用し、インスタンスタイプは一番小さな t1.micro を使用します。
$ ec2-run-instances \
--group cms-app \
--instance-type t1.micro \
--instance-count 1 \
--key <key-pair-name> \
ami-d170f5d0
RESERVATION r-79d4587a 376158489050 cms-app
INSTANCE i-7d496c7e ami-d170f5d0 pending 0 t1.micro 2013-02-05T12:49:04+0000 ap-northeast-1a
aki-44992845 monitoring-disabled ebs paravirtual xen sg-e1bacee0 default false作成したインスタンスにわかりやすく"Name"タグをつけておきます。NameタグをつけるとEC2 Management ConsoleのName列に表示されてインスタンスが区別しやすくなります。
タグをつける際には付与先のEC2インスタンスを指定します。EC2インスタンスは作成時に表示された i-xxxxxxxx がIDなので、これを指定します。
$ ec2-create-tags i-7d496c7e --tag Name=az-a-cms1 TAG instance i-7d496c7e Name az-a-cms1
EIPを割り当て、EC2インスタンスに関連づける
Elastic IP（固定グローバルIPアドレス）を取得して、作成したEC2インスタンスに関連づけます。
まず ec2-allocate-address を実行してEIPを取得します。
$ ec2-allocate-address ADDRESS 54.249.238.6 standard
表示されたEIPをEC2インスタンスに関連づけます。先ほどと同様EC2インスタンスは作成時に表示された i-xxxxxxxx がIDなので、これを指定します。
$ ec2-associate-address 54.249.238.6 --instance i-7d496c7e ADDRESS 54.249.238.6 i-7d496c7e
（a-blog cmsのセットアップ）
ここまでの作業でEIP（グローバルIPアドレス）を使ってEC2インスタンス上で動いているa-blog cmsというアプリケーションが表示できるはずです。早速ブラウザから表示してみましょう。
初期設定が済んでいないので http://54.249.239.207/setup/install.php というURLに移動してインストールウィザードが表示されます。画面の指示に従って初期設定をしてください。（基本的にデフォルトのままボタンをクリックしていけば良いだけです）
- データベースサーバ名
- localhost
- データベースが存在しなかった場合に、指定された名前でデータベースを作成する
- チェックする
- データベース名
- ablogcms
- データベースユーザー名
- root
- データベースパスワード
- XXXXXXXX
Phase-2 RDSインスタンスを立ち上げる
MySQL DB用Security Groupを作成する
RDS用のセキュリティグループ（ファイアウォール）を作成します。
EC2の時と同様まず cms-db というセキュリティグループを作成し、次にその作成したセキュリティグループに通信を許可したいポート(tcp/3306)を追加していきます。
ここで特徴的なのはアクセス元としてEC2で作成したセキュリティグループ cms-app を指定できることです。これによってRDSにEC2インスタンスからのみアクセスを許可することができます。
$ rds-create-db-security-group cms-db -d "db SG for cms (port 3306)" SECGROUP cms-db db SG for cms (port 3306)
なお --ec2-security-group-owner-id に指定するAWS Account Numberは ec2-describe-group で調べることができます。
$ ec2-describe-group cms-app
GROUP sg-bba3d4ba 376158489050 cms-app SG for cms app (port 80 and 22)
PERMISSION 376158489050 cms-app ALLOWS tcp 22 22 FROM CIDR 0.0.0.0/0 ingress
PERMISSION 376158489050 cms-app ALLOWS tcp 80 80 FROM CIDR 0.0.0.0/0 ingress
$ rds-authorize-db-security-group-ingress cms-db \
--ec2-security-group-name cms-app \
--ec2-security-group-owner-id 376158489050
SECGROUP cms-db db SG for cms (port 3306)
EC2-SECGROUP cms-app sg-e1bacee0 376158489050 authorizing
MySQL DB用Parameter Groupを作成する
MySQLのデータベース設定ファイル(my.conf)にあたるパラメーターグループを作成します。パラメータグループを作成することで同じDB設定のRDSを複数作成することができるようになります。
なおパラメータグループ名(cms-db-mysql55)は、DBの種類(mysql)とバージョン(5.5)が分かるよう命名するのがコツだそうです。
$ rds-create-db-parameter-group cms-db-mysql55 \ --db-parameter-group-family mysql5.5 \ -d "db PG for cms(mysql-5.5)" DBPARAMETERGROUP cms-db-mysql55 mysql5.5 db PG for cms(mysql-5.5)
DBインスタンスを作成する
作成したセキュリティグループとパラメータグループを指定し、RDSインスタンス "cmsdb" を作成します。
なお以下で指定している "cmsdb" は「RDSのインスタンス名」のことで、--db-nameで指定している "mydb" はMySQLのデータベース名のことです。後ほどEC2上にあるMySQLデータをRDSにインポートしますが、その際に指定するのはMySQLデータベース名である "mydb" の方なのでご注意ください。
コマンドを実行してから実際に作成され使えるようになるまでに5分程度かかります。しばらくお待ちください。
$ rds-create-db-instance cmsdb \
--db-security-groups cms-db \
--db-instance-class db.t1.micro \
--engine mysql \
--db-parameter-group-name cms-db-mysql55 \
--db-name mydb \
--master-username awsuser \
--master-user-password mypassword \
--allocated-storage 5 \
--backup-retention-period 0
DBINSTANCE cmsdb db.t1.micro mysql 5 awsuser creating 1 **** n 5.5.27 general-public-license
SECGROUP cms-db active
PARAMGRP cms-db-mysql55 in-sync
OPTIONGROUP default:mysql-5-5 in-syncRDSインスタンスの状態は rds-describe-db-instances コマンドで確認することができます。"creating" が "available" になれば作成完了です。
$ rds-describe-db-instances cmsdb
DBINSTANCE cmsdb 2013-02-15T13:51:23.868Z db.t1.micro mysql 5 awsuser available cmsdb.c9cxowny4ezp.ap-northeast-1.rds.amazonaws.com 3306 ap-northeast-1c 0 n 5.5.27 general-public-license
SECGROUP cms-db active
PARAMGRP cms-db-mysql55 in-sync
OPTIONGROUP default:mysql-5-5 in-sync
（EC2上のDBデータをRDSに移行する）
EC2インスタンスにログインしてMySQLデータベースをバックアップ＆RDSにリストアします。作業内容自体は一般的なMySQLの操作と変わりません。
データインポート時に指定するユーザ名とパスワードはRDSインスタンス作成時に指定した--master-username / --master-user-password のことです。また接続先ホスト名は rds-describe-db-instances コマンドで表示される「エンドポイント」と呼ばれるホスト名を指定します。インポート先のデータベースはRDSインスタンス作成時に --db-name で指定したデータベース名になります。
$ mysqldump -uroot -pXXXXXXXX ablogcms > backup.sql $ mysql -uawsuser -pmypassword -h cmsdb.c9cxowny4ezp.ap-northeast-1.rds.amazonaws.com mydb < backup.sql
インポートが完了したらEC2上のablogの設定ファイルを修正して、接続先データベースを変更します。
また以降の作業で混乱しないようにEC2上のMySQLプロセスは止めてしまいましょう。
$ sudo service mysqld stop Stopping mysqld: [ OK ] $ sudo chkconfig mysqld off $ sudo chkconfig --list mysqld mysqld 0:off 1:off 2:off 3:off 4:off 5:off 6:off
スケールアウトできるようAMIを作成する
ablogが動いているEC2インスタンスからカスタムAMIを作成します。AMIを作成しておいて、EC2インスタンス作成時にこのAMIを指定することで同じ設定のサーバをいくつでも作成することができるようになります。
$ ec2-create-image --name cms-app-image -d "ablog custom AMI image" i-a35e75a0 IMAGE ami-dd9116dc $ ec2-describe-images IMAGE ami-dd9116dc 376158489050/cms-app-image 376158489050 available private x86_64 machine aki-44992845 ebs paravirtual xen BLOCKDEVICEMAPPING EBS /dev/sda1 snap-9ba164b8 8 true standard
Phase-3 異なるAZにEC2インスタンスを立ち上げELBで負荷分散する
カスタムAMIからEC2インスタンスを起動する
先程作ったカスタムAMIを指定してEC2インスタンスを新たに起動します。さらにここでは1つ目とは異なるアベイラビリティゾーンで起動しています。
（1つ目のEC2インスタンスがap-northeast-1bで作成されていたので、ここではap-northeast-1aを指定しています）
$ ec2-describe-availability-zones AVAILABILITYZONE ap-northeast-1a available ap-northeast-1 AVAILABILITYZONE ap-northeast-1b available ap-northeast-1 AVAILABILITYZONE ap-northeast-1c available ap-northeast-1 $ ec2-run-instances \ --group cms-app \ --instance-type t1.micro \ --instance-count 1 \ --key <key-pair-name> \ --availability-zone ap-northeast-1a \ ami-dd9116dc
ロードバランサーを作成する
ELB "cms-lb" を作成します。ロードバランシングされるEC2インスタンスがあるリージョンとアベイラビリティゾーンを明示的に指定する必要があります。
$ elb-create-lb cms-lb \ --listener "lb-port=80,instance-port=80,protocol=http" \ --availability-zones ap-northeast-1a,ap-northeast-1b \ --region ap-northeast-1 DNS_NAME cms-lb-XXXXXXXXX.ap-northeast-1.elb.amazonaws.com
ロードバランサーにインスタンスを関連づける
ここでもリージョンは明示的に指定する必要があります。
$ elb-register-instances-with-lb cms-lb --region ap-northeast-1 --instances i-a35e75a0, i-af2209ac INSTANCE_ID i-af2209ac INSTANCE_ID i-a35e75a0 $ elb-describe-instance-health cms-lb --region=ap-northeast-1 INSTANCE_ID i-a35e75a0 InService N/A N/A INSTANCE_ID i-af2209ac InService N/A N/A
ロードバランサが作成できたら、ロードバランサ経由でEC2インスタンスにアクセスしてみます。
http://cms-lb-XXXXXXXXX.ap-northeast-1.elb.amazonaws.com/
試しに片方のapacheを停止させてみましょう。ヘルスチェックで一方がOutOfServiceになっていても、ablogは表示されていればOK。
（一方のablogが動いているEC2インスタンスにsshでログインする） $ sudo service httpd stop Stopping httpd: [ OK ] （次に作業用インスタンスからヘルスチェックを行う → どちらかがOutOfServiceになっているはず） $ elb-describe-instance-health cms-lb --region=ap-northeast-1 INSTANCE_ID i-a35e75a0 OutOfService Instance has failed at least the UnhealthyThreshold number of health checks consecutively. Instance INSTANCE_ID i-af2209ac InService N/A N/A
後始末
ELBやRDSはそのままにしておくと時間で課金されるので実験が終わったら削除しておくのを忘れないでください。
ELBの削除
$ elb-delete-lb cms-lb --region ap-northeast-1
Warning: Deleting a LoadBalancer can lead to service disruption to any
customers connected to the LoadBalancer. Are you sure you want to delete
this LoadBalancer? [Ny]y
OK-Deleting LoadBalancer
EC2とEIPの削除
$ ec2-disassociate-address 54.249.238.6 ADDRESS 54.249.238.6 $ ec2-release-address 54.249.238.6 ADDRESS 54.249.238.6 $ ec2-terminate-instances i-a35e75a0 INSTANCE i-a35e75a0 running shutting-down $ ec2-terminate-instances i-af2209ac INSTANCE i-af2209ac running shutting-down
AMI、スナップショットの削除
AMIを作成する際には自動でスナップショットも作成されているので、AMIだけでなくスナップショットも削除します。
AMIを削除します。
$ ec2-deregister ami-dd9116dc IMAGE ami-dd9116dc
スナップショットを削除します。
$ ec2-describe-snapshots SNAPSHOT snap-9ba164b8 vol-be05909c completed 2013-02-15T14:32:10+0000 100% 376158489050 8 Created by CreateImage(i-a35e75a0) for ami-dd9116dc from vol-be05909c $ ec2-delete-snapshot snap-9ba164b8 SNAPSHOT snap-9ba164b8
RDSの削除
DBインスタンスの削除処理には時間がかかるので、rds-delete-db-instance後すぐにはパラメータグループを削除できません。
DBセキュリティグループ(cms-db)でEC2セキュリティグループ(cms-app)を参照しているので、先にcms-dbを削除してからcms-appを削除してください。
$ rds-delete-db-instance cmsdb -f --skip-final-snapshot
DBINSTANCE cmsdb 2013-02-05T13:33:24.196Z db.t1.micro mysql 5 awsuser deleting cmsdb.c9cxowny4ezp.ap-northeast-1.rds.amazonaws.com 3306 ap-northeast-1a 1 n 5.5.27 general-public-license
SECGROUP cms-db active
PARAMGRP cms-db-mysql55 in-sync
（RDSインスタンスが削除されるまでしばらく時間がかかります）
$ rds-delete-db-parameter-group cms-db-mysql55 -f
$ rds-delete-db-security-group cms-db -f
$ ec2-delete-group cms-app
RETURN true
EC2へのログインアカウントの制約にみる今後のサーバ運用の自動化の流れについて
最初に結論
- AWS EC2インスタンスでは複数アカウントによるログインが行いにくくなっている
- 人による作業は環境に差異が発生しやすくなるから
- Capistrano,Chef,CloudFormation,OpsWorksなどを使って自動化しましょう
はじめに
いつもは普段使っているパソコンでEC2のインスタンスにsshでログインしていろいろと作業をしていたのですが、ある日事情により人のパソコンを借りて作業の続きをすることがありました。ところがいざログインしようとした時、認証につかう秘密鍵ファイル(*.pem)が手元にないためログインできないことに気付きました。pemファイルの再ダウンロードはできないので別の秘密鍵を作成してインスタンスを作り直す必要がありました。
ちょっと出先で作業したい、といった場合の備えどうしておけばいいのでしょうか?
これまでのUnixサーバ運用的な考えでは
どこでも作業ができるようにするためには以下いずれかの対策が思いつきます。
1つ目の案は簡単で1人でやるには十分なのです。が、企業での利用など複数のサーバ管理者がいる場合にはすべての人で秘密鍵を共有するのでしょうか? セキュリティの問題からちょっと考えにくいですね。ならば2でいうアカウント管理を独自に管理していこう、となればいいのでしょうが、EC2インスタンスが10台とか100台規模になってきた場合に管理が大変になります。
これまでUnixを管理してきた人ならNISを利用したアカウントの一元管理を思いつくでしょう。ところがAWSではNISサービスを提供していないようです。なぜでしょう? EC2で独自NISサーバを構築すればいいのでしょうか?
AWSの機能不足と考えることもできますが、すでに多くのユーザに利用されているサービスです、ここは需要がないからととらえるのが妥当でしょう。つまりEC2に複数アカウントがなくても困らない運用する、これまでのUnix管理の常識にとらわれない、AWSの富豪的サーバ利用にあったやり方に考え方を変えてみる必要がある、と捉えてみることにしましょう。
補足
ちなみに当初IAM(Identity and Account Management)を使ってユーザ・グループを作成すればEC2サーバへのログインが管理できるのではないかと思い調べたのですが、IAMのFAQに書いてある通りできないそうです。
AWS Identity and Access Management FAQs
Q: ユーザーは、AWS ユーザー名およびパスワードを使用して、EC2 インスタンスに SSH で接続できますか？
いいえ。IAM で作成されたユーザーのセキュリティ証明書は、EC2 のお客様のインスタンスには反映されません。お客様の EC2 インスタンスの認証は、お客様の責任下にあります。
AWSによるこれからサーバ運用
そもそもなぜログインが必要かというとサーバ上での作業が必要だからです。パッケージのインストールや設定ファイルの変更、アプリケーションのデプロイなどがこれにあたりますが、いままでこれらは人手による作業でした。
サービスが大きくなり負荷をさばくために、EC2インスタンスを増やしてスケールアウトさせる方式を採用したとしましょう。このとき重要なのは「各サーバが同じ設定であること」です。あるサーバで動くアプリが環境の違いのため別のサーバで動かず、苦労をしたという経験を、開発者なら何度かあるのではないでしょうか? サーバごとに微妙に設定が違ってしまうのは、人手で作業をしているため、サーバごとに設定漏れが発生してしまうためです。
それならばいっそsshによるログインを制限してはどうでしょう?というのがAWSでのアプローチだと思われます。人手でサーバ設定する機会を減らすことで、スケールアウト時に発生しうる問題を排除するわけです。
手作業による設定やデプロイをする代わりに、最近ではCapistranoやChefといったソフトを使い、これらの作業を自動化する流れが主流になりつつあります。EC2インスタンスを作成した後は、事前に決めた設定に従って自動的にサーバ環境を構築することで、サーバ間の差異がなくなるわけです。
AWSではCloudFormationというAWSの各種サービスと設定を組み合わせたテンプレートを作成できるインフラ構築サービスや、OpsWorksというアプリケーションデプロイのテンプレートサービスも提供しています。AWSを利用することを前提とした今後の運用方法は以下のような流れになるのでしょう。
- 試験的なソフト導入や設定修正は個々人ごとにEC2インスタンスを作成してそこで行う
- 設定が決まったらChefのレシピに反映する
- スケールアウト時にはChefを実行することでサーバに設定を適用する
以上、これからはサーバ運用についても人手から自動化へ考えを変えていく必要があるね、というお話でした。
補足
環境構築の自動化はなにもAWSを利用するときしかメリットがないわけではなありません。アプリケーション開発時には本番環境とは別に、開発環境や本番導入前の検証環境をもっている場合があると思います。もしかしたら仮想化技術を使って個人ごとに開発環境をもっているかもしれません。これら複数の環境を本番環境と一緒にする際にも環境構築の自動化ツールは有用だと思われます。
AMI (Amazon Machine Images) のVectorみたいなサービスについて
Amazon Web Service で提供されている仮想マシンサービスであるEC2(Elastic Compute Cloud)では、Amazon Machine Imagesという仮想マシンイメージの配布を行っています。
EC2で構築した環境をディスクイメージとして保存してAMIとして公開することが誰でもできて、その環境を使いたい人は公開されたAMIを選んで仮想マシンを作成し動かすことができる、というものです。
環境構築が難しいシステムをインストール・設定済みのものをAMIとして公開してくれている方が増えてきています。
AWSコンソールという管理画面からAMIを検索することができますが、現在のところお世辞にも使いやすい画面ではないし、検索に一致したAMIがどういう用途でなにが設定されたイメージなのかも分かりにくいです。(一応 Descriptionという説明欄はあるけど、すべてのAMIで記入されているわけではないし、一行コメントなので詳細まではわかりません)
現在は自分が設定した環境をAMIとして公開し、Twitterなどで「作ってみたから使ってみてね」とAMI IDを広めている状況のようです。
いずれはVectorや窓の杜のようにオススメAMIとか人気AMIとかがカテゴリ別にまとまってたりランキング形式で紹介されたりして、活発にAMIのやりとりがされるようになるのかなぁ、とそんなことを考えました。
そうなるとシステム構築を生業している企業は仕事がなくなっちゃうかもしれませんね・・・
2013-03-02 17:18 追記
Amazon Market PlaceのページではOS別や用途別の検索ができることを知りました。各EC2インスタンスごとの利用料金もみることができます（アプリ使用量+EC2使用量でもBIツールが月3000円から試せるとか（安い!）。現在英語ページだけですが日本（Tokyoリージョン）でも独自AMIが活発にやりとりされるようになるのが楽しみですね。
