【登壇資料】 『なぜIaCの引き継ぎは 上手くいかないのか?』#devio2022

2022.07.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

弊社のオンラインイベント DevelopersIO 2022 「なぜIaCの引き継ぎは 上手くいかないのか?」の資料です。

登壇概要

「IaC構築したが、引き継ぎや運用が上手くいかない」といった悩みはありませんか? 上手く引き継ぐために気をつけた方がいいポイントを、失敗例や実装例を交えつつ紹介します。

動画

登壇資料

セッション内容

引き継ぎがうまくいかない原因

automation恐怖症

引き継がれる側にわからないことがあると、IaCツールの実行が怖くなります。 結果IaCを使わず手動変更するようになって、設定がカオスになります。(オートメーション恐怖症)

引き継がれる側のわからないを無くす努力をすることが必要です。

このセッションでは、以下「3つの分からない」について触れました。

  • IaCツールのコードが「わからない」
    • IaCツールの使い方がわからないというよりは、独特の使われ方をしていてわからない状態になっている
  • デプロイ手順が「わからない」
  • IaC管理しているリソースが「わからない」

1. IaCツールのコードが「わからない」

IaCツールの使い方が独特で、作った人以外は触れないような状況になることです。

モジュール化やライブラリ化はうまく活用できれば記述量を減らせて、とても効果的です。

しかし、やりすぎたりIaCツールをラップした独自ツールを作ると複雑になることがあります。

もちろん上手く運用できているチームはあると思いますが、メンテンナンスに十分に工数をかけれない場合は避けた方がいいかもしれません。

ecsタスク定義のモジュール化

私が実際に体験したライブラリ化の失敗例です。 CDKでECSを使用することが多かったので、記述量を減らすためにECSのライブラリ化を行いました。

この際に、タスク定義もライブラリに含めていました。

CDKで初回生成時にタスク定義を作成します。この時点では、タスク定義では200レスポンスを返すテスト用のサンプルAppがデプロイされます。

その後、アプリケーションの設定が固まったらアプリケーションリポジトリにjsonファイルでタスク定義を配置するような運用をしていました。

この結果、2重管理になってしまいライブラリ化したCDKのアップデートが走るとタスク定義がサンプルAppが動作する初期状態に先祖返りする事象が発生しました。

このような事象を発生させないために、IaCツールのコードはできるだけシンプルに作ることをお勧めします。

IaCで一番実現したいことは、変更のリードタイムを短縮することだと思います。

多少コードが長くても、変更しやすいコードの方が運用はしやすいです。

2. デプロイ手順が「わからない」

デプロイの属人化についてです。

最初のうちはローカルから手動でIaCツールをデプロイすることがあるかと思います。

しかし、複数人で運用する場合はローカルでのデプロイは問題になることがあります。

  • デプロイのために、各ユーザーに強い権限を付与
  • 適用した際の履歴どこに残す問題
    • いつ誰がデプロイしたか、適用の履歴が追えない
  • 手順が増える・適用忘れが発生する
    • 複数環境があると手動では適用忘れが発生する可能性がある

解決策としては、IaCもCI/CDパイプライン上で自動デプロイすることです。

  • パイプラインに権限を渡す
  • パイプライン上に適用履歴が残る
  • 手順も簡略化できる

以下はデプロイパイプラインの例です。

デプロイパイプライン

上記の他にも、DEV環境・STG環境・本番環境のように複数環境を運用する際に、環境毎にブランチ(devブランチ,stgブランチ,prdブランチ)を分けるパターンがあります。

この方法は環境個別に柔軟に変更を加えることができるというメリットがあります。

反面、環境差異が発生しやすく、ブランチを切り替えなければ、環境の状態がわかりません。

また、prdブランチに直接pushすることで本番反映ができるためSTGやDEV環境でのテストをスキップして本番反映ができてしまいます。

そのため、上記のようにmainブランチ1本で、DEV>STG>PRDの順番で環境に反映されるフローを構築することをお勧めします。

3. IaC管理しているリソースが「わからない」

IaC管理と手動管理のリソースが混在してしまっている状態では、手動変更かIaCから変更か迷ってしまうことがあります。

こういった際には、ポリシーの策定やタグ付けが有効だと思います。

IaCで全てを作るのが正義というわけではなく、IaC管理が向かないリソースもあるため手動構築を選ぶのも一つだと思います。

1度しか作らないものや変更が少ないものは手動の方が楽です。

IaCの使用範囲もツールを使い始める前に決めておくといいと思います。初期構築だけか運用も行うのかなど。 (もちろん、理想も運用もIaCで行うことです)

タグを付与することで、管理方法の判別をしやすくなります。 TerraformやCDKでは、作成したリソースに共通タグをつけことが簡単にできます。

AWS CDKで管理しているリソースに一括で共通タグを付与する | DevelopersIO

Terraformなら簡単に全AWSリソースに共通タグを設定できます | DevelopersIO

まとめ

IaC まとめ