Terraform Enterpriseを導入してTerraform v0.10からv0.12に上げた話
須藤 悠
こんにちは！リクルートライフスタイルの共通クラウド基盤でリードクラウドアーキテクトをしている須藤です。
この記事は Terraform Advent Calendar 2019 の2日目の記事です！( リクルートライフスタイル Advent Calendar 2019 2日目の記事でもあります)
2019.06.14 AWS Summit Tokyo 2019 でのセッション
本題に入る前に、我々のチームの新卒2年目、天野がAWS Summit Tokyo 2019で発表したセッションを紹介します。
我々のクラウド基盤では、攻めのインフラであり続けることをひとつの理念として掲げ、サービスレベルの向上・運用の省力化につながるよう積極的にマネージドサービスを活用しています。AWSの新機能の利用も積極的にしており、たとえば6月のセキュリティにフォーカスしたAWSのイベント re:Inforce で発表された VPC Traffic Mirroring も検証を重ね、利用しています。そういった進歩を止めない文化の組織であることが、Terraform Enterpriseの導入にもつながっています。
2019.10.23 HashiCorp Meetup でのセッション
Terraform Enterprise導入について、先日のHashiCorp Meetupで発表しました。こちらはその際の資料です。このときにお伝えした内容を、あらためて整理してお伝えします。
リクルートライフスタイルの共通クラウド基盤は、サービスごとにアカウントを払い出して、サービス開発者がその環境を構築する、というスタイルです。クラウドアーキテクトチームはCCoE(Cloud Center of Excellence)であり、サービス開発者に対してアーキテクチャ相談やコードレビューなどの規範的・助言的な活動を通して成長しあっていく、という活動をしています。共通クラウド基盤として管理しているAWSアカウントの数は、 70 を超えます。
Terraform Enterprise を選択した理由
- 何に課題を感じていたのか？
70 を超えるアカウント、 140 を超えるWorkspaceを11人で管理していましたが、Terraform用の強力な権限を持ったCredentialを将来に渡ってどう安全に管理していくか、というところに課題を感じていました。また、この多数のWorkspaceにおいて、1300を超えるコミット、430を超えるPull Requestが作られており、日々plan/applyをしていましたが、誤った構成変更が反映されてしまうとサービス障害に直結しかねないため、Pull Requestにおけるコードレビューとは別に、planレビューとapply承認のできる快適なワークフローを求めていました。いくつかのCI/CDツールで試作するなど模索を続けていましたが、ID管理・権限管理との兼ね合いもありなかなか満足のいくワークフローが作れずにいました。
- なぜTerraform Cloudではないのか？
これは、我々が利用しているリポジトリがGithub Enterpriseであり、連携するためには固定IPが必要になることに理由があります。こうした背景がない(固定IPを必要としない)組織においては、 Terraform Cloud で十分に恩恵を受けられますので、まずはそちらを試すと良いでしょう。
- 最終的に決め手になったのは？
TerraformやCI/CDのスペシャリストが稼働をかけてTerraformのCI/CDワークフローをメンテナンスし続けるよりも、Terraform Enterpriseを購入した方が安価であること。
月に1〜3回程度のアップデートがあり、管理画面からアップデートボタンを押すだけで簡単に常に最新版のTerraform Enterpriseを利用し続けられること。
この2点でした。HashiCorpが考える「ツール化されたTerraformのベストプラクティス」を買う、という感覚が近いです。Terraform Enterpriseの価格については非公開のようですので、興味のある方はHashiCorp Japanにコンタクトを取ってみましょう。購入前に検証用ライセンスを払い出して貰うことで、導入に問題ないかの確認もできますよ！
Terraform Enterprise導入にあたっての課題
- Workspace数
Terraform Enterpriseのライセンス形態がWorkspace数ベースであったこと、我々のTerraformコードベースがGlobalなリソースとRegionalなリソースでWorkspaceを分けて管理していたことが、結果的にネックになってしまうことがわかりました。そのため、Workspace数をアカウント数と同程度まで少なくしたい、という要件が生じました。
- Terraform v0.10系から v0.12系への移行
もともと我々のチームではTerraform v0.10.8を利用していましたが、新しいHCLの恩恵を受けるために v0.12系への移行を検討していました。v0.12の正式リリースが、ちょうどTerraform Enterprise導入を検討していた時期に重なったため、導入にあわせて v0.12系への移行も検討しました。
このとき大きく分けて、「今のTerraformコードベースを v0.12系の記法にマイグレートする」という選択肢と、「v0.12系の記法で新たにTerraformコードを書き起こす」という選択肢が挙がりました。結論から言えば、我々は後者を選択しました。Workspace数を少なくしたい、という要件が生じていたために、ゼロからより良い形で書き直した方が将来に向けて技術的負債がない状態でスタートできるね、という判断です。
- Terraformのリライトとtfstateの移行
Terraformコードベースのリライトにあたり、それまで
1
2
3
4
5
6
7
8
9
modules
├── cloudtrail
├── cloudwatch_logs
├── config
├── guardduty
├── iam
:
├── s3_bucket
└── vpc
というようなAWSのサービスごとにmoduleを作成していた構成を改め、
1
2
3
4
5
6
7
modules
├── account_base
├── audit
├── id_federation
├── log_collection
├── standard_network
:
と、ユースケースごとにmoduleを作成する形としました。構成しているリソースが、GlobalなのかRegionalなのか、というのを考慮してmoduleを作らなくて良いことも、この助けになりました。
Terraformのコード自体のリライトは比較的すんなりできたのですが、既にTerraformで構成管理しているアカウントすべてで、既存のtfstateをv0.12のtfstateに変更しなければいけない、という課題が最後に生じました。これについては、 state mv コマンドではなく import コマンドで、今ある環境を正としてtfstateを作り直しました。800行を超えるシェルスクリプトを書いてtfstateを再構築したので、この部分がいちばんの力技だったでしょうか。
- Terraform Enterprise 導入時に遭遇したトラブル
Terraform Enterpriseには Automated Recovery 機能があります。定期的にSnapshotをS3に格納して、クラッシュした場合にはS3のSnapshotから自動で回復してくれる、というものです。このAutomated Recoveryが正常に機能せず、クラッシュさせると立ち上がってこない、という症状に検証中に遭遇しました。
Terraform Enterpriseは replicatedctl というコマンドによってインストールやリカバリが行われますが、そのために必要な設定 /etc/replicated.conf が適切にされていなかったことが原因でした。この設定ファイルについての詳細は、 インストーラーのドキュメント で公開されていますので、導入するときには良く確認しておきましょう。
Terraform Enterprise に感じているメリット
Terraform Enterprise自体が我々の管理しているAWS上で稼働することで、そもそもTerraformの実行にCredentialを使う必要がなくなり、EC2RoleとExternalIDによるSTS AssumeRoleによってplan/applyが実行できるようになりました。Credentialの管理上の不安からは完全に開放されたことになります。
我々の基盤管理の性質上、GitOps的なCI/CDのみではサービスに影響を生じさせないためのガードに不足があると感じていたので、メンテナンスを気にしなくても良いapply承認付きのワークフローが手に入ったことは、効率化に大きく寄与しました。コードをリライトした効果と、Terraform Enterpriseによるワークフローが手に入った効果の合計にはなりますが、Terraformのコード変更の必要性が生じてから本番環境反映までのリードタイムは、およそ半分に短縮されました。
Terraform Enterpriseにおいては、tfstateのbackendは s3 ではなく remote になります。Terraform Enterprise自体がtfstateのバージョン管理も提供しています。applyされていないplanがある状態でtfstateをロックしてくれるので、安心感があります。もちろん、tfstateのエクスポート機能もありますので、Terraform Enterpriseでの管理から外して s3 backendに変えたい、となったときも対応できます。
我々のような管理しているWorkspace数が多いという組織や、Terraformコードを編集するエンジニアが多い組織では、特にTerraform EnterpriseやTerraform Cloudを導入する価値が高いのではないでしょうか。
さいごに
Meetupを主催いただいた HashiCorp Japan のみなさま、ありがとうございました！貴重な発表の機会をいただき、Mitchell Hashimotoとのツーショットもたいへん素敵な記念になりました。
Terraformに興味のある方は、ぜひ Terraform-JP の勉強会にも足を運んでみてください。 Terraform-JP slack もあります！
また、わたしたち共通クラウド基盤のチームでは、一緒に働く クラウドアーキテクトポジションを採用中 です！リクルートライフスタイルの共通クラウド基盤を進化させていく仲間になりませんか？この記事を読んでご興味を持っていただけた方は、中途採用ページからご連絡ください。お待ちしています！