未経験からの基盤構築挑戦記　第8回：連携編

Last updated at 2026-09-28Posted at 2026-09-28

前回：未経験からの基盤構築挑戦記　第7回：Keycloak編

はじめに

ここまで、Terraform、Puppet、Vault、Consul、ELK、Keycloakと、それぞれ単体で触ってきた。最終回として、個別に触ってきたツール同士を、実際に連携させてみる。

こんな方におすすめ

個別のツールは触ったが、実際にどう組み合わせて使うのかイメージが湧かない方
「秘密情報をコードに直書きしない」という鉄則が、具体的にどう実現されるのか知りたい方
Terraformのsensitive（機密情報）表示について気になる方

やること：VaultとTerraformを繋げる

今回試すのは、**「Vaultに保存した値を、Terraformが読み取って、実際に動いているnginxコンテナに反映させる」**という構成。実務でも典型的な、「秘密情報をコードの外に置いておき、構築ツールが都度取りに行く」というパターンを再現する。

Vaultに値を保存する

vault server -dev &
export VAULT_ADDR='http://127.0.0.1:8200'
vault kv put secret/nginx-config welcome_message="Vaultから取得したメッセージです"

main.tfに、Vaultへの「参照」を書く

terraform {
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "~> 3.0"
    }
    vault = {
      source  = "hashicorp/vault"
      version = "~> 4.0"
    }
  }
}

provider "docker" {}

provider "vault" {
  address = "http://127.0.0.1:8200"
}

data "vault_kv_secret_v2" "nginx_config" {
  mount = "secret"
  name  = "nginx-config"
}

resource "docker_image" "nginx" {
  name = "nginx:latest"
}

resource "docker_container" "nginx" {
  name  = "terraform-nginx"
  image = docker_image.nginx.image_id

  env = [
    "WELCOME_MESSAGE=${data.vault_kv_secret_v2.nginx_config.data["welcome_message"]}"
  ]

  ports {
    internal = 80
    external = 8081
  }
}

ポイントは、data "vault_kv_secret_v2"の部分。値そのものをコードに書かず、「Vaultのこの場所にある値を、実行時に取ってきてください」という参照だけを書いている。

plan → apply

terraform init
terraform plan

terraform planの出力で、envの項目に注目すると、

+ env = (sensitive value)

と表示され、実際の値は隠されていた。特に「隠してください」という設定を書いていないにもかかわらず、Terraformが「Vault providerを経由した値」を自動的に機密情報として認識し、画面やログから隠してくれていた。

terraform apply

yesで確定すると、無事に構築が完了した。

コンテナの中身を確認する

docker exec terraform-nginx env | grep WELCOME_MESSAGE

WELCOME_MESSAGE=Vaultから取得したメッセージです

Vaultに保存した文字列が、そのままコンテナの中の環境変数として渡っていることを確認できた。

「渡っている」と「表示される」は別の話だった

ここで、当然出てくる疑問にぶつかった。「環境変数として渡っているなら、ブラウザでnginxを開いたときに、そのメッセージが表示されるのでは？」

結論、表示されない。理由を整理すると：

今回変更したのは、コンテナの中に環境変数というメモを1枚追加しただけ
nginxが表示するHTMLファイル自体には、一切手を加えていない
nginxは「決められたファイルの中身を、そのまま返す」だけのプログラムなので、環境変数の中に何が置いてあろうと、それを読んでHTMLに埋め込むという処理をするようプログラムされていない限り、気づきもしない

「値が正しく届くかの確認（配線のテスト）」と「画面に正しく表示されるかの確認（見た目のテスト）」は、別の作業という理解に至った。実務でVaultにパスワードやAPIキーのような「人間に見せない情報」を保存する場合は、配線のテストだけで目的は達成される。一方、今回のように、本来は画面に表示してもおかしくない情報を扱う場合は、見た目のテストまで省略できない。この違いに気づけたのは、疑問をそのままにせず掘り下げたからこそだった。

変更の重さに応じて、確認の粒度を変える

とはいえ、見た目のテストまで毎回必ず必要か、というと、それも変更内容次第で変わる。今回のような表示メッセージ1つの変更であれば、配線の確認だけで本番に反映しても大きな問題は起きにくい。一方、顧客情報やデータベース接続設定のような変更であれば、開発環境での検証・レビュー・承認といった段階を、慎重に踏む必要がある。

これは「リスクベースアプローチ」と呼ばれる考え方で、変更が失敗した場合の影響の大きさに応じて、確認の手厚さを調整する、という実務での基本的な判断軸だった。今回のシリーズを通して出てきた「最小権限の原則」「多重防御」とも、根っこは同じ発想でつながっている。

まとめ

今回、以下を体験できた。

VaultとTerraformを、実際に連携させて構築する
Terraformが機密情報を自動的にマスキングする挙動を確認する
「値が渡ること」と「画面に表示されること」の違いを、疑問を掘り下げながら整理する

最後に、それぞれ何のためにやったのか、狙いを簡潔にまとめておく。

メッセージという、あえて画面に表示してもおかしくない値を選んだこと：「渡っているのに、なぜ表示されないのか」という疑問を意図的に引き出し、配線と表示の違いを体感するため
plan結果でsensitive valueと表示されたことを見逃さなかったこと：Terraformが自動でやってくれている安全対策に気づき、その意味を理解するため

第0回から始まったこのシリーズは、ここでいったんの区切りとする。未経験の状態から、無料の範囲だけで、基盤構築の主要な要素に一通り触れ、最後には個別のツール同士を連携させるところまでたどり着けた。次は、また別のテーマで挑戦していきたい。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

未経験からの基盤構築挑戦記 第8回：連携編