情シス向けのローカル環境でのTerraformテスト環境構築方法

この記事について

  • 社内の情シスメンバー向けに勉強会的なものをやったときにステップバイステップで環境構築できるように説明した資料。
    • ※SREなどガチガチのインフラ屋さんなどには情報量が薄いので、この記事の内容は適しませんので、このページはそっ閉じしてください。
    • 勉強会時には記述していたが、ブログ記載にあたり記述内容を削除、修正しているところがあります。故に、一部説明が不十分な箇所があります。
      • 特に肝心な認証周りの記述については、記載内容薄めです。
        • 社内勉強用には認証周りの記述もしていたのですが、さすがに機微な情報なので...。
  • 既に社内でTerraform環境によるデプロイができている状態の人向け。
    • 他の人がTerraformによるCI/CD環境構築してくれているが、「管理者が自分に変わってしまった！」等で、サクッと自分のPC(Macを想定)でTerraformの挙動を試してみたい方向け。
  • お題として、「AzureAD環境にあるユーザーを操作する」 みたいな感じで書いてますが、適宜ご自身の会社の環境に読み替えてください。
    • 余談：AzureADをTerraform管理下に置くためのファーストステップには以前にそんな感じの記事を書いたのでそちらを参照ください。 ※記事の内容が古いのでいずれ直します。。

最終形

下記のようなことができるようになること。

  1. terraformコマンドの基本的なものが理解できる。
  2. ローカルPCにてTerraformのインストール ＆ バージョン切り替えができる。
  3. terraform planでtfファイルと実環境の差分を見れること。
  4. 特定リソース(今回はダミーのAzureADユーザーを作成)をimportできること。
  5. やらかしてしまった ときのterraform stateの修正方法。

実践編1: terraformコマンドの基本を理解

情シス的に下記を知っていればだいたいは対処できる系のコマンド(多分)

  • terraform init
    • terraformコマンドを叩くための初期化コマンド
      • これを実行すると各種providerなど必要なものをダウンロードして実行環境整えてくれる
  • terraform plan
    • 現行のtfファイルと相手先の環境が合っているかの確認コマンド
  • terraform apply
    • 現行のtfファイルの内容で相手先環境を更新
  • terraform import
    • 相手先リソースの内容をstateファイルに書き込む
  • terraform state pull > 出力先ファイルパス.json
    • 現行の構成状態(stateファイル)を取得 ※テキストに出力したい場合は > とかで外部出力する。
      • ※出力したファイルを別のフォルダとかにコピーしておくと更に安全。
      • バックアップファイル自体を削除したり、改変しちゃったときに別場所にコピーしたものからも復旧できるので。(バックアップはいくつあってもいい)
  • terraform state -force push
    • ローカルにあるstateファイルの内容で更新。
      • forceつけとかないと大概の場合うまくいかない。
      • これを実施するときは最終手段。(何かしらのリカバリ系)
  • 地味に使う技： コマンドに -var "変数名=値"
    • tfファイルに環境ごとで違う変数をわたしたいときに使う
      • 例: -var “env=prod” とするとenvという変数にprodを入れた状態でTerraformを実行できる。

実践編2: terraformをローカルPCにインストールする。

  • Terraformはバージョンを変えることが割とあります。
    • バージョンが違うとtfファイルの書き方が変わるなど

  • そのため、Terraformのバージョン変更や変更が容易な tfenv を用います。

  • 手順

    1. ターミナルで brew install tfenv コマンドでtfenvをインストール。
    2. パスを通すために、一旦ターミナルを終了、再度起動。
    3. tfenv --version でバージョンが表示されることを確認。
    4. ご自身のプロジェクトで何のTerraformバージョンが使われているか調べるために terraform { と言ったキーワードで検索。
      • required_version = "1.2.5" みたいになっていれば、それがそのプロジェクトのバージョンです。
      • まぁ確認しなくても、違うバージョン使うと このバージョン使ってね！ というエラーが出て、怒られるのでこんなことしなくても大丈夫そう…
    5. tfenv install <<バージョン>> で指定されたTerraformのバージョンをインストールしつつ、 tfenv use <<バージョン>> で利用するTerraformバージョンを指定する。
    6. terraform --version で指定されたバージョンがインストールされたことを確認。

実践編3: terraform planでtfファイルと実環境の差分を見れること。

※下記は環境により異なるので一例。

  1. 各環境に合わせた認証情報をターミナル上でセットする。
    • 例：
      • AzureAD環境の場合
      • AWS環境の場合
        • aws configureコマンドなどで、対象のAWSアカウントの認証情報をセットする。

応用編1: AzureADの特定リソース(今回はAzureADユーザー)をimportする

  1. AzureADで適当なユーザーを作成。
  2. そのユーザーのページを開いて、 オブジェクト ID をメモする。
  3. 作業ミス時リカバリ対応のため現状のstateファイルのバックアップを取得しておく。
    • terraform state pull > statefile_backup.txt
  4. importする。今回使うリソースは azuread_user。
    1. リンク先の末尾に import文の例がある。
      1. 今回だと terraform import azuread_user.my_user 00000000-0000-0000-0000-000000000000
        1. my_user の部分がtfファイルに記載した名前。 000000〜 の部分にオブジェクトIDを指定する。
  5. user-test.tf と言った形の拡張子.tf の適当なテキストファイルを用意し、下記のように作成する。
    jsx resource "azuread_user" "my_user" {
  6. 試しに terraform plan してみる。
    1. 差分が表示されるので、差分がなくなるように作成したtfファイル(上記例だとuser-test.tf)を追記、修正する。

応用編2: やらかしてしまった ときのterraform stateの修正方法。

※上記の 応用編1 の変更内容を「やらかしてしまった」と仮定して、応用編1の変更内容をなかったことにします。
(この操作によりリカバリ操作の雰囲気がつかめるはず)

  1. 応用編1 で取得したバックアップファイルの statefile_backup.txt を使います。
  2. terraform state push -force statefile_backup.txt を実行。
    • これをすることで応用編1 の変更内容の前の状態に戻せる。
  3. terraform plan -var "env=prod" を実行。
    • 応用編1 と違い、新規リソースが作成しようとする挙動になることを確認。