なぜterraformなのか

IaCを読んでさらに仕事でもterraformを数ヶ月使用してみた。自分だけがterraformを使っている状況では意味がないので布教する際に何を根拠にterraformを使うべきなのかまとめる。

一般的に述べられているIaCのメリット

• CLIから構成を変更できるのでCI/CDの導入が可能
• gitによるバージョン管理
• コードの共有・再利用
• コード化された手順を第三者が検証できる

terraformを実際に使用してみた視点から以下に述べる

CLIから構成を変更できるのでCI/CDの導入が可能について

Github Actionsにてterraformを利用することによってPRごとに異なるテスト環境を作成することができた。CIから作成するように記述するとコード化されることを強制されるので人間が操作する余地がない。

gitによるバージョン管理

変更履歴が保存されていることによって他人によって修正された箇所が理解できる。

コードの共有・再利用

全く同じ構成であれば再利用できるが実際はプロジェクトの予算、要件によって異なるので想像してたようには再利用はできない。小さな単位(vpc, ses)だけmoduleとして切り出して必要な部分だけうまく再利用することはできる？

コード化された手順を第三者が検証できる

第三者が検証する必要のあるほどコンプライアンスが厳しいシステムを作成したことがないためわからない。PRを通して第三者がチェックできるという文脈では役に立っている。

なぜterraformなのか

• 宣言的フォーマットによる冪等性
• ほぼすべてのawsのインフラを表現できるクラウドに適したIaCツール

以下に詳しく書いてみる。

冪等性

従来の方法

• 修正するべきことがあるとインフラ担当がssh接続して情報を追加する(手動)

  • 大抵インフラは担当者しか触らないのでドキュメントを維持していくことは難しい
  • 担当者が変わった、担当者が忘れた頃に再現ができなく問題が発生する

• deployスクリプトを用意してそこに追加の編集を加える(not 宣言的フォーマット)

  • 手続き型言語で冪等性を保つようにスクリプトを書いていくのは難しい
    • mkdir -p などoptionで対応できればい良いが大抵「現在起動しているjavaプロセスを落として~」といった記述が入る
  • また修正する内容が一行実行すればいいだけの場合わざわざスクリプトは書かない

宣言的フォーマットの場合

docker-composeなどの宣言的フォーマットを備えたツールで修正した場合ymlファイルを修正してインフラを修正する。再作成するときに、Containerが持っている状態は再作成される。 何かしら(OS, packageなど)アップデートされて動かなくなってい場合この時点で気づいて直すことができる。

• productionに適用する際には必ずCIを通す
• コードを書いてから反映させる

など従来の方法より煩雑になっているのは間違いない。
が、アプリケーションコードをproductionへ手作業で反映しないようにinfraもコード管理することによる恩恵を受けることができる。

イミュータブルサーバーアプローチ

• deployのたびに新しいアプリケーションサーバーを作成してサーバーを入れ替える

本番環境前に様々なテスト可能、実際のデータを書き込むテストはできない。そもそも一回deployすると次の新規開発が無いようなprojectでは効果は薄い？

awsのインフラを表現できるクラウド利用に適したIaCツール

実務で2パターンほどinfra構築したがawsにあってterraformにない機能はなかった。fargate spotが発表された際にもすぐ対応されたことからも「結局コンソール画面から操作している」といったことには大抵の場合はならない。

最後に

terraform結構使えるので積極的に使ってゆく。