Share
Embed
Terraform EnterpriseやTerraform CloudのAPIを活用して、一歩踏み込んだTerraform運用自動化を! / HashiTalks_sudo
2022/08/25_HashiTalks: Japanでの、須藤の講演資料になります
Transcript
24 slides
-
2022.08.25 HashiTalks Yu SUDO @ リクルート インフラソリューションユニット 2 SRE部 クラウドグループ
クラウドの横断基盤を管理・運⽤・改善 している組織。 AWS基盤チームSENTOのリーダー。 -
2022.08.25 HashiTalks CCoE Cloud Center of Excellence SENTOチームの特性 IRE Infrastructure
Reliability Engineering 9 -
2022.08.25 HashiTalks CCoE 規範的・助⾔的活動 プロダクトに対する伴⾛ 新機能の検討・検証 EOSL対応 SENTOチームの特性 IRE 基盤コンポーネント
ID管理, 踏み台, VPC管理, 専⽤線, WAF, NWF, メールGW, リアルタイム監査, etc → Terraform活⽤︕ 10 -
2022.08.25 HashiTalks 定期的な構成差分チェックをしたい • プロダクトとSENTO基盤でアカウントを共有しており、SENTO基盤で管理している部分に ついてもプロダクトが操作することが可能 • Terraformで構築・運⽤している環境に対して、しばらく時間が経過してからソースコードを 変更したときに、plan時にそれまで認識していなかった差分を⽣じることがあった •
公式にDrift Detection機能が発表されるよりも前だった 100を超えるWorkspaceに対して⼀⻫に操作したい • 全アカウントに対して、再度Run(plan)をかけ直したいケースがあった • applyのapprove待ちになっているRun(plan)をすべてDiscardしたいケースがあった • Workspace数が100を超えているので、そういった操作が必要になったときに⼤きな負担 だった Terraform運⽤⾃動化の背景 13 -
2022.08.25 HashiTalks 47種類のJSON APIが公開されてる、 って知ってました︖ GUI上で実施可能なほぼすべての操作が APIとしても利⽤可能︕ → Runs API
と Organizations API、 Workspaces API で やりたいことが実現できる︕ ということで、2つの事例を紹介していきます https://www.terraform.io/cloud-docs/api-docs/run Terraform EnterpriseやTerraform Cloudの JSON API 14 -
2022.08.25 HashiTalks SENTOチームとプロダクトチームの責任共有 • SENTO基盤において、AWSアカウントの構築・管理(AWS+Terraform)はSENTOチーム • 基盤上でのサービス構築・運⽤はプロダクトチーム 基盤側の管理リソースをプロダクトが変更することを⼀部許容 • SCP(Service
Control Policy)でタグベースのガードレールはあるものの、限界がある • プロダクト側のカスタマイズで、Terraformコードと実際のリソースに乖離が発⽣することがある • 差分があるときに、リソースを元に戻すか、リソースに合わせてコードを変更するか、連携したい 差分を検知して知らせてくれる機能がなかった • PRが作成されて、Terraform Enterprise上でRun(plan)が実⾏されるまで気付くことができない Terraform管理リソースのDrift Detection 16 -
2022.08.25 HashiTalks Private subnet Drift Detectionのシステム構成 17 Amazon ECS Recruit
Product AWS Accounts GitHub Enterprise (Terraform Code) JSON API Notification to Slack SENTO Team AWS Step Functions Amazon EventBridge Workspace⼀覧を取得 各WorkspaceでSpeculative Planを作成 Plan結果をチェック 差分を検知、またはplanが異常終了したら通知 SENTO AWS Account SENTO VPC planを多数実⾏する=実⾏時間が15分を超えると想定 実⾏には Lambda ではなく ECS+Fargate を利⽤ Step FunctionsからECSタスクを起動することで、エラー時にリトライ EventBridgeで定期的にステートマシンを実⾏して差分を⾃動検知 -
2022.08.25 HashiTalks 全WorkspaceにDiscardをかけたいユースケース • planでは問題なさそうに⾒えるがapplyでコケるケースなど • 最近では、AWS Provider v4.0のS3のBreaking changesが原因で発⽣
• 100を超えるWorkspace数のため、Applyがコケた場合のリカバリの負担が⼤きい • 本番環境でapply承認待ちのRunはすべて⼿動でDiscardしていた 全WorkspaceにRe-Runをかけたいユースケース • 他のリソースの作成タイミングと近すぎる場合や、depends_onが意図通りにならない場合 など、applyでエラーになった後にRe-Runすると解消するケース • state import後の正常性確認として、Re-Runでplanを実⾏して差分がないことを確認 したい、というケース ⼀⻫Re-Run、⼀⻫Discard 20 -
2022.08.25 HashiTalks ⼀⻫Re-Run、⼀⻫Discardのシステム構成 21 SENTO AWS Account SENTO VPC Private
subnet Recruit Product AWS Accounts JSON API SENTO Team 各WorkspaceのCurrent runのステータスをチェックしてRun APIを実⾏ [⼀⻫Discard] planned状態であればdiscardを実⾏ [⼀⻫Re-Run] statusがfinal stateに該当する場合は新たなRunを作成 ⼀⻫Discard、⼀⻫Re-Runの実⾏にはLambdaを選択 Drift Detectionと異なりplan結果の確認が不要で 短時間で処理が完了する LambdaはJenkinsからAWS CLIでinvokeする Lambda function ⾃動化ツールのひとつとしてJenkinsを利⽤している ⼀⻫Discard、⼀⻫Re-Runのジョブを追加した 必要になったときにジョブを実⾏する invoke GitHub Enterprise (Terraform Code) -
2022.08.25 HashiTalks Drift Detectionでプロダクトチームによるリソース変更を素早く検知できるように • moduleに機能を追加しようとして想定外のplan差分が出て混乱する、といったトラブルを 予防できるようになった • プロダクト側が検証等で⼀時的な設定変更をして元に戻すのを忘れた場合や、好ましくな い状態に変更された場合も、⾃動検知できるようになった
⼀⻫Re-Run、⼀⻫Discardの仕組みで業務負担が軽減した • 100超のWorkspaceに対して1つずつ Re-Run / Discard をする必要がなくなった 定期的に⾃動実⾏したい操作がある、業務フロー上⼿動操作が多く負担、 といった課題をお持ちの場合は、ぜひJSON APIを利⽤して⾃動化を検討 してみましょう︕ 運⽤⾃動化によって 23