release-please で実現する手軽で不変な Docker イメージタグ付け方法

おもにクラウドの話してます - 広島 #2 の発表資料です。
https://omoni-cloud.connpass.com/event/320415/

1. release-please で実現する ⼿軽で不変な Docker イメージタグ付け⽅法 chanyou
2. Yu Nakamura - chanyou ‧ DRE ← Data Engineer ← SWE ‧ X: @chanyou0311 ‧ Google Cloud ‧ Azure
3. 突然ですが、 コンテナ使ってますか？🙋
4. プライベートなアプリケーション開発における コンテナ構築⽅法
5. クラウドにおけるコンテナ技術
6. 実⾏環境としてのコンテナ ‧Kubernetes でアプリケーションを容易にデプロイできる ‧コンテナ化されたアプリケーションの実⾏環境の整備 ‧AWS ECS ‧Azure App Service ‧GCP Cloud Run
7. 開発体験の良さ ‧ローカル環境と本番環境の差が⼩さい ‧FaaS だとローカルで動作環境⽤意するのが結構⼤変 ‧CI/CD の構築‧運⽤コストが低い ‧CI/CD パイプラインの再利⽤がしやすい
8. なぜ本番環境でコンテナを採⽤するのだろうか
9. Immutable Infrastructure の実現 ‧デプロイしやすい ‧スケールしやすい ‧ロールバックしやすい
10. コンテナ使えば Immutable Infrastructure を すぐに実現できる？
11. 🙅
12. Immutable な Image が必要
13. Google Cloud のベストプラクティスを参考に https://cloud.google.com/architecture/best-practices-for-building-containers
14. https://cloud.google.com/architecture/best-practices-for-building-containers Google Cloud のベストプラクティスを参考に
15. セマンティック バージョニングを使⽤したタグ付け https://cloud.google.com/architecture/best-practices-for-building-containers
16. Git commit ハッシュを使⽤したタグ付け https://cloud.google.com/architecture/best-practices-for-building-containers
17. イメージのタグ付け難しい… ‧SemVer 😊 利便性は⾼い 😢 ⾃らバージョン番号管理するのは⼤変 ‧Git commit hash 😊 タグ付け⾃体は⾃動化すれば簡単 😢 ⼀つ前のバージョン…ってどれ？
18. いいとこ取りはできないだろうか 🤔
19. release-please
20. release-please > Rease Please automates CHANGELOG generation, the creation of GitHub releases, and version bumps for your projects. ⾃動でリポジトリを SemVer 管理してくれるツール ‧CHANGELOG の更新 ‧GitHub リリースの作成 ‧任意の JSON や YAML ファイルの更新 https://github.com/googleapis/release-please
21. 利⽤⽅法 ‧GitHub Actions (推奨) ‧CLI (npm) ‧GitHub App
22. どうやってバージョン管理しているのか Conventional Commits に従ってコミットメッセージを記述しておく https://github.com/googleapis/release-please
23. どうやっているのか release-please はコミットログのパースを⾏うことで次のバージョン番号 を導き出している v1.0.1 のとき fix: typo → v1.0.2 feat: いいね機能の追加 → v1.1.0
24. GitHub Actions での例
25. ⽤意するもの (GitHub Actions) workflow: .github/workflows/release-please.yaml `uses: googleapis/release-please-action@v4` を呼び出す config: release-please-config.json モノレポの場合、各サービスの設定を定義する manifest: .release-please-manifest.json モノレポの場合、各サービスのバージョンを記録する 例) {"frontend":"1.7.0","backend":"2.0.2"}
26. バージョンが更新されるまでの流れ 1. (開発者) Conventional Commits message で commit して push する 2. (GitHub Actions) release-please (draft-mode) が実⾏されて PR が作成される 3. (開発者) PR をマージする 4. (GitHub Actions) release-please (deploy-mode) が実⾏される ◦ CHANGELOG の更新 ◦ GitHub リリースの作成 ◦ GitHub Actions で任意の処理の実⾏ ▪ ここで Docker Image の build と push を⾏う
27. デモ
28. これから個⼈ブログをリリースします
29. Docker Image のアーキテクチャ
30. インフラアーキテクチャ
31. ディレクトリ構成 .github/workflows/release-please.yaml release-please-config.json .release-please-manifest.json app/Dockerfile app/CHANGELOG.md helm/CHANGELOG.md
32. Docker Image の push までの流れ
33. まとめ
34. まとめ ‧release-please で⼿軽に SemVer を導⼊できた ‧⼿軽で不変な Docker Image の構築ができるようになった ‧Immutable Infrastructure への扉が開かれた…！ ‧コミットメッセージの記法に制約がかかる ‧チーム開発に適⽤できるかは要議論 ‧⽣成AIによるメッセージの補完に期待