Terraform

仕事柄、プロジェクトごとに複数アカウントを切り替えて HCP Terraform (旧称 Terraform Cloud) を使っている。 HCP Terraform ではローカル環境などで terraform plan する前に terraform login で Plan を実行するアカウントのトークンを取得しておく必要がある。 しかし、terraform login で取得したトークンは 1 アカウント分しか保存されないので、アカウント切り替え時に都度トークンを取得する手間が発生する。 そこで、HCP Terraform のアカウントを使い分ける方法を紹介する。 要約 環境変数 TF_CLI_CONFIG_FILE を使用して CLI 設定ファイルを切り替え プロジェクトごとに .terraformrc ファイルを用意 direnv で自動的に環境変数を切り替え オプションとして ghq + peco と組み合わせて効率化 HCP Terraform のトークン Terraform ではコマンド実行時に CLI 設定ファイルが読み込まれる。 デフォルトでは $HOME/.terraformrc と $HOME/.terraform.d/credentials.tfrc.json というファイルを読み込む。 これらのファイルに設定されているトークンが HCP Terraform の認証に使われるが、使われるトークンの優先順位は次のようになる。 $HOME/.terraform.d/credentials.tfrc.json $HOME/.terraformrc .terraform.d/credentials.tfrc.json .terraform.d/credentials.tfrc.json は HCP Terraform のトークンを格納するファイル。 terraform login で取得されたトークンがこのファイルへ自動的に登録される。 ファイルの中身は以下のようになっており、HCP Terraform のドメイン app.terraform.io または Terraform Enterprise (HCP Terraform のセルフホスト版) のドメインが設定される。 ...

こちらは エーピーコミュニケーションズ Advent Calendar 2024 の 1 日目の記事です。 Ephemeral values の登場 先日リリースされた Terraform v1.10.0 で Ephemeral values という新しい機能が登場しました。 Terraform 1.10 improves handling secrets in state with ephemeral values Terraform 1.10 is generally available, and it includes ephemeral values along with improvements to plan and apply performances. www.hashicorp.com Ephemeral values は次の要素で構成されています。 Ephemeral input variables / Ephemeral output variables Ephemeral resources Write-only attribute (v1.11 で追加予定) この中でも今回は Ephemeral resources に焦点を当ててみます。 ...

普段プライベートでは Terraform Cloud は Azure のリソース（このブログの Static Apps や自宅ラボと連携しているサービス）を管理するために使ってます。 最近 Terraform Cloud を触る、というかドキュメントを読み漁る機会があって、この機会に Terraform Cloud Operator for Kubernetes を自宅ラボに入れてみるかぁ、となったのでやってみました。 ちなみに最近アップデートされた v2 のほうです。 HCP Terraform Operator for Kubernetes overview | Terraform | HashiCorp Developer The HCP Terraform Operator for Kubernetes allows you to provision infrastructure directly from the Kubernetes control plane. developer.hashicorp.com Terraform Cloud Operator for Kubernetes は長すぎるので、以降 TFC Operator と記載します。 TFC Operator は何ができるの？ TFC Operator はカスタムリソースを使って Terarform Cloud のワークスペースやモジュール、そしてエージェントプールを Kubernetes のリソースとして管理することができます。 ...

はじめに 本ブログは Azure の Azure Static Web Apps という PaaS でホスティングしています。 今までは Azure Portal で画面ポチポチしながら設定変更していましたが、なにかあったときに備えてリソースを Terraform で管理するようにします。 いわゆる Infrastructure as Code です。 今回は Azure Static Web Apps の既存リソースを Terraform 構成ファイルに落とし込んで、Terraform 自体を Terraform Cloud に管理してもらう形にします。 どちらかと言うと Terraform Cloud を使う方便だったり。 Azure Static Web Apps 既存リソースの Terraform 化 まず、Azure Static Web Apps のリソースを Terraform で管理できるように構成ファイルを作成します。 事前にプロバイダの設定ファイルを作成してから terraform init しておきます。 terraform { required_version = ">= 0.12" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.0" } } } provider "azurerm" { features {} } そして、staticsite.tf ファイルにリソースの箱だけ用意しておきます。 Azure Static Web Apps のリソースはサイト本体を管理する [azurerm_static_site] と、サイトアクセスに利用するカスタムドメインを管理する [azurerm_static_site_custom_domain] の2種類です。 ...

前回の投稿で、Terraform を使って AKS で AGIC を動かす際のハマりポイントを紹介しました。 その際はマネージド ID の権限周りの設定がうまくできていなかったのですが、解決方法がわかったので改めて Terrafrom で AKS と AGW をデプロイする書き方を整理します。 デプロイパターン まず、AGIC から使う前提の AGW を Terraform でデプロイするパターンとしては以下の 2 つが考えられます。 AKS と AGW を個別にデプロイ AKS デプロイ時に AGW も作成 それぞれについて、Terraform の書き方とデメリットについて説明します。 前提条件として、以下のリソースは既に存在しているものとします。 リソースグループ VNet AKS 用 サブネット AGW 用 サブネット AKS と AGW を個別にデプロイ PIP AKS と AGW を個別にデプロイするパターンでは、Public IP も作成する必要があります。 resource "azurerm_public_ip" "pip" { name = local.pip_name resource_group_name = azurerm_resource_group.rg.name location = azurerm_resource_group.rg.location allocation_method = "Static" sku = "Standard" } AGW 次に、PIP に依存する形で AGW を作成します。 ...

Terraform を使って Azure Kubernetes Service (AKS) で AGIC を動かす機会があったので、ハマりポイントを記録しておきます。 AGIC とは Application Gateway Ingress Controller (AGIC) は、Azure ネイティブの L7 ロードバランサ Application Gateway を利用した AKS で動作する Ingress Controller です。 AGIC を使うことで、AKS で Application Gateway の機能（URL ルーティングや TLS 終端）を使うことができます。 また、AKS クラスタ外の Application Gateway がオートスケールするため、トラフィックの増減に対してクラスタでのリソース消費がありません。 この機能を使うためには、Azure に AKS と Application Gateway、そして Public IP のリソースをデプロイする必要があります。 Terraform から Application Gateway を作成する方法として 2 パターンあります。 Application Gateway と Public IP のリソースタイプを指定する AKS のリソースタイプで Application Gateway を指定する ちなみに、利用した Terraform のバージョンは以下になります（バージョン古いと怒られていますね…）。 ...

前回、Terraform を使って Proxmox VE に VM を作成した。 このとき作成した main.tf は最小限の項目しか設定していなかったので、VM のパラメータを設定するように変更する。 設定項目はドキュメントを参照した。VM のネットデバイスやディスクは個別のブロックで設定するらしい。 terraform { required_providers { proxmox = { source = "telmate/proxmox" version = "~> 2.9.10" } } } provider "proxmox" { pm_api_url = "https://pve1.nnstt1.home:8006/api2/json" } resource "proxmox_vm_qemu" "terraform-test" { name = "terraform-test" target_node = "pve1" iso = "local:iso/Fedora-Server-dvd-x86_64-36-1.5.iso" ### 以下、追加した項目 bios = "ovmf" onboot = true memory = 2048 sockets = 1 cores = 2 cpu = "host" scsihw = "pvscsi" # Disk block disk { type = "scsi" storage = "local-lvm" size = "20G" format = "raw" } # Network block network { model = "vmxnet3" bridge = "vmbr0" } } 名前通りの設定をすればよいので難しい点はなさそう。 ...

先日構築した Proxmox VE クラスタを IaC で管理したいと思い、重い腰を上げてついに Terraform に入門した。 Terraform はクラウドリソースを管理するのがメインと思っていたけど、幸いにも Proxmox VE にも対応している。 「対応している」よりは「誰かが対応するように Provider というものを作ってくれている」という表現のほうが正しい。 Proxmox VE で VM やコンテナを作るための「Proxmox Provider」というものが公開されている。 Terraform Registry - proxmox 手始めに Proxmox Provider のドキュメントに沿って VM を作成してみる。 Proxmox VE Terraform 用ユーザ/ロールの作成 Proxmox VE に Terraform が利用するユーザとロールを作成する。 クラスタ管理権限を付与することもできるが、必要最低限の権限を割り当てることでセキュリティリスクを低減する。 root@pve1:~# pveum role add TerraformProv -privs "VM.Allocate VM.Clone VM.Config.CDROM VM.Config.CPU VM.Config.Cloudinit VM.Config.Disk VM.Config.HWType VM.Config.Memory VM.Config.Network VM.Config.Options VM.Monitor VM.Audit VM.PowerMgmt Datastore.AllocateSpace Datastore.Audit" root@pve1:~# pveum user add terraform-prov@pve --password <password> root@pve1:~# pveum aclmod / -user terraform-prov@pve -role TerraformProv 作成したロールとユーザを確認する。 表形式で出力されるが見切れてしまっている。 ...