はじめに
英語を単純に発音しただけのカタカナ語だと意味は分かりづらい。AWSのドキュメントやAWSコンソールは親しみやすく日本語にしてくれてはいるんだろうけど、まだ英語の方が意味が取りやすい。
というわけで、AWSのCloudFormation周りの用語を自分なりにまとめてみました。
CloudFormation周りの用語
スタック
CloudFormationテンプレート1枚で構成されるサービス群。
インフラリソースをひとまとめにしたもの。
CloudFormationコンソールのトップにテンプレート単位で登録され、コンソール上では定義パラメータの確認や動いているインスタンス、ネットワークIDなどが確認できる。
CloudFormationテンプレートを修正することで、後から削除、変更などができる。
ChefからのDevOpsをサポートしたAWSのサービスOpsworksでも同様の意味で使われているようです。
ロールバック
スタックをコンソール上で削除したときや構築が途中で失敗したときに全てのインフラサービスを削除してくれる機能。
サクッと環境作ってテストして、ネットワークごと削除。といったことが可能になる。
S3やECSレポジトリなど、ファイルを含んでいると削除できないリソースについては、削除が失敗する。
Delete Policy
ロールバックによって、リソースが削除されないようにするオプション。
Cloudformationテンプレート内に記述して、リソースごとに設定が可能。本番環境などで誤ってスタックが削除された場合などにデータベースサーバーだけはそのまま残しておく、みたいなことに使うみたい。
Cloudformationテンプレート
EC2インスタンスやS3バケット、IAM、VPCネットワークの設定などAWSの全てのサービスをコードで定義したymlまたはjsonファイル。
サービスごとの各種パラメータはここで設定。
S3バケットにアップしてCloudformation コンソールで構築する。
AWSのサービスはパラメータが多すぎるので、基本構成だけでも1000行は軽く超えることになる。
パラメータ設定に不備があるとスタック構築中にエラー→ロールバックという悲しいことになるので、Codeデザイナーなどに流し込んで部分的に試しながら作成するのがいいと思います。時間は不可逆です。
パラメータ
各種AWSサービスの設定で使われる値
- VPCへのSSHアクセスのIP制限
- インスタンスタイプの設定
- CPU数、メモリ
- SNS通知先のメールアドレス
など
これらの値をGUIでインフラ構築時に設定する形にしておくことで、同じ構成を設定を変えて構築するなど、汎用的に使えるようになります。
ネストされたテンプレートへのパラメータの受け渡しを行うことでより汎用的で見通しの良いテンプレート管理ができるようになるといいですね！
CloudFormationデザイナー
AWSサービスのアイコンをドラッグ&ドロップで配置していくことによって、スタックを作成できます。
S3に配置したCloudformationテンプレートからスタックを作成して、簡単なネットワーク図を作成することもできます。
あくまでテンプレート1枚ごとなので、ネストしたテンプレート構成の場合はネットワーク図出力として使えなかったり、逆にネストしたテンプレート構成に書き出せないのがもどかしいところ。
既存のインフラ構成をスタックにすることもできるようです。
ネスト（ネストされたテンプレート）
長くなりがちなテンプレートを分割して管理できる。
複数のテンプレートを1枚の親テンプレートから呼び出して、サービス同士を組み合わせたインフラ構成を構築できるようにしておくこと。
ネストされたテンプレート間では、それぞれのサービスに依存した状態で構築を行うので、構築の順序とパラメータの受け渡しが重要になる。
分割のコツとしては、プラベート/パブリック含むVPCネットワーク系とルーター周りを1つのテンプレートとして、そのほかをサービスとして依存しない最小単位のサービス群でテンプレート化。親テンプレートからVPC、EC2やS3、データベース、デプロイ周りの順にネストされたテンプレートを呼び出していく構成がいいかと思います。
パイプライン
継続的デプロイを行うためのサービス構成
例:
Codepipeline + CodeCommit + CodeBuild + CodeDeploy
GitHubやAWS謹製CodeCommitなどのコードリポジトリに開発者からプッシュされたことを検知して、自動的にテストを行い、デプロイされるという一連の流れ
SNSやLambdaを連携して、Slackなどへの通知を行うようにするとチームのみんなに喜ばれる
マルチAZ（マルチAZ構成）
複数のアベイラビリティーゾーンに渡って展開するサービス構成のこと。
基本的には同じサービスを冗長化しておかないと意味がない。複数台構成になるので料金は倍。
AWSのデータセンターが物理的破壊されてもサービスが存続できる、必要があるかはサービス次第。
アベイラビリティーゾーン（AZ）
AWSのデータセンターがある物理的な地区分けのこと。
ap-northeast-1bは罠
リージョン
アベイラビリティゾーンの上位にある地域枠
東京、大阪、シンガポール、ソウルなどがある
CloudFormationあるある
- cloudfrontと間違えて検索して一向に望みの結果が出てこない
- ネストされた最後のテンプレートの検証に軽く30分はロスト
- 自由入力パラメータを設定しすぎてある程度知識がないと構築出来ない
- Googleで関連キーワードを調べまくっても結局わからなくてAWS語で書かれた公式ドキュメントを読む