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

3. 3
CircleCIとは？
https://circleci.com/
最近GitLab
連携しました
🎉🎉🎉

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 >>.*/

16. 16
ワークフローの実行時間が約10分から5分以下へ

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がジョブの環境変数に登録される。