Tweet
Tweet

Slide 1

Slide 1 text

Terraform CI/CD パイプライン AWS CodeCommit 代替手段

Slide 2

Slide 2 text

自己紹介 名前 / 檜山 準（ひやんが） 職種 / AWS エンジニア（SIer 所属） 出身 / 栃木県 趣味 / ギター 🎸 @hiyanger

Slide 3

Slide 3 text

話す内容 1. 旧 Terraform CI/CD パイプライン 2. CodeCommit の代替手段検討 2-1. Amazon CodeCatalyst / 概要から動作まで 2-2. GitLab（EC2） / 概要から動作まで ちょっと AWS よりの内容です

Slide 4

Slide 4 text

旧！ Terraform CI/CD パイプライン

Slide 5

Slide 5 text

ときは 2024 年 3 月 Zenn でこんな本を書きました

Slide 6

Slide 6 text

こんなものがつくれます 「AWS CodeCommit」を起点に develop ブランチ：開発環境へ plan / apply main ブランチ：商用環境へ plan / apply

Slide 7

Slide 7 text

…CodeCommit ? 🤔 「AWS CodeCommit」を起点に develop ブランチ：開発環境へ plan / apply main ブランチ：商用環境へ plan / apply

Slide 8

Slide 8 text

…CodeCommit ? 🤔

Slide 9

Slide 9 text

2024 年 7 月某日 （本の作成から約 4ヶ月後...）

Slide 10

Slide 10 text

2024/7 「今後作成される」AWSアカウントで CodeCommit が使えなくなりました 😢

Slide 11

Slide 11 text

というわけで... CodeCommit の 代替手段検討

Slide 12

Slide 12 text

前提 そもそもなんで GitHub じゃなくて、 CodeCommit を使ってたの？ システムを AWS 内で 完結させたいからなのだ！ （データを一歩も外に出したくない!!）

Slide 13

Slide 13 text

AWSさま「CodeCommit の代わりに、Amazon CodeCatalyst、GitLab、GitHub、ま たはお好みのサードパーティソースプロバイダーの使用を検討してください🙏」

Slide 14

Slide 14 text

先に（自分的）結論 　　　① まずは CodeCatalyst を検討！ 　　　② ダメなら GitLab（AWS 環境内に構築）！

Slide 15

Slide 15 text

CodeCatalyst

Slide 16

Slide 16 text

CodeCatalyst ・利用は通常 AWS アカウントからではなく、ビルダー ID から AWS アカウントに繋ぎ混んで使う ・Workflows という GitHub Actions 的なものがあり、 　AWS 側は IAM ロールだけ作れば terraform plan や apply が流せる（CodePipeline がいらない🔥） AWS 版 GitHub みたいな感じ😽 許容が必要なポイント ※前提：もともと CodeCommit を使っていた理由はシステムを AWS 内に閉じさせたいから （通常 GitHub 利用ができない案件） ・ビルダーID → AWS アカウント という通信経路が発生する ・リージョンがオレゴンとアイルランドしかない（デプロイ自体はどこにでもできる） ・権限まわり（IAM と連動した CodeCommit レベルまでできるのか）

Slide 17

Slide 17 text

料金 小規模であれば 意識しなくてよさそう!!

Slide 18

Slide 18 text

実際に terraform plan / apply してみる！

Slide 19

Slide 19 text

Workflows pull request terraform plan merge main ブランチ terraform apply

Slide 20

Slide 20 text

動作する Workflow は2本

Slide 21

Slide 21 text

コードを push / pull request !!

Slide 22

Slide 22 text

Workflows の コード 参考↓

Slide 23

Slide 23 text

plan / apply が Run 成功!!

Slide 24

Slide 24 text

GitLab（EC2）

Slide 25

Slide 25 text

GitLab（EC2） ・EC2 上に構築するのでコードが AWS 上に配置できる（ ≒ CodeCommit） ・正しい https 通信が必要なため、証明書の設定も必要 ・CodePipeline で使う過程で AWS のデベロッパーツールの接続が必要 ・GitLab 構築、証明書、接続、CodePipeline など CodeCatalyst に 　比べると作業ボリュームは大きい ・EC2 がデフォルトのインスタンスサイズとディスクでは動かない 　多少の上乗せが必要 = コスト要考慮 許容が必要なポイント 概要

Slide 26

Slide 26 text

実際に terraform plan / apply してみる！

Slide 27

Slide 27 text

動作の流れ plan apply merge

Slide 28

Slide 28 text

接続設定はこんな感じ！

Slide 29

Slide 29 text

CodePipeline のソースステージ

Slide 30

Slide 30 text

CodePipelineでの terraform plan / apply

Slide 31

Slide 31 text

※ 非 VPC 経由における GitLab と CodePipeline 間の通信 接続には別 VPC を経由する方法としない方法がある ↓ 経由しない方法で GitLab 側の通信を自分の IP からの https （git push だけできる）のみに絞る ↓ CodePipeline 側でソースステージの動作がエラーになった （フローログには CodePipeline からのアクセスが記録されてた コード変更検知まではできたのでおしい！） ↓ 非 VPC だと内部通信だけで完結きる？🤔 非 VPC 経由の接続では GitLab と CodePipeline で AWS 外の通信がされるもよう🤤

Slide 32

Slide 32 text

さいごにもういっかい！（自分的）結論 　　　① まずは CodeCatalyst を検討！ 　　　② ダメなら GitLab（AWS 環境内に構築）！

Slide 33

Slide 33 text

参考（神たちへの感謝 🙏）

Slide 34

Slide 34 text

おわり ありがとうございました！ ※ 構築の詳細は私の Zenn Scrap にて