Zenn
🗂

Terraform cloudの最初の構成を考えるのと、変数セット(Variable sets)のキめ方

2024/12/10に公開
AWS
Terraform
Terraform Cloud
tech

記事巻き戻して再開

階層

Organizations

トップに Organizations がある。これはurlのslug的なものを含むため、Terraform cloud内でユニークである必要があるから、既に誰かがTerraform cloud内で取得済みの場合これを利用できない。

Workspaces

Organizationを作ったらワークスペースを作る。設定のスコープがOraganizationを跨ぐようなものは存在せず、完全に分離される。ただし設定を共有するという場合、ワークスペースからその手の機能が出てくるのでこの項ではそれを細かく解説する。

構成例

ここでは最も簡単な例として組織1というOrganizationに4つワークスペースをぶら下げてみる構成例を考えてみよう。

  • 組織1
    • プロジェクト1 - prod
    • プロジェクト1 - dev
    • プロジェクト2 - prod
    • プロジェクト2 - dev

プロジェクト

ここで例示したプロジェクト1 - prodというような名前のワークスペースを命名する事もできるんだけど、今はProjectという概念が出来たのでもし同一Organizationの中で分離して管理する必要があるのであれば、そっちで管理した方がよさそう。

割と最近できた概念。

https://dev.classmethod.jp/articles/update-terraform-cloud-add-project/

精査する

Organizationの下にいくつもプロジェクトを作るもんなのか、あるいはプロジェクトごとにOrganizationを分けるか、など。ただ、先述したようにorganizationをまたぐ情報の共有は基本的にできない。だから客先のOrganizationの名前を登録するでなく、自社のOrganizationの下に客先の構成をProjectとして持つっていう構成も考えられますよね。

  • 自社の名前(Organization)
    • 客のプロジェクト1
      • prod (workspace)
      • dev (workspace)
    • 客のプロジェクト2
      • prod (workspace)
      • dev (workspace)

まあこの辺は決まりがあるわけじゃないのでトライアンドエラーでやってみてくださいという事で。

はじめてみる

前は何か1からのチュートリアルみたいなの書いたけどまあzenn.devでそれをやる事もねえかと思ったのでやめます。適当なgitレポジトリとリンクする所はまあ頑張ってもろて

provider "aws" {
  region = "ap-northeast-1"
}

こんな内容のファイルだけ置くところからスタートするといいんじゃないかと。regionをも柔軟に指定したいとなると面倒だけどまあこれで大体なんとかなるんじゃねえかと。

ワークスペースの変数

これは基本的にワークスペースごとに

  • Terraform変数
  • 環境変数

が定義できるんだけどVariable setsってのがみえる

Variable setsを使用すると、Organization内の複数のワークスペース間で変数を再利用できます。複数のワークスペースで使用される変数については、Variable setsを作成することをお勧めします。

といっている。これは冒頭の構成をよく吟味して決定する必要があるが

  • 自社の名前(Organization)
    • 客のプロジェクト1
      • prod (workspace)
      • dev (workspace)
    • 客のプロジェクト2
      • prod (workspace)
      • dev (workspace)

このパターンではおそらくプロジェクトごとにAWSの接続情報が異なるのでそれぞれセットしないといけないはずだ。ただしかし

Variable setsの適用範囲にProjectを選択できるようになりました。(2023/4/28更新)

なのでプロジェクトごとに変数セットを当てられるようになっているからやはり接続情報とかはVariable setsに放りこんでおいた方がよさそうな気もしますね。

ってわけでVariable setsを作ってみよう

これはWorkspaceごとに作るのではないのでもう1つ上位のOrganizationの設定の中にあるメニュー

するとこんな感じで作れていく

スコープも細かく刻めるのだがApply globallyを選択する

この組織内の現在およびこれから作成されるのすべてのワークスペースがこの変数セットにアクセスできます。

ここでは例によって

  • AWS_ACCESS_KEY_ID（公開キー）
  • AWS_SECRET_ACCESS_KEY（秘密キー、Sensitiveとして設定）

をセットしていく。もちろん環境変数にセット

まあなんとなくこんな感じで書いて作成する

VPCを作ってみる

とりあえず何か作らないと機能しないので、とりあえずVPCを作る

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "main-vpc"
  }
}

するとVariable setsが効いてるためワークスペースでの変数のセットは必要なく

このようにした時に考えること

Apply globallyにしているのでworkspaceごとで全て共通のAWS変数を使うので、同じアカウントに作成しにいく事になる。ということはたとえば

  • prod
  • dev

のようなワークスペースを作った場合同じアカウントに作成しにいくから

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "main-vpc"
  }
}

とするとvpcが綺麗に被ってまーアカンよねってことで。

まあこれ作れちゃうからね。なので使い始める前にこの辺をよく吟味してから構築していってくださいねと。設計は最初でしくじると後に相当響いてきますからね...

Discussion