RailsアプリケーションをElastic Beanstalkにデプロイする
前回の記事で簡単なRailsアプリケーションのサンプルを作成しました。
今回はこのサンプルをElastic Beanstalkにデプロイしてみたいと思います。デプロイに必要となるコマンドラインツールなど、環境構築手順は前回の記事に書いてありますので、そちらを参照して下さい。
EB CLIの設定
作成したプロジェクトリポジトリでeb initコマンドを実行して環境設定を行います。
$ cd ~/repos/mimawarigumi $ eb init Select a default region 1) us-east-1 : US East (N. Virginia) 2) us-west-1 : US West (N. California) 3) us-west-2 : US West (Oregon) 4) eu-west-1 : EU (Ireland) 5) eu-central-1 : EU (Frankfurt) 6) ap-southeast-1 : Asia Pacific (Singapore) 7) ap-southeast-2 : Asia Pacific (Sydney) 8) ap-northeast-1 : Asia Pacific (Tokyo) 9) sa-east-1 : South America (Sao Paulo) (default is 3): 1 Enter Application Name (default is "mimawarigumi"): Application mimawarigumi has been created. It appears you are using Ruby. Is this correct? (y/n): y Select a platform version. 1) Ruby 2.2 (Puma) 2) Ruby 2.2 (Passenger Standalone) 3) Ruby 2.1 (Puma) 4) Ruby 2.1 (Passenger Standalone) 5) Ruby 2.0 (Puma) 6) Ruby 2.0 (Passenger Standalone) 7) Ruby 1.9.3 (default is 1): 1 Do you want to set up SSH for your instances? (y/n): n
環境設定が完了すると、以下のように.gitignoreが更新されており、.elasticbeanstalk/configが作成されています。
変更点は忘れずにコミットしておいて下さい。
$ git diff diff --git a/.gitignore b/.gitignore index cd84d08..a90ebee 100644 --- a/.gitignore +++ b/.gitignore @@ -26,3 +26,8 @@ # Ignore dotenv /.env + +# Elastic Beanstalk Files +.elasticbeanstalk/* +!.elasticbeanstalk/*.cfg.yml +!.elasticbeanstalk/*.global.yml $ ls .elasticbeanstalk/ config.yml $ git add .gitignore $ git commit -m "Elastic Beanstalkの設定ファイルを除外するようにした"
AWS Management Consoleでは、以下のようにApplicationが作成されています。
環境作成とアプリケーションのデプロイ
環境作成とデプロイをしていきます。eb createコマンドでタイムアウトしてしまう場合は--timeoutオプションを使ってみて下さい（タイムアウトしても環境作成とデプロイが失敗するわけではありません）。
$ eb create --database --database.engine postgres Enter Environment Name (default is mimawarigumi-dev): mimawarigumi-env Enter DNS CNAME prefix (default is mimawarigumi-env): Enter an RDS DB username (default is "ebroot"): mimawarigumi Enter an RDS DB master password: Retype password to confirm: WARNING: Deploying a previously deployed commit. Environment details for: mimawarigumi-env Application name: mimawarigumi Region: us-east-1 Deployed Version: a265 Environment ID: e-zhkdupp9c6 Platform: 64bit Amazon Linux 2015.03 v1.4.3 running Ruby 2.2 (Puma) Tier: WebServer-Standard CNAME: mimawarigumi-env.elasticbeanstalk.com Updated: 2015-07-15 00:11:00.587000+00:00 Printing Status: INFO: createEnvironment is starting. （略） --- $ eb setenv SECRET_KEY_BASE=`bundle exec rake secret`
Management Consoleでは以下のようになっています。
動作確認
Management Consoleに書かれているリンクにアクセスするとWebページが表示されます。
環境の削除
環境を削除する場合は以下のコマンドを実行します。
$ eb terminate
あとがき
前回作成したRailsアプリをElastic Beanstalkにデプロイしました。
その他の設定をしたい場合は別途ebコマンドを使ってやって下さい。これをCodePipelineとかと連携出来るのかな？
参考
- http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/create_deploy_Ruby_rails.html
- http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/create_deploy_Ruby.rds.html#create_deploy_Ruby.rds.newDB
- create - Elastic Beanstalk
- EB CLI 3.x を使って Elastic Beanstalk に Rails アプリをデプロイする - xykのブログ
- ElasticBeanstalkでらくらくRails環境構築 - Qiita
- Rails 4.2 を PostgreSQL を使って Elastic Beanstalk にセットアップする (2) | FIVETEESIXONE
CentOS7にRailsプロジェクトを作成するまで
たまに簡単なAWSサービスの動作確認とかで、簡単なRailsアプリケーションの開発環境を作るまでの手順がブログにまとまってると（個人的に）便利だなと思うことがあるので、今回はそんな環境を構築する手順を書きます。
パッケージは執筆時点でのバージョンなので、適宜アップデートして下さい。
使用したAMI
CentOS 7 x86_64 (2014_09_29) EBS HVM-b7ee8a69-ee97-4a49-9e68-afaee216db2e-ami-d2a117ba.2 (ami-89634988)
※起動時にIAMロールもセットしています。
基本設定
まず最初に自分自身のユーザーを作成や時間の設定をします。EC2インスタンス起動直後に接続するユーザーはcentosです。
$ sudo -i # useradd okochang # passwd okochang # visudo -f /etc/sudoers.d/okochang # sudo cat /etc/sudoers.d/okochang # User rules for okochang okochang ALL=(ALL) NOPASSWD:ALL # timedatectl set-timezone Asia/Tokyo # sed -i -e "s/^ - update_hostname/# - update_hostname/g" /etc/cloud/cloud.cfg # echo 'rails.okochang.com' > /etc/hostname
作成したユーザーに手元の環境から接続するためのSSH公開鍵をセットしたり、今後使うためにSSHキーペアを作成します。
$ su - okochang $ mkdir -m 700 .ssh $ echo 'ssh-rsa your-ssh-key-tesxt-data' .ssh/authorized_keys $ chmod 600 .ssh/authorized_keys $ ssh-keygen -C rails.okochang.com $ sudo reboot
SELinuxごめんなさい
$ sudo sed -i -e "s/^SELINUX=enforcing/SELINUX=disabled/g" /etc/selinux/config $ sudo reboot
必要なパッケージのインストール
Railsの環境を構築するために必要なパッケージのインストールと、AWSのコマンドラインツールをインストールしておきます。
$ sudo yum update -y $ sudo yum install -y git emacs gcc make zlib-devel libxml2-devel libxslt-devel readline-devel openssl-devel gcc-c++ curl-devel ruby-devel vim wget epel-release bzip2 bind-utils nodejs $ sudo reboot
$ sudo easy_install pip $ sudo pip install awscli $ sudo pip install awsebcli
Git
ソースコードの管理にGitを使うので、このへんも設定しておきます。
$ git config --global user.email "okochang@example.com" $ git config --global user.name "okochang"
Ruby
rbenvを使って、現時点最新の安定版であるRuby 2.2.2をインストールします。
$ git clone https://github.com/sstephenson/rbenv.git ~/.rbenv $ git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build $ cd .rbenv/plugins/ruby-build/ $ sudo ./install.sh $ cd $ echo 'export PATH=$HOME/.rbenv/bin:$PATH' >> .bashrc $ echo 'eval "$(rbenv init -)"' >> .bashrc $ exec $SHELL -l $ rbenv install --list $ rbenv install 2.2.2 $ rbenv global 2.2.2
gems
サンプルプロジェクトではBundlerを使ってgemパッケージを管理しますので、インストールします。
$ gem install rbenv-rehash $ rbenv rehash $ gem install bundler
PostgresQL
サンプルプロジェクトでデータベースは使う予定はありませんが、PostgreSQLを使えるようにしてます。プロジェクト名をmimawarigumiにする予定なので、ユーザー名に指定しています。
$ sudo yum install -y postgresql postgresql-server postgresql-libs postgresql-contrib postgresql-devel $ sudo su - postgres $ initdb --encoding=UTF-8 --locale=ja_JP.UTF-8 $ exit $ sudo systemctl start postgresql $ sudo systemctl enable postgresql $ sudo su - postgres $ createuser -a -d -P mimawarigumi $ exit
サンプル用のRailsプロジェクト作成
プロジェクト用のディレクトリを作成して、railsコマンドでプロジェクトを初期化します。
初期化したら、現時点の内容をコミットします。以降の作業は適宜コミットしていくものとします。
$ mkdir -p repos/mimawarigumi $ cd repos/mimawarigumi $ bundle init $ sed -i -e 's/# gem "rails"/gem "rails"/g' Gemfile $ bundle config build.nokogiri --use-system-libraries $ bundle install --path vendor/bundle $ bundle exec rails new . -d postgresql --skip-test-unit $ bundle exec rake db:migrate cat << EOF >> .gitignore # Ignore ruby version configuration. /.ruby-version # Ingonre bundled contents. /vendor/bundle # Ignore sass cache .sass-cache # Ignore dotenv /.env EOF $ git add . $ git commit -m "initial commit"
静的ページの作成
静的ページの作成をしていきます。最初にGemfileにrspecとcapybaraを追加してインストールしておきました。具体的な変更内容はこちらを見て下さい。
$ vim Gemfile $ bundle install --path vendor/bundle $ bundle exec rails generate controller StaticPages home --no-test-framework $ bundle exec rails generate rspec:install $ bundle exec rails generate integration_test static_pages $ vim app/views/static_pages/home.html.erb $ vim spec/rails_helper.rb $ vim app/views/static_pages/home.html.erb $ vim config/routes.rb $ vim config/database.yml
AWS CodeCommitのリポジトリにSSHでアクセスする
前回のブログでAWS CodeCommitを触ってみました。その時作成しGitたリポジトリへはHTTPSを使ってアクセスしましたが、今回はSSHを使ったやり方をまとめます。
ドキュメントにはリポジトリのサイズが大きい場合はHTTPSでなくSSHの使用を検討しましょうって書いてますね。
SSHキーの操作をするIAMポリシーを作成＆割り当てる
AWS Management ConsoleでIAMにアクセスし、左メニューからPoliciesを選択します。
ポリシーテンプレートの中からIAMUserSSHKeysを選択し、Attachを選択します。
アタッチしたいユーザーをチェックして、Attach Policyをクリックします（IAMユーザーは事前に作成しておいて下さい）。
IAMユーザーにSSH公開鍵を割り当てる
IAMユーザーにSSH公開鍵を割り当てます。左メニューからUsersを選択します。
割り当てたいユーザーをクリックします。
設定画面のSSH keys for AWS CodeCommitにあるUpload SSH Keyをクリックします。
使いたいSSH公開鍵のテキストデータをペーストしてUpload SSH Keyをクリックします。
※SSHの公開鍵と秘密鍵のペアは事前に作成しておいて下さい。
ローカルコンピュータのSSH設定
CodeCommitにSSHアクセスする場合の設定をします。SSH公開鍵をアップロードするとSSH Key IDが付与されます。
CodeCommitのホスト名、付与されたSSH Key ID、秘密鍵のパス、を以下のように設定します。
$ vim .ssh/config
Host git-codecommit.*.amazonaws.com
User APKAI2EI6HC4N47QBQ3Q
IdentityFile ~/.ssh/your-ssh-private-key.pem設定ファイルの権限設定を忘れずにしておいてください。
$ chmod 600 .ssh/config
動作確認
以下のようにSSHで前回のGitリポジトリを手元にCloneできました。
$ git clone ssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/SampleRepository
必要に応じて、リモートリポジトリの設定を追加します。
$ git remote add ssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/SampleRepository
AWS CodeCommitを触ってみた
久しぶりのブログとなってしまいました。
AWS Summits 2015 | New YorkでAWSからいくつかの新サービスがリリースされたようです。新しいサービスはひと通り触ってみたいなと思っておりまして、まずはお手軽に始められそうなAWS CodeCommitから手を付けてみましたのでログを残しておきます。
CodeCommitは、2014年のAWS re:Inventで発表されてから何となくこんなサービスだろうとイメージはしていたものの、理解するには触ってみるのが一番です。
gitの設定
次にgitの設定をします。
以下はaws configureコマンドで認証情報のdefaultを設定している場合の例ですが、--profileオプションを使うことも出来ます。
また、特定のディレクトリ以下のみに指定する場合は--localオプションを使用し、gitのデフォルト設定にする場合は--globalオプションを使用して下さい。
$ cd development-repo/ $ git config --local credential.helper '!aws codecommit credential-helper $@' $ git config --local credential.UseHttpPath true
CodeCommitをGitのリポジトリとして登録する
CodeCommitのダッシュボードからリポジトリを選択します。
リポジトリの詳細画面からHTTPSのアクセス先をコピーしておきます。
以下のようにリモートリポジトリを追加してPushします。
$ git remote add codecommit https://git-codecommit.us-east-1.amazonaws.com/v1/repos/SampleRepository $ git push codecommit master
退職しませんでした
こんにちは＠oko_changです。
昨日は私の誕生日だったのですが、たくさんのお祝いのコメントを頂き本当にありがとうございます！
毎年この時期はTwitterなどで退職しましたブログや入社しましたブログなどが賑わいます。
そんな私も最近までこっそり転職活動をしていたのですが、最終的に退職しないという決断をしました。
当初転職活動を始めたのは、今までと違った形でインフラエンジニアとして働いてみたいなと思った事がきっかけとなり、この点を転職先に求めていました。
その後、3月中旬くらいに別チーム（サービス開発をしているチーム）の同僚と送別会がてら飲んでるときに、彼のチームで働くというお誘いを受けました。
この提案は考えもしませんでしたし、私がもともと想像していたプランとは少し違いしましたが、自分にとっては良い経験になりそうだし、面白いチャレンジに思えたので、退職しないことを選びました。
退職しないという決断が正しいのかはまだ分かりませんが、この決断を正しくすることは自分にかかっていると思うので、これからしっかり正しい決断に育てていきたいと思います。
転職活動を始めてから、勉強会やコミュニティで知り合った方からのアドバイスを頂いたりしたのは大きな助けとなりました。
また、実際に転職先として考えていた企業で働くエンジニアの方にお話を頂く機会もあり、とても刺激を受けました。
退職の意思を伝えたときに応援してくれた方、引き留めてくれた方、ありがとうございます。
直接お礼をさせていただきたい方がいっぱいいますが、まずはこの場を借りてお礼をさせて頂きます。
これからもよろしくお願いします。
ELBのConnection Drainingの動作をテストする
こんにちは＠oko_changです。
先日、ELBののConnection Draining機能がリリースされました。
Connection Drainingの機能については、こちらのブログに参考にして、動作テストはこちらのブログに記載されているように大きなダミーファイルを使えば良さそうです。
環境
リリースノートを見るとAWS CLIはConnection Drainingに対応しているようです。
1.3.2より前のバージョンをご使用の方はsudo pip install --upgrade awscliをして下さい。
テスト環境の作成
まず最初にテスト用のELBを作成します。
$ aws elb create-load-balancer \ --load-balancer-name okochang-elb \ --listeners Protocol=http,LoadBalancerPort=80,InstanceProtocol=http,InstancePort=80 \ --subnets subnet-28f4fd4a \ --security-groups sg-d1e3fcbd \ --region ap-northeast-1 $ aws elb configure-health-check \ --load-balancer-name okochang-elb \ --health-check Target="HTTP:80/index.html",Interval=30,Timeout=15,UnhealthyThreshold=5,HealthyThreshold=5 \ --region ap-northeast-1
次にテスト用EC2インスタンスを作成し、ELBの分散対象に加えます。
$ aws ec2 run-instances \ --image-id ami-b5c0b1b4 \ --security-group-ids sg-b72d31db \ --instance-type t1.micro \ --subnet-id subnet-28f4fd4a \ --private-ip-address 10.0.10.10 \ --key-name okochang-key \ --associate-public-ip-addres \ --region ap-northeast-1 $ aws elb register-instances-with-load-balancer \ --load-balancer-name okochang-elb \ --instances i-3a1f443d \ --region ap-northeast-1
テスト用EC2インスタンスにはWebサーバを構築して、ダミーファイルを作成しておきます。
# dd if=/dev/zero of=tempfile bs=10M count=50
動作確認
Connection Draining有効時
ELBは現在、作成するとデフォルトでConnection Drainingが有効になっています。
先ほどのリリースノートにあるとおりConnection Drainingには対応されているはずですが、describe-load-balancer-attributesを実行してもレスポンスは返ってきませんでした。
$ aws elb describe-load-balancer-attributes --load-balancer-name okochang-elb --region ap-northeast-1
{
"LoadBalancerAttributes": {
"CrossZoneLoadBalancing": {
"Enabled": false
},
"AccessLog": {
"Enabled": false
}
}
}というわけで以下はElastic Load Balancing API Toolsを使って動作確認をしています。
先ほど作成したELBのConnection Drainingが有効になっている事が確認出来ます。
$ elb-describe-lb-attributes okochang-elb --region ap-northeast-1 --headers CROSS_ZONE_LOADBALANCING CROSSZONE_LOADBALANCING_ENABLED CROSS_ZONE_LOADBALANCING false ACCESS_LOG ACCESSLOG_ENABLED ACCESS_LOG false CONNECTION_DRAINING CONNECTION_DRAINING_ENABLED CONNECTION_DRAINING_TIMEOUT CONNECTION_DRAINING false 300
以下のようにすると秒数を変更したりできます。
$ elb-modify-lb-attributes okochang-elb --connection-draining "enabled=true, timeout=1800" --region ap-northeast-1 --headers CONNECTION_DRAINING CONNECTION_DRAINING_ENABLED CONNECTION_DRAINING_TIMEOUT CONNECTION_DRAINING true 1800
それではテスト用のダミーファイルをダウンロードします。
$ curl -OL http://okochang-elb-625610288.ap-northeast-1.elb.amazonaws.com/tempfile
ダウンロード途中に以下のようにELBからインスタンスを外してみます。
$ elb-deregister-instances-from-lb okochang-elb --instances i-3a1f443d --region ap-northeast-1 --headers
elb-describe-instance-healthを実行してみると、STATEがInServiceで、DESCRIPTIONがInstance deregistration currently in progress.となっており、ELBから指定された秒数外れるのを待っている状態である事が分かります。
$ elb-describe-instance-health okochang-elb INSTANCE_ID INSTANCE_ID STATE DESCRIPTION REASON-CODE INSTANCE_ID i-3a1f443d InService Instance deregistration currently in progress. N/A
その後、きちんとダウンロードも無事に完了しました。
$ curl -OL http://okochang-elb-625610288.ap-northeast-1.elb.amazonaws.com/tempfile
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 500M 100 500M 0 0 2640k 0 0:03:13 0:03:13 --:--:-- 2974k
Connection Draining無効時
次はConnection Drainingを無効にしてテストします。
$ elb-modify-lb-attributes okochang-elb --connection-draining "enabled=false" --region ap-northeast-1 --headers CONNECTION_DRAINING CONNECTION_DRAINING_ENABLED CONNECTION_DRAINING_TIMEOUT CONNECTION_DRAINING false 300
以下のようにしっかりと無効になってる事を確認しておきます。
$ elb-describe-lb-attributes okochang-elb --region ap-northeast-1 --headers CROSS_ZONE_LOADBALANCING CROSSZONE_LOADBALANCING_ENABLED CROSS_ZONE_LOADBALANCING false ACCESS_LOG ACCESSLOG_ENABLED ACCESS_LOG false CONNECTION_DRAINING CONNECTION_DRAINING_ENABLED CONNECTION_DRAINING_TIMEOUT CONNECTION_DRAINING false 1800
先ほど外したインスタンスをELBに戻しておきます。
$ elb-register-instances-with-lb okochang-elb --instances i-3a1f443d --region ap-northeast-1 --headers INSTANCE_ID INSTANCE_ID INSTANCE_ID i-3a1f443d
再度テスト用のダミーファイルをダウンロードします。
$ curl -OL http://okochang-elb-625610288.ap-northeast-1.elb.amazonaws.com/tempfile
先ほどと同様にインスタンスをELBから外します。
$ elb-deregister-instances-from-lb okochang-elb --instances i-3a1f443d --region ap-northeast-1 --headers No instances currently registered to LoadBalancer
今度はすぐにELBから外れました。
$ elb-describe-instance-health okochang-elb No instances currently registered to LoadBalancer
Connection Drainingを無効時はダウンロードが失敗しました。
$ curl -OL http://okochang-elb-625610288.ap-northeast-1.elb.amazonaws.com/tempfile
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
67 500M 67 337M 0 0 2739k 0 0:03:06 0:02:06 0:01:00 2821k
curl: (18) transfer closed with 170663064 bytes remaining to read
まとめ
無事に期待する動作を確認出来ました。
ELB配下のインスタンスをメンテナンスするときなど、運用時に助かる機能なので重宝しますね。
どうやらすでに作成されているELBはConnection Drainingは無効になってるみたいなのでタイミングを見て有効にしておきたいですね。
その後
AWS CLIでConnection Drainingが使えないなーと悩んでいたら＠j3tm0t0さんから以下のようにアドバイス頂きました。
@oko_chang --debug するとレスポンスにはちゃんと返ってるようですね。このあたりに足してあげると出ると思われます。 https://t.co/r9FeLqtOjv
— moto (@j3tm0t0) 2014, 3月 23@oko_chang https://t.co/iRmOcu3aEN を site-packages/botocore/data/aws/elb/ に置いたら、出るようになると思います。
— moto (@j3tm0t0) 2014, 3月 23debugオプションをつけてレスポンスが返ってくることと、その後Connection Drainingの情報が取得出来ました！
＠j3tm0t0さんありがとうとうございます！
$ aws elb describe-load-balancer-attributes --load-balancer-name okochang-elb --region ap-northeast-1
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": false,
"Timeout": 1800
},
"CrossZoneLoadBalancing": {
"Enabled": false
},
"AccessLog": {
"Enabled": false
}
}
}
参考リンク
- http://aws.typepad.com/aws_japan/2014/03/elb-connection-draining-remove-instances-from-service-with-care.html
- http://aws.amazon.com/jp/about-aws/whats-new/2014/03/20/elastic-load-balancing-supports-connection-draining/
- http://dev.classmethod.jp/cloud/aws/elb-connection-draining/
- http://aws.amazon.com/releasenotes/CLI/8669233270940230
- http://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancer-attributes.html
- http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/config-conn-drain.html
- https://github.com/aws/aws-cli/blob/develop/CHANGELOG.rst
- http://aws.amazon.com/developertools/Amazon-EC2/2536
- http://docs.aws.amazon.com/ElasticLoadBalancing/latest/APIReference/API_LoadBalancerAttributes.html
VPC内のELBが使用しているローカルIPアドレスをEC2インスタンス起動時に指定してみる実験
こんにちは＠oko_changです。
VPC内でELBを使用する場合、ELBは指定されたサブネット内のローカルIPアドレスを使用します。
なんとなく気になったので、ELBがローカルIPアドレスを使用した後にそのアドレスを指定してEC2インスタンスを起動した場合の動作を確認してみました。
確認手順
※VPCとVPCサブネットは事前に作成しておきます。
まず最初に、VPC内でELBを作成します。
$ aws elb create-load-balancer \ --load-balancer-name okochang-elb \ --listeners Protocol=http,LoadBalancerPort=80,InstanceProtocol=http,InstancePort=80 \ --subnets subnet-28f4fd4a \ --security-groups sg-d1e3fcbd \ --region ap-northeast-1
ELBのヘルスチェックを設定します。
$ aws elb configure-health-check \ --load-balancer-name okochang-elb \ --health-check Target="HTTP:80/index.html",Interval=30,Timeout=15,UnhealthyThreshold=5,HealthyThreshold=5
負荷分散対象のEC2インスタンスを起動します。
$ aws ec2 run-instances \ --image-id ami-b5c0b1b4 \ --security-group-ids sg-b72d31db \ --instance-type t1.micro \ --subnet-id subnet-28f4fd4a \ --private-ip-address 10.0.10.10 \ --key-name okochang-key \ --associate-public-ip-addres
ELBに起動したEC2インスタンスを分散対象として設定します。
$ aws elb register-instances-with-load-balancer \ --load-balancer-name okochang-elb \ --instances i-3ebce539
負荷分散対象のEC2インスタンスにWebサーバをインストールし、ELB（10.0.10.17）からアクセスされていることを確認します。
# yum install httpd -y # vi /etc/httpd/conf/httpd.conf # echo "Hello World" > /var/www/html/index.html # httpd -t # chkconfig httpd on # service httpd start # tail -f /var/log/httpd/access_log 2014-03-21 23:31:46 JST 340 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0] 2014-03-21 23:32:16 JST 348 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0] 2014-03-21 23:32:46 JST 340 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0] 2014-03-21 23:33:16 JST 338 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0] 2014-03-21 23:33:46 JST 326 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0] 2014-03-21 23:34:16 JST 352 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0] 2014-03-21 23:34:46 JST 324 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0] 2014-03-21 23:35:16 JST 338 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0] 2014-03-21 23:35:46 JST 322 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0] 2014-03-21 23:36:16 JST 350 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0]
ELBが使用しているIPアドレスと同じIPを指定して起動します。
やはりIPアドレスが使用中になって起動出来ませんね。
$ aws ec2 run-instances \ --image-id ami-b5c0b1b4 \ --security-group-ids sg-b72d31db \ --instance-type t1.micro \ --subnet-id subnet-28f4fd4a \ --private-ip-address 10.0.10.17 \ --key-name okochang-key \ --associate-public-ip-addres A client error (InvalidIPAddress.InUse) occurred when calling the RunInstances operation: Address 10.0.10.17 is in use.
ちなみにELBが使用しているネットワークインターフェースの情報も以下のようにdescribe-network-intaerfacesで確認する事が出来ます。
$ aws ec2 describe-network-interfaces --filters Name=description,Values="ELB okochang-elb"
