re:Invent2020セッションレポート ：(DOP309) Test twice, deploy once: Testing infrastructure code on AWS

概要

インフラコードのテストに関するセッションです。タイトルの「Test twice, deploy once」は、英語のことわざ（？）である「measure twice and cut once」（2回測って、1回切る＝慎重に）から来ているようです。どのように正確に、インフラをテストできるのか。といった観点ですね。

AWSさんのセッションなので、AWS標準のツールであるCloudFormationとCDKを使用する場合の話になります。（TerraformなどAWS外のIaCツールについての説明はありません）

セッション内容

Why infrastructure as code?

• 背景

  • 昔はオンプレミスのサーバー数百台にそれぞれJavaなどのソフトウェアをインストールしていた。時間がかかる
  • 2000年代前半にIaCという言葉が出てきてブームになってきた
  • 現代ではインフラはコード前提で考えるべき。クリックではなくLovelyなインフラのコードを

• なぜIaCなのか？

  • 再利用可能で、何がデプロイされるのか予測できる
  • 共通のツールで変更リリースをコード変更として実行できる、テストもできる
  • 本番やステージングなど、環境のコピーがしやすい

Testing AWS CloudFormation

• コードには何をするか？

  • テストをする、アプリケーションと同様
  • 本番環境にリリース前にテストを実行しておきたい

• CloudFormationの概要

  • AWSのIaCフレームワーク
  • YAML or JSONで記載
  • テストの実施手法もたくさんある

• テストはどこから始めれば良いか
  • Editorでまずできる
  • 例えばVS Codeであればテスト用のプラグインが用意されている
  • 例えばCloudFormation nag、セキュリティ的な警告も出してくれる（強い権限のIAMなど）

• cfn-nag
  • rubyのgemパッケージ
  • セキュアでないコードを見つけて警告を出してくれる

• cfn-lint
  • linter
  • コードの静的解析ツールで、文法チェックを行ってくれる
  • リージョン単位でサポートしていないEC2などのケイパビリティも含めてチェックしてくれる

• TaskCat
  • 実際にテンプレートをデプロイしてテストできるツール
  • 複数のパラメータ入力に対応
  • 設定したパラメータで、実際にテンプレートがデプロイできるかチェックできる
  • デプロイが正常に完了したら、リソースは削除される

Testing AWS Cloud Development Kit (AWS CDK)

• なぜCDKなのか？
  • CloudFormationはパラメータを書くので読みやすい、JSON or YAML
  • Pythonコードで開発を行っているチームの場合、なぜPythonでIaCを書かないのか？となる
  • CDKを使うとPythonで書ける
  • JavaやC#など他の言語にも対応している
  • 開発も盛んに行われており、ライブラリも多い
  • CloudFormationよりも複雑になることもある、なのでテストをする

• CDKをどうテストしていくか
  • jest というツールを使用してテストができる
  • Snapshot tests、Fine-grained assertions、Validation tests３種のテストができる

• Snapshots
  • CDKでデプロイした状況をSnapshotとして状態保存しておき、変更がされたら検知ができる
  • 一度CDK経由でデプロイして、リソースの変更が行われると、テストがfailとなる
  • テストがfailした場合はスナップショットを更新して対応する

• fine-grained assertions
  • Snapshotsではできなかった機能単位の細かなテストを実施したい
  • fine-grained assertionsを使用して実行できる
  • 例えばメッセージ保持期間がXXXのSQSリソースがあるかチェックするいった書き方ができる
  • チェックする内容から書くテスト駆動開発な進め方もできる

• SQSキューの保持期間が誤っていると以下のようにエラーになる

• validation tests
  • 時間がないので資料なし、説明でさらっと
  • 値の最小、最大といった少し複雑な書き方ができる。

Pipeline

• IaCもアプリ同様にパイプラインにいれましょう

• GitリポジトリにIaCテンプレートをコミット

• Buildフェーズではテストに必要なパッケージを用意してlintやnagといったコード解析テストを実行
• CDKの場合はjestを使用

• Testフェーズではどこかの環境にデプロイを行い、Lambda等を使用して環境チェックを行うテストを実行する
• テストが正常終了したらProduction環境へリリース

• CloudFormationの場合は以下のようなパイプライン構成となる

CDK Pipelines デモ

※デモ見たいかたはこちらのセッション動画をご覧ください（28:50頃～）

↓デモより一部説明を抜粋↓

• CDK Pipelinesはマルチリージョン、マルチアカウントにパイプラインの整備ができる
• パイプラインリソースとアプリケーションリソース（デモではLambda＋API GW）をCDKの中で管理
• stageという概念を使って、同じAWSリソースを複製できる
• cdk deployコマンドでパイプラインをデプロイできる
• test用のステージおよび処理もCDKの中に書ける（CurlコマンドによるURLチェックなど）
• デモで使ったコードは以下Githubにある

GitHub - darko-mesaros/cdk-pipelines

Homework

• 宿題（まとめ）
  • インフラコードに色々なツールを入れて書き方デバッグ、テストをしてみよう
  • インフラをCI/CDしよう
  • 素晴らしいセキュアなインフラコードを書くことを楽しもう

感想

今やっている私がやっている業務にドンピシャな内容でした。現在はCloudFormationをメインにIaCの管理を行っていますが、パラメータを全て書くというところにツラさを感じているところです。パラメータの可読性は高くて良いのですが。

また、パイプラインも合わせてCloudFormationで作っているのですが、パイプラインの数も多くなりここも中々ツラくなってきているところです。CDK Pipelinesはパイプラインの整備や管理に大いに役立ちそうです。できるところから、CDKも試していきたいと思います。

IaCのテストにフォーカスしたセッションは過去に見たことがなく、悩んでいるところでもあったのでとても有益なセッションでした。インフラもテスト駆動で開発していきたいですね。