Terraform Enterprise を触ってみた

はじめに

以前から触りたいと思っていた、Terraform Enterpriseのトライアルライセンスを手に入れたので触ってみました。

Terraform Enterpriseとは

Terraform Enterpriseは商用のTerraformです。OSS版のTerraformの機能に加えて、Policy as CodeやStateをTerraform Enterpriseが管理する、Terrafromコマンド実行時に任意のTerraform Versionを選択できるなどチームで使用するのに嬉しい機能が追加されています。
単体でCI/CDパイプラインとして使用ができ、CircleCIやCodeBuildなので実現していた機構を単体で実現が可能です。

やってみた

IAMユーザーの作成

Terraform EnterpriseからAWSアカウントへのアクセスを許可する為にIAMユーザーが必要です。
今回はAdministratorAccess権限でIAMユーザーを発行します。

IAM_USER_UserName=$(aws iam create-user --user-name 'terraform-enterprise' | jq -r '.User.UserName')
aws iam attach-user-policy --user-name ${IAM_USER_UserName} --policy-arn 'arn:aws:iam::aws:policy/AdministratorAccess'
aws iam create-access-key --user-name ${IAM_USER_UserName} > iam_user_cred_for_tf-ent.json

iam_user_cred_for_tf-ent.jsonに記載されている、AccessKeyIdSecretAccessKeyを、後ほど使用します。

バージョン管理システム(VCS)の追加

今回はVCSにGithubを使用します。
GitHub - VCS Providers - Terraform Enterprise - Terraform by HashiCorp 上記のページを参考に進めていきます。

Terraform Enterpriseにログインして、New Workspaceをクリックします。

SOURCEがNONEとなっており、何も検出できていません。+アイコンをクリックして追加します。

VCS追加画面に遷移しました。Add a VCS Providerをクリックします。

画面が切り替わりますが、一旦そのままで別タブでGithubの連携App追加ページを開きます。
New OAuth Application

Application name Homepage URL Authorization callback URL
Terraform Enterprise(Classmethod) https://app.terraform.io https://example.com/replace-this-later

Application nameは認識しやすい名称を設定すればOKです。Authorization callback URLは後で変更します。

アプリの登録が完了すると、Client IDClient Secretが表示されます。メモして置いてください。
また、アプリのアイコンを設定する事が可能です。下記URLからTerraformのアイコンをDLできます。

https://www.terraform.io/docs/enterprise/vcs/images/tfe_logo-c7548f8d.png

Terraformの画面に戻り、Client IDClient Secretを入力します。

VCSが登録されるとCallback URLが表示されます。コピーします。

Terraformの画面に戻り、Authorization callback URLを上書きして保存します。

Connect organization Classmethodをクリックします。

TerraformからGithubへの接続を認可します。

Workspaceの作成

New Workspaceをクリックします。

先ほどとは異なり、SOURCEにGitHubが追加されています。
Workspace nameとRepositoryを指定します。

最初に変数の設定を行います。上部メニューのVariablesから設定できます。

今回使うリポジトリは、projectenvという変数が必須です。 これらをTerraform Variablesに設定します。

TerraformからAWSへアクセスさせる為に、作成したアクセスキーを設定する必要があります。 Environment Variablesに作成したアクセスキーを登録します。AWS_ACCESS_KEY_IDをsensitiveに設定すると後から調査できなくなるのでsensitive設定しない方が良いと私は考えています。

PLAN & APPLY

Runsに移動してQueue Planをクリックします。

terraform planが実行され、承認を要求して止まっています。

Confirm & Applyをクリックして適用します。

コメントを求められるので入力します。

無事に成功しました。

AWSアカウントを確認してVPCが作成されていればOKです。
後でサブネット数を変更するのでサブネットを確認しておきます。

Variables変更による更新

今回使用しているRepositoryはnum_subnetsでサブネット数を制御しています。(デフォルト3個)
Terraform Variablesnum_subnets = 2を設定します。

Queue Planからコメントを入力して実行します。

変更内容を確認します。3個目のサブネットとルートテーブルの関連付けを削除しようとしています。(0始まり配列なので2は3個目を意味します)
意図した変更なので承認します。

承認コメントを入力します。

成功しました。

AWSアカウントを確認してサブネット数が2個になっていればOKです。

コード変更による更新

コード自体を変更した時の更新もやってみます。
以下の設定をtrue→falseと変更し、RepositoryにPushしました。

enable_dns_hostnames = false
enable_dns_support   = false

Runsを確認するとTerraformが自動で変更を検知し承認を要求しています。
クリックして中身を確認しましょう。

既にPlanが完了しており、意図した変更内容が表示されていました。

ちなみに承認コメントは空でもOKでした。

成功しています。

2つの設定がVPCに正しく適用されていました。

STATEの確認

Terraform EnterpriseはSTATEのバージョン管理も行ってくれます。
メニューのStatesから履歴を確認できます。
(ここで同じ名前で2つ表示されているのは、dataを使っていて更新日時とシリアルが更新されている為でした)

DESTROY

terraform destroyは初期状態では実行できません。
Environment VariablesCONFIRM_DESTROY=1を設定する必要があります。

SettingsDestruction adn Deletion を開いてください。

Queue destroy Planをクリックするとterraform destroyが実行されます。

削除内容を確認します。

承認します。

さらにWorkspacesを削除する場合は、Delete from Terraform Enterpriseをクリックします。

本当に削除して良いか確認されます。

あとがき

基本的なOSS版と際のほぼ無いところですが、まず触ってみました。特にもっさり感はなくサクサク動く感じでした。
次はEnterprise独自の機能を触っていきたいと思います!!