Descripción general del despliegue¶
KanjiIQ utiliza un pipeline de CI/CD completamente automatizado que compila imágenes Docker, las publica en el Forgejo Container Registry y las despliega en el clúster k3s con cada push a main.
Flujo del pipeline¶
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]Activación basada en rutas¶
Cada componente tiene su propio flujo de trabajo, que se activa solo cuando cambian los archivos relevantes:
| Flujo de trabajo | Rutas de activación | Imagen |
|---|---|---|
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 |
Esto significa que cambiar una página de documentación no activa una recompilación del frontend o backend.
Estrategia de despliegue¶
KanjiIQ usa rolling updates de Kubernetes:
- Se crean nuevos pods con la imagen actualizada
- Las sondas de readiness deben pasar antes de terminar los pods anteriores
- Si la nueva versión falla los health checks, el despliegue se detiene automáticamente
- Despliegues sin tiempo de inactividad con 2 réplicas
Entornos¶
| Entorno | Propósito | URL |
|---|---|---|
| Producción | Aplicación en vivo | kanjiiq.com |
| Staging | Pruebas de pre-lanzamiento | Namespace local de k8s |
| Desarrollo | Desarrollo local | localhost:8080 / localhost:3000 |
El entorno de staging refleja los manifiestos de producción en un namespace de Kubernetes separado (jlpt-kanji-staging) con su propia instancia de PostgreSQL.
Etiquetado de imágenes¶
Cada compilación produce dos etiquetas:
:latest— Siempre apunta a la compilación más reciente:COMMIT_SHA— Etiqueta inmutable para trazabilidad
Los despliegues usan la etiqueta de commit SHA para garantizar despliegues determinísticos: