Capistranoで異なるAvilabilityZoneにEC2インスタンスをラウンチする

前回、

次回はデータベースの作成や初期設定を直前タスクとして挿入して、さらにWordPressの設定ファイルの書き換え、GitHubからWordPressテーマをダウンロードするところまでやってみようと思います。

とか云っていたのですが、都合によりCapistrano3を使ってAWSのEC2インスタンス作成を行ったので、そのTIPSを残しておこうかと思います。
今回は、デプロイ用のEC2インスタンスから公式のAMIを利用してAvailabilityZonesが異なるエリアにそれぞれEC2インスタンスを立ててみました。試験的に、AMIは最新のインスタンスタイプ「t2.micro」に対応した「Amazon Linux AMI 2014.03.2 (HVM)」を利用して、Tokyoリージョンの1aと1cのAvailabilityZoneにそれぞれ2台ずつ、合計4インスタンスを同時に立ててみます。

※ 事前準備として、インスタンスを立てるAWSアカウントにてVPCやSubnet等EC2インスタンスを作成する上で必要最小限の設定をしておく必要があります。特に今回は異なるAvailabilityZoneへのインスタンスを立てるのでそれぞれのゾーンにSubnetを設定しておく必要があります。

さて、早速デプロイの手順です。
はじめに、デプロイ環境(サーバ)の設定を行うため、config/deploy/test.rbを編集します。
今回は動的に作成したEC2インスタンスをデプロイ環境とするため、事前のサーバ設定ができません。というのも、AWSで立ち上がる新規インスタンスにはElasticIPを付与しないので、毎回PublicIPが異なり、エンドポイントURLも動的に変わってしまうためです。なので、今回はインスタンスが起動した後にCapistoranoのタスクにて対象サーバを設定するようにします。
初期のサーバ設定は不要となるので、記述をコメントアウトしておきます。なお、SSHのオプションだけは最終的に共通で利用する予定なので残しておきます(今回のデプロイタスクでは使いませんが…)。

今回のデプロイでは、「AWS SDK for Ruby」を利用するので、あらかじめSDKをインストールしておきます。

次に、config/deploy.rbにデプロイ内容を設定します。

実際にインスタンスのラウンチをしてみる。

上記のようなログが出力され、インスタンスのラウンチは完了したようなので、AWSのマネージメント・コンソール側で確認してみます。

AWSのマネージメント・コンソールで新規インスタンスを確認

確かに4つのインスタンスが、交互に別々のAvailabilityZonesで起動していました。理想どおりの動きです。
なお、AWSのインスタンスが起動する時間は環境によってまちまちのため、上記の「launch」タスクはEC2インスタンスの起動状況までは確認せずに終了させています。ただ、このままだとCapistoranoの次のタスクが起動した際にインスタンスの情報が引き継げないので、「launch」タスクで起動したインスタンスのIDを「CREATED_INSTANCES」というファイルに書き出して終了させています。
次のタスクでは、この「CREATED_INSTANCES」に書き出されているインスタンスIDを拾って、インスタンスの起動状況をチェックし、ステータスが「:running」であれば、デプロイ先のサーバとして設定を行うようにしています。
また、「check」タスクではステータスが「:running」である新規インスタンスのプライベートIPアドレスを取得して、それをデプロイ先サーバのホスト名として利用していますが、新インスタンスにパブリックIPアドレスが割り当てられてパブリックDNSが設定されているのであれば、ここを{}.map(&:dns_name)と名前引きにしても大丈夫です。

後続タスクを実行してみます。

前タスクで作成したインスタンスの情報を引き継いで、無事にデプロイ先のサーバとして設定されました。
この後のタスク(今回の例では「deploy」タスク)で、各新規インスタンスに対してApacheやPHP、MySQLのインストールを行えば、晴れて前回のWordPressのデプロイに繋げられるようになります。

最終的には、Capistranoのコマンドを2~3回入力するだけで、サーバ作成からWordPressデプロイまで一気に出来てしまうという夢のようなデプロイ環境が作れそうです。

参考サイト

おすすめ記事