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
に記載されている、AccessKeyId
とSecretAccessKey
を、後ほど使用します。
バージョン管理システム(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 IDとClient Secretが表示されます。メモして置いてください。 また、アプリのアイコンを設定する事が可能です。下記URLからTerraformのアイコンをDLできます。
https://www.terraform.io/docs/enterprise/vcs/images/tfe_logo-c7548f8d.png
Terraformの画面に戻り、Client IDとClient Secretを入力します。
VCSが登録されるとCallback URLが表示されます。コピーします。
Terraformの画面に戻り、Authorization callback URLを上書きして保存します。
Connect organization Classmethodをクリックします。
TerraformからGithubへの接続を認可します。
Workspaceの作成
New Workspaceをクリックします。
先ほどとは異なり、SOURCEにGitHubが追加されています。 Workspace nameとRepositoryを指定します。
最初に変数の設定を行います。上部メニューのVariablesから設定できます。
今回使うリポジトリは、project
とenv
という変数が必須です。
これらを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 Variablesでnum_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 VariablesにCONFIRM_DESTROY=1
を設定する必要があります。
Settings → Destruction adn Deletion を開いてください。
Queue destroy Planをクリックするとterraform destroy
が実行されます。
削除内容を確認します。
承認します。
さらにWorkspacesを削除する場合は、Delete from Terraform Enterpriseをクリックします。
本当に削除して良いか確認されます。
あとがき
基本的なOSS版と際のほぼ無いところですが、まず触ってみました。特にもっさり感はなくサクサク動く感じでした。 次はEnterprise独自の機能を触っていきたいと思います!!