cloudformation getting started with yaml

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト⼤村幸敬

2017/11/14 JAWS-UG アーキテクチャ専⾨⽀部

CloudFormationGetting Started with YAML


Who am I ?⼤村幸敬（おおむらゆきたか）

Amazon Web Services JapanSolution 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/


CloudFormationYAMLテンプレート作成の基礎


テンプレートを書く

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


1. YAMLおさらい


YAMLおさらい• オフィシャルドキュメントではJSONも併記されているが

ここでは書きやすさを重視して徹底的にYAMLを使うことを考える

• YAML書式のポイント• 配列とハッシュ• フロースタイルとブロックスタイル• 型• 複数⾏の⽂字列

より多くの仕様はあるが、CFnで使うならここで⽰した内容を理解すれば⼗分YAMLの詳しい情報→ http://magazine.rubyist.net/?0009-YAML


配列とハッシュ

配列

ハッシュ

- aaa- bbb- ccc

配列のハッシュ

abc: value1def: value2ghi: value3

abc:- aaa- bbb- ccc

def:- eee- fff- ggg

ハッシュの配列- abc: value1def: value2

- ghi: value3jkl: 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: value1def: value2ghi: value3

• 複数⾏表記と1⾏表記• 通常はブロックスタイルを使う• 1⾏にまとめたい部分のみフロースタイルがおすすめ

[aaa, bbb, ccc]

{abc: value1, def: value2, ghi: value3

フロースタイル


型• YAMLは次のデータ型を⾃動的に判断する

• 整数 / 浮動⼩数点 / 真偽値 (true, false)⽇付 / タイムスタンプ

• 上記以外は⽂字列として認識• ⽂字列を明⽰するにはダブルクォートやシングルクォート

• 型指定の使い⽅• 書きやすくするには極⼒クォートを使わない

• テンプレートバージョン指定くらい• JSONからツール変換するとクォートの有無がまちまちなので注意• オフィシャルドキュメントのサンプルでは

必ずしもクォートが必要でないものにも付いている場合がある

CFnはこれでも問題なし


複数⾏の⽂字列の扱い• ⽂字列にもブロックスタイルがある

• UserDataを書く場合に便利

text1:hogerahogehogefoobar

パイプがないと改⾏が削除される

text1: |hogerahogehogefoobar

パイプを書くことで改⾏が保持される

hogerahogehogefoobar

hogera hogehoge foobar

※枠外に実際に得られる⽂字列を⽰した


2. エディタによるサポート


エディタによるサポート• 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等を使っていると意⾒あり


3. テンプレートの基本構造


テンプレートの基本構造（全体）テンプレートバージョン（固定）

説明 (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=dbpasswordParameterKey=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 もよく使うという意⾒あり。プログラマにはこちらのほうが馴染み深いとのこと。


4. テンプレートの作りかた


どうやってテンプレートを書くか• マネジメントコンソールで作った環境からバックポート

• 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.yamlaws 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/shmode=$1; shiftstack_name=$1; shifttemplate=$1; shiftif [ "$mode" != "create" -a "$mode" != "update" ]; thenecho "$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" != "" ]; thenparams="--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おさらい2. エディタによるサポート3. テンプレートの基本構造4. テンプレートの作りかた


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&公開ホスト名

PublicSubet1

PrivateSubet1

PrivateSubet2

PublicSubet2

AutoScalingGroup

IAM Role & Policy

HostedZone

DataVolume


継続運⽤可能なWeb3階層アーキテクチャを作る• 分割⽅針

• ステートレス / ステートフルは別スタックとする• 外部インターフェースと内部コンポーネントは別スタックと

する• ライフサイクルが異なるものは別スタックとする• 管理主体が異なるものは別スタックとする• スタック間の連携はCrossStack Referenceを使⽤する



Basion

AP

ALB

サービス提供公開ホスト名

EIP&公開ホスト名

PublicSubet1

PrivateSubet1

PrivateSubet2

PublicSubet2

AutoScalingGroup

LB⽤SG

AP⽤SG

DB⽤SG

Basion⽤SG

HostedZone

テンプレート（=スタック）分割例・CrossStack Reference変数名はスタック名-xxx とし、

複数の環境を構築した場合もコンフリクトしないよう設定・スタック作成時の依存関係はシェルスクリプトで記載



Basion

AP

ALB

サービス提供公開ホスト名

EIP&公開ホスト名

PublicSubet1

PrivateSubet1

PrivateSubet2

PublicSubet2

AutoScalingGroup

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

Technology