(メモ) AWS VPC 設定の自動化について考えてみた。 #aws #ansible
AWS を使う多くの案件の構築に携わり VPC 周りの設定をしていると、いつも同じようなことをやっていることに気づきました。
VPC を作って、Subnet を作って、Routing Table を設定して、Security Group 作って、…。
だいたい、環境構築時の最初の1回しかやらないような設定作業がほとんどなので、喉元過ぎれば熱さを忘れるで、一度構築を終えると気にしなくなるのですが、なんらかツールを使って自動化する余地はありそうです。
例えば、複数の案件で同じような設定変更をしなければならなくなったときなどにも、同じツールが使えると便利です。
そのツールを使って、設定が正しいことの確認もできるともっといいです。
そこで、こういう用途に何が使えそうか、軽く調べてみました。
すると、以下の2つの方法は取れそうでした。
- (1) CloudFormation を使う
- (2) Ansible を使う
(1) CloudFormation で必要な設定を JSON のテンプレートとして作成しておけば、異なる案件で同じような設定をしたいときにも使えそうです。
テンプレートを更新した後にスタックの更新処理を行うことで、変更を適用することができるようです。
テンプレートをソースコード管理(SCM)システムで集中管理する場合、CloudFront の UpdateStack API で TemplateBody としてローカルのテンプレートを指定するやり方ができそうです。(または AWS CLI を使うやり方もあります。)
UpdateStack API に dry-run 機能はなさそうですが、GetTemplate API で現在のスタックに適用されいているテンプレートを取得し、SCMのテンプレートと差分を比較して、処理を実行するか決めるようなやり方が考えられそうです。
(2) Ansible の場合、ec2_vpc という module が使えるようです。
下記ブログに実施例が載っています。
Ansible の場合、サーバの構成管理に使われることもあって、設定が正しいことのテストもできます。
また、設定ファイルは yaml なので、SCM管理が容易で、アカウント横断で共通の設定を共有するのは簡単そうです。
アカウントごとにカスタマイズしたい設定も、頑張れば適切に管理できそうです。
(1), (2) どちらのやり方も不可能ではなさそうです。
もし既に CloudFormation を使っている場合は (1) がよさそうな気がします。 ただ、使い方を変えなければならないケースもあるかもしれません。
何も使っていない場合、(2) の方が敷居が低そうな印象はあります。
上のやり方の落とし穴や、他に「こうやるといいよ」というノウハウがありましたら、コメントなどいただけるとうれしいです。
