Amazon Web Services ブログ

[AWS Black Belt Online Seminar] AWS CloudFormation 資料及び QA 公開

先日 (2020/08/26) 開催しました AWS Black Belt Online Seminar「AWS CloudFormation」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

20200826 AWS Black Belt Online Seminar AWS CloudFormation

AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます）

Q. AWS CloudFormation テンプレートを作り込む際、実際にスタック作成してトライ＆エラーで作り込んでますが、スタック作成せずにテンプレートを検証できる方法はないでしょうか？
A. 本 Black Belt の 55 スライド目のとおり、事前にテスト関連ツールにて事前検証可能です。最終的には実環境でのテストが必要ですが、本 Black Belt で紹介した機能を使用して事前に検証することで、実環境でのトライ&エラーを防ぐことができます。

Q. CloudFormation 初心者なのですが、プログラミング経験は豊富なので、これから IaC に携わる場合は、CDK や Pulumi を学習する方がよいでしょうか？
A. プログラミング言語に慣れているということであれば、AWS Cloud Development Kit (CDK) から取り組むのも一つの手です。CloudFormation よりも少ない行数で構成管理を実現できる可能性があります。AWS CDK を使うことで CloudFormation を知らなくてよくなる訳ではございません。あくまで AWS CDK は CloudFormation のテンプレートエンジンであり、リソースによっては高レベルライブラリが用意されておらず、CloudFormation テンプレートと同様のプロパティ指定が必要になる場合もございます。プログラミングに慣れている方は、過度に抽象化やロジックを作り込まずシンプルに実装することを意識してください。AWS CDK の導入メリット、インストール方法等、詳細についてはこちらの Black Belt をご確認ください。

Q. StackSets は、管理者アカウントではなく、操作権限を付与したIAMユーザーでも作成可能でしょうか？
A. 権限を付与したIAMユーザーでも操作可能です。セルフマネージド型、サービスマネージド型によって前提条件が変わってきます。詳細についてはこちらのドキュメントをご覧ください。

Q. CodeDeploy でデプロイする時にパラメータを渡したい場合ですが、パラメータもファイル化して CodeCommit に管理し、自動で取り込んでデプロイまでできるのでしょうか？
A. アプリケーションではなくパラメータをデプロイするパラメータパイプラインという考え方があります。どの時点でパラメータを確定させるかによっていくつかの実装方法があります。以下の 3 つの方式のとおり、パラメータパイプラインの考え方をまず検討していただくことが重要です。

  1. AWS CodeBuild でデプロイアーティファクトを作り、パラメータを Git のコミット時に確定する方式
  2. AWS Systems Manager の Parameter Store にパラメータを保持しておき、デプロイ時に確定する方式
  3. AWS AppConfig にアプリケーションが動く時に定期的にパラメータを取得し、メモリ等にキャッシュしていく方式

1 つ目は、デプロイアーティファクトを作る際に Git リポジトリからファイルをダウンロードしてビルドする方式です。パラメータがコミット時に確定するため、アプリケーションのバージョンに依存するような設定を持つ際に有効です。2 つ目は、AWS CodeDeploy AppSpec ファイルの AfterInstall に設定を入れて、Systems Manager の Parameter Store にアクセスして値を取得する方式です。デプロイ時に値が確定するため、DB 接続先の制御の際に便利です。3 つ目は、AWS AppConfig を用いる方式です。パラメータを動的に変更ができるため、フラグを制御する際に便利です。

Q. スタックの更新で、具体的にどんな項目の差分がドリフトとしてひっかかるのでしょうか？
A. 現在のスタックの設定と、テンプレートが指定する設定とを比較し、誤差があれば詳細の情報が差分として表示されます。ドリフト検出は、CREATE_COMPLETE、UPDATE_COMPLETE、UPDATE_ROLLBACK_COMPLETE、UPDATE_ROLLBACK_FAILED の状態にあるスタックに実行できます。チェックしたスタックにネストされている他のスタックには適用されません。これらのチェックはユーザーが自ら行います。こちらの公式ドキュメントにドリフトに関するイメージ、詳細が記載されておりますので、こちらもご活用ください。

Q. テンプレートについて、テンプレートは1つのみ作って管理するほうが良いのでしょうか？それとも機能分割して複数テンプレートで管理するほうが良いのでしょうか？ 複数の機能を作成する場合、テンプレート一つだと記述が煩雑になり、 管理が大変になる懸念があります。 もし機能分割する場合、どのような基準があるかも教えていただけると助かります。
A. ライフサイクル別にテンプレートを分けて管理した方がより管理しやすくなります。どのように分割するか、具体的な話については本 Black Belt の 82 スライド目の資料をご覧ください。

Q. ドリフトの検出は、スケジューリング等で自動実行できますか？
A. AWS Config Rules にて、ドリフトの検出を自動化できます。AWSのマネージドルールである、cloudformation-stack-drift-detection-check をご活用ください。

Q. AWS CloudFormation “Custom Resource” “Resource Provider” の使い分け、制約など分かるドキュメントや資料あれば教えていただけますか？
A. Custom Resource は、リソースを作る代わりに Lambda など外部の処理を呼び出すことを可能にします。AWS CloudFormation が対応していないリソースを AWS SDK を使用して、作成したり、外部の API を呼び出したりするような用途に利用できます。一方で Resource Provider は独自のリソースを定義するもので、リソースタイプの仕様と、対象リソースの作成/更新/削除の際に行う処理を定義することで、AWS リソースと同じように管理が可能です。
一般的には、リソースを定義したい場合は Resource Provider を、単に何らかの処理を追加したい場合は Custom Resource を使うことが多いですが、詳しくはこちらのドキュメントをご参照ください。

また、CloudFormation CLI の解説のドキュメントもございますので、こちらもご活用ください。

Q. CodePipeLine で本日紹介頂いたテストツールを流してパスした場合のみ、デプロイするという事は可能でしょうか？また、CodePipeLine の最後に、ChangeSet の確認フローを入れて人手による承認がなされた後に、デプロイするといった事は可能でしょうか？
A. 両方とも可能です。CodePipeline の承認アクションにつきましてはこちらのドキュメントをご覧ください。

Q. “DeletionPolicy” : “Retain” を S3 バケットに適用した場合、S3 バケットのオブジェクトも保護される認識で合っておりますでしょうか？
A. はい、合っております。オブジェクトも保持されます。

Q. AWS CloudFormation で構築後、 AWS Systems Manager などでソフトウェア・パッチを定期的に適用し、 AMI イメージを更新していく運用を検討しています。 Drift として検知され現状は無視する運用としていますが、参考になる設計／実装／運用があれば教えていただけますか？
A. AMI を入れ替えていく運用をする際は、AMI を構築してデプロイするパイプラインが一案としてあげられます。流れとしては次のとおりで、サーバごと入れ替えてしまう運用となります。

  1. 1. EC2 Image Builder や独自のスクリプトで、ベースとなる AMI に対して OS のパッチ適用やセットアップを行い、AMI 化を行う。
  2. 2. CloudFormation の EC2 定義の AMI を新しい AMI に変更し、CloudFormation の変更を適用する。

上記の例は、デプロイ対象が AMI=EC2 となる、CI/CD パイプラインです。サーバ入れ替え時にサービスが止まってしまうのを避けたいのであれば、AutoScalingGroupのUpdatePolicy を使ってローリングアップデートすることで、サーバを順次入れ替えていくことができます。
https://docs.thinkwithwp.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-attribute-updatepolicy.html

AMI にアプリケーションを含めてデプロイする場合は上記のとおりですが、実際はアプリケーションのデプロイだけは CodeDeploy を使うことにして、CodeDeploy の Blue/Green デプロイを使う方法もよく用いられます。

Q. スタックに入れることができるリソースには何があり、何がないのでしょうか？
A. CloudFormation でサポートされているすべてのAWSリソースタイプはこちらのドキュメントをご覧ください。AWSの新しいサービスがリリースされた後も、追従する形で対応しております。

新規、更新されたリソースに関する重要な変更点も公開されております。アップデート情報を知りたい場合はこちらのドキュメントをご覧ください。

なお、CloudFormationに関するフィードバックがございましたら、是非こちらののリポジトリにIssueを上げていただければと思います。+1もお待ちしております。

Q. AWS Hands-on for Beginners の URL を教えてください
A. こちらの URL からご覧ください。AWS Hands-on for Beginners を実施の際は申し込みが必要となります。

Q. リソースの DelitionPolicy 属性で保持とありましたが、削除されても保持というのは削除操作を無効にするのでしょうか？削除されてもテンプレートからは削除しないということでしょうか？
A.削除操作を無効にするのではありません。CloudFormation のスタック削除操作によってリソースが一括で削除されますが、その中でも DeletionPolicy をつけられたものが保持されます。すべてのリソースに対して、DeletionPolicy が指定できます。

Q. ヘルパースクリプトについてもう少し詳しく知りたいのですが、どこを参照すると良いでしょうか？
A. 本 Black Belt の 93、94 スライド目にも記載がございますが、より詳細を知りたい場合はこちらのドキュメントをご覧ください。

Q. スタックポリシーを利用してリソース別の削除保護を実施してみたいのですが、CodePipeline を利用して各スタックを管理している場合、スタックポリシーにて保護しているスタックが Pipeline 上に存在する状態で Pipeline を実行すると、Pipeline 全体が止まってしまうのでしょうか？　止まってしまう場合はどのような対処を取るべきでしょうか？
A. スタックポリシーで削除保護をしているということは、対象のリソースを削除してはいけないということです。テンプレートの変更に伴って対象スタックを削除しようとし、エラーになったということは、そのときテンプレートに行った変更に何かしら問題があるのだと言えます。スタックの変更に失敗した場合、CodePipeline のパイプラインは停止します。修正方法としては、リソースを削除しないようにテンプレートを修正して最初からパイプラインを実行するか、スタックポリシーだけを一時的に変更してパイプラインを途中から再実行する方法が考えられます。

—

今後の AWS Webinar | イベントスケジュール

直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。

—
AWS Summit Online 絶賛開催中！

 

日本初の AWS Summit Online は、従来の AWS Summit Tokyo/Osaka で想定するセッションをフルスケールで提供します。150 を超えるセッション、20 を超えるセルフペースハンズオンにより、ご自分のレベルと目的に沿って好きな時間に知識を得ることができます。

開催期間： 2020 年 9 月 8 日 ～ 9 月 30 日　｜　詳細・お申し込みについてはこちら≫

ライブ配信されたセッションほか、AWS 認定セッション、お客様事例セッション、セルフペースハンズオン、Partner Discovery Session (パートナーセッション) などを現在オンデマンドで配信中です。ライブで配信された基調講演などを見逃した方はこの機会にどうぞご視聴ください。

—

【AWS Summit Online 参加のビギナーの方も総復習としてご視聴ください】AWSome Day Online Conference

「AWSome Day Online」は、AWSの主要サービスや基礎知識を約 2.5 時間という短い時間で、ポイントを押さえて紹介いたします。技術的な面だけではなく、AWS クラウドを学ぶために必要となる知識を身に付けたい方、エンジニアのみならず、営業職、プリセールス職、学生まで幅広い方々におすすめします。

※この回ではAWSエキスパートによる技術的な内容についてチャット形式でのQ&Aを実施します。
※AWS サービスの導入に関するご相談も同時にチャット形式にて対応します。
※2020年は毎月第一水曜日に開催します。

日時：2020 年 10 月 7 日（水） 15:00 – 18:00 終了予定 | 詳細・お申込みについてはこちら≫

—

AWS Black Belt Online Seminar

9 月のアジェンダは以下になります。セミナー中は内容に関する疑問点を質問することができます。参加された方だけの特権ですので、ぜひこの機会にご視聴ください。

9 月分の詳細・お申込はこちら≫

  • 9/29（火）12:00-13:00 Amazon Aurora MySQL Compatible Edition ユースケース毎のスケーリング手法
  • 9/30（水）18:00-19:00 Amazon Kinesis Video Streams