はじめに
- この記事は完全に私見であり、全ての企業様に通じるものではありません
- この記事の内容が最適であるという保証はできません
- Terraformマウントを取りたい目的の記事ではありません
- TerraformでAWSやGCPリソースの構成管理ができる、というスコープを意識しています
なぜこの記事を書こうと思ったのか
自身がいくつかの企業に「クラウドエンジニア、SREエンジニア」といったロールで転職をする際に
Infrastructure as Code(以下IaC)関連のツールにおける習熟度について、以下のような状況を経験したため整理したかったという動機です。
- あまり深くツッコミを入れられることが無かった
- 面接側になったときもどこまでツッコミを入れるべきか思案することが多かった
Terraformを使えれば面接を制する？
答えは No です。
IaCやDevOps、CloudNativeといった最近よく聞く耳障りのいい概念が昨今いくつも産まれています。
これらに共通する意味合いとして「特定のツールを使うことがこれらの概念を体現するわけではない、文化として個人からチーム、チームから組織へ伝搬させて馴染ませていくこと」が重要であり、これが出来て初めてこれらの概念を取り入れたと言えます。
話が脱線しましたが、TerraformやAnsibleといったツールは
- 管理しやすいコードを書ける人が
- それを使うことで何が美味しいのかを伝えることができて
- それを導入したプロダクトやプロジェクトに対して、より健全なサポートを行える
ことを成せることが重要です。
そのために、ある程度のレベルというのがどれくらいなのかを主観的に把握することが本記事の目的となります。
本題
抑えておくと評価されやすい事柄
下記に明示したチェックリストがだいたい埋まる、もしくはより良い方法が頭に浮かびメリットも説明できるという状態であれば
堂々と履歴書に書いたり、自分のリポジトリに公開してもマイナスにはならないのではないかと思います。
コードを書くまで
- インフラ構成図を作れる
- 通信の流れを簡略化して非技術者に説明できる
- それぞれのエンドポイントに定義されるポートやプロトコルを明示できる
- リージョンやゾーンレベルでのネットワーク階層化ができ、技術者に説明できる
- インターネット通信するトラフィックの暗号化要否を技術者に説明できる
コードを書くとき
- いつ「やっぱ複数環境を同じように作って！」と言われても最小限の対応(workspaceを切り替える等)で作れるよう冪等性を意識する
- いつ「デフォルトで使用するリージョンとは別のリージョンにも同じように作って！」と言われても作れるよう冪等性を意識する
- VMのマシンタイプやログの保持期間など差異がある場合は必ずコメントに理由を書く
- あわせて議論のソースが別途ドキュメントなどにあればURLを書く
- ローカルマシンで構築する際にプロファイルを切り替える必要がある場合、特に意識しなくても切り替わるようにする
- 開発環境では必要だが本番環境では不要なリソース(WAFによるIP制限等)などがあれば冗長にならないよう定義する
- Terraform VersionとProvider Versionを明示し、意図せずバージョンを更新しなければならなくなる状況を避ける
- 複数人で利用できるようtfstateファイルの管理をクラウド(本番環境や管理環境のオブジェクトストレージ、terraform cloud等)に保存する
- tfstateファイルを間違って消してしまっても復元できるようバージョン管理する
- ｖ0.11系以前とv0.12系の差異を知っている
- 構築するまでに思ったより時間がかかるリソースは一旦手動で構築して terraform importコマンドで補完する
コードの内容
- Data resourceは率先して使うようにする(クラウドベンダー側で変動する情報は特に)
- Meta Parameterのdepends_onやlifecycleを使うことで構築優先度をコントロールしなければならない場合は使うようにする
- よく確認する値や参照先を間違えるとまずい値、開発者へよく連絡する値はOutputに定義し、なにかしらの方法ですぐに共有できるようにしておく
- HCL(Hashicorp Configuration Language)に詳しくない開発者でもなんとなく読み取れるように簡素化して書くことを意識する
- formatやreplaceなどの関数で値を加工する場合はLocalsで定義しておく
- gitなどでパスワードのような秘匿情報を管理する場合は、KMSなどで暗号化したファイルをコミットする
まとめ
ここまでざっくりと自身がTerraformを書いたりコードレビューする際に意識していることを書き出してみました。
もっと考えられることはありますし、プロジェクト内での制約に縛られたコードを書かざるを得ないケースもあると思います。
この記事が数ある構成管理ツールの一つであるTerraformをアピールポイントにしたい求職者の方や、保有スキルとしてチーム開発に溶け込めるか判断したい面接担当者の方に少しでも役立てば幸いです。