デプロイメント概要¶
KanjiIQは、mainへのプッシュごとにDockerイメージをビルドし、Forgejo Container Registryにプッシュし、k3sクラスターにデプロイする、完全に自動化されたCI/CDパイプラインを使用しています。
パイプラインフロー¶
graph LR
A[git push main] --> B[Forgejo Actions<br/>Triggered]
B --> C[Docker Build<br/>Multi-stage]
C --> D[Push to Registry<br/><registry>]
D --> E[kubectl set image<br/>Rolling update]
E --> F[Rollout Status<br/>Health check]パスベースのトリガー¶
各コンポーネントには、関連ファイルが変更された場合にのみトリガーされる独自のワークフローがあります：
| ワークフロー | トリガーパス | イメージ |
|---|---|---|
deploy-frontend.yml |
frontend/**, Dockerfile.frontend, nginx.frontend.conf |
jlpt-kanji-frontend |
deploy-backend.yml |
backend/**, Dockerfile.backend |
jlpt-kanji-backend |
deploy-docs.yml |
docs/**, mkdocs.yml, Dockerfile.docs |
jlpt-kanji-docs |
これにより、ドキュメントページの変更がフロントエンドやバックエンドの再ビルドをトリガーすることはありません。
デプロイメント戦略¶
KanjiIQはKubernetesのローリングアップデートを使用しています：
- 更新されたイメージで新しいPodが作成されます
- 古いPodが終了する前にreadinessプローブが通過する必要があります
- 新しいバージョンがヘルスチェックに失敗した場合、ロールアウトは自動的に停止されます
- 2レプリカによるゼロダウンタイムデプロイメント
環境¶
| 環境 | 用途 | URL |
|---|---|---|
| 本番 | ライブアプリケーション | kanjiiq.com |
| ステージング | リリース前テスト | ローカルk8s namespace |
| 開発 | ローカル開発 | localhost:8080 / localhost:3000 |
ステージング環境は、独自のPostgreSQLインスタンスを持つ別のKubernetes namespace（jlpt-kanji-staging）で本番マニフェストをミラーリングしています。
イメージタグ付け¶
すべてのビルドで2つのタグが生成されます：
:latest— 常に最新のビルドを指す:COMMIT_SHA— トレーサビリティのための不変タグ
デプロイメントは決定論的なロールアウトを保証するためにコミットSHAタグを使用します：