CloudFormation Getting Started with YAML

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
アマゾンウェブサービスジャパン株式会社
ソリューションアーキテクト
⼤村幸敬
2017/11/14 JAWS-UG アーキテクチャ専⾨⽀部
CloudFormation
Getting Started with YAML

Who am I ?
⼤村幸敬（おおむらゆきたか）
Amazon Web Services Japan
Solution Architect
好きなサービス： AWS CLI
運⽤の現場をもっと楽にしたい
興味のある領域：
ITインフラ×アジャイル
B
&
E
2

今回検討したいこと
• エンジニアが気軽にテンプレートを書きはじめるための
情報を整理する
• ある運⽤を⾏うために適切な
テンプレート設計（分割）の指針を考える
• CFnによる運⽤が適合する
アーキテクチャおよび利⽤シーンを考える

Agenda
1. CloudFormation YAMLテンプレート作成の基礎
2. CloudFormationによる環境構築の例
1. 100⼈ハンズオン⽤に環境を作る
2. 継続運⽤可能なWeb3階層アーキテクチャを作る

CloudFormationとは
• BlackBelt（オンラインセミナー）の資料を参照のこと
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2016-aws-cloudformation
参考：他のサービスの資料も多数あります→ https://aws.amazon.com/jp/aws-jp-introduction/

CloudFormation
YAMLテンプレート作成の基礎

テンプレートを書く
1. YAMLおさらい
2. エディタによるサポート
3. テンプレートの基本構造
4. テンプレートの作りかた

1. YAMLおさらい

YAMLおさらい
• オフィシャルドキュメントではJSONも併記されているが
ここでは書きやすさを重視して
徹底的にYAMLを使うことを考える
• YAML書式のポイント
• 配列とハッシュ
• フロースタイルとブロックスタイル
• 型
• 複数⾏の⽂字列
より多くの仕様はあるが、CFnで使うならここで⽰した内容を理解すれば⼗分
YAMLの詳しい情報→ http://magazine.rubyist.net/?0009-YAML

配列とハッシュ
配列
ハッシュ
- aaa
- bbb
- ccc
配列のハッシュ
abc: value1
def: value2
ghi: value3
abc:
- aaa
- bbb
- ccc
def:
- eee
- fff
- ggg
ハッシュの配列
- abc: value1
def: value2
- ghi: value3
jkl: value4
[
{"abc": "value1",
"def": "value2" },
{"ghi": "value3",
"jkl": "value4" }
]
• インデントでデータ構造を表す
{ "abc": "value1",
"def": "value2",
"ghi": "value3”}
[ "aaa", "bbb", "ccc"]
{ "abc": [ "aaa", "bbb", "ccc" ],
"def": [ "eee", "fff", "ggg" ]}
※枠外はJSON表記

ブロックスタイルとフロースタイル
ブロックスタイル
- aaa
- bbb
- ccc
abc: value1
def: value2
ghi: value3
• 複数⾏表記と1⾏表記
• 通常はブロックスタイルを使う
• 1⾏にまとめたい部分のみフロースタイルがおすすめ
[aaa, bbb, ccc]
{abc: value1, def: value2, ghi: value3
フロースタイル

型
• YAMLは次のデータ型を⾃動的に判断する
• 整数 / 浮動⼩数点 / 真偽値 (true, false)
⽇付 / タイムスタンプ
• 上記以外は⽂字列として認識
• ⽂字列を明⽰するにはダブルクォートやシングルクォート
• 型指定の使い⽅
• 書きやすくするには極⼒クォートを使わない
• テンプレートバージョン指定くらい
• JSONからツール変換するとクォートの有無がまちまちなので注意
• オフィシャルドキュメントのサンプルでは
必ずしもクォートが必要でないものにも付いている場合がある
CFnはこれでも問題なし

複数⾏の⽂字列の扱い
• ⽂字列にもブロックスタイルがある
• UserDataを書く場合に便利
text1:
hogera
hogehoge
foobar
パイプがないと改⾏が
削除される
text1: |
hogera
hogehoge
foobar
パイプを書くことで
改⾏が保持される
hogera
hogehoge
foobar
hogera hogehoge foobar
※枠外に実際に得られる⽂字列を⽰した

エディタによるサポート
• YAMLは書きやすいがツールによる書式チェックは必要
• 加えてaws cloudformation validate-templateも
• お好きなエディタで
• ハイライト
• フォーマッティング
• ⽂法チェック
• ⾃動補完
• 参考：CloudFormation Designerでは
• JSONでプロパティを書く際に
Ctrl-Spaceで属性をサジェスト可能
例：emacsの場合、以下のような機能を使っています
yaml-mode, fly-check, highlight-indentation, auto-complete
http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/working-with-templates-cfn-designer-json-editor.html
会場では vim、VS Code等を使っていると意⾒あり

テンプレートの基本構造（全体）
テンプレートバージョン（固定）
説明 (Description)
AWSリソース (Resource)
出⼒ (Outputs)個々のリソース
※左記テンプレートから作られる環境

テンプレートの基本構造（リソース）
リソース論理名
テンプレート内で参照する情報
実際に作られるリソースの名前は
これと異なるもの（物理名）が設定される
（別途指定が可能）
タイプ (Type)
どのAWSリソースを作るか
プロパティ (Properties)
リソースの設定値

テンプレートの基本構造（Outputs）
スタックの外へ情報を出すために使う
（Exportについては後ほど説明)

テンプレートの基本構造
（Parameter）
パラメータ（Parameter）
スタック作成時に指定可能な変数を定義
個々のパラメータ定義
!Ref 関数を使⽤して参照（後述）
aws cloudformation create-stack
--stack-name yaml-stack-aurora
--template-body file://yaml-aurora.yaml
--capabilities CAPABILITY_IAM
--parameters
ParameterKey=SecStackName,ParameterValue=yaml-stack2-nw
ParameterKey=BaseStackName,ParameterValue=yaml-stack2
ParameterKey=DBPassword,ParameterValue=dbpassword
ParameterKey=DBUser,ParameterValue=dbuser
パラメータ付きでスタックを作るCLIコマンドの例

スタック間の情報連携
（Cross Stack Reference）
②別のスタックから参照可能な値が
エクスポートされる
①Exportを使って他のスタックから
参照したい値をエクスポート
例：セキュリティグループID
③ImportValue関数を使って
値を参照する
会場から、NestedStackもあるが、各スタックが独⽴してい
るCrossStackReferenceのほうが運⽤しやすいと意⾒あり

組み込み関数
• テンプレートの記述に使える関数
• 全15種
http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html
• 記法は完全名の「Fn::xxx」と短縮形の「!xxx」の2つ
• 短縮形を使う⽅が記述がシンプルになる
• 短縮型呼び出しに短縮形引数を指定できないため
⼀部では完全名のほうがよく使われる
• よく使う関数
• 値を参照する !Ref, !GetAtt
• ⽂字列を加⼯する !Sub
• AZを取得する !GetAZs
• エクスポート値取得 Fn::ImportValue
• Base64エンコード Fn::Base64
会場から、!FindInMap や !If などの条件分岐もよく
使うと意⾒あり。ここではテンプレートを複雑にしな
いという⽅針で関数を紹介しました。テンプレートを
どこまで汎⽤的にするかは多様な考え⽅があります。

組み込み関数の使⽤例
!Ref
• テンプレート内の論理名から物理名（ID）を参照する
• 返る値はリソースによって異なる
リソースのリファレンスで確認
!GetAtt
• リソースが持つ属性値を取得する
• 属性値はリソースによって異なる
• リソースのリファレンスで確認
!Sub
• 本来は⽂字列内の変数を指定した値で置き換える関数
• ${xxx}で指定した変数(パラメータ、論理名、属性）の
展開を⾏う⽤途でもよく使われる
!Select
• 配列内の要素を選択する
• 例： !Select [ 1, [ apples, grapes, oranges, mangoes] ] は grapes を返す
!GetAZs
• AZ名を取得する
• 引数がない場合はすべてのAZの配列を返す
会場から、⽂字列⽣成は !Join もよく使うという意⾒あり。
プログラマにはこちらのほうが馴染み深いとのこと。

どうやってテンプレートを書くか
• マネジメントコンソールで作った環境からバックポート
• CloudFormerを使⽤して構成済み環境からテンプレートを⽣成→YAMLへ変換
• YAMLへの変換には cfn-flip がオススメ（ https://github.com/awslabs/aws-cfn-template-flip ）
• 即値を含むため⼿で直さなければいけないところが多い / CloudFormerが未対応リソースもある
• →リファレンスを⾒ることになる
• CLIで出⼒→YAMLへ変換
• 例: aws rds describe-db-instances | ruby -ryaml -rjson -e 'puts YAML.dump(JSON.parse(STDIN.read))'
• →必要な部分だけを抽出するためにリファレンスを⾒ることになる
• サンプルコード＆スニペットから使える部分を抽出する
• https://aws.amazon.com/jp/cloudformation/aws-cloudformation-templates/
• awslabs (https://github.com/awslabs ) やソリューションテンプレートもお
すすめ
• →⾃分⽤に加⼯するためにリファレンスを⾒ることになる
• リファレンスを⾒ながら⼿で書く
• 試⾏錯誤はあるが結局これが⼀番書きやすい

CFnテンプレート作成のリファレンス
• AWSリソース（まずはここ作成可能なすべてのリソースの情報）
http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html
• リソースプロパティ（リソースの中で指定できる特定の情報の集まり）
http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-product-property-reference.html
• 組み込み関数
http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html
• 疑似パラメータ（テンプレートの中で利⽤可能な定義済み変数）
http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html
• 属性（⼀部のリソースにのみ設定可能な更新、削除時の挙動設定）
http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-product-attribute-reference.html

CFnテンプレート作成のリファレンス
• AWSリソース（作成可能なすべてのリソースの情報）
http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html
• 構⽂ / プロパティ / 戻り値 / 例が記載されている
構⽂プロパティ戻り値
!Ref 論理名で参照できる値
!GetAtt 論理名.xxx で参照できる値
Propertiesに指定する値の詳細Resource内に記載する内容

CFnスタックを作る
• テンプレート作成中はスタック作成とRollbackの繰り返し
→C L I ! C L I !
• マネジメントコンソールでもよいが都度パラメータ指定が⾯倒
• とはいえコマンドが⻑いのも⼊⼒が⼤変
• 簡単なヘルパースクリプトを作ることをオススメします
aws cloudformation validate-template --template-body file://yaml-aurora.yaml
aws cloudformation create-stack --stack-name yaml-stack-aurora --template-body file://yaml-aurora.yaml
--capabilities CAPABILITY_IAM --parameters ParameterKey=SecStackName,ParameterValue=yaml-stack2-nw
ParameterKey=BaseStackName,ParameterValue=yaml-stack2 ParameterKey=DBPassword,ParameterValue=dbpassword
ParameterKey=DBUser,ParameterValue=dbuser
aws cloudformation describe-stack-events --stack-name yaml-stack-aurora –query 'reverse(StackEvents[])’

CFnスタック管理⽤ヘルパースクリプトを作る
• よく使うコマンドを簡単に使えるようにしておく
• 作成 / 更新 / 削除 / 状態確認 / validation
例： cfn-update.sh
#!/bin/sh
mode=$1; shift
stack_name=$1; shift
template=$1; shift
if [ "$mode" != "create" -a "$mode" != "update" ]; then
echo "$0 (create|update) stack-name template-name [param1=val2 param2=val2 ...]”; exit 1
fi
params=$(echo $* | perl -np -e "s/([^= ]+)=([^ ]+)/ParameterKey=¥1,ParameterValue=¥2/g")
if [ "$params" != "" ]; then
params="--parameters ${params}”
fi
cmd="aws cloudformation ${mode}-stack --stack-name ${stack_name} --template-body file://${template} --capabilities CAPABILITY_IAM $params”
echo ${cmd}
eval ${cmd}
使用例
./cfn-validate.sh yaml-eip.yaml
./cfn-update.sh create yaml-stack-r53 yaml-r53.yaml
./cfn-update.sh create yaml-stack-eip yaml-eip.yaml R53StackName=yaml-stack-r53
./cfn-status.sh yaml-stack-eip -v

テンプレートを書く（まとめ）
1. YAMLおさらい

CloudFormationテンプレートの例

CloudFormationテンプレートの例
• 100⼈ハンズオン⽤に環境を作る
• 継続運⽤可能なWeb3階層アーキテクチャを作る

100⼈ハンズオン⽤に環境を作る
要件
• 100名同時にAWSのハンズオンをしたい
• AWSのマネジメントコンソールに⾃分だけのIDでアクセス
• VPC環境が⾃分専⽤にあらかじめ⽤意される
• VPC上にEC2インスタンス等を構築する

100⼈ハンズオン⽤に環境を作る（例）
親アカウント
⼦アカウント
（10個）
us-east-1
ap-northeast-1
…
各リージョンの
EC2のみ操作可能な
IAMユーザ
10のアカウントの
10のRegionに
それぞれ
VPC環境を⽤意
CLIを使ってシェルスクリプトで実装
・Organizationsで⼦アカウントを作成
・⼩アカウントにはAssumeRoleでのみアクセス
・⼦アカウントにStackSet実⾏⽤のRoleを作成
Cloudformation StackSetを使⽤
・各アカウント作成する10のIAMユーザと
IAMポリシーはスクリプトで⾃動⽣成
・全アカウントのus-east-1に対しStackSetで展開
Cloudformation StackSetを使⽤
・VPC作成テンプレートを
全アカウントの全リージョンに対し
StackSetで展開
・OrganizationsはCFn未対応
・StackSet実⾏のため各アカウントに以下のRole作成が必要
- AWSCloudFormationStackSetAdministrationRole
- AWSCloudFormationStackSetExecutionRole
user001〜10を作成 & pw設定
CFn Template内ではLoopを書けないため
10⼈分のyamlを⽣成し各リージョンに設定
EC2のみIAMポリシーのConditionで操作可能
なリソースのリージョンを制限
当時はStackSet内のStack数制限が50であり、3つのStackSet
に分けて構築。
現在は200まで拡張されたので⼀発で構築可能
余談：ハンズオンで作成したVPC上のリソースはCFn管理下で
ないため、別途全環境を操作可能なシェルスクリプトを使って
状態確認&クリーンナップを実施

継続運⽤可能なWeb3階層アーキテクチャを作る（例）
BasionAP AP
• 本番環境以外に同様の構成の
開発・ステージング環境を作る
• サービス提供ホスト名とBasion
（踏み台）ホスト名はバックエンド
を変えた場合でも維持する
• APサーバ（アプリケーション）
更新時もDBは変更しない（ステート
レス・ステートフル分離）
• セキュリティ設定（アクセス制御）
は別の専⾨チームが⾏う
• 踏み台ホストには作業データを残す
ためのDataVolume(EBS)をつける
• RDS、DataVolumeは削除の際ス
ナップショットを作成するSecurity Group
ALB
サービス提供公開ホスト名
EIP&公開ホスト名
Public
Subet1
Private
Subet1
Private
Subet2
Public
Subet2
Auto
Scaling
Group
IAM Role & Policy
Hosted
Zone
DataVolume

継続運⽤可能なWeb3階層アーキテクチャを作る
• 分割⽅針
• ステートレス / ステートフルは別スタックとする
• 外部インターフェースと内部コンポーネントは別スタックと
する
• ライフサイクルが異なるものは別スタックとする
• 管理主体が異なるものは別スタックとする
• スタック間の連携はCrossStack Referenceを使⽤する

Basion
AP
ALB
Public
Subet1
Private
Subet1
Private
Subet2
Public
Subet2
Auto
Scaling
Group
LB⽤
SG
AP⽤
SG
DB⽤
SG
Basion⽤
SG
HostedZone
テンプレート（=スタック）分割例
・CrossStack Reference変数名はスタック名-xxx とし、
複数の環境を構築した場合もコンフリクトしないよう設定
・スタック作成時の依存関係はシェルスクリプトで記載

Basion
AP
ALB
Public
Subet1
Private
Subet1
Private
Subet2
Public
Subet2
Auto
Scaling
Group
LB⽤
SG
AP⽤
SG
DB⽤
SG
Basion⽤
SG
HostedZone
考えられる検討事項（参考として）
スタック間の依存関係やスタック作成時に指定するパラメータをどこ
かに記述しなければいけない。シェルスクリプト？
HostedZoneを⼀度消してしまうとレジストラへNSの登録変
更が必要になるので注意。通常消すことはまず無い。
この構成の場合、開発・ステージング・本番それぞれにドメイ
ンを取得することになる。⼀⽅でドメインを１つにする場合は
HostedZoneは１つだけ作成し、それぞれの環境で異なるホス
ト名を使う必要がある。
ベースネットワークスタックを作るのはよくある構成
各システムごとに環境を払い出す場合に使われる。
セキュリティポリシーを統⼀的に管理したい場合や専⾨チームによる統制を⾏う場合はスタックを分ける
⼀⽅で開発および運⽤中の細かな⽳あけに部⾨間の調整が発⽣することの対応は検討が必要。
ホスト名の情報は⼀元管理したほうがよいが、実際はリソースに紐
づく情報である。⼀元管理を優先してレコードセット管理⽤スタッ
クとするか、このようにリソースに紐付けた形とするか。
IAMロールはサーバの役割に強く依存し、変更トリガは開発側
にあるので同じスタックとした。別環境で同じ内容のロールが
作られることになるが、削除の際の依存関係を無くしたいため
この構成としている。⼀⽅でセキュリティ統制上は別スタック
としたほうが管理主体を別にしやすい。
ステートフルなDBとステートレスなAPはライフサイ
クルが異なりスタックを分ける⽅がよい。アプリケー
ションのデプロイ⼿法がインプレースアップデートで
あればこのスタック内の設定変更でよいが、
BlueGreenデプロイを⾏いALBも変更するような場合
はスタック間の参照に不整合がでないよう対応が必要
DBのログイン情報をスタック作成時にどのように安全に渡
すか？別途SSM Parameter Storeにデータを⼊れ、CLIから
渡す⽅法がある。CFnのParametersで⾒えてしまうことに
ついては「NoEcho」プロパティを設定することでCLIやマ
ネジメントコンソールから⾒えなくなる。
作成したリソースをどこまで使いまわすか？IAMRoleや
SecurityGroupは使い回しも可能だが、環境（システム）を跨いで利
⽤すると想定外の依存関係が発⽣して削除で困ることもある。
EC2にDeletionPolicyを設定できないため、削除時に
⾃動的にスナップショットは取得できない。EBSの
データを保全する場合は別途データディスクをつけ、
DeletionPolicyの設定が必要。
RDSにDeletionPolicyの設定は必須。snapshotかretain。

まとめ
1. CloudFormation YAMLテンプレート作成の基礎
2. CloudFormationによる環境構築の例
1. 100⼈ハンズオン⽤に環境を作る
2. 継続運⽤可能なWeb3階層アーキテクチャを作る
ここで紹介したのは検討のためのサンプルです。
みなさんの環境、体制、ポリシー、アーキテクチャによって最適な⽅
法は変わります。運⽤におけるツールはCloudFormationだけではな
く、またCloudFormationの使い⽅に唯⼀のベストな解はありません。
まずはご⾃⾝でお試しいただき、よりよいCloudFormationの活⽤ノ
ウハウを検討してみてください。

Thank You!

CloudFormation Getting Started with YAML

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to CloudFormation Getting Started with YAML

Similar to CloudFormation Getting Started with YAML (20)

More from Yukitaka Ohmura

More from Yukitaka Ohmura (11)

CloudFormation Getting Started with YAML