ansibleによるEC2・VPC環境構築(その3)

食欲の秋に(体重的な意味で)危機感を覚える Coati開発チーム 沼野井です。
でも秋の味覚を食べないという選択肢はないですよね!

 

前回までのあらすじ

ansibleで、

 

VPCと、それに紐づく サブネットルートテーブルセキュリティグループを作ったCoatiだった・・・

 

というわけで、前回に続いて、ansibleでEC2・VPC環境を構築していこうと思います。

今回は、

  • 前回作成したSIOS VPC内に EC2インスタンスを作成
  • 前回作成したSIOS VPCとお客様VPCをPeeringで接続

します。

 

Playbookの内容

Coatiチームで使用している、環境デプロイ用のPlaybookのディレクトリ構成と、変数定義をしているall.ymlの内容をもう一回掲載します。

  • ディレクトリ構成

 

group_vars/all.yml

 

 

インスタンス作成

作成したVPC内にEC2インスタンスを作成するplaybook, setup_ec2.ymlの中身を見ていきます。

順にみていきます。

ec2_remote_factsはAWS内の(複数の)インスタンスの情報を集めるモジュールです。
IPアドレス・サブネット名など多種のFilterを設定して検索することができます。
今回は、SUBNET_IDのサブネット、EC2_PRIVATE_IPのIPアドレスのインスタンスが、環境内に既に存在しているかどうかをチェックしています。

続いて、AMIの検索です。
Coati開発チームでは、Coati Manager用のAMIをあらかじめ用意していて、タグ Role=CoatiManager をつけています。ec2_ami_findモジュールを利用して、タグをキーにしてAMIのIDを取得します。

いよいよ、インスタンスの作成です。そのものズバリな ec2モジュールを使います。
パラメータはAWS Management ConsoleでEC2インスタンスを作成する際にお馴染みな面々を指定していきます。imageには、さきほど検索したAMIのIDを指定しています。

instance_tags: で Name=名前, Role=CoatiManager、というタグ付けもしています。

最後の

は、ec2.instancesがある場合にはインスタンスの作成をしない、という条件判定です。
一番最初に ec2_remote_factモジュールで同じIPアドレスとサブネットのインスタンスを検索したときに、もし既に存在している場合には変数ec2.instancesなんらかの値が入っているはずですので、その場合にはインスタンスの作成は行わないようにしています。

 

VPCピアリング接続

VPCピアリングを行うplaybook, vpc_peering.ymlです。

 

ec2_vpc_peerモジュールを使い、接続するVPCをそれぞれ指定して、VPCピアリング接続を行います。
このplaybookを実行したあと、お客様に接続を承認していただくと、晴れて両VPCがピアリング接続されることになります。

ここまでの結果

ついに、Coati環境が完成しました!

いかがでしたでしょうか?
今後も、役に立ちそうなplaybookを紹介していく予定ですので、よろしくお願いします。

 

SNSでもご購読できます。