CloudInitを使ってアプリケーションの自動デプロイを構成してみる(たたき台)

AWS運用自動化サービス「Cloud Automator」
この記事は1年以上前に書かれたものです。
内容が古い可能性がありますのでご注意ください。

         

こんにちはAWSチームの柳瀬です。
先日cloudinitの簡単な使い方を書いたので、今度はAuto Scalingと組み合わせて使ってみたいと思います。
Auto Scalingはとても便利なサービスですが、実際に使う場合は以下のような課題が出てきます。

課題

  • Auto Scaling構成後にアプリケーションをリリースすると、launch-configに登録したAMIのソースコードが古くなる
  • 新しいアプリケーションをリリースする度にAMI作りなおすのマンドクセ(‘A`)
  • rc.localに書いてもいいけど処理を変更するときはAMI作りなおさなきゃいけない

ミドルウェアの設定は変更が少ないとしても、プログラムは定期的に新しいバージョンに変更されたりしますよね。
今回はCloudInitとSubversionを使って起動時に最新のソースコードを設置する構成を作ってみました。
※例ではSubversionを使用しておりますが、Gitでも同じ構成にする事は可能です。

構成図

  • 今回テストで使用したディストリビューションはAmazon Linuxとなります
  • EC2インスタンスにはApacheと、Subversionのクライアントが動作するようにしております

CloudInitに渡すUser Dataのサンプル

EC2インスタンスの起動時に渡すUser Dataには以下のように指定します。
起動時にセキュリティアップデートを行いたくない場合は適宜”repo_upgrade: none”として下さい。

Apacheのコンフィグの修正点

インストールしたApacheでは以下のようにドキュメントルートを変更しています。

/etc/sudoersの変更点

CloudInitでtty経由でないsudoを実行しているので、以下のようにsudoの設定を変更しています。

Auto ScalingでUser Dataを有効にする

Auto ScalingでUser Dataを渡すには以下のようにコマンドを実行します。

User Dataを修正したい場合はlaunch-configを再作成し、as-update-auto-scaling-groupを実行すればOKです。

出来る事

  • Auto Scalingから起動された段階で最新のアプリケーションをSubversionから設置出来ます
  • 最新のアプリケーションが設置されてからWebサーバを起動し、ELBの分散対象にする事が出来ます
  • 処理内容を変更したい場合は渡すUserDataを編集するだけなので、AMIの再作成は必要ありません
  • SubversionなどのCVSを導入している方はそれを使う事が出来ます

注意点

  • 起動時に最新のアプリケーションを設置しているため、ELBの分散対象になるまで少し時間がかかります
  • Subversionインスタンスのtags以下はバージョンナンバーで管理されている事が前提となります
  • Subversionに認証設定をしている場合は起動するAMIに設定をしておいて下さい
  • Elastic Beanstalk使おうというツッコミはご遠慮くだ(ry

まとめ

基本のAMI作成後はこのようにインスタンスの外部から状態を変更出来ると柔軟に設定変更が可能だと思います。
まずはたたき台として作ってみた構成なので、AWSユーザー会などで議論が出来たらいいですね:D

AWS運用自動化サービス「Cloud Automator」