Deployment-Übersicht¶
KanjiIQ verwendet eine vollständig automatisierte CI/CD-Pipeline, die Docker-Images erstellt, sie in die Forgejo Container Registry hochlädt und bei jedem Push auf main im k3s-Cluster bereitstellt.
Pipeline-Ablauf¶
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]Pfadbasierte Auslösung¶
Jede Komponente hat ihren eigenen Workflow, der nur ausgelöst wird, wenn relevante Dateien sich ändern:
| Workflow | Auslöserpfade | Image |
|---|---|---|
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 |
Das bedeutet, dass eine Änderung an einer Dokumentationsseite keinen Frontend- oder Backend-Neuaufbau auslöst.
Deployment-Strategie¶
KanjiIQ verwendet Kubernetes Rolling Updates:
- Neue Pods werden mit dem aktualisierten Image erstellt
- Readiness-Probes müssen bestanden werden, bevor alte Pods beendet werden
- Wenn die neue Version die Gesundheitsprüfungen nicht besteht, wird das Rollout automatisch gestoppt
- Null-Ausfallzeit-Deployments mit 2 Replikaten
Umgebungen¶
| Umgebung | Zweck | URL |
|---|---|---|
| Produktion | Live-Anwendung | kanjiiq.com |
| Staging | Vorab-Tests | Lokaler k8s-Namespace |
| Entwicklung | Lokale Entwicklung | localhost:8080 / localhost:3000 |
Die Staging-Umgebung spiegelt die Produktionsmanifeste in einem separaten Kubernetes-Namespace (jlpt-kanji-staging) mit eigener PostgreSQL-Instanz wider.
Image-Tagging¶
Jeder Build erzeugt zwei Tags:
:latest— Zeigt immer auf den neuesten Build:COMMIT_SHA— Unveränderlicher Tag für Nachverfolgbarkeit
Deployments verwenden den Commit-SHA-Tag, um deterministische Rollouts zu gewährleisten: