VPC

AWSの新機能「Inter-Region VPC Peering」でリージョン間VPCピアリングしてみた

国内・海外問わず旅行好きなSIOS Coati開発担当、沼野井です。

 

さて、先日のAWS re:invent 2017では例によってたくさんの新機能がお披露目されましたが、その中の1つ、

Inter-Region VPC Peering

で、リージョン間のVPCピアリングが可能になりました。

今のところ、できるリージョンは

  • 米国東部(バージニア北部)
  • 米国東部(オハイオ)
  • 米国西部(オレゴン)
  • 欧州(アイルランド)

の4つです。残念ながら東京は入ってないんですが、AWSのことなのできっとすぐにできるようになるでしょう。

というわけで、今回はこのInter-Region VPC Peeringを試してみました。

 

ピアリング接続を作成してみる

まず、バージニアとオハイオにVPCを作ります。

バージニア

 

 

オハイオ

 

で、バージニアの方からオハイオにピアリング接続を作成してみます。

バージニアの方で、ピアリング接続の作成画面を開きます。

リージョンを選択するカラムが追加されていますね。オハイオを選んで作成!

成功! 

あとは、同一リージョン内のVPCピアリングと同じようにオハイオ側が承諾すれば完了です。

 

 

無事できました。すごいですね。

 

通信してみる

せっかくなんでインスタンス作って通信してみました。

バージニア

 

オハイオ

 

ping飛ばしてみました。

東京リージョン内の2つのVPCピアリングで接続した2つのインスタンスでのping結果を速度比較してみます。

 

おっ意外と差がありますね? 

まあ、条件などを考慮した厳密な測定では全くないのでご参考、ではありますが、シビアに速度を気にするアプリを開発されている方は、計測・検証が必要かもしれません。

 

CLIで作成してみる

さて、GUI(Management Console)では無事作成できたリージョン間ピアリングですが、CLIではできるんでしょうか?

先ほど作成したVPC Peeringをいったん消して、CLIで再度作成してみましょう。

VPCピアリングを作成するコマンドは aws ec2 create-vpc-peering-connection–peer-region ですが、–peering-regionオプションでピアリング先(アクセプタ)のリージョンを指定すればよいようです。

バージニアに作成したインスタンスでCLIを実行してみます。

DEKITA! CLIもばっちりです。

 

Ansibleでできるか調べてみる

ansibleはどうかな? と思って調べましたが、さすがにまだ未対応のようです。

ec2_vpc_peerモジュール

ピアリング先(アクセプタ)のリージョンを指定することができません(注:上記ページ内のExampleのregionは、ピアリング元(リクエスタ)のリージョンの指定です)。

あせらず、でも期待して待ちましょう!

 


リージョン間ピアリングは使い所が多そうです。SIOS Coati世界展開も近いかも知れません(!?)

この調子でリージョン間ピアリングを通して物理的に人間の輸送ができるようになったりしませんかね? 海外旅行が捗るんですが。
ジェフ・ベゾスさんならあと20年くらいでやってくれそうな気もします。

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を紹介していく予定ですので、よろしくお願いします。

 

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

シルバーウィークに遅い夏休みを満喫した沼野井です。

・・・本当はこれ書いてるの9/14なんですが、公開日の調整の結果↑にような挨拶となりました。
こんな笑点みたいな挨拶をする機会があるとは思ってもいませんでした。

 

前回までのあらすじ

 

この構成をansibleで作ろう、と思うCoatiだった・・・

 

というわけで、前回の続きで、ansibleによるEC2・VPC環境構築の、実際のplaybookの内容についてです。

 

Playbookの内容

あ、前回すっかり忘れていたのですが、使用しているansibleのバージョンは 2.3 です。ご承知おきください。

Coatiチームで使用している、環境デプロイ用のPlaybookのディレクトリ構成は以下のようになっています。

なんぞこれ? と目がハテナな方はこちら(英語ですが)
ansibleの標準的なディレクトリ構成と思っていただいてよいと思います。

個々に中身をご紹介していきます。

(1) group_vars/all.yml

全playbookで使う変数を定義しています。以下のような感じです。

冒頭の5行の、

はお客様のお申込み内容に従って入力しています。残りの項目は固定値または、↑の内容から自動的に作成されるという寸法です。

(2) VPC.yml

VPCを作成して、その中にCoati Managerインスタンスを作成するplaybookです。インスタンスも作るのにVPC.ymlってネーミングがイマイチです。すみません。

そのネーミングのイマイチなVPC.ymlの中身はこんな感じです。

こんだけ。

これは、「ロールVPCのタスクを実行しなさいね」と言ってるだけです。
ロールVPCのタスクとは

こいつらです。実際にはmain.ymlがまず呼ばれます。

main.ymlは

これもこんだけで、本体であるsetup_vpc.ymlとsetup_ec2.ymlをincludeしています。

本体の1つ、setup_vpc.ymlの中身を見ていきます。

一転して長くなりましたね。本体ですから、実際いろいろやってます。順にみていきますと、

ec2_factsは(playbookを実行している)ホストの情報を色々集めてくるモジュールです。今回は、パブリックIPアドレスを取得するため(だけ)に使っています。
registerは、集めたネタを変数(この場合 変数名もec2_facts)に格納します。
実際にec2_factsを使っているところは後ほど!

Coati Managerインスタンスを格納するVPCを作成しています。ec2_vpc_netモジュールを使います。

{{ VPC_NAME }} は group_vars/all.ymlで定義してあるものです(ansibleでは、”{{}}”で囲むと変数の値が取り出せます)
同様に{{VPC_CIDR_BLOCK}}, {{ REGION }}もgroup_vars/all.ymlで定義しています。
あと、tags:を利用して、 作成したVPCにRole=CoatiManager というタグをつけています。

ec2_vpc_netモジュールは、作成したVPCのIDなどを実行時の結果として戻しますので、実行結果をregisterで変数vpcに格納しておいて、あとで使うことができます。

作ったVPCにsubnetを作成します。今作ったVPC IDが必要です。ここで、さきほどregisterで保存した変数vpcを使います。VPC IDは、

のようにして参照できます。

同様に、作成したVPCにインターネットゲートウェイを作成しています。ec2_vpc_igwモジュールを使います。

ルートテーブルの作成です。ec2_vpc_route_tableモジュールを使います。ちょっとパラメータが増えましたが、基本は同じです。
なお、ここでは送信先を0.0.0.0/0にしていますが、適切に設定してくださいね!

セキュリティグループの作成です。ec2_groupモジュールを使います。以下のポートに穴をあけています。

ポート番号 ソース 備考
80 0.0.0.0/0(※)
22 手元のPCのIPアドレス 私がオフィスから直接ログインして操作するため
22 オペレーション端末のIPアドレス オペレーション端末からログインして色々設定するため
-1 手元のPCのIPアドレス ICMPです。ping用
-1 オペレーション端末のIPアドレス ICMPです。ping用

※ここでは0.0.0.0/0と書いてありますが、適切に設定してくださいね!

「オペレーション端末の(グローバル)IPアドレス」の指定に、最初の方で取っておいたec2_factsを使っています。
やっと伏線回収できました!

セキュリティグループ構築その2、です。同じセキュリティグループに割り当てられたインスタンスからのトラフィックを許可しています。

 

ここまでの結果

・・・いかがでしたでしょうか。ここまでで、

 

の構成ができました。

 

少し長くなってしまったので、Coati Managerインスタンスの作成とVPC Peeringの設定は次回にしようと思います!

AnsibleによるEC2・VPC環境構築(その1)

未だにNintendo Switchが買えないSIOS Coati 開発チーム、沼野井です。もうニンゴジラは見たくない!

本日は、AnsibleによるAWS EC2・VPC環境構築についてお話ししたいと思います。

コマンドベースの環境設定ツールとしてすっかりメジャーになったAnsible。Playbookというファイルにお願いごとを書いておいてコマンドを実行すると、夜までまたずともすぐに叶えてくれる、7人の小人以上よりも便利なナイスガイ。
近年、開発元を赤い帽子のあの会社が買収するなどメジャー街道を驀進中です。

私は、Ansibleの

  • シンプルなところ
  • 色々なモジュールが用意されているところ
  • PythonベースでGithubにソースが公開されているので何か起きても結構調べられちゃうところ

が気に入っています。

Ansibleの公式ドキュメントはこちらをどうぞ。
公式ドキュメントは英語なんですが、日本語の書籍やWebサイトが多く存在します。それもまた良いところですね。


実は、何を隠そう、SIOS Coatiでも、本番環境・テスト環境の構築をAnsibleで行っています!
まぁ、ここまで前振りして使ってなかったら逆にびっくりですが…

というわけで、今回は、SIOS Coatiの監視環境を自動作成するのに使っている、AWS用のモジュールについてご紹介します。
AWSで繰り返し環境を構築したいけどマニュアルでやってるよ・・という方の参考となれば幸いです。

SIOS Coatiの基本的な監視環境は、以下の通りです。

作業と、それに使うモジュールは以下の通りです。

Coati ManagerのVPC関連の設定

# 作業 モジュール名
1 VPCの設定 ec2_vpc_net
2 subnetの設定 ec2_vpc_subnet
3 ルートテーブルの設定 ec2_vpc_route_table
4 インターネットゲートウェイの設定 ec2_vpc_igw
5 セキュリティグループの設定 ec2_group

Coati ManagerのEC2インスタンスの設定

# 作業 モジュール名
6 インスタンスの設定 ec2

Coati ManagerのVPC Peeringインスタンスの設定

# 作業 モジュール名
7 VPC Peeringの設定 ec2_vpc_peer

Ansibleの標準モジュールだけで一通りできてしまって、楽チンなことこの上ありません!

上記のほかにも、様々なモジュールが用意されていますよ!

AnsibleのAWS関連モジュール一覧

 

本日ご紹介したモジュールを利用した、実際のplaybookについては、次回ご説明したいと思います。


 

最後にまた宣伝で恐縮ですが

弊社では、Ansibleについてのテクニカルサポートをご提供しております!