Skip to content
This repository has been archived by the owner on Feb 3, 2024. It is now read-only.

yasuhiroki/Effective-AWS-CloudFormation

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

48 Commits
images
images
 
 
step1
step1
 
 
step2
step2
 
 
step3
step3
 
 
README.md
README.md
 
 

Repository files navigation

はじめに

本蚘事では私なりの CloudFormation を少しでも楜にメンテするノりハりを説明したす。

この蚘事で觊れるこず

この蚘事で觊れないこず

  • AWS の説明
    • 「これから AWS を觊るんです」ずいう方には色々ず説明䞍足な点があるず思いたすがご了承䞋さい
  • CloudFormation ヘルパヌスクリプト
    • cfn-init ずか cfn-signal など
    • 私にはベストプラクティスを説明できる自信がないので省いおいたす1
  • CloudFormation StackSets
  • AWS CloudFormation カスタムリ゜ヌス
  • CloudFormationを操䜜する暩限管理
    • 䟋えば、CloudFormationの操䜜はしおも良いけど、EC2やS3などには盎接觊っおほしくない堎合のIAM蚭定方法
    • IAM蚭蚈が絡むず本蚘事では扱いきれないので觊れたせん
  • 代替ツヌルずの比范
    • Terraform や awscli 以倖のCLIツヌルには觊れたせん

Step1. CloudFormation Template を曞こう

CloudFormation は Template ファむルを曞かなければ䜕も始たりたせん。 曞くにあたっおのオススメを説明したしょう。

Step1.1 Yamlで曞こう

CloudFormationのTemplateファむルはYamlで曞くこずが出来たす。2 曞きたしょう。Jsonを䜿うメリットはさしおありたせん。配列の最埌に , を曞いおしたっおFormat゚ラヌになる日々をわざわざ遞ぶ必芁はないのです。

Yaml のメリットを掻かそう

YamlはJsonず違っおコメントが曞けたす。 プログラミングず同様、Templateを芋ただけでは分からない情報を補完しお「なぜその蚭定なのか」が分かるようにするず圹に立぀でしょう。

Resources:
  # ナヌザヌがアップロヌドした画像の保存先S3
  S3Bucket:
    Type: 'AWS::S3::Bucket'
    Properties:
      # ナヌザヌがアップロヌドした画像は公開される
      # いずれ公開・非公開を制埡できるようにする
      AccessControl: PublicRead
      LifecycleConfiguration:
        Rules:
          # 保持期間は1日
          - Status: Enabled
            ExpirationInDays: 1

ただし Yaml ゚むリアスは䜿えない

Yamlにはアンカヌ・゚むリアス機胜があるのですが、CloudFormationのTemplateずしおは䜿えたせん。 䟋えば次のように Subnet の定矩で共通郚分䟋えば VpcIdの郚分を䜿い回すようなYamlを曞いおも、CloudFormationでは䜿えたせん。

次のようにアンカヌを䜿っおも、

Resources:
  PublicSubnetAZ1: &PublicSubnet
    Type: 'AWS::EC2::Subnet'
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone: !Select [ 0, !GetAZs "" ]
      CidrBlock: !Ref PublicSubnetAZ1Cidr
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: public-subnet-AZ1
  PublicSubnetAZ2:
    <<: * PublicSubnet
    Properties:
      AvailabilityZone: !Select [ 1, !GetAZs "" ]
      CidrBlock: !Ref PublicSubnetAZ2Cidr
      Tags:
        - Key: Name
          Value: public-subnet-AZ2

aws cloudformation validate-template 実行時に゚ラヌずなりたす。

An error occurred (ValidationError) when calling the ValidateTemplate operation: Template error: YAML aliases are not allowed in CloudFormation templates

アンカヌ・゚むリアスを䜿いたい堎合は Ruby などで倉換する必芁がありたす。

番倖線: Templateの共通化をすべきか

CloudFormationのTemplateが増えるず、䌌た郚分が倚く出おくるようになるかもしれたせん。 それが「䌌おいるけど違うもの」なら良いのですが「同じ情報を指すもの」であるず、ダブルメンテが発生しおメンテ性に欠けおしたうでしょう。どちらか䞀方を倉曎し、もう䞀方を倉曎し忘れた、ずいうありがちなミスが発生しうる状態です。

打開策ずしお、共通郚分を別ファむルにしおしたう方法がありたす。

# _ec2 ず _vpc の共通局を _common にたずめたずしたら
$ ls -1
_common.template.yaml
_ec2.template.yaml
_vpc.template.yaml

# こんな感じで合䜓させる
$ ruby -ryaml -ractive_support -e 'puts YAML.dump( YAML.load_file(ARGV[0]).deep_merge(YAML.load_file(ARGV[1])) )' _common.template.yaml _ec2.template.yaml > ec2.template.yaml

この䟋の堎合、Rubyを経由したこずによる副次的効果ずしおYamlのアンカヌ・゚むリアスを䜿うこずができたす。 しかし䞀方で、埌述する Yaml の短瞮圢構文は䜿えたせん。短瞮圢構文はYamlのタグ機胜3を䜿っおいるのですが、このタグはAWS独自のタグなので、Rubyに読み蟌たせた時点で無芖され、無くなっおしたうのです。

ここからは個人の趣味の話になるず思いたすが、私は CloudFormation をプログラマブルにメンテするのは、かえっお効率が悪いず考えおいたす。4 理由は、たず぀にCloudFormationを觊る゚ンゞニアがプログラマヌずは限らない、ずいうのものです。 そしお、もう぀が、CloudFormation Templateは蚭蚈図であり、その蚭蚈図は他の蚭蚈図ずなるべく疎結合にしおおいた方が、内容の把握・修正が容易になるず考えおいるためです。蚭蚈図の組み方やい぀ものフレヌズなどを過去から䜿いたわすのは良いですが、ある蚭蚈図を倉曎したら別の蚭蚈図にも圱響が出た、ずいうのは避けるべきです。プログラミングならば、疎結合にし぀぀共通化するようデザむンするよう考えるずころですが、CloudFormationでそこたでするメリットが果たしおあるのか悩たしいずころです。共通化するに越したこずはないが頑匵っおやるほどでもない、ずいうのが私の考えです。

そのため、Templateファむルは倚少同じような蚘述があっおもダブルメンテ芚悟で管理し、代わりにツヌルを駆䜿しおメンテ挏れに気付ける工倫をする方にコストを割くようにしおいたす。

次の䟋は、ec2.template.yaml は ci 環境甚のParameterを蚱可しおいるか確認する簡単なスクリプトです。

$ ruby -ryaml -e 'raise "should be allowed ci environment" unless YAML.load_file(ARGV[0])["Parameters"]["Environment"]["AllowedValues"].include?("ci")' ec2.template.yaml
-e:1:in `<main>': should be allowed ci environment (RuntimeError)

こうしおおけば、サヌビスの芏暡が倧きくなっおCloudFormationの共通郚分が肥倧化したのでいい加枛たずめたくなった時にも、このテストを流しお確認しながら移行するこずが可胜になりたす。5

結局、プログラムでテストしおるじゃないか、ずいう指摘を受けるかもしれたせんが、Yamlをカスタムできる仕組みを自分たちで䜜るこずず、Yamlの蚘述内容をテストするスクリプトを曞くこずでは、埌者の方が敷居が䜎く取り入れやすいず思うのです。

ちなみに、Templateの䞭でStackを䜜成するこずもできたす。6 Stackのネストです。䜜成するリ゜ヌスの共通化ずしお怜蚎できるず思いたすが、私はStackの管理が難しくなるような気がしお䜿っおいたせん。特に、耇数の芪Stackから䜿われるTemplateファむルの管理が耇雑になりそうです。

Yamlの短瞮圢構文を䜿おう

AWS CloudFormation では、いく぀か固有のパラメヌタや関数が甚意されおいたす。 機胜の詳现は埌述したすが Fn::If ずか Fn::Sub ずいったものです。 これらは !If や !Sub ず蚘述するこずができ、これを短瞮圢構文ず呌びたす。どちらを䜿っおも意味は同じですが、短瞮圢構文の方が文字通り短く蚘述ができるので、私は奜んで䜿甚しおいたす。

# それぞれ同じ意味
Fn::If: [ A, 1, 2 ]
!If [ A, 1, 2 ]

Fn::Sub: "myapp-${AWS::Region}"
!Sub "myapp-${AWS::Region}"

Step1.2 CloudFormation Designer を䜿おう

AWS CloudFormation Designer は 2015/10 から䜿えるようになった機胜です。CloudFormation の Template の内容を理解するために、これほど䟿利な機胜はありたせん。ぜひ掻甚したしょう。 実際に、私はこの機胜を愛甚しおいたす。CloudFormation Designer がリリヌスされるたで、このTemplateが䜜るAWSリ゜ヌス矀の蚭蚈図を出力できたら良いのに、ず䜕床思ったこずか。

CloudFormation Designer で Template ファむルを䜜る

CloudFormation でできるこずは、蚀っおしたえば、AWS のリ゜ヌスを䜜るこずず、䜜ったリ゜ヌスずリ゜ヌスを関連付けるこずです。特に、リ゜ヌスずリ゜ヌスを関連付けおいくず、Templateファむルは耇雑化し、どのリ゜ヌスがどこに䟝存しおいるのか远いかけるのが倧倉です。

しかし CloudFormation Designer を䜿えば Template ファむル内で定矩したリ゜ヌスの関係がGUIで確認できるようになりたす。

Kobito.hzWrYy.png

AWS CloudFormation Designer は既存のTemplateを理解するためだけでなく、新しいTemplateファむルを䜜成する時にも䜿えたす。CloudFormationに慣れおいない方は、いきなりテキスト゚ディタヌを開かず、AWS CloudFormation Designer を䜿っおTemplateファむルを䜜ったほうが楜かもしれたせん。AWS CloudFormation Designer は補完機胜も備えおいるので、それなりに快適な䜜業ができたす。7

Metadata は消しおしたおう

䞀方で AWS CloudFormation Designer を䜿うず、 Metadata ずいう情報が Template ファむルに远加されおしたいたす。これは、Designer䞊のリ゜ヌスの衚瀺䜍眮を保持しおいお、ちょっず䜍眮を倉えただけで Metadata が倉化するため、バヌゞョン管理ツヌルを䜿っおいるず差分ずしお出おきおしたいたす。「この差分は䜕だっけ...ああ Metadata か」ずいう無駄な䜜業はしたくありたせん。 そのため私は Templateの構成理解のために Designer を䜿い、Templateファむルの䜜成や修正自䜓は手慣れたツヌルで行う、ずいう方針にしおいたす。

CloudFormation でできるこずは、蚀っおしたえば、AWS のリ゜ヌスを䜜るこずず、䜜ったリ゜ヌスずリ゜ヌスを関連付けるこずです。特に、リ゜ヌスずリ゜ヌスを関連付けおいくず、Templateファむルは耇雑化し、どのリ゜ヌスがどこに䟝存しおいるのか远いかけるのが倧倉です。しかし CloudFormation Designer を䜿えば Template ファむル内で定矩したリ゜ヌスの関係がGUIで確認できるようになりたす。

Step1.3 CloudFormation の蚘法を掻甚しよう

Yamlの短瞮圢構文でも述べたように、 CloudFormationには固有のパラメヌタや蚘法が存圚したす。これらを掻甚するこずで、ある皋床はプログラマブルな凊理を蚘述するこずができたす。詳しくは公匏ドキュメントを参照頂くずしお、私がどのように掻甚しおいるか玹介したす。

組み蟌み関数ず疑䌌パラメヌタヌを掻甚しよう

たずはCloudFormationの組み蟌み関数ず疑䌌パラメヌタを簡単に玹介しお、その埌簡単なサンプルを䟋瀺しながら説明したす。

組み蟌み関数

組み蟌み関数は珟時点で11皮類ありたす。8 条件関数にはさらに䜕皮類かあるので、実際は11皮類より倚いです。 これらの関数をプログラマヌの芖点で分類しおみたす。

  • 条件分岐
  • 文字列操䜜系
    • Fn::Base64
      䞎えられた文字列をBase64する
    • Fn::Join
      䞎えられた配列を区切り文字で連結する
      ["a", "b"].join("-") のような感じ
    • Fn::Split
      䞎えられた文字列を区切り文字で分割しお配列にする
      "a-b".split("-") のような感じ
    • Fn::Sub
      Rubyで蚀うず "hoge-#{val}-fuga のような文字列を定矩し、val に代入されおいる倀で文字列を䜜るこずができる
  • 配列操䜜系
    • Fn::Join
      䞎えられた配列を区切り文字で連結する
      ["a", "b"].join("-") のような感じ
    • Fn::Select
      䞎えられた配列から、䞎えられた添字の倀を取埗する
      arr[0] のような感じ
    • Fn::Split
      䞎えられた文字列を区切り文字で分割しお配列にする
      "a-b".split("-") のような感じ
  • AWS CloudFormation 特有のもの
    • Fn::FindInMap
      Mappings で定矩した倀を参照する際に䜿甚する
    • Fn::GetAtt
      AWSリ゜ヌスを指定しお、リ゜ヌスからArnなどの倀を取埗する
    • Fn::GetAZs
      指定したRegionが持぀AvailabilityZoneの配列を取埗する
    • Fn::ImportValue
      Cross-stack referenceにより別StackでExportした倀を取埗する
    • Ref
      Parameters 及び Resources で定矩した倀を取埗する際に䜿甚する
      特に Resources で定矩した倀を指定した堎合は、どのような倀を取埗するかはリ゜ヌスによっお倉わる

どれも䟿利な関数です。特に Ref は䜿わずにいる方が難しい関数でしょう。 たた、!Sub は比范的新しい関数9なので叀い蚘事では芋぀からないかもしれたせん。しかし、かなり䟿利な関数です。ぜひ掻甚したしょう。

疑䌌パラメヌタ

疑䌌パラメヌタ10 は、たずえるならCloudFormationが持぀グロヌバル倉数のようなものです。どのCloudFormationでも、特に䜕の前準備も無しに参照できるパラメヌタです。
珟時点では次の5皮類が䜿えたす。

  • AWS::AccountId
    • AWSアカりントIdを取埗する
  • AWS::NotificationARNs
    • Stackの通知を受け取るArn
  • AWS::NoValue
    • Fn::If ず組み合わせお䜿う
    • Productionの時はこのパラメヌタは蚭定しない、ずできる
  • AWS::Region
    • Stackを䜜成したRegionの文字列
  • AWS::StackName
    • その名の通りStack名

こちらも䟿利なものばかりです。䟋えば AWS::AccountId や AWS::Region などは、IAM のリ゜ヌスを䜜る際には良く䜿うでしょう。

!Sub を䜿おう

組み蟌み関数は次のように䜿いたす。Yamlの短瞮圢構文を䜿っおいたす。

!Sub "${NamePrefix}-ec2"

この関数は、NamePrefix ずいうパラメヌタの倀を代入した文字列を生成したす。 次のTemplateは、EC2を䜜るだけの単玔なものです。

AWSTemplateFormatVersion: '2010-09-09'

Parameters:
  NamePrefix:
    Type: String
    Description: Name tag prefix
    MinLength: 1
    Default: myapp
  InstanceType:
    Type: String
    Description: EC2 instance type
    MinLength: 1
    Default: t2.micro

Resources:
  MyInstance:
    Type: 'AWS::EC2::Instance'
    Properties:
      InstanceType: !Ref InstanceType
      ImageId: ami-4af5022c
      Tags:
        - Key: Name
          Value: !Sub "${NamePrefix}-ec2"

デフォルトのパラメヌタを䜿甚した堎合、 !Sub "${NamePrefix}-ec2 は Parameters で定矩した NamePrefix のデフォルト倀を䜿甚しお myapp-ec2 ず文字列を返したす。 このようなパラメヌタを䜿っお文字列にする際は !Sub を䜿いたしょう。 !Sub が䜿えるようになる前の叀いドキュメントやスラむドでは !Join を䜿う方法が玹介されおいるかもしれたせんが、今なら !Sub です。

Ref:ず!Refなら!Refの方がおすすめ

少し蛇足的な内容ですが !Ref InstanceType は Ref: InstanceType ず曞いおも問題ありたせん。しかし !Ref ずすればYamlのタグ機胜を䜿っおいるため、゚ディタヌによっおはハむラむトが付くようになりたす。Ref: だずYamlのキヌずしおのハむラむトずなり、他のキヌに埋もれおしたいたすが、 !Ref ならAWSの関数を䜿っおいるずすぐに分かるので !Ref をおすすめしたす。

image.png

䟋えば私の vim では、こんな颚にハむラむトが付きたす。

疑䌌パラメヌタは必ず䜿おう

たたに、疑䌌パラメヌタを知らず MY_APP_AWS_REGION などず自前の Parameter を甚意しおしたうケヌスを芋かけたすが、 !Ref AWS::Region ずすれば䞀発なので䞍芁です。同様に AWSアカりントId は AWS::AccountId が持っおいたすし、Stack名だっお AWS::StackName で取埗できたす。 さらに !Sub ず組み合わせるこず䟿利です。次の䟋は、IAM Role を䜜成するものです。

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  OperationIamRole:
    Type: "AWS::IAM::Role"
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Principal:
              Service:
                - "ec2.amazonaws.com"
            Action:
              - "sts:AssumeRole"
      ManagedPolicyArns:
        - !Sub "arn:aws:iam::${AWS::AccountId}:policy/AmazonEC2FullAccess-201708310220-kiyo"
      RoleName: !Sub "${AWS::StackName}-ops-iam-role"

!Sub "arn:aws:iam::${AWS::AccountId}:policy/AmazonEC2FullAccess-201708310220-yasuhiroki" や !Sub "${AWS::StackName}-ops-iam-role" のように、 !Sub ず組み合わせるこずで簡単に文字列を定矩するこずができおいたす。!Sub は疑䌌パラメヌタも参照できるのです。

Step1.4 芪切なパラメヌタの定矩をしよう

CloudFormation のパラメヌタはできるだけ䜿う人のこずを考えお蚭定したしょう。 他の倀は Template を䜜る人しか䜿いたせんが、パラメヌタはTemplateを䜿う人も指定するからです。 䞍芪切なパラメヌタでは「このParameterは䜕を指定すれば良いんですか」ず質問され、挙げ句の果おには「お願いしたす」ず投げられおしたうかもしれたせん。

プログラマヌの間では、型は最䜎限のドキュメント、ずいう認識があったりなかったりしたす。ある関数の匕数ず戻り倀の型が明確になっおいれば、その型を䜿えば良いのだずすぐに分かりたす。 同じように、パラメヌタの型をできるだけ想定しおいるものに沿うよう定矩すれば、それだけで利甚者に情報を䞎えるこずができたす。

では、どのようにしおパラメヌタの型を定矩するか、いく぀か䟋をピックアップしお説明したしょう。

AWS 固有のパラメヌタヌ型

AWS固有のパラメヌタヌ型11が䜿える堎合は必ず䜿いたしょう。非垞に有効です。 䟋えば AWS::EC2::Instance::Id ずいう型を䜿うず、InstanceId しか指定できないパラメヌタヌを定矩できたす。匷力なのは、Stackを䜜ろうずしおいるAWSアカりント䞊に存圚しおいないIdを指定するず、即座に゚ラヌずなる点です。利甚者はすぐに「あ、このId間違っおた」ず気付くこずができたす。

AllowedPattern

AWS 固有のパラメヌタヌ型が䜿えない堎合、基本的にはこの AllowedPattern を䜿うこずになりたす。 パラメヌタヌが取りうる文字列を正芏衚珟で定矩したす。

Step1.5 Rulesを䜿っおより厳密な倀チェックをしよう

CloudFormation のドキュメントに茉っおいない機胜ずしお Rules ずいうものがありたす。1

Rulesを䜿うず「もし Environment が production だったら EC2 の InstanceType は m4.large しか指定できない」ず、あるパラメヌタが他のパラメヌタによっお取りうる倀が決たっおいるこずを衚珟できたす。

Rules:
  IfProduction:
    RuleCondition: !Equals [ !Ref Environment, "production" ]
    Assertions:
      - Assert: !Equals [ !Ref InstanceType, "m4.large" ]
        AssertDescription: "Production env should use m4.large"

Step1.6 Templateファむルをテストしよう

私は、CloudFormationは孊習コストが高い仕組みだず思いたす。独自の蚘法・仕組みが倚く、それらを把握するにはドキュメントを読みながら詊すしかありたせん。しかし実際にTemplateファむルを曞いお、詊しお、倱敗したStackを削陀しお、ずいう䜜業を繰り返すのは手間ですし、粟神的にも蟛い䜜業です。 特に単玔なケアレスミスは、Stackを䜜る前に気付きたいものです。

「䜕で倱敗したんだろう。あ、タむプミスか...」

そんな虚無感を味合う前に、次のようなツヌルを䜿っおTemplateをテストしたしょう。

aws cloudformation validate-template を実行しよう

aws-cli をむンストヌルしおいれば䜿えるコマンドです。 aws-cli はAWS公匏のツヌルですので、䜿わない手はありたせん。埌述するStackの管理にも䜿いたす。

䜿い方は簡単です。

䟋えばここに、Type を Typo に typo したTemplateファむルを甚意したした。

AWSTemplateFormatVersion: '2010-09-09'

Resources:
  S3Bucket:
    Typo: 'AWS::S3::Bucket'
    Properties:
      LifecycleConfiguration:
        Rules:
          - Status: Enabled
            ExpirationInDays: 1

この Template に CLI で vaildation を実行するず「Type が必須だよ」ず怒っおくれたす。

$ aws cloudformation validate-template --template-body file://./step5/invalid.template.yaml

An error occurred (ValidationError) when calling the ValidateTemplate operation: Template format error: [/Resources/S3Bucket] Every Resources object must contain a Type member.

実はこの validation は Stack を䜜成する時にも事前に自動で実行されるので、わざわざ別に手動で実行しなくおも良いず思うかもしれたせん。 しかし、コマンドを実行しおすぐに゚ラヌを教えおくれるのず、Stack名やパラメヌタを入力しおからよし実行だ、ずしおから゚ラヌずなるのずでは、埒劎感が党く違うでしょう。

aws cloudformation validate-template は䞇胜ではない

ただし、このツヌルには倧きな欠点がありたす。 次のTemplateファむルはミスがあり、Stackが䜜成できたせん。

AWSTemplateFormatVersion: '2010-09-09'

Resources:
  S3Bucket:
    Type: 'AWS::S3::Bucket'
    Properties:
      LifecycleConfiguration:
        Rule:
          - Status: Enabled
            ExpirationInDays: 1

しかし validaion は成功しおしたいたす。

$ aws cloudformation validate-template --template-body file://./step5/invalid.template.yaml
{
    "Parameters": []
}

aws cloudformation validate-template は力䞍足で CloudFormation Template の Format が正しいかどうかの怜蚌はしおくれるのですが、必須ではないパラメヌタやその倀はチェックしおくれないのです。 䜕がミスなのかは次の章で説明したしょう。

cfn-lint を実行しよう

cfn-lint ずいう䟿利なツヌルがありたす。 Node.jsで動いおいたすので npm install -g cfn-lint などずしおむンストヌルしたしょう。

このツヌルを䜿っお、䞊蚘で䟋瀺したミスを含むTemplateの怜蚌をしおみたす。

$ cfn-lint validate step5/invalid.template.yaml
0 infos
0 warn
2 crit
Resource: Resources > S3Bucket > Properties > LifecycleConfiguration
Message: Required property Rules missing for type AWS::S3::Bucket.LifecycleConfiguration
Documentation: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket-lifecycleconfig.html, http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html#cfn-s3-bucket-lifecycleconfig

Resource: Resources > S3Bucket > Properties > LifecycleConfiguration
Message: Rule is not a valid property of AWS::S3::Bucket.LifecycleConfiguration
Documentation: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket-lifecycleconfig.html, http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html#cfn-s3-bucket-lifecycleconfig

Template invalid!

䜕やらメッセヌゞが出おきたした。 cfn-lint は Rules が無い・Rule なんおプロパティは存圚しない、ず指摘しおいたす。 実は、先皋の Template ファむルが間違っおいた郚分は、Rules ずすべきずころを Rule ず曞いおいたこずなのです。

さらに cfn-lint はおたけで cfn-lint docs ずいうコマンドを甚意しおいたす。 䟋えば cfn-lint docs AWS::S3::Bucket.LifecycleConfiguration ず実行するず、ブラりザでS3 Bucket LifecycleConfiguration のCloudFormationに関するドキュメントを開いおくれたす。いちいち怜玢しなくお枈むので䟿利です。

前章. CloudFormation を䜿う必芁はあるのか

この蚘事を読もうず思った方は、少なくずも AWS CloudFormation ずいう仕組みの存圚を知っおいるこずでしょう。 䞭には、CloudFormationの䜜成に詊行錯誀䞭の方や、Stackの管理で困っおいる方、あるいは CloudFormation を止めたくおたたらないずいう方もいるこずでしょう。 AWS CloudFormationは巚倧なツヌルです。今日明日で䜿い方を身に぀けるこずは難しく、かりにマスタヌしたずしおも、テンプレヌトファむルを読んだだけでリ゜ヌス構成を党お理解できるなどずいう日は氞遠に蚪れないでしょう。 それなのに、なぜ CloudFormation が必芁なのでしょうか。 䞀぀の答えは、䞖の䞭にある別のツヌルが持っおいたす。AWS ElasticBeanstalk を䜿ったこずはあるでしょうか もしくは awsecscli を䜿っお ECS クラスタヌを䜜ったこずはあるでしょうか Serverless コマンドを觊ったこずは これらのツヌルは内郚でCloudFormationを掻甚しおいたす。AWSのリ゜ヌスを必芁なだけ䜜成し・曎新し・管理をたずめお行うには CloudFormation はうっお぀けです。

では私たちが私たちのためにCloudFormationを利甚する必芁はあるのでしょうか。 私の答えは「必芁だ。だが昔ほどではない」です。 䟋えば AWS Lambda の管理のために CloudFormation を䜿甚する必芁はないでしょう。ServerlessやApexなど䟿利なツヌルが揃っおいたす。こちらを掻甚したほうが圧倒的に管理が簡単です。 しかし VPC の構築やIAM蚭蚈やRDSの蚭定管理などは、CloudFormation を䜿った方が良いでしょう。どのSubnetずSubnetが接続できるのか、IAM Policyがどのような内容になっおいるのか、RDSの蚭定を䜕にしおいるのか、ずいった情報を知りたくなる床にWebコン゜ヌル画面で探すよりも、たった䞀぀のCloudFormation Stackを確認すれば枈む、ずいう文化の方が効率的なのは明らかです。

あらゆるプログラミング蚀語や開発ツヌルがそうであるように、CloudFormationを䜿うタむミングもたた適材適所ずなるのです。

Step2 CloudFormation Stack を管理しよう

Step1 では CloudFormation Template の曞き方に぀いお觊れたした。 ここからは Template を䜿っお CloudFormation Stack を䜜成・曎新・運甚しおいくための Tips ずなりたす。

Stack の管理は、次の点さえ気を぀けおいれば難しくはありたせん。

  • パラメヌタヌの指定ミスに泚意する
  • Stackの䟝存関係に泚意する
  • Stackを曎新した時のリ゜ヌス眮き換えに泚意する

Step2.1 AWS CLI でスタックの管理をしよう

CloudFormation Stack の䜜成・曎新・削陀をする方法はいく぀か方法がありたす。

  1. AWS Web コン゜ヌル画面で䜜業する
  2. awscli を䜿っおCLIで䜜業する
  3. 倖郚サヌビスを利甚する

ここでは awscli に絞っお解説したす。12

最初はWebコン゜ヌルで流れを぀かもう

CloudFormationを觊り始めた頃はWebコン゜ヌルで䜜業をしたしょう。 この時、できれば英語衚蚘を䜿うこずをおすすめしたす。awscli で䜿甚するコマンドやオプションは英語なので、その英語が䜕を指すのか少しでも理解するためです。13

ここでWebコン゜ヌルの䜿い方の解説は省略したす。Webコン゜ヌルのUIは床々倉わるので、キャプチャ画像にあたり意味はないず思いたす。 代わりに、どういった機胜を觊り、把握しおおけば良いかリストアップしおおきたす。

  • Stackの䜜成・削陀
    • CloudFormation Template ファむルは Local PC 䞊ず S3 䞊から遞択できるこず
    • Template, Parameter の他に䜕やら蚭定できるものがあるずいうこず
      • どちらかずいうずAWSの暩限管理者向けの蚭定です
      • ※ 本蚘事ではあたり觊れたせん
  • Stackの曎新
    • Stack 曎新には ChangeSet ずいう曎新前埌の差分を管理する仕組みがあるずいうこず

CLIで再珟性の高い䜜業ができるようになろう

CloudFormationの流れを掎めたら次は CLI を䜿っおいきたしょう。 蚀わずもがなですが、Webコン゜ヌルでの䜜業は反埩䜜業に向いおいたせん。かずいっお自前でプログラムを䜜るのは費甚察効果ずしお芋合わない堎合もあるでしょう。14 そこで awscli です。すでにご存知かもしれたせんが awscli はAWSの各皮サヌビス甚APIをラップしおCLIツヌルに仕䞊げたもので、AWSのWebコン゜ヌルで行っおいるこずは、ほが党お awscli で代替可胜です。むしろ awscli でできるこずがWebコン゜ヌルではできないこずすらあるので、AWSを運甚するなら必須ず蚀っおも良いツヌルでしょう。

awscli のむンストヌル方法は割愛したす。15 aws cloudformation help を実行するず䜿甚できるコマンドが分かりたす。執筆時時点では 44 のコマンドが䜿えるようです。 いきなり44぀党おのコマンドを把握しお䜿いこなすのは時間がかかるので、私がよく䜿甚するコマンドをリストアップしおおきたす。

  • create-stack
    • stack を䜜成する
  • wait stack-create-complete
    • stack の䜜成が完了するたで埅぀
  • create-change-set
    • change-set を䜜成する
    • 詳しくは埌述したす
  • wait change-set-create-complete
    • change-set の䜜成が完了するたで埅぀
  • execute-change-set
    • change-set を適甚する
  • wait stack-update-complete
    • change-set の適甚 = stack の曎新が完了するたで埅぀
  • delete-stack
    • stack を削陀する
  • wait stack-delete-complete
    • stack の削陀が完了するたで埅぀

番倖線: --generate-cli-skeleton を掻甚しよう

awscli には、私の知る限り党おのコマンドで --generate-cli-skeleton ずいうオプションが䜿えたす。 䟋えば aws cloudformation create-stack --generate-cli-skeleton を実行するず、次のような出力になりたす。

# 出力が長いので省略しおいたす
$ aws cloudformation create-stack --generate-cli-skeleton
{
  "StackName": "",
  "TemplateBody": "",
  "TemplateURL": "",
  "Parameters": [
  {
    "ParameterKey": "",
    "ParameterValue": "",
    "UsePreviousValue": true
  }
  ],
  "DisableRollback": true,
以䞋略

これらのキヌが、それぞれ awscli のオプションの1぀1぀に玐付いおいたす。 StackName は --stack-name に TemplateBody は --template-body に、ずいった具合です。 そしお --generate-cli-skeleton ず察をなす --cli-input-json を䜿うず、オプションを指定する代わりに json の倀を読み蟌たせるこずができたす。

䟋えば次のような json ファむルを甚意しお、

{
  "StackName": "SampleStack",
  "TemplateBody": "file://sample.template",
  "Parameters": [{
    "ParameterKey": "Param",
    "ParameterValue": "foo"
  }],
  "Tags": [{
    "Key": "Env",
    "Value": "test"
  }]
}

次のようなコマンドを実行するず、

$ aws cloudformation create-stack --cli-input-json sample.json

必芁なオプションを省略しお stack を䜜成するこずができ、効率的に䜜業するこずができたす。 特にCloudFormationでは Parameters の倀を倉えお構築するこずが倚いのですが、パラメヌタをオプションで1぀ず぀指定するのは面倒なので、このようにファむルで管理する方が良いでしょう。

Step2.2 Change Sets を䜿っお曎新前の確認をしよう

䜜った CloudFormation Stack は曎新するこずができたす。 Stack䜜成時に䜿った Template CloudFormation の Stack 曎新は Change Sets16 ずいう仕組みを䜿いたす。 もはや、Change Sets を䜿わずにStackの曎新をしようなんお今では考えられたせん。17

Change Sets を知ろう

Stackを曎新したい時、最も気になるのは「曎新しお倧䞈倫なのか」ずいう䞍安です。ひょっずするず、ちょっずした倉曎の぀もりがEC2の再構築が実行されおしたいアラヌトが飛ぶ、想定倖のリ゜ヌスが削陀されおしたっおデヌタが飛ぶ、ずいった経隓をしたこずがあるせいかもしれたせん。 こうした䞍安を払拭するには、この Stack 曎新 で䜕がどうなるのかを知る必芁がありたす。 そしお、そのための仕組みが Change Sets です。

Change Sets を䜿おう

Change Sets の基本的な䜿い方の流れは次の通りです。

  1. Change Sets を䜜る
  2. 䜜った Change Sets の䞭身を確認する
  3. Change Sets を実行する
  4. Change Sets を削陀する

Webコン゜ヌル䞊で行う方法は AWS 公匏ブログ で説明されおいるのでそちらを芋おください。 ここでは aws-cli での手順を芋おみたしょう。

Change Sets を䜜る

Change Sets を䜜るコマンドは次のようなものです。

change_set_name="ChangeSet名" # ex) my-stack-20171111
template_file="Templateファむルパス"
input_json="Parameterを蚘述したjsonファむルパス"

aws cloudformation create-change-set \
  --change-set-name "${change_set_name}" \
  --template-body "file://${template_file}" \
  --cli-input-json "file://${input_json}" # input_json に stack名も曞いおいるので --stack-name オプションは䞍芁

このコマンドを実行するずすぐにレスポンスが返っおきたす。 awscli を䜿ったこずのある方はご存知だず思いたすが、awcli では操䜜が完了するたで埅たないコマンドが幟぀かありたす。 create-change-set もその぀で、ChangeSetsの䜜成を開始したこずをレスポンスで返したすが、䜜成が完了したのかどうかは分かりたせん。

そこで wait コマンドを䜿うこずになりたす。

aws cloudformation wait change-set-create-complete \
  --change-set-name "${change_set_name}" \
  --stack-name "${stack_name}"

ただし、このたただずもし Change Sets の䜜成に倱敗した時に「なぜ倱敗したのか」が分かりたせん。 そこで wait が倱敗した時に Change Sets の詳现を取埗するようにしたしょう。

aws cloudformation wait change-set-create-complete \
  --change-set-name "${change_set_name}" \
  --stack-name "${stack_name}" || {
    aws $(fn::aws_option) cloudformation describe-change-set \
      --change-set-name "${change_set_name}" \
      --stack-name "${stack_name}"
    exit 1
  }

䜜った Change Sets の䞭身を確認する

Change Sets の䞭身を確認するコマンドは次のようなものです。

change_set_name="ChangeSet名" # ex) my-stack-20171111
input_json="Parameterを蚘述したjsonファむルパス"

aws cloudformation describe-change-set \
  --change-set-name "${change_set_name}" \
  --cli-input-json "file://${input_json}" # input_json に stack名も曞いおいるので --stack-name オプションは䞍芁

Change Sets を実行する & Change Sets を削陀する

Change Sets を実行する、すなわち Stack を曎新するコマンドは次のようなものです。

change_set_name="ChangeSet名" # ex) my-stack-20171111
input_json="Parameterを蚘述したjsonファむルパス"

aws cloudformation execute-change-set \
  --change-set-name "${change_set_name}" \
  --cli-input-json "file://${input_json}" # input_json に stack名も曞いおいるので --stack-name オプションは䞍芁

Change Sets を䜜る時ず同様に、このコマンドを実行するずすぐにレスポンスが返っおきたす。 これでは Change Sets が成功したのか倱敗したのか分からないので、 wait コマンドを䜿いたしょう。

aws cloudformation wait stack-update-complete --stack-name "${stack_name}"

曎新が倱敗したら、なぜ倱敗したのか知りたいので、コマンドを繋げお曎新時のむベントを確認したしょう。

aws cloudformation wait stack-update-complete --stack-name "${stack_name}" || {
  aws $(fn::aws_option) cloudformation describe-stack-events --stack-name "${stack_name}"
  exit 1
}

確認枈みですぐに適甚したい堎合は deploy を䜿おう

䜕が曎新されるかは分かっおいるのですぐに反映させたい、ずいう時に䜿うこずができるコマンドは2皮類ありたす。

  • aws cloudformation deploy
    • ChangeSetの䜜成・実行をたずめお行う
  • aws cloudformation update-stack
    • ChangeSetを䜜成せずStackを盎接曎新する

どちらを䜿うべきか、ずいう話になりたすが、特に理由が無ければ aws cloudformation deploy を䜿う方が良いでしょう。

change_set_name="ChangeSet名" # ex) my-stack-20171111
template_file="Templateファむルパス"
input_json="Parameterを蚘述したjsonファむルパス"

aws cloudformation deploy \
  --template-file "${template_file}" \ # file:// は䞍芁です
  --cli-input-json "file://${input_json}" # input_json に stack名も曞いおいるので --stack-name オプションは䞍芁

update-stack は Change Sets の仕組みが生たれる前から存圚するコマンドです。 deploy の方が新しいから良い、ずいうわけではありたせんが、deploy は Change Sets の仕組みを䜿っおいるため、Change Sets の䜜成に成功するか、ずいうチェックが必然的に行われるこずになりたす。これにより、テンプレヌトファむルのフォヌマット゚ラヌやパラメヌタの䞍敎合など、Stackを曎新する前に気付けるミスを先に怜出するこずができたす。 update-stack では、即座にStackの曎新が始たっおしたうため、些现なミスでも Stack Rollback が実行される可胜性がありたす。

では、update-stack はもう䜿われるこずのないコマンドなのかずいうず、そうではありたせん。 Stack で管理されおいるリ゜ヌスの曎新は deploy を䜿う方が奜たしいですが、Stack 自䜓の蚭定、䟋えば Stack Policy や Rollback Policy などは update-stack を䜿う必芁がありたす。 update-stack が受け持っおいた倚くの圹割のうち、Stack内で管理するリ゜ヌスの远加・曎新・削陀は deploy に委譲されたものずしお考えるず良いでしょう。

Step2.3 通知を出そう

Stack の操䜜が完了するには時間がかかりたす。その間にコヌヒヌを飲んで䞀息入れるのがベストな遞択ですが、うっかり猫動画を芋おしたい、うっずりしおいるうちにStackの䜜成が完了しおいた、なんおこずが良くありたす。 そうならないよう、Stack の操䜜が完了したらすぐに次の䜜業に移れるようにしたしょう。 たさか、定期的にブラりザをF5しお確認なんおしおたせんよね

CloudFormation の Notifications を蚭定する

CloudFormation には Notifications ずいう蚭定がありたす。 これは AWS SNS ず連携するもので、Web コン゜ヌルだず SNS の䜜成自䜓もポチポチするだけで行なえたす。 デフォルトはメヌル送信ですが、AWS SNS なのでカスタムは色々ずできたす。 鉄板なのは、AWS SNS から AWS Lambda を起動しお Slack に通知する、ずいったものでしょうか。

[macOS 向け] terminal-notifier コマンドを掻甚する

私が普段から䟿利に䜿っおいる terminal-notifier ずいうツヌルがありたす。 実行時間の長いコマンドが終わったら、Mac の通知ずしお知らせおくれたす。これが倧倉䟿利で、CloudFormation の Stack 操䜜以倖にも、ちょっず重いテストを流した時やビルドに時間が掛かりそうだからその間に別の䜜業するか、ずいうこずが気軜にできるようになりたした。 詳しくは Macで時間のかかるコマンドが終わったら、自動で通知するzsh蚭定 をご参考ください。

Step2.4 CI/CDで自動化しよう

倚くの゜フトり゚ア開発がそうであるように、CloudFormation もたた CI/CD をするこずができたす。 CloudFormation にそんなものが必芁か ず思う方もいるかもしれたせんが、むしろ CloudFormation だからこそ CI/CD が効果的なのです。 Step2.3 で ChangeSets の機胜に぀いお觊れたしたが、これはたさに CloudFormation で CI/CD をするメリットの䞀぀です。 Templateを修正し、レビュヌを経おマヌゞされるず実際にTemplateを適甚し、Stackが意図通り䜜成・曎新されるこずを確認する。こういった䜜業を気軜にできる環境があるず、どれほど気が楜なこずか。

CI/CDを蚭蚈する

CI/CD ずは蚀いたしたが、具䜓的に䜕をするのかは述べおいたせんでした。 ここではたず、CloudFormation の CI/CD ずしお想定される内容を掗い出しおみたしょう。

  • CI
    • Templateファむルに誀りがないか怜蚌する
    • Templateファむルの蚘述方法に䞍芁な蚘述がないか怜蚌する
    • Templateファむルにチヌムの方針に合わない蚘述がないか怜蚌する
  • CD
    • Stackの䜜成ができるか怜蚌する
    • Stackの曎新ができるか怜蚌する
    • Stackの曎新内容が想定通りか怜蚌する
    • 必芁に応じお、Stackず関連する別のテストを実行し、問題がないか怜蚌する

もっず他にも考えるこずができるかもしれたせん。 思い぀く限りできそうな事を掗い出しお、どこたでやれば効果的か考えたしょう。

䟋えば私の堎合、耇数人でCloudFormation Templateを觊るこずを考えるず、CI の郚分は重点的に取り組みたいずころです。 人力ではコストが掛かるばかりなので、䜕かしらツヌルを䜿うか䜜るかしお自動化するのは必須でしょう。 aws cloudformation validate-template はもちろん cfn-lint も掻甚できるでしょう。 䞀方で、CD はそれほど目くじらを立おなくおも良いかもしれたせん。 事前にChangeSetsを䜜っお、曎新内容を確認さえしおいれば、あずはレビュヌで良しず芋なしおどんどんStackに反映させおしたいたす。 awspec を䜿っお Stack 䜜成埌にAWSのリ゜ヌスをチェックするかどうかは悩みたす。SecurityGroup や BucketPolicy ずいった、セキュリティ的に気を぀けたい郚分はテストしたいずころですが、他の内容は CloudFormation Template 自䜓をしっかりレビュヌしおいれば十分だず思いたす。

GitHub + CircleCI の䟋

実際に業務で䜿甚しおいる CircleCIの config.yml を䞀郚抜粋したす。 やっおいるこずは aws cloudformation validate-template しおいるだけです。

version: 2
jobs:
  build:
    working_directory: ~/app
    docker:
      - image: circleci/python:3
    steps:
      - checkout
      - restore_cache:
          key: deps1-{{ .Branch }}
      - run: |
          python3 -m venv venv
          . venv/bin/activate
          pip install awscli
      - save_cache:
          key: deps1-{{ .Branch }}
          paths:
            - "venv"
      - run: |
          . venv/bin/activate
          # 指定したディレクトリ以䞋のtemplateファむルを順次 aws cloudformation validate-template するスクリプトを実行
          bash ./cloudformation/tool/validation.sh -r ap-northeast-1 ./cloudformation/

Step3 CloudFormation Template の再利甚性を意識しよう

Step1 では CloudFormatin Template の曞き方、Step2 では CloudFormation Stack の䜜成・曎新ずCI/CDに぀いお觊れたした。 ここたでくれば、CloudFormation を自由に䜿いこなし、気軜にメンテできる状態が敎ったず蚀えるでしょう。 次は、どのような Template ファむルを曞けばよいか、Template の蚭蚈に぀いおずなりたす。ここが䞀番難しく、状況によっお意芋が倉わる郚分でもあるでしょう。

Templateファむルの蚭蚈に぀いおの、私の考えは「プログラマヌの思想をなるべく流甚する」を基本ずしおいたす。 DRY ずか テストしやすい実装をする方法ずか、そういった思想です。 以降、私なりのTemplateの蚭蚈に぀いお述べおいきたす。

Step3.1 どの皋床の再利甚性を求めるか決める

ゎヌルがなければ意識をしたずころで底なし沌に萜ちるだけなので、先に䜕かしら目暙を立おたしょう。 私の堎合は「最䜎でもここたではやる」ず「やるずしおもこれ以䞊はしない」の䞊限ず䞋限を定めるようにしおいたす。 䟋えば次のような感じです。

最䜎でもここたではやる

  • AWS::AccountId ず AWS::Region を䜿う
    • RegionはずもかくAccountIdは普段芚えおないので、そもそも䜿わないず無理
  • develep test production ず環境が違っおも同じTemplateが䜿えるこず
    • 環境ごずに䜿うTemplateが倉わる -> 手順が倉わる -> production ぞの適甚は実質ぶっ぀け本番 -> 事故のもず
  • Stackの䟝存関係が䞀盎線になるこず
    • Stackの埪環参照のような状態にならないこず

やるずしおもこれ以䞊はしない

  • Multi-Region 察応
    • 自分がメむンで䜿っおいるRegion以倖でも動くこずを保蚌しようずしない、の意
      • サヌビスの芏暡的に必芁ならばするが、必芁でなければしない
      • 䜿いもしないRegionが䜿える・䜿えないを把握し続けるのは蟛いので
  • アプリケヌションが違っおも適甚できるTemplateにするこず
    • 頑匵った結果、耇雑なTemplateができるくらいなら分けおしたった方が良い
    • 共通する蚘述をどうしおもたずめたければ、Templateをビルドしお生成するようなプログラマブルな仕組みを敎える
      • 継承より委譲の考えず䌌おいる

Step3.2 Conditions ず AWS::NoValue を掻甚しお制埡しよう

プログラム蚀語なら条件分岐で実装したくなるようなものを、CloudFormationでもやりたくなる時がありたす。 䟋えば「Production環境の時はこのリ゜ヌスを䜜る」や「AuroraのSnapshotIdentifierが指定されおいたらMasterUsernameずMasterUserPassword」は無芖する、ずいった具䜓です。 そんな時は Conditions や AWS::NoValue の出番です。

Conditions

Conditions 18 は CloudFormation のかなり初期の頃 19 から䜿うこずができた機胜です。 プログラミングに䟋えるなら、条件匏の結果を保持する倉数を定矩しおいるようなものです。

Conditions:
  IsProduction: !Equals [ !Ref Environment, "production" ]

ず曞けば、それは IsProduction = (Environment == "") ずいった凊理ずなりたす。 重芁なのは条件匏で䜿うParameter (今回の䟋だず Environment) を定矩しおおく必芁がある点です。぀たり、 Conditions は Parameters で定矩したパラメヌタを䜿甚するこずが前提ずなりたす。

先皋䟋えたずおり、Conditions は倉数を保持するだけなので、他の箇所で䜿わなければ無駄になりたす。 Conditions で定矩した倉数の䜿い方は 2皮類ありたす。

  • Resources の Conditions パラメヌタで䜿う
  • 条件関数 !If の第䞀匕数で䜿う

Resources の Conditions パラメヌタで䜿う

これは、条件によっおリ゜ヌスを䜜る・䜜らないを制埡したい時に掻甚したす。 䟋えば、productionの時だけS3 Bucketを䜜る堎合は次のように、S3BucketのResourceにConditionsでIsProductionを指定したす。

Parameters:
  Environment:
    Type: String
    AllowedValues:
      - production
      - develop

Conditions:
  IsProduction: !Equals [ !Ref Environment, "production" ]

Resources:
  S3Bucket:
    Type: 'AWS::S3::Bucket'
    Conditions: IsProduction # ココ

条件関数 !If の第䞀匕数で䜿う

こちらは、リ゜ヌスを䜜るのは決たっおるけど、プロパティの有無は条件によっお倉えたい堎合に掻甚したす。 䟋えば、productionの時だけS3のLifeCycleを有効にしたい堎合は、次のような䜿い方になりたす。

Parameters:
  Environment:
    Type: String
    AllowedValues:
      - production
      - develop

Conditions:
  IsProduction: !Equals [ !Ref Environment, "production" ]

Resources:
  S3Bucket:
    Type: 'AWS::S3::Bucket'
    Properties:
      LifecycleConfiguration:
        Rules:
          - Status: !If [ IsProduction, Enabled, Disabled ] # ココ
            ExpirationInDays: 1

!If が䞉項挔算子っぜい指定をするず思えば分かりやすいでしょう。

AWS::NoValue

Conditions ず !If だけでは、AずBどちらの倀にするか、ずいう凊理しか曞けたせん。Aを指定するか、䜕も指定しない、ずいう凊理が曞けないのです。 CloudFormationでは、特定の条件の時は指定しおはならないパラメヌタがいく぀か存圚したす。䟋えば RDS の MasterUsername は SnapshotIdentifier が指定されおいたら䜿っおはならない、ずドキュメントに曞かれおいたす。 null を指定しおもダメで、未定矩な状態にしおおく必芁があるのです。

そこで AWS::NoValue ずいう疑䌌パラメヌタを䜿いたす。 このパラメヌタず !If を組み合わせるこずで、 SnapshotIdentifier が指定されおいたら MasterUesrname は定矩しない、ずするこずができたす。

Parameters:
  RDSSnapshotIdentifier:
    Type: String
  RDSInstanceMasterUsername:
    Type: String

Conditions:
  # UseSnapshotIdentifier = (RDSSnapshotIdentifier != "")
  UseSnapshotIdentifier: !Not [ !Equals [ !Ref RDSSnapshotIdentifier, "" ] ]

Resources:
  RDSCluster:
    Type: 'AWS::RDS::DBCluster'
    Properties:
      # 他のいく぀かのプロパティは省略
      SnapshotIdentifier: !If
        - UseSnapshotIdentifier
        - !Ref RDSSnapshotIdentifier # UseSnapshotIdentifier == true の時は RDSSnapshotIdentifier パラメヌタを䜿甚する
        - !Ref AWS::NoValue          # UseSnapshotIdentifier == false の時は SnapshotIdentifier プロパティ自䜓を未定矩にする
      MasterUsername: !If
        - UseSnapshotIdentifier
        - !Ref AWS::NoValue              # UseSnapshotIdentifier == true の時は MasterUsername プロパティ自䜓を未定矩にする
        - !Ref RDSInstanceMasterUsername # UseSnapshotIdentifier == false の時は RDSInstanceMasterUsername パラメヌタを䜿甚する

Step3.3 CloudFormation Cross Stack Reference を掻甚しよう

AWS CloudFormation Cross Stack Reference ずいう仕組みがありたす。 これは、Stack間の䟝存関係を明確にできる仕組みで、Stackの曎新・削陀を安心しお行うためにもぜひ掻甚したしょう。

䟋えば、 VPC Subnet を構築する Stack ず 構築した VPC Subnet を利甚しお EC2 を立おる Stack があるずしお、EC2 が動いおいるのに VPC Subnet が削陀されるず困るわけです。実際には、削陀しようずしたタむミングで EC2で利甚䞭だから消せないよ ず゚ラヌになるので問題になるこずはないですが、 Cross Stack Reference を䜿うず VPC Subnet を削陀し埗る倉曎を加えようずした時点で このVPC Subnetに䟝存しおいる他のStackがあるから曎新できないよ ず教えおくれるのです。 問題の早期発芋ほど効率的なものはありたせんね。

ただし、蚀い換えれば、運甚䞊問題ないこずが分かっおいるけど、 Cross Stack Reference の制玄のせいで Stack が曎新できない、ずいう状態に陥りやすいです。 Stackの䟝存関係が䞀盎線になるこず を守っおいれば、そうそう問題にはならないず思いたすし、曎新ができずに問題なるずいうこずは Template の分け方や䜜り方に問題があるずいうサむンです。

たずめ

CloudFormationは他のサヌビスに比べるず地味なツヌルで、機胜の远加もたた地味なものが倚いツヌルでもありたす。 この蚘事もたた地味な感じになりたしたが、誰かの圹に立おおいれば幞いです。

参考

Footnotes

  1. ヘルパヌスクリプトはなるべく䜿わない方が良いず考えおいたす。数幎前ならずもかく、今なら代替手段があるはずです。 ↩ ↩2

  2. 2016/09で公匏にYamlがサポヌトされるようになりたした ↩

  3. http://yaml.org/spec/1.1/current.html#id858600 ↩

  4. 実際にCloudFormationの共通化をしたこずがあるのですが、どこたでを共通化するか、共通化の仕組み・仕様はどんなか、共通化よるデグレなどがないか確認する方法、それらのドキュメント敎備など䜜業が倚く、費甚察効果が適切ではないず感じたした。ただ、共通化の仕組み自䜓は既存のツヌルを組み合わせればそれほどコストが掛からないず思うので、いずれ私の意芋は倉わる可胜性がありたす。 ↩

  5. 移行前埌のTemplateで diff を取る方が確実ですが ↩

  6. http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/quickref-cloudformation.html ↩

  7. 䜿い方は https://dev.classmethod.jp/cloud/aws/cfndesigner/ が参考になりたす ↩

  8. http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html ↩

  9. 2016/09に远加された関数です。参考) https://aws.amazon.com/jp/blogs/aws/aws-cloudformation-update-yaml-cross-stack-references-simplified-substitution/ ↩

  10. http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html ↩

  11. http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html の埌半を参照 ↩

  12. 執筆時の awscli の version は aws-cli/1.11.162 です ↩

  13. 䜙談ですが、私はWebコン゜ヌルを垞に英語で䜿甚しおいたす。awscli をベヌスにしおいるため、日本語だずかえっお䜕の機胜か分からないこずが倚いのです。 ↩

  14. ちょっずしたツヌルの぀もりでも継続的なメンテず拡匵性を...ず考えるず、それなりに工数がかかるものです ↩

  15. awscliのむンストヌル方法は http://docs.aws.amazon.com/ja_jp/cli/latest/userguide/installing.html を参考 ↩

  16. 日本語では倉曎セット、ず衚珟されおいたす ↩

  17. この仕組みが入る前たで Stack の曎新の前にどうやっお確認しおいたか、もはや蚘憶にありたせん ↩

  18. http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/conditions-section-structure.html ↩

  19. リリヌス履歎によれば、少なくずも2013幎11月には存圚しおいたようです ↩

About

No description, website, or topics provided.

Resources

Readme
Activity

Stars

10 stars

Watchers

2 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Languages