ひだまりソケットは壊れない

ソフトウェア開発に関する話を書きます。 最近は主に Android アプリ、Windows アプリ (UWP アプリ)、Java 関係です。

まじめなことを書くつもりでやっています。 適当なことは 「一角獣は夜に啼く」 に書いています。

Terraform の remote バックエンドを使用する (tfstate ファイルを共有できる / apply をリモートで実行できる)

概要

背景

これまで Terraform を local バックエンドのみで使ってきた (tfstate ファイルをローカルホスト上に保持) のだけれど、複数マシンで Terraform を使いたい場合に不便だったのでバックエンドについて調べた。 そこで、最近は remote バックエンドというものがあって便利そうということが分かったので使ってみた。

やったこと

もともとローカルホスト上に tfstate ファイルを保持していたが、remote バックエンドを使うように変更した。

雑感

  • remote バックエンドで Terraform Cloud を使うのは、かなり簡単に始められて楽だった
  • 取り入れるのも楽だし状態保持だけなら無料枠でできるので、個人の趣味プロジェクトとかでも気軽に使っていきたい
    • Terraform Cloud が止まったときとかのリスクは多少気になるが
  • リモート実行もチーム開発で使うのに便利そうだった

バックエンド (backend) とは

Terraform のバックエンドとは、状態 (state) の読み込み方法や、適用 (apply) などの操作の実行方法を決めるもの。 この抽象化によって、ローカルファイル以外での状態保持 (tfstate ファイルの保持) やリモート実行などが可能になっている。 デフォルトでは local バックエンドが使われている。 (ローカルホスト上に状態ファイルを保持するなどの通常動作。)

バックエンドを使用するための設定と初期化

バックエンドの設定は、Terraform ファイルで行われる。 terraform セクションに、以下のように backend 節を書けば良いとのこと。

terraform {
  backend "remote" {
    address = "demo.consul.io"
    scheme  = "https"
    path    = "example_app/terraform_state"
  }
}

バックエンドを使用するための変更の適用は terraform init で行われる。 もし既にローカルホスト上に状態ファイル (tfstate ファイル) がある状態で新たにバックエンドの設定を追加した場合も、terraform init を実行すればローカルから移行してくれる (移行するかどうかインタラクティブに聞いてくれる; 自分の手元で local から remote への移行を確認)。

また、バックエンドの設定の一部を Terraform ファイル以外で設定する方法もある。 (Partial Configuration と呼ぶらしい)

  • インタラクティブ : インタラクティブな入力が無効になっていない場合はインタラクティブに聞いてくれる
  • ファイル : terraform init -backend-config={file_path} という感じで、設定を別に書いたファイルを指定できる
  • コマンドオプション : terraform init -backend-config="{key}={value}" -backend-config="{key}={value}" 形式で指定できる

上記の方法ではバックエンドの種類自体を指定することができない (ですよね? できるのかな?) ので、同じソースコードリポジトリを使っている人たちがそれぞれ別のバックエンドの種類を使用したい場合に不便では……? と一瞬思ったのだけど、その場合は backend.tf みたいなファイルを別に用意して (そしてこのファイルはソースコードリポジトリにはコミットしないことにする)、そこにバックエンドだけの設定を書けば良さそうだった。

remote バックエンド

remote バックエンドを使用すると、Terraform Cloud (https://app.terraform.io/ または Terraform Enterprise) に状態を保持したり、Terraform Cloud 上で処理を実行したりできる。

今回は https://app.terraform.io/ を使用した。 アカウントを作成して、組織 (organization) を作る必要がある。 VCS との連携もできるが、しなくても良い。

local から remote への移行

上述のとおり、Terraform ファイルに設定を書いて terraform init すれば簡単に移行できた。 ワークスペースは事前に作成しておく必要はない。 (terraform init で作成される。)

apply などの処理のリモート実行

https://app.terraform.io/ の無料アカウントでは本来はリモート実行はできないが、試用期間があるっぽくてリモート実行も試してみることができた。 ローカルホスト上で terraform apply 等のコマンドを実行すると、ローカルホスト上のファイルが Terraform Cloud に送信されて、そこで実行が行われるようだった。

(はまりどころ) tfstate ファイルや .auto.tfvars ファイルの扱い

ローカルホスト上のファイルが Terraform Cloud に送られる際、tfstate ファイルや .auto.tfvars ファイルも送られているっぽかった。 (どのファイルが送られるのかまでは調べていないが、少なくともこれらのファイルは送信されるっぽいことは確認した)。

そのため、tfstate ファイルがローカル側に存在すると、エラーになってしまう。 具体的には以下のようなエラーが発生した。

------------ Terraform Enterprise System Message ------------

Terraform Enterprise detected a terraform.tfstate file in your working directory: <VCS-REPO>/terraform.tfstate

The presence of this file causes a state migration error which prevents Terraform from running successfully. To fix this error please migrate your local terraform.tfstate to Terraform Enterprise and make sure the the file is deleted from your version control system.

For step by step instructions on how to migrate your terraform.tfstate file from Terraform Open Source to Terraform Enterprise, please see:

https://www.terraform.io/docs/enterprise/migrate/index.html

-------------------------------------------------------------

Setup failed: Terraform Enterprise detected a terraform.tfstate file

.auto.tfvars ファイルも送られるのでローカル側で変数を定義している場合は特に Terraform Cloud 側で設定を追加しなくてもこれまで通り動くはずである。 が、複数マシンで同じように動かしたいと思うので、Terraform Cloud のワークスペースの Variables で設定した方が良さそうである。

(はまりどころ) aws プロバイダで profile での認証情報指定ができない

それはそうで Terraform Enterprise 側に AWS CLI とかがインストールされていないしプロフィール設定もしていないはずなので、もともと aws プロバイダで profile による認証情報設定をしている場合は、リモート実行するために書き換える必要がある。

便利 : apply 前のレビューなどをチームで可能

下記の図のように、web UI 上でリモート実行の様子を確認できる。 下記の図では閉じているが、plan の結果も見ることができて、web UI 上で confirm することもできる。

f:id:nobuoka:20190915015808p:plain
Terraform Cloud でのリモート実行

チームで開発している際には、ここでレビュー等を行うフローにすることもできて便利そう。

『Infrastructure As Code』 に書かれていた 「ワークフローにガバナンスを組み込む : 承認などのフローも自動化してログの保持などをすることで、手での承認よりも良いものになる」 というのを実現するにも、こういう仕組みを使えると良さそうである。

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス