AWSの全てをコードで管理する方法〜その理想と現実〜

C47bda32c8455a59471cd7e19c32c074?s=47 濱田孝治
November 01, 2019

 AWSの全てをコードで管理する方法〜その理想と現実〜

AWSの最大の特徴の一つ、「コードによるインフラの運用管理」

アプリケーションやインフラ運用のさらなる効率化を目指す時、IaC(Infrastructure as Code)の導入は必須と言えます。その効果は絶大ですが、下手に導入してしまうと逆に運用管理自体の硬直化を招き「最初は楽しかったのに、今はなんでこんな辛いんだろう…」という気持ちになってしまいます。

このセッションでは、CloudFormationについてそのIaCの手段について触れつつ、各運用現場に即したIaCを導入するために考えるべきことについて、お話します。

C47bda32c8455a59471cd7e19c32c074?s=128

濱田孝治

November 01, 2019
Tweet

Transcript

  1. AWSの全てを コードで管理する⽅法 〜その理想と現実〜 濱⽥孝治(ハマコー)

  2. スライドは後で⼊⼿することが出来ますので 発表中の内容をメモする必要はありません。 写真撮影をする場合は フラッシュ・シャッター⾳が出ないようにご配慮ください Attention

  3. 3 ⾃⼰紹介 濱⽥孝治(ハマコー) •2017年9⽉⼊社(元独⽴系SIer) •AWS事業本部コンサルティング部 •好きなサービス •CloudFormation •ECS、Fargate、EKS

  4. 4 @hamako9999 ハマコー

  5. 5 #cmdevio #cmdevio5

  6. 6 みなさん AWSをコードで管理することに どんなイメージをお持ちでしょうか︖

  7. 7 CloudFormation

  8. 8 CloudFormationの位置付け CloudFormation VPC Public subnet Amazon EMR Amazon Kinesis

    Data Firehose Amazon Athena Amazon Simple Notification Service Amazon Simple Queue Service Amazon EC2 Amazon Elastic Container Service AWS Lambda AWS Fargate Amazon WorkSpaces AWS IoT Core Amazon Personalize Amazon CloudWatch Amazon Simple Storage Service (S3) Amazon RDS
  9. 9 めちゃくちゃ強⼒ だけど、つかいこなしが難しい

  10. 10 CloudFormationを 知らないとどうなるか︖

  11. 11 これから⻑くAWSを運⽤していく時 その効率化の選択肢を捨てることになる

  12. 12 なぜハマコーはここに⽴っているのか︖ Infrastructure as Codeの可能性を感じてもらいたい 今のあなたの⽇常業務が劇的に効率化する可能性あり Infrastructure as Codeの危険性もしってもらいたい あまり準備せずにいきなり導⼊するとインフラが溶ける可能

    性あり
  13. 13 40分後みなさんにこうなってもらいたい Infrastructure as Code未体験の⼈ その可能性に気づきCloudFormationを書きたくてうずうず する Infrastructure as Code体験済みの⼈

    今の運⽤を⾒直すためのきっかけとなる
  14. 14 みなさんのこれからの AWSライフがより良いものに なることを願って

  15. 15 Infrastructure as Codeを極めるまで 1.Infrastructure as Codeを理解する 2.CLIで実⾏する 3.複数リソースを作成する 4.運⽤上の⾟みを理解する

    5.パイプラインでインフラ構築を⾃動化する
  16. 16 Infrastructure as Codeを極めるまで 1.Infrastructure as Codeを理解する 2.CLIで実⾏する 3.複数リソースを作成する 4.運⽤上の⾟みを理解する

    5.パイプラインでインフラ構築を⾃動化する
  17. 17 Infrastructure as Codeとはなにか︖ コードでインフラを定義する⼿法 Resources: FirstVPC: Type: AWS::EC2::VPC Properties:

    CidrBlock: 10.0.0.0/16 FirstVPC 10.0.0.0/16 template (YAML形式)
  18. 18 Infrastructure as Codeとはなにか︖ テンプレートファイルにはリソースの状態を定義するた め、同じテンプレートを複数回実⾏しても、インフラは 更新されない Resources: FirstVPC: Type:

    AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 FirstVPC 10.0.0.0/16 template (YAML形式) 何度実⾏しても AWS側は変わらない
  19. 19 Infrastructure as Codeとはなにか︖ aws cliで作成する場合 $aws ec2 create-vpc --

    cidr-block 10.0.0.0/16 VPC 10.0.0.0/16 create-vpc.sh (Shell形式)
  20. VPC 10.0.0.0/16 VPC 10.0.0.0/16 VPC 10.0.0.0/16 20 Infrastructure as Codeとはなにか︖

    aws cliは処理を定義するため、複数回実⾏した場合、 その処理が毎回実⾏され、そのたびにインフラ側が更新 される $aws ec2 create-vpc -- cidr-block 10.0.0.0/16 VPC 10.0.0.0/16 create-vpc.sh (Shell形式) 実⾏するだけ インフラは増えていく
  21. 21 代表的なInfrastructure as Codeの⼿法 • AWS CloudFormation • Terraform by

    HashiCorp • Cloud Development Kit(CDK)
  22. 22 代表的なInfrastructure as Codeの⼿法 • AWS CloudFormation • Terraform by

    HashiCorp • Cloud Development Kit(CDK) 今⽇のメインコンテンツ
  23. 23 CloudFormationの概要 • テンプレートファイルでAWSリソースをプロビジョ ニングするサービス • テンプレートベースで作成〜変更〜削除も可能 • CloudFormation⾃体の追加料⾦なし AWS

    CloudFormation template (JSON/YAML) Stack (リソース) Amazon EC2 AWS Lambda Amazon RDS Amazon Simple Storage Service (S3)
  24. 24 CloudFormationの概要 • テンプレート • CloudFormationの最も要となる部分 AWSTemplateFormatVersion: '2010-09-09' Description: codecommit

    and ecr Parameters: accountAllias: Type: String accountAlliasLowerCase: Type: String Resources: ecr: Type: AWS::ECR::Repository Properties: RepositoryName: !Sub ${accountAlliasLowerCase}-ecr Outputs: ecr: Value: !GetAtt ecr.Arn Export: Name: ecr • テキストファイルで記述 • JSON/YAML • スタックのリソース状態 を記述 • リソースを記載する順番 は関係なし (CloudFormationが⾃動 的に解決)
  25. 25 CloudFormationの概要 引⽤元︓https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-aws-cloudformation

  26. 26 CloudFormationの概要 引⽤元︓https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-aws-cloudformation ほぼ必須 取扱注意 まま使う ほぼ必須

  27. 27 CloudFormationの概要 • AWSのサービス全てに対応しているわけではない • ただ、普通に使うサービスはほぼ網羅されている ASK AmazonMQ Amplify Console

    API Gateway API Gateway V2 Application Auto Scaling App Mesh AppStream 2.0 AppSync Athena AWS Auto Scaling Amazon EC2 Auto Scaling AWS Backup AWS Batch AWS Budgets Certificate Manager AWS Cloud9 CloudFormation CloudFront AWS Cloud Map CloudTrail CloudWatch [CloudWatch Logs] CloudWatch イベント CodeBuild CodeCommit CodeDeploy CodePipeline CodeStar Amazon Cognito Config AWS Data Pipeline DAX Directory Service DLM DMS Amazon DocumentDB DynamoDB EC2 Amazon ECR ECS EFS EKS ElastiCache Elasticsearch Elastic Beanstalk Elastic Load Balancing ElasticLoadBalancingV2 Amazon EMR FSx GameLift AWS Glue GuardDuty IAM Inspector IoT IoT1Click IoT Analytics IoTEvents AWS IoT Greengrass AWS IoT Things Graph Amazon Kinesis KinesisAnalytics Amazon Kinesis Data Analytics V2 Amazon Kinesis Data Firehose KMS LakeFormation Lambda ManagedBlockchain MediaLive MediaStore MSK Amazon Neptune OpsWorks OpsWorks-CM Pinpoint PinpointEmail QLDB RAM RDS Amazon Redshift RoboMaker Route 53 Route 53 Resolver Amazon S3 Amazon SageMaker Secrets Manager Service Catalog SecurityHub SES Amazon SimpleDB Amazon SNS Amazon SQS ステップ関数 Systems Manager AWS SFTP WAF WAF Regional WorkSpaces 共有プロパティタイプ
  28. 28 CloudFormationを使う主なメリット • インフラの管理を簡略化 • ⼀度テンプレートからスタックを作成しておくと変更が簡 単。また、スタック単位でのリソース⼀括削除も可能

  29. 29 CloudFormationを使う主なメリット • インフラの管理を簡略化 • ⼀度テンプレートからスタックを作成しておくと変更が簡 単。また、スタック単位でのリソース⼀括削除も可能 • インフラを簡単に複製可能 •

    テンプレートを使い回すことで、複数リージョンへのイン フラ展開が簡単
  30. 30 CloudFormationを使う主なメリット • インフラの管理を簡略化 • ⼀度テンプレートからスタックを作成しておくと変更が簡 単。また、スタック単位でのリソース⼀括削除も可能 • インフラを簡単に複製可能 •

    テンプレートを使い回すことで、複数リージョンへのイン フラ展開が簡単 • インフラの変更管理が可能 • テンプレートのテキストファイルをベースにすることで バージョン管理システムによるインフラ管理が可能
  31. 31 突然の宣伝 ⼀番最初の取っ掛かりで迷ったら 「CloudFormation ⼊⾨」 でググってみよう

  32. 32 最初の⼊⾨にはこちらがオススメ https://dev.classmethod.jp/cloud/aws/cloudformation-beginner01/

  33. 33 第⼀段階突破︕ これで皆さん Infrastructure as Codeの第⼀歩を 踏み出しました︕︕

  34. 34 Infrastructure as Codeを極めるまで 1.Infrastructure as Codeを理解する 2.CLIで実⾏する 3.複数リソースを作成する 4.運⽤上の⾟みを理解する

    5.パイプラインでインフラ構築を⾃動化する
  35. 35 CloudFormationの実⾏⽅法候補 • マネジメントコンソール • CLI

  36. 36 そもそもの話 Infrastructure as Code のメリットってなんでしたっけ︖

  37. 37 CloudFormationを使う主なメリット(再掲) • インフラの管理を簡略化 • ⼀度テンプレートからスタックを作成しておくと変更が簡 単。また、スタック単位でのリソース⼀括削除も可能 • インフラを簡単に複製可能 •

    テンプレートを使い回すことで、複数リージョンへのイン フラ展開が簡単 • インフラの変更管理が可能 • テンプレートのテキストファイルをベースにすることで バージョン管理システムによるインフラ管理が可能
  38. 38 CloudFormationを使う主なメリット(再掲) • インフラの管理を簡略化 • ⼀度テンプレートからスタックを作成しておくと変更が簡 単。また、スタック単位でのリソース⼀括削除も可能 • インフラを簡単に複製可能 •

    テンプレートを使い回すことで、複数リージョンへのイン フラ展開が簡単 • インフラの変更管理が可能 • テンプレートのテキストファイルをベースにすることで バージョン管理システムによるインフラ管理が可能 そもそも CloudFormationの実⾏そのものに 再現性が必須
  39. 39 CloudFormationの実⾏⽅法結論 • マネジメントコンソール • CLI ⾃然とこちらが候補になる

  40. 40 ここで最⼤の注意点 AWS CLIでCloudFormationを 実⾏するとき create-stack、update-stackではなく deployをつかうこと

  41. 41 各コマンドの挙動の違い • create-stack、update-stack • 何故かコマンドに冪等性がない • スタックが無いときはcreate→2回⽬以降はエラー • スタックが有るときはupdate→1回⽬はエラー

    • コマンドが⾮同期で実⾏される→別途結果を待ち受ける必要有り • 関連コマンドを使い分ける必要がある • wait stack-create-complete • create-change-set • wait change-set-create-complete • execute-change-set • wait stack-update-complete • wait stack-delete-complete
  42. 42 各コマンドの挙動の違い • deploy(推奨) • 新規も更新もこのコマンドで完結 • チェンジセット(後述)が必ず作成される • validate-templateの実⾏とか流さなくてもdeployするだけでエ

    ラーは把握可能 • コマンドが同期的に実⾏される→スタック作成完了時に結果が戻 る
  43. 43 #!/bin/bash CFN_TEMPLATE=vpc.yml CFN_STACK_NAME=vpc # テンプレートの実⾏ aws cloudformation deploy --stack-name

    ${CFN_STACK_NAME} -- template-file ${CFN_TEMPLATE} ¥ --parameter-overrides ¥ NameTagPrefix=prd ¥ VPCCIDR=10.70 実⾏シェルの例
  44. 44 CloudFormationの闇 ここで 本当にあった怖い話を します

  45. 45 怖い話(1) • CodeCommitを定義したテンプレートを作成 • テンプレート︓App1Repos.yaml • 「Web」と「Proxy」の2つのCodeCommitを定義 • スタック︓AppRepos

    AWS CloudFormation App1Repos.yaml AppRepos Web (CodeCommit) Proxy (CodeCommit)
  46. 46 怖い話(2) 別のアプリ⽤の CodeCommitほしいな もういっちょテンプレート作るか

  47. 47 怖い話(3) • 別のCodeCommitを定義したテンプレートを作成 • テンプレート︓App2Repos.yaml • 「Sidecar」と「Broker」の2つのCodeCommitを定義 • スタック︓AppRepos

    AWS CloudFormation App2Repos.yaml AppRepos Sidecar (CodeCommit) Broker (CodeCommit)
  48. 48 怖い話(4) 賢明な皆さん 何が起こったかおわかりでしょうか

  49. 49 怖い話(5) • スタック名を最初のテンプレート実⾏時と同じものを 使ったため、元のテンプレートで定義した CodeCommitが跡形も無く消えました AWS CloudFormation App2Repos.yaml AppRepos

    Sidecar (CodeCommit) Broker (CodeCommit) Web (CodeCommit) Proxy (CodeCommit)
  50. 50 怖い話からの学び CloudFormationは 扱い⽅を間違えると 劇薬になりうる

  51. 51 怖い話からの学び まずは チェンジセットを知ろう

  52. 52 チェンジセットとは • すでにあるスタックを更新するとき、事前にスタック に対する変更点を出⼒する機能 AWS CloudFormation App2Repos.yaml (template) AppRepos

    (Stack) Change set deployするときは 必ず作成されている
  53. 53 チェンジセットとは • 先程の例だと、実はこのようなチェンジセットが作成 されていた。これを⾒ておけば事故は防げた。 アクション欄にAdd or Removeされるリ ソースが表⽰されている

  54. 54 チェンジセットとは • deployするときデフォルトではチェンジセットの適 ⽤まで⾃動で実⾏される • チェンジセット作成して⽌める場合は、--no- execute-changesetを使う AWS CloudFormation

    App2Repos.yaml (template) AppRepos (Stack) Change set --no-execute-changeset 指定でここで⽌まる デフォルトではStackに 即反映される
  55. 55 実⾏シェルの例(改善例) #!/bin/bash CHANGESET_OPTION="--no-execute-changeset" if [ $# = 1 ]

    && [ $1 = "deploy" ]; then echo "deploy mode" CHANGESET_OPTION="" fi CFN_TEMPLATE=App2Repos.yml CFN_STACK_NAME=AppRepos # テンプレートの実⾏ aws cloudformation deploy --stack-name ${CFN_STACK_NAME} --template- file ${CFN_TEMPLATE} ${CHANGESET_OPTION} ¥ --parameter-overrides ¥ NameTagPrefix=prd ¥ VPCCIDR=10.70
  56. 56 実⾏結果はGUIで⾒よう︕ • 実⾏するのはCLIでも実⾏結果はGUIが素敵

  57. 57 第⼆段階突破 ここまでで CloudFormationを実⾏するための 基礎を習得できました︕

  58. 58 Infrastructure as Codeを極めるまで 1.Infrastructure as Codeを理解する 2.CLIで実⾏する 3.複数リソースを作成する 4.運⽤上の⾟みを理解する

    5.パイプラインでインフラ構築を⾃動化する
  59. 59 CloudFormationに慣れてくると ありとあらゆるリソースを CloudFormationで作りたくなってくる︕︕

  60. 60 典型的な⼀式を作る時どう作るか︖ • VPC、ネットワーク、SecurityGroup、ALB、EC2、 RDSをCloudFormationで作りたい • ⼀つのテンプレートに全て書いても良いが、余裕で 1000⾏を超える → メンテできる︖

  61. 61 典型的な⼀式を作る時どう作るか︖ • VPC、ネットワーク、SecurityGroup、ALB、EC2、 RDSをCloudFormationで作りたい • ⼀つのテンプレートに全て書いても良いが、余裕で 1000⾏を超える → メンテできる︖

    テンプレートやスタックの分割を どうするかを必ず考える必要がある
  62. 62 スタックを分割するときに考えるべきこと • スタックに含めるリソースの数 • テンプレートが⼤きくなると可読性が 著しく下がるのをどうするか︖ • リソースの依存関係 •

    どのリソースがどのリソースを参照す るか︖ • ライフサイクル • リソースに対して変更が⼊る頻度は︖ • リソース変更の権限 • 誰がそのリソースを変更するのか︖ Amazon EC2 Amazon RDS Amazon VPC Security group Elastic Load Balancing (ELB)
  63. 63 スタックの分け⽅の実例 Amazon EC2 Amazon RDS Amazon VPC Security group

    Elastic Load Balancing
  64. 64 スタックの分け⽅の実例 • 依存関係をシェルのファ イル名のプレフィックス で明⽰ • シェル実⾏順と依存関係 がひと⽬で分かる •

    テンプレートは別ディレ クトリにまとめても良い USFF  ᵓᴷᴷWQDTI ᵓᴷᴷTFDVSJUZHSPVQTI ᵓᴷᴷBMCTI ᵓᴷᴷFDTI ᵓᴷᴷSETTI ᵓᴷᴷBMCZNM ᵓᴷᴷFDZNM ᵓᴷᴷSETZNM ᵓᴷᴷTFDVSJUZHSPVQZNM ᵋᴷᴷWQDZNM
  65. 65 スタックの分け⽅の実例 実⾏シェル テンプレート スタック名 含まれるリソース 010-vpc.sh vpc.yml vpc •

    VPC • IGW、NGW • RouteTable • Subnet • EIP 020-security- group.sh securitygroup.yml securitygroup • SecurityGroup 030-alb.sh alb.yml alb • ApplicationLoadbalancer • TargetGroup 040-ec2.sh ec2.yml ec2 • EC2 • IAM Role • IAM Policy 050-rds.sh rds.yml rds • RDS • SubnetGroup • ParameterGroup
  66. 66 当然出てくる疑問 スタック分けるのは良いけど スタック間でのリソースの参照⽅法は どうするのか︖ (EC2作るときのサブネットIDとか)

  67. 67 スタック間でリソースを参照する⽅法 • ⽅法①︓クロススタック参照を使う • CloudFormationマネージドな仕組み • 基本はこれ(ハマコー⼀番好きなやつ) • ⽅法②︓ダイナミック参照を使う

    • パラメータストアやSecrets Managerを参照 • ⽅法③︓シェルで頑張る • テンプレートを呼び出す前にシェルでパラメータを頑張っ て作る • なにげに汎⽤性は⼀番⾼い
  68. 68 ⽅法①︓クロススタック参照 • テンプレートのOutputにパラメータ名を付与 • 別のテンプレートでパラメータ名を指定して参照 Outputs: PublicSubnet1a: Value: !Ref

    PublicSubnet1a Export: Name: PublicSubnet1a Type: AWS::EC2::Instance Properties: SubnetId: !ImportValue PublicSubnet1a
  69. 69 ⽅法①︓クロススタック参照 Amazon EC2 Amazon RDS Amazon VPC Security group

    Elastic Load Balancing • あらかじめ参照されるスタックの⽅で名前決めてエク スポートしておけば、全スタックから参照できる
  70. 70 ⽅法①︓クロススタック参照(注意点) Amazon EC2 Amazon RDS Amazon VPC Security group

    Elastic Load Balancing • 参照しているスタックがある場合、参照元スタックで そのリソースの削除や変更ができない スタック削除や変更しようとすると 「参照先があるから無理」とエラーになる →運⽤上致命傷になりうるので注意
  71. 71 ⽅法①︓クロススタック参照が駄⽬なパターン • ECSのタスク定義とサービスの関係のように、更新時 参照元を先に変更する必要があるリソースはクロスス タック参照しては駄⽬ Amazon Elastic Container Service

    Task:10 Service Task:11 Service Taskのバージョンを11にあげようと思っても Serviceからクロススタック参照しているため変更できない
  72. 72 ⽅法②︓ダイナミック参照 • テンプレートから直接AWS Systems Managerのパ ラメータストアや、AWS Secrets Managerを参照 する

    Template AWS Secrets Manager Parameter Store
  73. Resources: rds: Type: AWS::RDS::DBInstance Properties: MasterUserPassword: {{resolve:ssm-secure:RDSMasterUserPassword:10}} 73 ⽅法②︓ダイナミック参照 •

    予めシェルやWebコンソール、もしくは、 CloudFormationの中で、パラメータストアや Secrets Managerの値を登録しておく • テンプレートでパラメータ名を指定して参照
  74. 74 ⽅法③︓シェルで頑張る • テンプレートに渡すパラメータをcliなどを駆使して取 得する # タスク設定⽤パラメータ CPU=256 MEMORY=512 IMAGE_URI=$(eval

    aws ecr describe-repositories --repository-names app-ecr -- query 'repositories[0].repositoryUri' --output text) # テンプレートの実⾏ aws cloudformation deploy --stack-name ${CFN_STACK_NAME} --template- file ${CFN_TEMPLATE} ¥ --capabilities CAPABILITY_NAMED_IAM ¥ --parameter-overrides ¥ accountAllias=${ACCOUNT_ALLIAS} ¥ accountAlliasLowerCase=${ACCOUNT_ALLIAS_LOWER_CASE} ¥ cpu=${CPU} ¥ memory=${MEMORY} ¥ imageUri=${IMAGE_URI}
  75. 75 第三段階突破 ここまでで CloudFormationつかって いろんなリソースを作りまくる ⽅法がわかりました︕

  76. 76 Infrastructure as Codeを極めるまで 1.Infrastructure as Codeを理解する 2.CLIで実⾏する 3.複数リソースを作成する 4.運⽤上の⾟みを理解する

    5.パイプラインでインフラ構築を⾃動化する
  77. 77 CloudFormation運⽤上の⼼構え AWSを複数⼈で管理している場合 おうおうにして事故は起こる (⼀⼈でやっててもあるYO)

  78. 78 運⽤時に考慮したいこと⼀覧 • スタックの作成〜削除がいつまでたっても終わらない 場合がある • 対応していないプロパティがある • 循環参照するには書き⽅に⼯夫が必要 •

    Conditionsに頼らない(使わない) • CloudFormation以外でリソースが変更されたとき の対処
  79. 79 ハマリポイント① スタックの作成〜削除がいつまでたっても 終わらない

  80. 80 対処⽅法 • 完全にケースバイケース • スタックに含まれているリソースの何をもって CloudFormationがスタック作成を完了としている のかわからない場合がある • エラーになって⽐較的短時間(3分程度)で返ってく

    る場合もある
  81. 81 返ってこない例① • すでにリソースにアタッチされているセキュリティグ ループの削除 • EC2等にわりあたっているセキュリティグループを CloudFormationから削除しようとすると、返ってこない • デフォルトタイムアウト(1時間)はずーっと頑張ってい

    る • 全然返ってこずに変だと思ったら、スタックの進⾏をキャ ンセルしましょう
  82. 82 返ってこない例② • ECSサービスの作成 • ECSのサービスが作成される→タスクが起動する→コンテ ナ起動して普通に使える→ログも正常 • 何故かスタック作成が終了しない •

    1時間後、タイムアウトからロールバックでコンテナも ECSサービスも削除される • #︕$%&#“@ʻ¥ • AWSサポート問い合わせ • ECSのサービス定義に不備があった→正直スマンカッタ • それならエラーだしていただけると…
  83. 83 ハマリポイント② CloudFormationで 対応していないプロパティが それなりにある (主に新機能)

  84. 84 対処⽅法 • 新機能がでて、APIは公開されるが CloudFormationで定義できないものはある • なにか試そうと思っても先にCloudFormationの公 式ドキュメントを必ず確認 • 対処⽅法

    • 基本対応されるのを待つしか無い • カスタムリソースを作る⽅法もある(魔境) • AWS CLIはほぼ即対応するので、シェルでそちらにいく のもあり
  85. 85 ハマリポイント③ 循環参照させるには 書き⽅に⼯夫が必要

  86. 86 対処⽅法 • 複数リソースが相互に参照しているテンプレートは実 ⾏できない • セキュリティグループなどでよくある • アプリケーションサーバが相互参照するなど •

    そのまま書くと「circular dependencies」(循環参照)
  87. 87 対処⽅法 • リソースそのものが相互参照にならないように書き⽅ の⼯夫が必要 • セキュリティグループの場合、以下の2つを分けてリソー ス定義する • AWS::EC2::SecurityGroup

    • AWS::EC2::SecurityGroupIngress
  88. 88 ハマリポイント④ Conditionsに頼らない(使わない)

  89. 89 Conditionsとは • テンプレートの中に条件分岐を埋め込む記法 • Resourcesに対して、パラメータの条件によりリソースの 作成有無などを指定可能 • 例)パラメータに”prod”が記載されている場合にEC2イン スタンスを作成する

    Parameters: Env: Type: String Conditions: CreateResources: {"Fn::Equals" : [{"Ref" : "Env"}, “prod"]} Resources: Ec2: Type: "AWS::EC2::Instance" Condition: "CreateResources"
  90. 90 Conditionsの注意点 • インフラをそのまま定義するテンプレートの記法と、 条件を記述する記法が相性が悪いため、可読性が著し く下がる • テンプレートへの「処理」は記載しない • どうしても1テンプレートで処理したい場合のみ利⽤

    • 環境毎に構成が違うのであれば、テンプレート⾃体を 分ける • もしくはシェルの中で条件判定をして、その結果をパラ メータとして渡して処理する
  91. 91 ハマリポイント⑤ CloudFormation以外で リソースが変更されたときの対処

  92. 92 ⾮常によくある事故 • CloudFormationでリソースを作る • なにかの拍⼦に誰かがWebコンソールから変更する • 次のスタック更新が正常に動かない(もしくは⼿動変 更分が巻き戻る) AWS

    CloudFormation template (JSON/YAML) Stack (リソース) Amazon EC2 変更するよ。キリッ あれ、何この差分︖ エラーになるねんけど
  93. 93 対処⽅法 • Drift Detection(ドリフト検出) • スタックの状態とリソースの差分を検出する機能 • ⼀度スタックを作成後、任意のタイミングでドリフトの検 出を実施

    → ドリフト状態かどうか確認可能
  94. 94 対処⽅法 • 実⾏タイミングは任意でもできるが⾃動で実⾏する⽅ 法もある • AWS Configに以下のマネージドルールが存在 • cloudformation-stack-drift-detection-check

    • 設定が変更されたタイミング、もしくは定期的にドリ フトの検出が⾃動で可能 • ドリフト検出されたタイミングでSNS経由でメールの受信 が可能︕︕
  95. 95 実際の設定はこちらを参考に https://dev.classmethod.jp/cloud/cloudformation-drift-notify/

  96. 96 ドリフト検出も万能ではない • 検出できるリソースに制限有り • https://docs.aws.amazon.com/en_pv/AWSCloudFormation/l atest/UserGuide/using-cfn-stack-drift-resource-list.html • API Gateway,

    Auto Scaling, EC2, ECS, CloudWatch, DynamoDB, Lambda, RDS, S3, SNS, SQSなど • その他動的に設定されるプロパティなど検出できないものが ある • 詳細はこちら • スタックとリソースに対するアンマネージド型設定変更の検出 • https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/Us erGuide/using-cfn-stack-drift.html
  97. 97 第四段階突破 ここまでで 実践的な運⽤⽅法も わかってきました︕

  98. 98 Infrastructure as Codeを極めるまで 1.Infrastructure as Codeを理解する 2.CLIで実⾏する 3.複数リソースを作成する 4.運⽤上の⾟みを理解する

    5.パイプラインでインフラ構築を⾃動化する
  99. 99 今までCloudFormationを どこで実⾏するかの話を していませんでした

  100. 100 CloudFormationを実⾏する場所候補 • 個⼈のクライアントPC • 適切な権限を保持したIAMユーザーでAWS CLIをインス トールして実⾏ • 適当なEC2インスタンス(Cloud9)

    • EC2インスタンスに適切なIAMロールを付与 • EC2インスタンスにSSH接続できるユーザーにより実⾏ • リポジトリからのパイプライン実⾏ • テンプレートのリポジトリコミットからのパイプラインに よる実⾏
  101. 101 CloudFormationを実⾏する場所候補 • 個⼈のクライアントPC • 適切な権限を保持したIAMユーザーでAWS CLIをインス トールして実⾏ • 適当なEC2インスタンス(Cloud9)

    • EC2インスタンスに適切なIAMロールを付与 • EC2インスタンスにSSH接続できるユーザーにより実⾏ • リポジトリからのパイプライン実⾏ • テンプレートのリポジトリコミットからのパイプラインに よる実⾏ テンプレートをバージョン管理する前提 のIaCにおいて、必然的な最終形態
  102. 102 パイプラインの⼀例 AWS CodePipeline AWS CodeCommit AWS CodeBuild template Stack

    Change set Shell 承 認 AWS CodeBuild template Change set Shell
  103. 103 CloudFormationのテストで利⽤できるツール • cfn-nag • https://github.com/stelligent/cfn_nag • CloudFormationテンプレートを解析し、セキュリ ティ的に脆弱な内容を検査するツール •

    ⾮常に強いIAMポリシーの適⽤ • 脆弱なセキュリティグループの適⽤ • S3バケットポリシーのワイルドカードプリンシパル • テンプレートに対してチェックするようにパイプライ ンを構築しておくことで⾃動化可能
  104. 104 さらに踏み込んだパイプラインの運⽤に向けて • AWS CloudFormation Validation Pipeline • https://docs.aws.amazon.com/solutions/latest/aws- cloudformation-validation-pipeline/welcome.html

  105. 105 さらに踏み込んだパイプラインの運⽤に向けて • CI/CD Pipeline for AWS CloudFormation Templates on

    the AWS Cloud Using AWS TaskCat • https://docs.aws.amazon.com/quickstart/latest/cicd- taskcat/welcome.html
  106. 106 第五段階突破 もう怖いものはなにもない

  107. 107 Infrastructure as Codeを極めるまで 1.Infrastructure as Codeを理解する 2.CLIで実⾏する 3.複数リソースを作成する 4.運⽤上の⾟みを理解する

    5.パイプラインでインフラ構築を⾃動化する
  108. 108 CloudFormation

  109. 109 めちゃくちゃ強⼒ だけど、つかいこなしが難しい

  110. 110 でも ワクワクしませんか︖

  111. 111 みなさんのこれからの AWSライフがより良いものに なることを願って