Vue d'ensemble Cloud Native¶
KanjiIQ est conçu selon les principes cloud-native, le rendant portable sur n'importe quelle plateforme conforme Kubernetes. L'application utilise les API Kubernetes standard sans extensions propriétaires de fournisseur cloud.
Alignement avec l'application 12 facteurs¶
| Facteur | Implémentation KanjiIQ |
|---|---|
| I. Base de code | Dépôt Git unique (Forgejo) suivi avec le contrôle de version |
| II. Dépendances | Explicitement déclarées dans pubspec.yaml (Dart) et requirements-docs.txt (Python) |
| III. Configuration | Variables d'environnement injectées via les Kubernetes Secrets et ConfigMaps |
| IV. Services externes | PostgreSQL accessible via DATABASE_URL — interchangeable sans modification du code |
| V. Build, Release, Run | Builds Docker multi-étapes vers images taggées vers rolling updates Kubernetes |
| VI. Processus | Conteneurs applicatifs sans état ; l'état réside dans PostgreSQL |
| VII. Liaison de port | Services autonomes : frontend sur :80, backend sur :8080 |
| VIII. Concurrence | Mise à l'échelle horizontale via les réplicas Kubernetes |
| IX. Jetabilité | Démarrage rapide, arrêt gracieux, sondes de santé |
| X. Parité dev/prod | Le namespace staging reproduit les manifestes de production |
| XI. Logs | Stdout/stderr (Kubernetes capture vers le système de fichiers du noeud) |
| XII. Processus d'administration | Les migrations de base de données s'exécutent comme des commandes ponctuelles |
Qu'est-ce qui rend KanjiIQ Cloud Native ?¶
API Kubernetes standard uniquement¶
Toutes les ressources utilisent les groupes d'API standard apps/v1, v1 et networking.k8s.io/v1 :
Deployment(pas de services managés spécifiques au cloud)Service(ClusterIP — fonctionne partout)Ingress(API réseau standard)PersistentVolumeClaim(requête de stockage indépendante du cloud)Secret(gestion de configuration standard)
Les seuls CRD non standard sont les Middlewares Traefik — qui peuvent être remplacés par des fonctionnalités équivalentes de contrôleur d'ingress sur n'importe quelle plateforme.
Tout est conteneurisé¶
Chaque composant dispose d'un Dockerfile prêt pour la production :
| Composant | Dockerfile | Image de base |
|---|---|---|
| Frontend | Dockerfile.frontend |
nginx:alpine |
| Backend | Dockerfile.backend |
dart:stable |
| Documentation | Dockerfile.docs |
nginx:alpine |
Toutes les images :
- Utilisent des builds multi-étapes (images de production légères)
- S'exécutent en tant que non-root (UID 1000)
- Incluent des vérifications de santé
- Sont poussées vers un registre de conteneurs (portable vers n'importe quel registre)
Infrastructure as Code¶
100 % de l'infrastructure est définie en YAML versionné :
k8s/
├── 00-namespace.yaml
├── 01-secrets.yaml (template)
├── 02-postgres-pvc.yaml
├── 03-postgres-deployment.yaml
├── 05-deployment.yaml
├── 06-service.yaml
├── 07-ingress.yaml
├── 08-security-middlewares.yaml
└── ...
Recréer l'environnement entier depuis zéro ne nécessite que :
Évaluation de la portabilité¶
| Composant | Portabilité | Notes |
|---|---|---|
| Deployments applicatifs | Entièrement portable | Manifestes k8s standard |
| Services | Entièrement portable | ClusterIP fonctionne partout |
| Ingress | Principalement portable | Peut nécessiter un changement de classe d'ingress |
| PVC | Entièrement portable | Les fournisseurs cloud provisionnent automatiquement le stockage |
| Secrets | Entièrement portable | Même API sur tous les clouds |
| Middlewares Traefik | Nécessite une adaptation | Remplacer par des alternatives cloud-native |
| Images de conteneurs | Entièrement portable | Push vers n'importe quel registre OCI |
| CI/CD | Nécessite une adaptation | Forgejo Actions vers GitHub Actions / Cloud Build |
Voir Portabilité pour les guides de migration détaillés vers AWS et GCP.