はじめに
皆さんTerraformしてますか。私はしていませんでした。
クラウド触っているならいつかやらなきゃなーと思いながら後回しにし続けていましたが、いよいよ逃げられなくなってきたのでやり始めました。いつかやるは最後までやらないと同義です。ここはひとまずAIと壁打ちしながら（多少粗くても）ハンズオンするのが吉ということで、いっちょやってみましたという話です。
Local Stackコミュニティ版終了のお知らせ
相手方はAWSを想定していましたが、定番のLocal Stackがアカウント登録制に移行するので使用に制限が出る可能性があるとの情報をキャッチしました。代替案のひとつがmotoでした。
boto3互換のSDKとして紹介されている印象ですが、普通にAWSモックサーバーとして機能したので、これを使ってローカル環境で行いました。
記録
こちらです。
やったことの資料もClaudeにまとめてもらいました。（むしろこれが本体みたいになってしまって記事に書きたかった内容を巻き取られている気がする…）
Dockerネットワークへの参加が云々という話も入っていますが、これは私の手際の問題で、Terraform以外に費やした作業がのコンテキストの一部として入っているからです。本質はTerraformのIaC哲学を体験することです。
Claude Code とのハンズオンの記録
以下、実際のClaudeとのやりとりの要約をQ&A形式にしたものです。
Q1. Terraformを触ったことがない状態から、init→plan→applyを実際に体験しながら学びたい
A. ローカルのAWS互換サーバー(moto)を使い、init(プロバイダ初期化)→plan(差分確認)→apply(実適用)→moto側での作成確認まで、実際にコマンドを叩きながら一通り体験した
マニュアルモードで、打たれる予定のコマンドを確認しながら。普段煩わしい確認依頼ですが、こういう場面では勉強になる、かもです。
Q2. ホストマシンからcurlでコンテナに名前解決して到達しようとしたが失敗した。なぜか
ホストOSの名前解決は、Dockerが提供するコンテナ間専用の内部DNSを一切参照しないため。ホストからコンテナへは、公開ポート(例: localhost:5000)経由でしか到達できない。
ただの私の知識不足。
Q3. destroyも体験したい
A. terraform destroyでリソースを削除し、moto側からS3バケットが実際に消えたことをホストから確認した`
planもそうですが、コンソールでどういう見た目になるかを確認しておきたかったです。
Q4. 思想とセットで、適切な.gitignoreを作ってほしい
A. 「コード(設計図)は追跡し、実行時の生成物・秘密・環境固有の値は追跡しない」という方針のもと、.terraform/・.tfstate・.tfvars等を除外対象にした。一方、プロバイダバージョンを固定する.terraform.lock.hclはあえて除外しない、と整理した
ふむふむ。
Q5. そもそも「プロバイダ」とは何を指す概念か
A. Terraform本体(コア)はAWSなど個別サービスの仕様を一切知らない。「リソースを作れ」という指示を実際のAPI呼び出しに変換するプラグインがプロバイダで、init時にダウンロードされる
Terraformのコンテナイメージに焼かれているのを勝手に想像していました。プロバイダ種類が多すぎるので手元に全部置いておけないって事でしょうか。
Q6. 手動で作ったリソースにTerraformが手を出さないようにしたい、特定のリソースだけを選んでIaC管理したい場合はどうするか
A. 単純に「コードに書かない」だけでよい。Terraformが認識・操作できるのはterraform.tfstateに記録されたリソースだけなので、コードに無い手動リソースは最初から対象外になる。あえて管理下に取り込みたい時だけterraform importを使う
Q7と並んで私が一番知りたかったことかもしれません。
Q7. それはドリフト検知と矛盾しないか。ドリフト検知もコード化されたリソースだけが対象か
A. 矛盾しない。ドリフト検知も「state内のリソースだけをrefreshして差分を見る」という同じ仕組みであり、管理境界とドリフト検知は同一の判定基準(state)の表裏だった
そもそも定義されていないリソースに対してドリフトも何も無いよ、という話ですね。そりゃそうじゃ。
Q8. ドリフトを解消して一区切りにしたい
A. applyを実行し、手動で加えたタグ変更をコード通りの状態に戻して解消した
宣言した通りに実体を合わせに行く。以上。
Q9. オンボーディングの記録を、コマンドと出力を対応させながらMermaid図も使ってドキュメント化してほしい
A. 実行コマンドと出力を要点だけ抜粋しつつ、構成図・概念図をMermaidで添えたMarkdownドキュメントとしてまとめた
レポーティングしてくれるの本当に助かりすぎます。
Q10. Terraformコンテナが専用のDockerネットワークに参加すること自体に、実質的な意味はあったのか
A. あった。参加を外すとcurlでの到達が実際に失敗することを確認した。ただしterraform plan自体はその状態でもエラーにならず正常終了したため、「planが成功した」ことは接続成功の証拠にならないという注意点も判明した
S3のAPIってそういう挙動多い気がしています。
Q11. 接続先をlocalhostに書き換えれば、そもそもネットワーク参加は不要だったのでは?
A. いいえ。コンテナ内のlocalhostはコンテナ自身を指すため、それだけでは到達できない。到達させるには、ネットワーク参加を無くすのではなく「ホストのネットワークをまるごと共有する」という別の(よりポータビリティに劣る)方式に切り替える必要があった
これも私の知識不足。
Q12. ポータビリティを優先するなら、ホストへのポートバインディングは無い方が理想的か
A. 理想的にはその通り。実運用フローはポートバインディングに一切依存していないことを確認した。ただし今回はホストからの手軽な動作確認という利便性を優先し、最終的には残す判断をした
これも。
Q13. 仕上げに、コードとドキュメントの間に矛盾(存在しないリソースへの参照など)がないか確認してほしい
A. 見出しへの内部リンクが実際に生成されるIDとズレている箇所を2件発見・修正した。それ以外はコード・設定内容と矛盾なしだった
本筋とは直接関係ないですが。最終確認は大事です。Claudeは結構やらかします。
まとめ
やり方が割と雑ではありますが、初心者としては得る所が多かったように思います。まだまだ勉強しないといけませんね！