AWS CloudFormationで環境構築

AWSでもコードで自動構築したいぞということで、CloudFormationのお話です。

今回のポイント

• 初期構築のときだけ、CloudFormationを使って設定。その後の変更は手で行う
• 変更されるリソースの種類やプロパティによっては、リソースの再作成が行われる。予想外の再作成が行われると最悪サービスがダウンしてしまう。（例えば、ELBでロードバランサが再作成されてしまうと、エンドポイントが変更されてしまう。）
• 必要なリソースを単一のテンプレートに書くのではなく、スタックは分割して書

下記の例ではEC2インスタンスの定義の際に、自動的にパッケージをインストールしたいなど何らかの処理を行う場合です。

"MyEc2Instance"  : {

    "Properties"   :  {

      "UserData"  :  {

            "Fn::Base64"  :  {

                "Fn:: Join"   :  {

                      "" ,

                      [

                                "#!/bin/bash\n"  ,

                                "yum  update    -y\n"

                      ] 

                }

              }

       }

 }

またLAMP環境を同じように設定することも可能です。

同様に、OpsWorksによって、運用上のオペレーションも自動化できます。

OpsWorksはシステムの環境情報を各インスタンスで共有し、Chefのレシピの配布と適用を行います。

Mysqlサーバのレイヤを追加

       db-masterレイヤはMysqlサーバの構成管理と、スタック内でのMysqlエンドポイント決定に利用されます。

$  aws  opsworks  create-layer  \

    --stack-id  6e4ea0c1-102b-400b-xxx

    --type  db-master   --name  db-master

    --shortname  db-master

{   "LayerId" :  "043fa815-577c-425b-8b6f-xxxx" }

設定の記述は割愛しますが、その後、Appレイヤを作成し、インスタンスの起動をします。

インスタンスにログインすると、設定が正常に済んでいれば、ユーザ名@ec2パブリックホスト名でインスタンスにログインできます。

デプロイするアプリケーションを登録

$  aws  opsworks  create-app  \

    --stack-id   6e4ea0c1-xxxx-xxxxx

    --name  rails_sample  --type  rails   \

    --app-source   Type=git, Url=http://github.com/higanworks〜   \

    --attributes  "RailsEnv=production"

{   "AppId"  :  "b4282cb9-d0fb-4300-xxxx-xxxx"   }

アプリケーションの登録や変更ではライフサイクルイベントは発生しません。新規のアプリケーションを登録した場合は、すでにConfigureイベントが完了し、イベントに対応するレシピが一度適用されているインスタンスにも構成情報の変更を反映する必要があります。