この記事では、私が5年間Terraformを使い続けて学んだことを説明します。
5年間Terraformを使ってきて、いくつかの重要な教訓を得ました。チームの規模やプロジェクトの性質に関わらず、論理的で使い勝手の良いTerraformプラットフォームを構成するために重要な5つのポイントがあります。
ターゲットオーディエンスの理解
この種の問題は、ある種の決断に影響します。理想的には、とにかく2つの状態があるべきです。リモート状態はラップトップだけがTerraformを実行しているマシンではないことを保証し、状態ロックは一度に一人だけがインフラストラクチャに変更を加えることを保証します。
命名規則は、開発チームだけでなく、プロジェクトの最終的な所有者にとっても意味のあるものでなければなりません。プロジェクトが他のチームに引き継がれるのであれば、そのチームが命名規則について発言権を持つことを保証すべきです。もしコードが技術者以外の利害関係者や社内のセキュリティ/GCRチームによってレビューされるのであれば、彼らが命名規則をチェックすることを保証すべきです。また、リソース名については、コードレビュアーに精査させるために、リソースタグを使用して、関連するデータ分類/プライバシー要件にフラグを立てるべきです。
リユース、リユース、リユース
Terraform 、ほとんどの一般的なユースケースに対応した既成モジュールのライブラリが用意されています。私はVPCモジュールとSecurityモジュールの機能の多くを使っています。これらのモジュールは関連するパラメータを与えるだけで使うことができます。パラメータを変えてこれらのモジュールを呼び出すだけで、ほとんどのユースケースに対応できます。これらのパブリックモジュールをできるだけ多く再利用することで、コーディング、テスト、チェック、修正、リファクタリングなどの繰り返しを避けることができます。
また、使用頻度や変更に基づいてモジュールやリソースを分割すると、大きな配当が得られることもわかりました。例えば、VPC関連の設定、セキュリティモジュール、ルーティングテーブル、VPCエンドポイントなど、一度しか使用しないインフラ足場はまとめておくことができます。しかし、プライベートマネージドドメインエントリー、オートスケーリングモジュール、ターゲットモジュール、ロードバランサーなどは、デプロイされるたびに変更されるため、これらを1回限りのインフラ足場から分離することで、コードの検査が容易になり、デバッグが速くなります。
暗黙の了解ではなく、明示的に
Terraformのコードにはよくあるパターンがあり、それが設計における誤った仮定につながることがあります。チームは、コードを書くために使われるTerraformのバージョンは常に変わらない、外部モジュールは変わらない、使うプロバイダは変わらない、と思い込んでしまうことがあります。これらの外部依存関係が必然的に変更されると、見つけにくい問題につながる可能性があります。
どこに行っても定義が明確であることを確認してください。事前にバージョンを定義することで、依存ライブラリが確実に固定されるため、議論、レビュー、テストの後に、依存関係を知った上で更新することができます。
ラップトップ、共有VM、CI/CDなど、あらゆる場所を自動化します。
配備のすべての段階で自動化された方法を使用することで、起こりうる問題を回避することができます。
コードをコミットする前に、terraform fmt と terraform validate を Git のプレコミットフックとして 実行します。このプレコミットファイルをリポジトリにチェックインすることで、チームメンバー全員にメリットがあります。これは表向きは些細なことですが、重要なことでもあり、プロジェクトの時間を大幅に節約することができます。
まず最初にすべきことは、README.mdファイルをきちんと書くことです。
Terraformのコードは自己文書化されていると思われています。しかし、それはその会社の命名規則、開発ガイドライン、機密情報、内輪ネタ、そして有効なTerraformコード以外のリポジトリにあるすべてのものを、見込みのあるチームがすでに理解している場合に限ります。README.mdファイルを維持することは良い習慣であり、多くの時間を節約し、チームメンバーにREADMEファイルに提出したものに対する責任を負わせることでチームメンバーの忠誠心を確保することにもなります。
最低限、READMEファイルには、Terraformのバージョン情報を含む、Terraform環境を作業環境で初期化する手順を記述しておく必要があります。必要な依存ライブラリとそのバージョン、チームが使用する便利なLinuxエイリアスを特定する必要があります。最も重要なことは、ブランチやPRレビューの方針やプロセス、命名規則、リソースラベルに関する標準を特定することです。
READMEファイルは、チームの新しいメンバーが参加したときに、何をすべきか、どうすれば正しいかを伝えることができるかというテストに合格する必要があります。もしそれができなければ、その後の数ヶ月間、延々と標準やプロセスの議論ミーティングに直面することになります。
まとめ
以上、Terraformを何年も使ってきた私が伝えたい5つの便利なTipsでした。あなたのベストプラクティスもぜひ共有してください。
