Infra

GitLab CI → Kubernetes via AdmanTIC/Rancher. Déploiement déclenché par branche ou par tag selon l'environnement.

Docker compose local

Le docker-compose.yml racine agrège les trois submodules
A1Connect nécessite docker-compose -p a1connect up -d (project name explicite pour éviter les conflits de réseau)
Sous Linux : ajouter extra_hosts: ["host.docker.internal:host-gateway"] dans les containers qui accèdent à RabbitMQ depuis un autre network
Problème connu A1Connect : si l'API (port 3000) ne répond pas → docker stop/start a1connect-api

Fichiers .env.example à copier dans chaque submodule (voir CLAUDE.md pour les chemins)
Inspire-v2 a deux .env : api/docker/.env et front/docker/.env
Les ports Docker sont configurables via .env pour A1Connect (éviter les conflits si plusieurs projets tournent)

staging branch push → environnement staging (A1Connect, Dema1n, Inspire-v2)
Tag git sur prod (numéro de version semver) → déploiement production (A1Connect, Dema1n, Inspire-v2)
Voir git-workflow.md pour le processus complet de MEP (MR main → prod, tag, release)

Fichier source : article1-connect/rabbitmq-defs.json (chargé en local seulement via load_definitions sur a1connect-rabbitmq)
Le RabbitMQ staging/prod est un cluster K8s séparé : un déploiement applicatif (A1Connect, Dema1n, Inspire) ne crée ni ne met à jour les bindings
Toute MR qui touche aux defs doit prévoir une application manuelle (UI Management ou import) sur staging puis prod à la MEP
Procédure complète : rabbitmq-definitions.md

Concepts

App = deployment + service + ingress dans Rancher UI
Déploiement = spec K8s (image, replicas) => Déduites des Apps
Pod = instance runtime -> corrrespond à un container dans 99% des cas
Secret = valeurs sensibles
ConfigMap = config non sensible -> en pratique on mélange un peu avec Secrets
Helm = On n'écrit pas de la config K8, on écrit de la config Helm qui passe par une moulinette (Helm Chart) qui transforme notr yaml en config K8

Ce qu'on peut faire

Vérifier si une app est up/down (Workloads > Pods, ou directement depuis Workloads > Déploiements > Health ou Apps > Installed Apps > Resources)
Consulter les logs (Workloads > pods > ... > Voir les Logs)
Modifier config/env (ConfigMap, Secret)
Modifier/Créer App

Pièges

Déploiements déclenchés uniquement depuis GitLab (jamais depuis Rancher)
Tout changement de config/secret/configmap/env depuis Rancher redéploie le pod
⚠️️️️️️⚠️️️️️️⚠️️️️️️ En prod, GitLab ne met pas à jour le tag d'image dans la config Rancher : avant de modifier une config, vérifier qu'elle référence bien le dernier tag, sinon le redéploiement auto va relancer une ancienne image
⚠️️️️️️ on ne touche que config d'app + Secrets/ConfigMaps, jamais les Déploiements ni les autres ressources K8s qui sont générées à partir des config des apps