Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
Ähnlich wie CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (7)
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
- 1. 1 CircleCIのinfrastructureを支える TerraformのCI/CDパイプラインの改 善 CircleCI合同会社 Takayuki Ito Senior Software Engineer HashiTalks: Japan 2022 (2022/08/25)
- 2. 2 自己紹介 伊藤貴之 （Takayuki Ito） @ganezasan Infrastructure team 所属 CircleCIでの経歴 https://peaks.cc/testing_with_jest Support Engineer Software Engineer Senior Support Engineer Senior Software Engineer
- 4. 4 CircleCIの構成 上記はCircleCI Server v4.x Architectureなので Cloud版のアーキテクチャとは若干異なります AWSやGCP など 大体のイメージで緑の部分の領域の infrastructureを インフラチームで管理している オレンジは 別チームが 担当
- 5. 5 infrastructure repository - Terraformを利用してAWSやRabbitmq, k8sのhelmチャートなどを管理 - 2022年8月24日時点では40以上のパーティションが含まれる - AWSアカウント、サービスでパーティションを分割 - 他のチームからもPullRequestをもらいレビューすることも多い - １日に何度もデプロイすることがある（利用頻度は高い） - モノレポの構成ですが全体ビルド&デプロイを行っていた - Pipeline全体の実行時間が平均で約11分（早いものだと１つのジョブは1,2分程度 で終了する）
- 6. 6 infrastructure repositoryのCIにおける課題 - すべてのパーティションを実行するためワークフローの実行時間が長い - terraform planでは失敗しないがterraform apply時に見つかる問題は結構あり、試行 錯誤する場合にビルド時間が長いのが不満だった。 - 何がデプロイされたのかパット見わからない - 一部のパーティションが肥大化している 差分ビルドを提案 （変更があったパーティションのビルドを行う）
- 7. 7 だが、思ったよりもメンバーの反応が悪かった - 今のワークフローで安定して動作している（大きな変更を入れるのは怖い） - 2.1の機能があまり利用されていなかった - CircleCIのコアな部分を管理しているプロジェクトのためデプロイできない状態には したくない 少しずつ改善することに! リファクタリング (古いのをきれいに) Drift Detection （terraform state と AWSの差分の検知） 差分ビルド (gitの差分の検知)
- 8. 8 CircleCIコンフィグのリファクタリング - YAMLのエイリアスとアンカーを利用 - 2.1の機能であるcommandを利用し共通化 - キャッシュの有効化 - ジョブの適切な分割 - parallelismを使って並列ジョブを作成した場合に、冗 長な処理が生まれる場合がある 1 1 1 1 4 3 2 1 1 5 Test and Validate job, parallelism:5 Validate job, parallelism:5 1 2 3 4 5 1 Test job
- 9. 9 Drift Detectionの導入 - Driftとは「頭文字D」に出てくるようなの車の運転方法のドリフトではなく「漂流 物」です。Drift Detectionのイメージとしては海上の船で海で漂流している氷山 などの漂流物を検知することです。 - TerraformでのDriftはterraform state と実リソースの差分を検知する - AWS Consoleからの直接のリソースの変更 - 既存のterraformが未適用 - 前回の適用が失敗 - 全体ビルドはDrift Detectionの機能を兼ねている Drift Detectionは最近Terraform Cloudでも導入されました 🎉 https://www.hashicorp.com/blog/terraform-cloud-adds-drift-detection-for-infrastructure-manag ement
- 10. 10 Approvalジョブにてインフラメ ンバーが変更内容を確認して からapplyする Drift Detectionの流れ terraform plan terraform plan terraform plan terraform plan terraform plan terraform plan すべてのパーティションで terraform planを実行 planの結果を集約し Continue APIで新しい workflow(s)を生成 Continue API Slack notify hold terraform apply Slack notify hold terraform apply Partition 1 Partition 2 💡差分を検知💡 (Dynamic Configuration) ⚡Scheduled pipelineにて2時間おきに起動
- 11. 11 Drift Detectionで考慮したこと 古いワークフローでapplyできないようにする Personal Tokenをなるべく利用しない terraform planが前回と異なる場合に適用し ない apply前に前回のterraform planを実行した 時刻をチェック Dynamic workflow(Continue API)を利用 apply前に前回のterraform planのハッシュ 値を比較
- 12. 12 Drift Detectionを導入した効果 - 反映漏れを以前よりも早く見つけることができるように - マニュアル操作で変更されたリソースをいち早く検知できるように - 以前だと放置されることが多く、時間が経って別のPullRequestをマージす る際などで問題が発見されていた - Terraform state lockの失敗が増えてきた - 全体としてはCIがよくなっている感が出てきた 差分ビルドを導入することに
- 13. 13 - 差分ビルドをお手軽に利用できる path-filtering orb - パラメーターが1つしか渡すことができていないのと pipeline parameterでpartitionの指定がある場合は pipeline parameterを優先したい要件があった - シェルスクリプトを作成 - 差分の取得はpath-filteringと同様の方法 - main branch以外の場合: git diff で main と現在のブランチのHEADを比較 - main branchの場合: git diff で git rev-parse HEAD~1 でマージされる前のコミットと mainブランチのHEADを比較 - 注意点 - Githubのマージ方法として「 rebase merge」は利用できない。rebase mergeは複数のコ ミットがある場合、コミットが個別に mainに追加するため1つ前のコミットが以前の mainの HEADではない - mainへの直接pushもbranch protectionで禁止する必要がある 差分の取得方法
- 14. 14 差分を検出し変更のあった パーティションを特定 特定のパーティションに 対応したジョブのみ起動 Partition 1 Partition 2 Partition 3 Partition 4 Partition 5 差分あり 差分あり cci/partition_2 cci/partition_5 find-partition test-and-deploy find-partition Continue API { "ci_partition_1": "cci/partition_2", "ci_partition_2": "cci/partition_5" } Pipeline parameterに応じて動的 にワークフローのジョブを制御 Pipeline parameterに応じて動的にワークフローのジョブを制御
- 15. 15 matrix job + filtersの組み合わせで Pipeline parametersでjobを設定 - pipeline parameterが含まれる場合は pipeline parameterの値から始まるブラ ンチ名が除外され（基本的には存在しな い）、pipeline parameterがない場合 は、すべてのブランチが除外される（つ まり実行されない） - matrixの exclude オプションはpipeline parameterに対応していない（対応要望 中） parameters: ci_partition_1: &ci_partition type: string default: '' ... 繰り返し ci_partition_42: *ci_partition workflows: test-and-deploy: jobs: - terraform: name: "terraform-<<matrix.partition>>" matrix: parameters: partition: - << pipeline.parameters.ci_partition_1 >> - << pipeline.parameters.ci_partition_2 >> - << pipeline.parameters.ci_partition_3 >> ... 繰り返し - << pipeline.parameters.ci_partition_42 >> filters: branches: ignore: /<< matrix.partition >>.*/
- 17. 17 - 差分ビルドは魅力的だがいきなりは導入できない - Drift Detectionが必要 - 差分ビルドによってCIワークフローで何がデプロイされてたのか見える化できた - Drift Detectionを導入した結果単純にビルド数が増え、開発中やデプロイ時に terraform state lockに失敗する問題が多々発生している まとめ
- 18. 18 - terraform state lockの取得の失敗の回避 - 一部のパーティションにリソースが集中している - Terraform moduleを対象にした tflint の実行 - tfmigrate のCI上での実行 おまけ: 今後の課題
- 19. Thank you. 19
- 20. 20 - 1つのpipelineでCIRCLE_CONTINUATION_KEYは基本的に1度しか利用できな い - Continue APIで作成されるworkflowは呼び出し元と同じpipeline上に作成され る。そのためコンフィグを分割した場合に、呼び出し元と同じpipeline parameterを受け取る必要がある - CIRCLE_CONTINUATION_KEYはすべてのsetupジョブ上から利用できる Continue APIの制限 setup workflowを有効化すると自動でCIRCLE_CONTINUATION_KEYがジョブの環境変数に登録される。