Terraform のリモートデプロイ実行環境を提供する OSS、Terrakube を検証してみた

はじめに

こんにちは、大島です。

grasys では、インフラストラクチャのリソース管理として Terraform を利用しています。Terraform のリモートデプロイ実行環境としてこのたび OSS である Terrakube を見つけました。その Terrakube について紹介したいと思います。

HCP Terraform ライクな仕上がりになっていて、Kubernetes で運用できるところも私としてはポイント高いです。Kubernetes 大好きです。

Terrakube とは

Terrakube は、Kubernetes 上で実行できる、Terraform や OpenTofu のリモート実行環境 を提供する OSS です。

機能

ユーザー管理

Terrakube では、ユーザー認証に Dex が使われています。
grasys は、Google アカウントを使っているので、Dex connector で Google の OIDC と接続することで、Google アカウントを使って Terrakube にログインできるようになっています。

素晴らしいです。ありがとうございます。

Dex connector で接続できるプロバイダは他にもいろいろあります。
公式ドキュメントをご参照ください。

Terrakube 上で操作するユーザーに対して、管理者や開発者など、権限を分けたいですよね。
Terrakube では Team という機能で提供しています。

Google Group と組み合わせることで、グループに所属するユーザー全体に一括で権限を設定できました。

OPA

grasysでは、Open Policy Agent を使ってデプロイ前にバリデーションチェックを行なっています。

Terrakube では、Template という機能を使って CI/CD パイプラインを作成します。そこで OPA を利用することができました。

Template

Template は、Terrakube の各ワークスペースの CI/CD パイプラインを提供します。YAML 形式 でステップを記述する、よくある形になっています。ステップ内のスクリプトの記述には BASH や GROOVY をサポートしています。

スクリプトを書けるので、上記のように OPA を実行したり、Slack へ通知したり、他にもいろいろとできるようです。

例えば、Planを実行後、特定のユーザーの承認を経て実環境にデプロイしたい場合が考えられます。その場合はこのような内容になります。

flow:
  - type: "terraformPlan"
    step: 100
    name: "Plan"
  - type: "approval"
    step: 150
    team: "xxxxxx@grasys.io"
    name: "Approval"
  - type: "terraformApply"
    step: 200
    name: "Apply"

Drift Detection

HCP Terraform でも機能としてあります、Drift Detection、Terrakube にもありました。
CI/CD パイプライン定義である Template と、Template を定期的に実行するスケジュールという機能を使って、定期的に Plan を実行することで、いつの間にか発生していた差分に気づくことができます。

気づきたいです、差分。

Dynamic Provider Credentials

デプロイする環境にアクセスする方法に、クラウドプロバイダのサービスアカウントのシークレットキーを使う方法がありますが、その場合、シークレットキーの情報をどこかで保持して設定する必要があります。

漏洩の危険があり、セキュアじゃないです。

Dynamic Provider Credentials では、サービスアカウントのシークレットキーではなく、フェデレーション ID を使って動的にクライアントを認証します。シークレットキーを管理する必要も、作成する必要もなくなります。

積極的に使いたいです。

Terrakube で利用するには、Terrakube の設定と、Workspace の設定が必要になります。

プライベートレジストリ

Terraform モジュールをプライベートに公開して利用できます。HCP Terraform にもありますね。
grasys でも、組織内で横断的にモジュールを再利用したいため、とても嬉しいです。

Terraform

Terrakube を設定するための Terraform を公開してくれています。ただ、エラー文はちょっと微妙です。

╷
│ Error: Error unmarshal payload response
│
│   with module.workspace.terrakube_workspace_tag.main["xxx"],
│   on ../../../modules/workspace/main.tf line 15, in resource "terrakube_workspace_tag" "main":
│   15: resource "terrakube_workspace_tag" "main" {
│
│ Error unmarshal payload response: data is not a jsonapi representation of '*client.WorkspaceTagEntity'

この時のエラーは、タグが存在しないか、あるいは、タグが既に設定されているかの時に発生しました。

GUI で操作すると操作履歴を残さないと再現性がなくなってしまうので私は IaC が大好きです。エラー文が微妙なことには目を瞑りましょう。不満があればコントリビュートすれば良いのです。OSS なので。

移行について

HCP Terraform で作成したワークスペースをそのまま Terrakube にインポートすることができます。

しかし、ワークスペースに設定している環境変数など、インポートしたそのままでヨシ！にはならず、あとちょっとのところが微妙に手が届かない、そんな歯痒さがありました。

結局、インポートした後、設定し直す作業が発生してしまいました。
全てを設定し直す必要がないのはいいですね。

最後に

Terrakube の全ては紹介できていませんが、どんなものなのかおおよその想像がついたのではないかなと思います。

SaaS は自分たちで管理しなくて良い分、料金は上がります。OSS は自分たちで構築運用保守の手間がありますが、料金としては安くなります。そこのトレードオフだと思いますが、Terrakube は、HCP Terraform の諸々の機能をカバーするように機能が充実しており、すごく頑張っているなと感じました。

なにを優先するかで Terrakube なのか、HCP Terraform なのか、はたまた別のものなのか選択していただけたらと思います。快適な IaC ライフをお過ごしください。