Terraform

ＨＯＭＥ ＞ Terraform

Terraform：記事リスト

Terraformのカテゴリーには以下の記事がリストされています。

TerraformでCloudFrontとS3の静的サイトをコード管理する方法｜OAC・HTTPSリダイレクト・キャッシュポリシーの実践設計

「S3バケットにウェブサイトをホスティングしているが、毎回コンソールからCloudFrontを手動設定している」「本番・検証・開発の3環境に同じ設定を繰り返す度に、細かい差異でバグが出る」
CloudFrontとS3を組み合わせた静的サイト配信は、設定項目が多く手動管理では属人化しやすい構成です。Terraformでコード管理すれば、設定の意図がHCLに記述されてGitで変更履歴を追跡でき、複数環境への展開もモジュール化で効率化できます。

この記事では、TerraformでCloudFront+S3の静的サイト配信基盤をゼロから構築する方法を解説します。旧方式のOAI（Origin Access Identity）ではなく現在推奨のOAC（Origin Access Control）でS3を保護する設計、HTTPSリダイレクト、マネージドキャッシュポリシー、ACM証明書とRoute 53レコードの管理まで、実際のHCLコードと実行ログで説明します。

動作確認環境: Terraform 1.7.x、hashicorp/aws プロバイダー 5.x、RHEL 9.4

この記事のポイント

・OAI（旧）ではなくOAC（Origin Access Control）でS3を保護するのが現在の推奨設計
・S3バケットはパブリックアクセスを全ブロックし、OACからのGetObjectのみをバケットポリシーで許可する
・CloudFrontのviewer_protocol_policy = "redirect-to-https"でHTTPSへの強制リダイレクトを設定できる
・ACM証明書はCloudFrontのグローバル要件によりus-east-1リージョンで作成する必要がある

続きを読む "TerraformでCloudFrontとS3の静的サイトをコード管理する方法｜OAC・HTTPSリダイレクト・キャッシュポリシーの実践設計"

OpenTofuとTerraformを比較する｜BSLライセンス変更後の移行判断・HCL互換性・機能差分の実践ガイド

「Terraform を本番環境で使っているが、HashiCorp のライセンス変更後に何が変わったのかを把握していない」「OpenTofu という選択肢があると聞いたが、移行すべきかの判断基準がわからない」——これはセミナーでよく受ける相談です。

2023 年 8 月、HashiCorp は Terraform のライセンスを MPL-2.0（Mozilla Public License）から BSL（Business Source License）に切り替えました。競合他社が Terraform をマネージドサービスとして再配布することを制限する変更で、Linux Foundation はこの動きに対抗して Terraform 1.5 コードをフォークし、OpenTofu を立ち上げました。2024 年 1 月に v1.6 が正式リリースされ、2026 年 8 月現在は v1.8 系が安定版として稼働しています。

この記事では、OpenTofu と Terraform を HCL コードレベルで比較し、移行手順と選択の判断基準を解説します。動作確認環境: Rocky Linux 9.4 / OpenTofu 1.8.0 / AWS プロバイダー v5.60.0 で動作確認済みです。

この記事のポイント

・OpenTofu は Terraform 1.5 のオープンソースフォーク・CLI は tofu コマンドで置き換わる
・HCL 構文・プロバイダー・state ファイルはほぼ完全に互換で既存コードの変更は不要
・移行は tofu init → tofu plan の 2 ステップで動作確認できる
・Terraform Cloud 非依存なら移行コストは低く・判断は「社内ポリシー」「将来リスク」で決まる

続きを読む "OpenTofuとTerraformを比較する｜BSLライセンス変更後の移行判断・HCL互換性・機能差分の実践ガイド"

TerraformでLambda関数をデプロイする方法｜aws_lambda_function・IAMロール・zip配布とCloudWatchログの実践設計

「LambdaをAWSコンソールで手動デプロイしていたら、IAMロールの設定が本番と開発でいつの間にかズレていた」
「関数が10本を超えたあたりから、誰がどのバージョンをデプロイしたか追跡できなくなった」

こういった問題はTerraformでLambdaを管理することで根本的に解決できます。関数本体・実行ロール・CloudWatchロググループをひとつのHCLで一貫して定義すれば、デプロイの差分はすべてterraform planで可視化でき、変更履歴はGitで追跡できます。

この記事では、aws_lambda_functionを起点に、IAMロール設計・zip配布・CloudWatchログ・環境変数の扱い方まで、実務で使える設計パターンを解説します。Rocky Linux 9.4 + Terraform v1.7.5、AWS Provider v5.54で動作確認済みです。

この記事のポイント

・aws_lambda_function + aws_iam_role + aws_cloudwatch_log_group を3点セットで定義するのが基本
・source_code_hashでコード変更を検出し、差分があるときだけ再デプロイを走らせる
・LambdaのIAMロールはAWSLambdaBasicExecutionRoleを起点に最小権限を追加する
・ログ保持期間をterraformで強制管理しないと無制限になり請求が膨らむ

続きを読む "TerraformでLambda関数をデプロイする方法｜aws_lambda_function・IAMロール・zip配布とCloudWatchログの実践設計"

TerraformでRDSをプロビジョニングする方法｜aws_db_instanceとサブネットグループ・パラメータグループの実践設計

「TerraformでRDSを追加しようとしたら、サブネットグループ・パラメータグループ・セキュリティグループと関連リソースが多くてどこから手をつけるべきかわからない」
こうした声はよく聞きます。RDSはEC2やVPCと比べてリソース間の依存関係が多く、サブネットグループの設定漏れやセキュリティグループの許可ポートミスで apply 直後にエラーになるケースが後を絶ちません。

この記事では、aws_db_instance を中心に、aws_db_subnet_group・aws_db_parameter_group・aws_security_group を組み合わせたRDSのプロビジョニング手順を実践解説します。MySQLを題材に、削除保護・マルチAZ・自動バックアップ・ストレージ暗号化といった本番環境の必須設定も含めてカバーします。

動作確認環境: Terraform 1.8.5 / AWS Provider 5.50.0（ap-northeast-1リージョン、MySQL 8.0.35）

この記事のポイント

・aws_db_instanceの前にサブネットグループとセキュリティグループの定義が必要
・aws_db_parameter_groupで文字コード・タイムゾーンをコードで管理できる
・本番環境ではdeletion_protection=trueとskip_final_snapshot=falseを必ず設定する
・storage_encrypted=trueでディスク暗号化をTerraformで管理できる（作成後に変更不可）
・terraform applyは完了まで最大20分かかるためCI/CDのタイムアウト設定に注意
・apply後はterraform outputとAWS CLIでRDSエンドポイントと状態を必ず確認する

続きを読む "TerraformでRDSをプロビジョニングする方法｜aws_db_instanceとサブネットグループ・パラメータグループの実践設計"

terraform consoleコマンドでHCL式を対話検証する方法｜変数・関数・条件式のデバッグ実践手順

「terraform plan を実行するたびに時間がかかる。変数の展開結果をすぐに確認したい。」
Terraform を書いていると、変数の値がどう展開されるか、関数が期待通り動くかをその場で確認したい場面が頻繁にある。apply を繰り返すのはリスクがあり、plan でさえ AWS API を呼ぶため数十秒かかることも多い。

この記事では、terraform console コマンドを使って HCL 式を対話的に評価・検証する方法を解説する。変数の参照・組み込み関数のテスト・条件式・for 式のデバッグまで、実際のコマンド出力例を交えて説明する。

動作確認環境: Terraform 1.7.5 / Rocky Linux 9.3

この記事のポイント

・terraform console でHCL式をplan不要で対話確認できる
・var.変数名・local値・data sourceも console で参照可能
・cidrsubnet・jsonencode・formatlist等の関数をその場で試せる
・for式・条件式のデバッグに console は特に効果的

続きを読む "terraform consoleコマンドでHCL式を対話検証する方法｜変数・関数・条件式のデバッグ実践手順"

Terraformのdata sourceで既存AWSリソースを参照する方法｜aws_ami・aws_vpc・aws_subnetsのfilter設計

「AWSのAMI IDやVPC IDをTerraformコードに直書きして、環境ごとにコピーしていませんか？」 ハードコードされたIDはAMIの定期更新で廃止されたとき、あるいはdev・stg・prodで別々のVPCを使うときに途端に管理しきれなくなります。Terraformにはこの問題を解決する仕組みとして data source（データソース）ブロックがあります。

この記事では、aws_ami・aws_vpc・aws_subnets・aws_caller_identity を使い、IDのハードコードをゼロにするポータブルなIaC設計を実践解説します。filterブロックの書き方、よくある「No results」エラーの対処まで、実際のterraform plan出力例を交えて解説します。

動作確認環境: Terraform 1.8.5 / AWS Provider 5.50.0（ap-northeast-1リージョン）

この記事のポイント

・data sourceはリソースを作らず既存の属性値をTerraformコードへ動的に取り込む仕組み
・aws_amiでmost_recent=trueとfilterを組み合わせると常に最新AMIを自動参照できる
・aws_vpc・aws_subnetsで既存VPCのサブネットIDを一覧取得しEC2やALBへ渡せる
・「No results」エラーはfilterのName値とAWSのタグ名の不一致が主な原因

続きを読む "Terraformのdata sourceで既存AWSリソースを参照する方法｜aws_ami・aws_vpc・aws_subnetsのfilter設計"

Terraformのprecondition・postcondition・checkでリソース設定を自動検証する方法｜Terraform 1.5以降のバリデーション機能と実践設計

「terraform applyを実行したら、変数に想定外の値が渡されていてEC2インスタンスのタイプが期待と違っていた」と後から気づくケースは珍しくない。リソースが作成されたあとで設定値の誤りに気づいても、修正のためにdestroyしてapplyし直す手間がかかる。

こうした問題を未然に防ぐために、Terraformにはバリデーション機能が用意されている。apply前に入力値を検証するprecondition、リソース作成後の状態を確認するpostcondition、そして継続的な整合性チェックを担うcheckブロックの3種類だ。

この記事では、Terraform 1.2以降で使えるprecondition・postconditionと、Terraform 1.5以降のcheckブロックの構文と使い分けを解説する。RHEL 9.4・Terraform 1.9で動作確認済みのコード例を中心に説明する。

この記事のポイント

・preconditionはapply前に入力値を検証し、失敗するとapplyをブロックできる
・postconditionはリソース作成後の状態をselfで参照して確認できる
・checkブロックは非ブロッキングで継続的なインフラ整合性チェックができる
・3機能を組み合わせると入力→作成→状態の3段階バリデーションが実現できる

続きを読む "Terraformのprecondition・postcondition・checkでリソース設定を自動検証する方法｜Terraform 1.5以降のバリデーション機能と実践設計"

terraform apply -targetの使い所と危険な乱用パターン｜ピンポイント変更の判断基準と安全な運用設計

「terraform apply -targetを使えば一部だけ先に適用できて便利だな」
そう思って使い始めたところ、次の全体適用でサービス断が発生した——現場でよく聞くインシデントです。

`terraform apply -target` は、Terraform のオプションのなかでも「正しく使えば有効、乱用すると危険」の差が最も大きい機能の一つです。公式ドキュメントでも「通常運用での使用は推奨しない（escape hatch）」と明記されているにもかかわらず、日常的に使ってしまっているチームが後を絶ちません。

この記事では、`-target` の仕組みと正当な使い道、危険な乱用パターン、そして `-target` に頼らなくて済む設計への移行方法を実務目線で解説します。Terraform 1.8系 / RHEL 9.4 環境で動作確認しています。

この記事のポイント

・terraform apply -targetは「緊急避難のオプション」であり通常運用向けではない
・乱用するとtfstateの整合性が崩れ、次の全体applyで予期しない変更が発生する
・正当な用途は「壊れたリソースのピンポイント再作成」「ドリフトした単一リソースの修正」の2つ
・-targetに頼る設計はモジュール分割やdepends_onで根本解決できる

続きを読む "terraform apply -targetの使い所と危険な乱用パターン｜ピンポイント変更の判断基準と安全な運用設計"

Terraformで複数AWSアカウントをまたぐ設計｜provider aliasとassume_roleでマルチアカウント構成を実装する方法

「開発環境と本番環境で別々のAWSアカウントを使っているが、Terraformのコードを2セット書いて管理するのは辛い」
「provider aliasは名前だけ知っているが、assume_roleと組み合わせてクロスアカウント操作をどう書けばいいのかわからない」

複数のAWSアカウントを扱う場合、Terraformのprovider aliasとassume_roleを組み合わせると、1つのコードベースで開発・ステージング・本番の各アカウントにまたがるリソースを同時管理できます。アカウントをまたぐ認証切り替えはTerraformが自動的に行ってくれます。

この記事では、provider aliasの基本設定からassume_roleによるクロスアカウント認証の仕組み、IAMクロスアカウントロールの準備手順、実際のリソース実装例、さらに「provider aliasで統合管理」と「ディレクトリ分割で分離管理」のどちらを選ぶべきかの判断基準まで解説します。

実行環境：Terraform 1.8.x（RHEL 9.4 / Ubuntu 24.04 LTSで動作確認済み）

この記事のポイント

・provider aliasで複数AWSアカウントへのproviderを1つのコードで定義できる
・assume_roleブロックにrole_arnを指定するだけでクロスアカウント認証が切り替わる
・リソース定義でprovider = aws.devのように明示すると作成先アカウントを固定できる
・本番/開発で構成差が大きい場合はディレクトリ分割のほうが安全

続きを読む "Terraformで複数AWSアカウントをまたぐ設計｜provider aliasとassume_roleでマルチアカウント構成を実装する方法"

Terraformのnull_resourceとterraform_dataの使いどころ｜local-execを乱用しないための判断基準

「Terraformで外部スクリプトを実行したいんだけど、null_resourceを使えばいいの？」 「terraform planを実行するたびに余計なスクリプトが走って困っている。」

そういった悩みを抱えているエンジニアは多い。null_resourceは確かに便利だが、使い方を誤るとTerraformコードの可読性が急落し、インフラのドリフト検出も困難になる。

この記事では、null_resourceとterraform_dataの違い・使い分け、そしてlocal-execプロビジョナーを「いつ使っていいか」「いつ代替手段を選ぶべきか」の判断基準を実践的に解説する。

この記事のポイント

・null_resourceはTerraform 0.x時代の回避策、terraform_dataが現代の正解
・local-execは「Terraformで管理できないもの」に限定して使う
・スクリプト実行はnull_resource/terraform_dataではなくAnsible等に委ねるのが設計上正しい
・triggers_replace引数の正しい使い方を理解すれば意図しない再実行は防げる

続きを読む "Terraformのnull_resourceとterraform_dataの使いどころ｜local-execを乱用しないための判断基準"

TerraformでIAMポリシーをコード管理する方法｜aws_iam_policy_documentで最小権限を宣言的に書く

「AWSのIAMポリシーをコンソールでポチポチ設定してきたが、誰がいつ何を変更したのかわからなくなった」
「最小権限の原則は理解しているが、全員がコンソールを触れる状況では権限の肥大化を止められない」

これはIAM管理が手作業に頼り続けることで生まれる問題です。TerraformでIAMを管理するようにすると、ポリシーの変更はすべてHCLファイルのコードとして記録され、Gitで差分管理・コードレビューできるようになります。

この記事では、Terraformのaws_iam_policy_documentデータソースを中心に、最小権限のIAMポリシーを宣言的に書く方法を解説します。S3読み取り専用ポリシーの基本から、Conditionブロックによる細かい権限制御、IAMロールへのアタッチ、よくあるトラブル対処まで一気通貫で習得できます。

実行環境：Terraform 1.8.x（RHEL 9.4 / Ubuntu 24.04 LTS で動作確認済み）

この記事のポイント

・aws_iam_policy_documentはIAMポリシーJSONをHCLで書くためのdata sourceで、コードレビューが可能になる
・statementブロックにactions/resources/effectを明示し、最小権限を宣言的に設計できる
・Conditionブロックを使うとIPアドレス制限やMFA必須などの細かい権限制御ができる
・tfstateにIAMアクセスキーが入るリスクに注意し、IAMロール設計を優先する

続きを読む "TerraformでIAMポリシーをコード管理する方法｜aws_iam_policy_documentで最小権限を宣言的に書く"

Terraformのdepends_onと依存関係設計・暗黙依存とterraform graphでリソース作成順序を制御する方法

「terraform planは通ったのに、applyしたらエラーになった。リソースの作成順序がおかしいのか？」「depends_onを書けばいいのはわかっているが、どこに書けば正しいのかわからない」
Terraformはリソース間のHCL参照式から依存関係を自動的に解決します。しかし、参照式では捕捉できない「副作用依存」が存在するとき、depends_onを明示的に指定しないと期待した順序でリソースが作成されません。

この記事では、terraform depends_on の正しい使い所と、暗黙依存（Implicit Dependency）が機能するしくみ、terraform graphを使った依存関係の可視化方法、さらにdepends_on過剰使用のリスクまで、実コードを交えて解説します。実務でTerraformを使うエンジニアが知っておくべき「依存関係設計の勘所」を体系的にまとめます。

この記事のポイント

・HCL参照式（aws_vpc.main.id など）を書くだけで暗黙依存が自動生成される
・depends_onは暗黙依存が捕捉できない副作用依存にのみ使う最後の手段
・terraform graph | dot -Tpng で依存関係グラフを画像として確認できる
・depends_onの過剰使用は計画精度を下げるため最小限にとどめる

続きを読む "Terraformのdepends_onと依存関係設計・暗黙依存とterraform graphでリソース作成順序を制御する方法"

Terraformのmoved・removedブロックで安全にリファクタリングする方法｜state mvに頼らない宣言型の構成変更

「リソース名を変えたいが、terraform state mv を打ち間違えたら取り返しがつかない」
Terraform で本番インフラを管理していると、そんな不安を抱える場面は必ずあります。

CLI コマンドによる state 操作は強力ですが、誰がいつ実行したかの履歴が残らず、チームで共有もできません。

Terraform 1.1 以降で導入された moved ブロック、そして 1.7 以降の removed ブロックを使えば、リソースの移動や state 管理除外を HCL コードとして宣言できます。変更内容を terraform plan で事前確認し、Pull Request でレビューして、チームに共有しながら安全にリファクタリングできる。これが宣言型アプローチの本質です。

この記事では、moved ブロック・removed ブロックの構文から実務リファクタリングパターン、よくあるエラーの対処まで体系的に解説します。

この記事のポイント

・moved ブロックは state mv の宣言型代替で VCS 管理・PR レビューが可能
・removed ブロックの destroy=false でインフラを残したまま state 除外できる
・plan 実行時に「Moved」表示で事前確認できるため誤操作リスクがほぼゼロ
・Terraform 1.1 以降で moved、1.7 以降で removed が利用可能

続きを読む "Terraformのmoved・removedブロックで安全にリファクタリングする方法｜state mvに頼らない宣言型の構成変更"

terraform testによるコード検証の始め方｜1.6以降のネイティブテスト機能でリグレッションを防ぐ

「terraform applyを実行したら、先週まで問題なかったモジュールが突然壊れていた」
チームでTerraformモジュールを共有していると、誰かの変更が別のモジュールを静かに壊すリグレッションが避けられません。手動で確認するのには限界があり、本番環境への適用後に発覚するケースも珍しくないのが現実です。

Terraform 1.6から、外部ライブラリなしで使える公式のネイティブテスト機能が正式リリースされました。.tftest.hclファイルを作成してterraform testコマンドを実行するだけで、モジュールの入出力やリソース属性を自動的に検証できます。

この記事では、terraform testの基本構文と実行方法を押さえたうえで、CI/CDへの組み込みやtflintとの役割分担まで実践的に解説します。前提バージョンはTerraform 1.6以降です。

この記事のポイント

・terraform testはTerraform 1.6から正式搭載されたネイティブテスト機能
・.tftest.hclにrunブロックとassertを書くだけでモジュール検証ができる
・tflintの静的解析とterraform testの動的テストは役割が異なる二軸
・GitHub Actionsへの組み込みでリグレッションを自動防止できる

続きを読む "terraform testによるコード検証の始め方｜1.6以降のネイティブテスト機能でリグレッションを防ぐ"

Terraformのsensitive変数とシークレット管理｜SSMパラメータストア参照で秘密情報を安全に扱う設計

「Terraformのvariableに sensitive = true を付けたから秘密情報は安全」と思っていたら、tfstateファイルを開いた瞬間にDBパスワードが平文で丸見えだった ── そんな落とし穴にはまるチームは少なくありません。
sensitive = true はTerraformのターミナル出力から値を隠す機能であり、シークレットの「保存」や「管理」の問題を解決するわけではありません。設計レベルでのシークレット管理が別途必要です。

この記事では、sensitive = true の正確な動作と限界を整理したうえで、AWS SSM Parameter Store（SecureString）をdata sourceで参照してシークレットをTerraformコードの外に切り出す設計を、実装例と実行結果を交えて解説します。
動作確認環境: Terraform 1.6 / AWS Provider 5.x

この記事のポイント

・sensitive = true はログ隠蔽のみ。tfstateには平文でシークレットが残る
・SSM Parameter Store（SecureString）でシークレットをコード外で管理する
・outputにsensitive指定を忘れるとCI/CDログに平文が流れる
・リモートバックエンドのSSE-KMS暗号化が最低限の対策

続きを読む "Terraformのsensitive変数とシークレット管理｜SSMパラメータストア参照で秘密情報を安全に扱う設計"

tflint・terraform fmt・validateでコード品質を自動チェックする方法｜pre-commitとCIへの組み込み手順

「terraform applyを実行してから書き間違いに気づいた」「チームで開発していると、インデントや命名規則がバラバラになってPRの差分がノイズだらけになる」こういった問題を放置すると、Terraformコードのレビューコストが静かに積み上がっていきます。

この記事では、Terraformのコード品質を静的チェックで自動化する3つのツール（terraform fmt・terraform validate・tflint）の役割と使い分けを解説し、pre-commitフックへの組み込みとGitHub Actions CIへの統合手順をステップごとに説明します。動作確認環境はRocky Linux 9.4 / Ubuntu 24.04 LTSです。

この記事のポイント

・tflint / terraform fmt / validateは「規約違反・構文・書式」をそれぞれ担当する
・実行順序はfmt → validate → tflintの順が鉄則
・pre-commitフックに登録するとコミット前にチェックが自動実行される
・GitHub Actionsに組み込むとPRレビュー時にチェック結果が可視化される

続きを読む "tflint・terraform fmt・validateでコード品質を自動チェックする方法｜pre-commitとCIへの組み込み手順"

Terraformのuser_dataとcloud-initでEC2を初期設定する方法｜provisionerを避けるサーバー初期化設計

「EC2を作るたびにSSH接続してパッケージインストールや設定ファイルの配置を手動でやっている」「remote-exec provisionerを使っているが、applyのたびにSSH接続失敗でリソースがtainted状態になる」
このような問題は、Terraformでのサーバー初期化設計を見直すことで解決できます。

この記事では、user_dataブロックとcloud-initを組み合わせたEC2初期化設計を実践的に解説します。provisionerが持つ構造的な問題点の整理から、HCLでのheredoc・templatefile()関数・base64encode()の使い方、cloud-config形式のYAML実践例、初期化ログの確認方法、よくあるトラブルの対処まで、本番で使えるレベルで体系化します。

この記事のポイント

・user_dataでEC2起動時にcloud-init処理を実行するのがprovisionerより安全な設計
・HCLのheredocまたはtemplatefile()で外部cloud-config YAMLを渡せる
・変更を反映するにはEC2の再作成（replace）が必要な点に注意する
・実行結果は /var/log/cloud-init-output.log で確認できる

続きを読む "Terraformのuser_dataとcloud-initでEC2を初期設定する方法｜provisionerを避けるサーバー初期化設計"

Terraform Registryの公開モジュールを本番で使う判断基準｜terraform-aws-modulesの選定とバージョン固定

「terraform-aws-modulesを本番に入れていいのか自信がない」「バージョンを固定しないとどんなリスクがあるのか」
Terraform Registryの公開モジュールは実装速度を大幅に短縮できる一方、外部コードを本番インフラに組み込む以上、選定を誤ると取り返しのつかない事態を招きます。

この記事では、Terraform Registryの仕組みからterraform-aws-modulesの選定基準、バージョン固定の正しい書き方、公開モジュールのカスタマイズ戦略、そして導入後のトラブル対処まで、本番採用の判断に必要な情報を体系的に解説します。

この記事のポイント

・terraform registry モジュールはsource + versionでバージョンを固定して使う
・terraform-aws-modulesはAWS公式支援・Star数1万超の実績ある公開モジュール群
・メンテ活性度・Issue対応速度・バージョン更新頻度の3点で本番採用を判断する
・variablesで吸収できないカスタマイズが出た時点で自作モジュールへの移行を検討する

続きを読む "Terraform Registryの公開モジュールを本番で使う判断基準｜terraform-aws-modulesの選定とバージョン固定"

Terraformのディレクトリ構成ベストプラクティス｜environments分割とmodules共通化のリポジトリ設計

「単一のmain.tfにすべてのリソースを書いていたら、環境ごとにファイルをコピーするようになってしまい、どれが最新か分からなくなった」
「terraform planを実行するたびに全リソースの差分確認に追われ、本当に変えたい設定に集中できない」

Terraformを使い始めたエンジニアが必ずぶつかるこの壁の根本原因は、terraform ディレクトリ構成が適切に設計されていないことにあります。

この記事では、単一ファイル構成（脱・単一main.tf）の限界を整理したうえで、environments分割とmodules共通化を組み合わせたリポジトリ設計のベストプラクティスを解説します。3つの設計パターンの比較・environments/dev/stg/prodの実装例・modules/の設計指針・よくある失敗パターンと対策まで、リポジトリ構成軸で体得できます。

実行環境：Terraform 1.8.x（RHEL 9.4 / Ubuntu 24.04 LTSで動作確認済み）

この記事のポイント

・単一main.tfはリソースが増えると「全リソースplan」「環境コピー増殖」で必ず破綻する
・environments分割型はdev/stg/prodをディレクトリで分離しtfstateも環境ごとに独立させる
・modules/共通化の基準は「2環境以上で同じ構成を使うリソース群」を抽出することだけ
・tfstateのS3バックエンドはenvironments/dev・stg・prodで必ずkeyパスを分ける

続きを読む "Terraformのディレクトリ構成ベストプラクティス｜environments分割とmodules共通化のリポジトリ設計"

Terraformのworkspaceと-var-fileで環境を分離する方法｜dev・stg・prodを1つのコードで管理する設計

「devのつもりでterraform applyしたら、prodのEC2を上書きしてしまった」
「workspace切り替えだけでは、インスタンスタイプやドメイン名の環境差分を管理しきれない」

terraform workspaceはtfstateを分離するための仕組みですが、workspaceを切り替えるだけでは「どの環境の変数値を使うか」まで制御できません。dev・stg・prodでインスタンスタイプ、DBのサイズ、ドメイン名が異なる現場では、workspaceと-var-fileを組み合わせて初めて完全な環境分離が実現します。

この記事では、terraform workspace 環境分離の設計として、workspaceと-var-fileを組み合わせたdev・stg・prodの管理方法を解説します。実行環境はTerraform 1.8（RHEL 9.4 / Ubuntu 24.04 LTS）で動作確認済みです。

この記事のポイント

・workspaceはtfstateを分離し、-var-fileはパラメータを分離する役割を担う
・2つを組み合わせることで1セットのHCLで3環境を安全に管理できる
・S3バックエンド使用時はworkspaceごとにtfstateのパスが自動で分かれる
・「workspace selectを忘れたまま apply」が最多事故パターンで対策が必要

続きを読む "Terraformのworkspaceと-var-fileで環境を分離する方法｜dev・stg・prodを1つのコードで管理する設計"

terraform importで既存AWSリソースをコード化する方法｜importブロックで手作業インフラをIaC管理下に置く手順

「既存のAWSリソースがTerraformで管理されていない。コンソールで手作業で作ったEC2やVPCをIaC化したいが、どこから手をつければいいかわからない」
こうした状況は、クラウド運用の現場でよく見かけます。Terraform導入前に作ったリソース、別チームが手動で作成したセキュリティグループ、移行作業で一時的にAWSコンソールから起動したEC2インスタンスなど、IaC管理外のリソースは思いのほか多いものです。

この記事では、terraform import を使って既存AWSリソースをTerraformのstate管理下に移す方法を解説します。旧来の terraform import コマンド方式（Terraform 1.4以前から利用可能）と、Terraform 1.5以降で使えるimportブロック（宣言的な新方式）の両方を比較しながら、実践的な手順を順を追って説明します。

この記事のポイント

・terraform importでAWSコンソール作成済みリソースをIaC管理下に移せる
・Terraform 1.5以降のimportブロックはPRレビュー可能な宣言的方式で推奨
・state mv/rmとは軸が異なる——実インフラを「取り込む」操作がimportの本質
・よくある失敗はIDフォーマット不一致とplan差分の修正漏れの2パターン

続きを読む "terraform importで既存AWSリソースをコード化する方法｜importブロックで手作業インフラをIaC管理下に置く手順"

Terraformのremote_stateでモジュール間データを受け渡す方法｜tfstate分離設計とoutput参照の実践

「VPCのIDを別のTerraformプロジェクトから参照したい」「tfstateを分離したのに、他の層からデータを取り出せない」
Terraformの構成が大きくなると、すべてのリソースを1つのtfstateに押し込むのが怖くなります。ネットワーク・コンピュート・アプリケーションの3層に分離してみたものの、「VPC IDをどうやって別プロジェクトに渡すんだ？」と詰まる方は多いです。

この記事では、terraform_remote_state data sourceを使って、分離されたtfstate間でデータを安全に受け渡す設計パターンを解説します。S3バックエンドを前提に、実際のHCLコードとterraform planの実行例を交えて説明します。

この記事のポイント

・terraform_remote_stateで別tfstateのoutputを参照できる
・backendブロックのS3設定で参照先のstateを指定する
・outputにsensitive=trueで機密情報を安全に渡せる
・設計の鉄則は「一方向参照のみ」で循環参照は禁止

続きを読む "Terraformのremote_stateでモジュール間データを受け渡す方法｜tfstate分離設計とoutput参照の実践"

Terraformのdynamic blockでHCL設定を動的に生成する方法｜繰り返し設定の簡潔化と実務パターン

「セキュリティグループのingressルールをTerraformで管理したいが、許可ポートの数だけブロックを静的にコピーしていたら100行を超えてしまった」
「EC2に追加するEBSボリュームの数を環境ごとに変えたいのに、resource{}自体をfor_eachで増やしても内部のブロックを制御できない」

Terraformを実務で使い始めると、ブロック単位での繰り返し設定という壁にぶつかります。resource{}全体をfor_eachで増やすことはできても、resource{}の内部にある特定のネストブロック（ingress・ebs_block_device・tags等）を動的に生成するには、別の構文が必要です。それがdynamic blockです。

この記事では、TerraformのHCLでネストブロックを動的に生成するdynamic blockの仕組みを解説します。基本構文から始め、iterator引数のカスタマイズ・セキュリティグループへの実務適用・for式との組み合わせ・よくあるエラーの切り分けまで、設計パターンとして体得できます。

実行環境：Terraform 1.8.x（RHEL 9.4 / Ubuntu 24.04 LTS で動作確認済み）

この記事のポイント

・dynamic blockはresource内のネストブロックをリストや集合から動的に生成するHCL構文
・for_each + content{} の組み合わせが基本形。iterator引数で参照名を変更できる
・セキュリティグループのingress・EBSボリューム追加が代表的な実務ユースケース
・for式をfor_each内で使うと、変数リストの変換・フィルタリングを1行で書ける

続きを読む "Terraformのdynamic blockでHCL設定を動的に生成する方法｜繰り返し設定の簡潔化と実務パターン"

Terraformのplan・applyエラーを調査・解決する方法｜TF_LOG・Stateロック・ドリフトを実践的に切り分ける

「terraform applyを実行したらエラーで止まった。でも何が原因か分からない」
Terraformを本番運用し始めると、こうした状況に必ず一度は直面します。エラーメッセージは英語で長く、どの行が本当の原因なのか見つけにくい。CI/CDに組み込んでいれば、パイプラインが突然止まって復旧に時間がかかることもあります。

この記事では、Terraformのplan・applyエラーを体系的に調査・解決するための実践手順を解説します。デバッグログ（TF_LOG）の活用、DynamoDBのStateロック解除、ドリフト検出とリカバリ（terraform plan -refresh-only の使い方と解消アプローチ）、よくあるエラーパターンの切り分けまで、実際のコマンド出力を交えて説明します。

この記事のポイント

・TF_LOG=DEBUG 設定だけでAPIレベルのエラー原因を特定できる
・DynamoDB Stateロック詰まりはforce-unlockコマンドで安全に解除できる
・terraform plan -refresh-only でドリフトを診断し、インフラは変更しない
・ドリフト解消は「コード修正・インフラ修正・terraform import」の3択で判断する
・CI/CDに -detailed-exitcode を組み込めばドリフトをexit codeで自動判定できる

続きを読む "Terraformのplan・applyエラーを調査・解決する方法｜TF_LOG・Stateロック・ドリフトを実践的に切り分ける"

Terraformのstate操作コマンド実践ガイド｜state list・state mv・state rmで既存インフラを安全に管理する方法

「TerraformのHCLを整理してモジュール化しようとしたら、terraform planで大量のdestroy/createが出てしまった」
「既存のAWSリソースをTerraformの管理から外したいのに、誤ってdestroyされてしまわないか心配だ」
「チームメンバーが手動でEC2を増設してしまい、tfstateと実態がずれた。どうやって修正すればいい？」

Terraform運用を本格化するほど、こうした「stateをどう操作するか」という問題に必ずぶつかります。

この記事では、terraform stateサブコマンド（list・show・mv・rm）の使い方を実践形式で解説します。モジュール化に伴うリソース移動、管理対象からの除外、stateのバックアップとロールバック、よくある操作ミスの対処まで、現場で即使える手順を説明します。
実行環境：Terraform 1.8.x、AWS Provider 5.x

この記事のポイント

・terraform state listで管理中リソースのアドレス一覧を確認できる
・terraform state mvはdestroyなしでリソースを移動・リネームできる
・terraform state rmは実インフラを削除せず管理対象から外すだけ
・操作前のterraform state pullによるバックアップが安全運用の絶対条件

続きを読む "Terraformのstate操作コマンド実践ガイド｜state list・state mv・state rmで既存インフラを安全に管理する方法"

GitHub ActionsでTerraformのCI/CDパイプラインを構築する方法｜plan自動実行からapply承認フローまで

「Terraformのコードをレビューしているのに、実際のplan結果を誰も確認できていない」「本番へのapplyを誰でも実行できる状態になっていて、誤操作でインフラが壊れないか不安だ」

こういった課題は、Terraformを個人で使い始めた段階から、チームに広げようとした瞬間に一気に顕在化します。コードレビューはできても、そのコードを適用したらインフラがどう変わるのかをレビュアーが把握できていない、というのは非常に多い現場の悩みです。そこへ「誰かがローカルから手動applyした」という事故が重なると、tfstateが壊れてインフラの実態とコードの乖離が始まります。

この記事では、GitHub Actionsを使ってTerraformのCI/CDパイプラインを構築する方法を解説します。PRトリガーによるterraform plan自動実行とPRへの結果コメント投稿、GitHub Environmentsを使った本番applyの承認フロー、AWSへのOIDC認証設定まで、チーム開発で実際に使えるワークフロー設計の全体像をカバーします。
動作確認環境: GitHub Actions（ubuntu-latestランナー）、Terraform 1.8.5、AWS（ap-northeast-1リージョン）。

この記事のポイント

・PR作成時にterraform planを自動実行してレビュアーが差分を確認できる
・GitHub Environmentsで本番applyに承認フローを挟み誤操作を防ぐ
・OIDCを使いアクセスキー不要でAWSへ安全に認証する方法
・workflow_dispatchで緊急時の手動apply実行を安全に制御する方法
・initの失敗・plan差分なし・OIDC認証エラー・stateロック残留の対処法

続きを読む "GitHub ActionsでTerraformのCI/CDパイプラインを構築する方法｜plan自動実行からapply承認フローまで"

Terraformのprovider設定とバージョン管理｜required_providersとterraform.lock.hclでチーム開発を安定させる方法

「terraform initをチームで実行したら自分のPCでは動くのに同僚の環境では動かない」「先月まで動いていたTerraformコードが急に別のプロバイダーバージョンを要求してくる」
Terraformで複数人の開発や複数環境（dev・staging・prod）の管理を始めると、プロバイダーのバージョン管理のズレが原因でこうした問題が起きます。TerraformのAWSプロバイダーは本体とは独立して頻繁に更新されるため、バージョン指定を適切に設計していないと静かに環境差異が生まれます。

この記事では、required_providers ブロックによるバージョン制約の設計と、terraform.lock.hcl を使ったチーム全体での環境固定方法を解説します。バージョン制約演算子の使い分け・複数プロバイダーの設定・provider alias による複数リージョン構成と、よくあるエラーの対処法も合わせて説明します。

動作確認環境: RHEL 9.4 / Ubuntu 24.04 LTS + Terraform v1.9.x + hashicorp/aws v5.x

この記事のポイント

・required_providers でプロバイダーのsource・バージョン制約を必ず明示するのが基本
・~> 演算子でメジャーバージョンを固定しつつセキュリティパッチを自動取り込みできる
・terraform.lock.hcl は必ずGitにコミットしてチーム全体の環境を固定する
・provider alias で複数リージョン・クロスアカウント構成を1コードベースで扱える

続きを読む "Terraformのprovider設定とバージョン管理｜required_providersとterraform.lock.hclでチーム開発を安定させる方法"

Terraformのlifecycleブロックで本番リソースを誤削除から守る方法｜prevent_destroyとignore_changesの実践設計

「terraform destroyを間違えて本番環境に実行してしまった」「terraform applyでRDSが削除・再作成されてデータが消えた」
Terraformを使い始めたエンジニアやチームで本格運用を始めたばかりの現場では、こうした誤操作が実際に起きています。Terraformは「宣言した状態を実現する」ことに忠実すぎるがゆえに、意図しない削除や置換が発生しやすいツールでもあります。

この記事では、Terraformの lifecycle ブロックを使って本番リソースを守る方法を解説します。prevent_destroy・create_before_destroy・ignore_changes の3設定の意味と、RDS・ALBへの実践的な適用パターンを具体的なコード例と実行ログで説明します。

この記事のポイント

・prevent_destroy = true で誤ったdestroy/replace操作をエラーでブロックできる
・create_before_destroyでALB・セキュリティグループのゼロダウンタイム置換を実現する
・ignore_changesでコンソール手動変更によるドリフトを安全に吸収できる
・RDSにはDeletion Protectionとの二重防護でより確実に誤削除を防げる

続きを読む "Terraformのlifecycleブロックで本番リソースを誤削除から守る方法｜prevent_destroyとignore_changesの実践設計"

TerraformのHCL変数設計｜variable・locals・output・data sourceで構成を整理する方法

「TerraformでインフラをHCLに落としたはいいが、同じリージョン名や環境名があちこちにハードコードされていて管理できない」
「開発・本番の切り替えでファイルを書き換えたら、うっかり本番用の値で開発環境を壊してしまった」

Terraformを触り始めたころ、こういった失敗は誰もが経験します。その根本原因は、Terraformの変数機能を正しく使っていないことにあります。

TerraformのHCLには「variable」「locals」「output」「data source」という4種類の変数・参照機能があります。これらを使い分けることで、コードの重複を排除し、環境ごとの値切り替えをファイルコピーなしに実現できます。さらに、Terraform 1.2以降で使えるprecondition・postconditionを組み合わせれば、設定ミスをapplyの前後に多段で検知できます。

この記事では、HCL変数設計の4要素を実際のコードと実行例で解説します。variables.tfの型定義・バリデーション・tfvarsによる環境分離・locals/outputの使い所・data sourceによる既存リソース参照、そしてlifecycleブロックのprecondition/postconditionによる多段防御まで、設計軸で整理して体得できます。

実行環境：Terraform 1.8.x（RHEL 9.4 / Ubuntu 24.04 LTS で動作確認済み）

この記事のポイント

・variable{}で入力値を外部化し、terraform.tfvarsで環境ごとに安全に切り替えられる
・locals{}は繰り返し使う式や計算結果を1箇所にまとめてDRYにするための要素
・output{}はモジュールから外部へ値を公開し、モジュール間の疎結合を保つ
・data{}ソースは「Terraformで作っていない既存リソース」をコードから参照するための機能
・precondition・postconditionはvariable validationで届かない実行時コンテキスト条件を多段で検証する

続きを読む "TerraformのHCL変数設計｜variable・locals・output・data sourceで構成を整理する方法"

TerraformとAnsibleの違いと使い分け｜IaCツール選定の判断軸

「TerraformとAnsibleって結局どっちを使えばいいの？」「両方学ぶ必要があるの？」
Infrastructure as Codeの導入を検討するエンジニアなら、一度はこの疑問にぶつかるはずです。

どちらもIaCを実現するツールですが、設計思想も得意領域もまったく異なります。「なんとなく流行っているから」という理由で選ぶと、現場で使い物にならない構成になってしまいます。

この記事では、TerraformとAnsibleの違いを設計思想レベルから整理し、「どの場面でどちらを選ぶべきか」の判断軸を実務目線で解説します。CI/CD連携の具体的な手順や、現場でよくある連携の失敗パターンも取り上げます。

この記事のポイント

・TerraformはインフラのプロビジョニングにAnsibleは設定管理に向く
・「宣言型」と「手続き型」の設計思想の違いが選定の核心になる
・現場では両ツールを役割分担させて併用するのが主流
・迷ったときはリソースの「作成/削除」ならTerraform、「設定/変更」ならAnsibleが目安

続きを読む "TerraformとAnsibleの違いと使い分け｜IaCツール選定の判断軸"

Terraformのtfstate管理とS3バックエンド設定｜チーム運用で壊さないための基礎

「チームでTerraformを使い始めたら、tfstateファイルが衝突してインフラの状態がめちゃくちゃになった」
「git管理しているtfstateを複数人が同時に変更して、どれが正しいか分からなくなった」
「S3バックエンドを設定しようとしたが、どのファイルに何を書けばいいのか分からない」

こうした悩みはチーム開発でTerraformを導入した直後に必ずといっていいほど発生します。

この記事では、tfstateの仕組みを基礎から解説し、S3バックエンドによるリモート管理の設定手順、DynamoDBを使ったState Lockingの実装、そしてstateが壊れたときのトラブルシューティングまで一気に解説します。
チームでTerraformを安全に運用するための設計知識を、実際のHCLコードと実行例を交えて丁寧に説明します。

この記事のポイント

・tfstateはTerraformがインフラの「現在の状態」を記録するJSONファイル
・S3バックエンド設定でtfstateをチーム共有・バージョン管理できる
・DynamoDB State Lockingで同時実行によるstate破損を防ぐ
・state破損・ロック残留はterraform force-unlockで対処できる

続きを読む "Terraformのtfstate管理とS3バックエンド設定｜チーム運用で壊さないための基礎"

TerraformでAWS VPCとEC2を構築する方法｜HCL記法とterraformコマンドの実践

「TerraformでAWSのVPCやEC2を構築しようとしたけど、どのファイルに何を書けばいいのかわからない」
「HCLの構文は調べたが、実際にterraform applyするまでの全体像がつかめない」

こういった悩みを持つエンジニアは多いです。Terraformのドキュメントは英語が中心で、しかもProviderのバージョンによって書き方が変わるため、情報が散らばりがちです。

この記事では、terraform aws vpc の構築を軸に、VPC・サブネット・インターネットゲートウェイ・EC2インスタンスをHCL（HashiCorp Configuration Language）で定義し、terraform init / plan / apply の実行フローまで一気通貫で解説します。さらに dynamic ブロック＋for_each によるセキュリティグループの動的ルール生成・locals での for 式活用・splat 式による出力値取得といった実務パターン、および既存AWSリソースをTerraform管理下に取り込む terraform import の基本手順まで押さえます。動作確認環境は Terraform v1.8.x / AWS Provider v5.x（Rocky Linux 9 / Amazon Linux 2023で動作確認済み）です。

この記事のポイント

・terraform aws vpcはHCLのresourceブロックで宣言的に定義する
・VPC→サブネット→IGW→ルートテーブルの順に依存関係を組む
・dynamic ブロック＋for_eachでSGのingressルールを動的に展開できる
・terraform plan で差分確認、apply で実際にAWSリソースが作成される
・tfstateはS3+DynamoDBでチーム共有するのが本番運用の鉄則

続きを読む "TerraformでAWS VPCとEC2を構築する方法｜HCL記法とterraformコマンドの実践"

Terraform入門｜Infrastructure as CodeでAWSインフラをコード化する基礎ハンズオン

「AWSのインフラ構築、毎回ポチポチとコンソールを操作していて、設定ミスや環境差異が怖い」
「Terraformを使えばインフラをコードで管理できると聞いたが、何から始めればいいのかわからない」
「コンソールで手動作成した既存リソース、どうやってTerraformに取り込めばいいんだ…」

こういった悩みを持つインフラエンジニアは多いでしょう。AWSコンソールでの手作業は、チームで運用するほどに属人化・設定漏れ・環境間の差異という問題を引き起こします。

この記事では、Infrastructure as Code（IaC）の代表格であるTerraformの概念から、HCL構文・状態管理・既存リソースの取り込み（terraform import）・モジュール設計、そしてAWSでVPCとEC2をコード化するハンズオンまでを体系的に解説します。「なぜTerraformを使うのか」「どう設計するか」「既存リソースをどう管理下に置くか」「よくあるトラブルをどう乗り越えるか」という4つの軸で、実務で使えるレベルまで踏み込んで説明します。

この記事のポイント

・TerraformはHCLでAWSインフラを宣言的にコード化できるIaCツール
・tfstateで状態を管理し、S3+DynamoDBでチーム共有するのが実務の基本
・terraform importで既存リソースをTerraformのstate管理に取り込める
・terraform fmt/validateでコードの構文ミスを即座に検知できる
・plan/apply失敗の多くは依存関係・権限・tfstate不整合が原因

続きを読む "Terraform入門｜Infrastructure as CodeでAWSインフラをコード化する基礎ハンズオン"

Linux無料マニュアル（図解60P） 名前とメールで30秒登録