coog-helm-charts

⚠️ : A new version has been introduced, starting with version 23.45.2345. This new version is incompatible with configurations of versions lower than 2345. ⚠️

• Un compte sur DockerHub
• Cluster Kubernetes en version 1.21+
• Installer helm 3.10+
• Installer Nginx Ingress Controller
• Configurer des volumes persistants pour la persistence des données - Indispensable en production

PostgreSQL est installé par defaut pour cette partie

La valeur mongodb.isManaged doit être à true pour installer MongoDB par le chart, laisser à false si vous avez un serveur MongoDB externe.

La valeur mongodb.isManaged doit être à true pour installer MongoDB par le chart, laisser à false si vous avez un serveur MongoDB externe.

Dans votre fichier de configuration des valeurs (exemple : client_values.yml) :

imageCredentials:
  registry: docker.io
  username: user-1234
  password: password-1234
  email: my-email@my-company.com

helm repo add coopengo https://gitlab.com/api/v4/projects/35933718/packages/helm/stable
helm upgrade -i coog coopengo/coog --namespace=coog-client -f client_values.yml

Dans votre fichier de configuration des valeurs (exemple : client_values.yml) :

Les EFS doivent être crée manuellement à l'avance.

Volume principal pour coog:

backCore:
  persistentVolume:
    enabled: true
    storageClass: "efs-sc"
    size: 10Gi
    customPersistentVolume:
      mountOptions:
        - "tls"
      persistentVolumeReclaimPolicy: "Retain"
      csi:
        driver: "efs.csi.aws.com"
        volumeHandle: "fs-123456789"

Si composants Front activés :

mongodb:
  persistence:
    storageClass: "efs-sc"
    size: 10Gi
    customPersistentVolume:
      mountOptions:
        - "tls"
      persistentVolumeReclaimPolicy: "Retain"
      csi:
        driver: "efs.csi.aws.com"
        volumeHandle: "fs-987654321"

Le chart supporte deux modes de déploiement RabbitMQ via le toggle rabbitmq.mode :

Le mode operator cible un RabbitmqCluster déployé hors-bande et accessible via DNS interne <cluster>.<namespace>.svc.cluster.local.

• Un RabbitmqCluster opérationnel sur le cluster (Cluster Operator + Topology Operator + CRDs rabbitmq.com installés).
• L'annotation rabbitmq.com/topology-allowed-namespaces posée sur le RabbitmqCluster CR (pas sur le namespace) avec une valeur incluant le namespace tenant ou *. Le Topology Operator ne lit cette annotation que sur le CR.
• Le namespace tenant a Istio activé en mode compatible (STRICT ou PERMISSIVE) si le namespace du cluster RabbitMQ enforce mTLS — sinon l'auth AMQP côté broker rejette les pods tenant.

rabbitmq:
  mode: operator
  isManaged: false        # OBLIGATOIRE en mode operator (désactive le subchart Bitnami)
  operator:
    cluster:
      name: rabbitmq-production       # défaut
      namespace: rabbitmq-system      # défaut
    vhost: "<nom-du-vhost>"           # nom du vhost à créer sur le cluster
    user:
      tags:
        - management
    permissions:
      configure: ".*"
      write: ".*"
      read: ".*"
  auth:
    username: "<user-tenant>"
    password: "<password-random>"

Le password est posé dans un Secret K8s <release>-rabbitmq-credentials du namespace tenant et importé par le User CRD via importCredentialsSecret — le Topology Operator l'applique au user créé sur rabbitmq-production.

1. Côté values : ajouter mode: operator, isManaged: false, et operator.vhost: "<même-valeur-que-rabbitmq.vhost>".

Pendant ~10-30s entre la création des CRDs et leur réconciliation par le Topology Operator, les pods qui rolling-restart peuvent voir des ACCESS_REFUSED transitoires. Les clients AMQP retentent automatiquement.

• rabbitmq.vhost legacy ignoré en mode operator : le helper coog.rabbitmq.vhost n'utilise que rabbitmq.operator.vhost en mode operator. Si tu mets rabbitmq.vhost: "foo" mais oublies rabbitmq.operator.vhost, le chart utilise le défaut /<release-name> au lieu de foo — vhost créé sous un nom inattendu, queues à recréer côté apps.
• isManaged: true + mode: operator : combinaison invalide. Un guard fail-fast dans _helpers.tpl rejette le rendu — corriger en passant isManaged: false.
• Annotation topology-allowed-namespaces mal posée : si elle est uniquement sur le namespace rabbitmq-system (ancien comportement) au lieu du RabbitmqCluster CR, les CRDs Topology restent en Ready: False avec resource is not allowed to reference defined cluster reference.
• rabbitmq.auth.password est bootstrap-only — helm upgrade ne rotate PAS le password : voir la section ci-dessous.

Le Topology Operator lit spec.importCredentialsSecret du User CRD uniquement à la création initiale, c'est-à-dire tant que status.credentials.name est vide. Une fois ce statut renseigné (premier reconcile), le Secret auto-généré <user-cr>-user-credentials devient la source de vérité et le Secret d'entrée que rend le chart (<release>-rabbitmq-credentials) n'est plus jamais relu.

Conséquence : modifier rabbitmq.auth.password dans les values puis helm upgrade met bien à jour le Secret d'entrée côté Kubernetes, mais n'a aucun effet côté broker ni sur le Secret de sortie consommé par les apps. Le broker continue d'accepter l'ancien password.

C'est documenté upstream et assumé par les mainteneurs :

« The Operator does not monitor either the provided secret object or the generated secret object, and updating either secret object won't update the credentials. As a workaround, add a label or annotation to users.rabbitmq.com object to trigger the Operator to reconcile. » — doc officielle « Using the Topology Operator »

Voir aussi l'issue #571 (fermée par une simple MAJ de doc, pas de fix code).

1. Mettre à jour le password côté values + helm upgrade :

   helm upgrade <release> coopengo/coog \
     --namespace <ns> --reuse-values \
     --set rabbitmq.auth.password='<nouveau-password>'

   Cela met à jour le Secret d'entrée <release>-rabbitmq-credentials (étape nécessaire mais insuffisante seule).

2. Lancer le helper fourni par le chart :

   ./coog/scripts/rotate-rabbitmq-user.sh \
     --release <release> --namespace <ns>

   Le script :

   • lit le nouveau password depuis le Secret d'entrée (pas d'argument shell, pas de leak via ps),
   • patch le Secret de sortie <release>-coog-rabbitmq-user-user-credentials,
   • annote le User CR avec un timestamp pour déclencher un reconcile,
   • valide via rabbitmqctl authenticate_user côté broker,
   • liste les Deployments qui consomment le Secret de sortie et qui sont à kubectl rollout restart manuellement.

3. Rollout des consommateurs identifiés :

   kubectl -n <ns> rollout restart deploy/<name>

⚠️ Pendant la fenêtre entre l'étape 2 et le rollout des consommateurs, les nouvelles connexions AMQP avec l'ancien password sont rejetées. Les connexions ouvertes restent valides (auth à la connexion). Pour une rotation sans coupure utilisateur, planifier sur une fenêtre de maintenance.

rabbitmq:
  mode: legacy
  isManaged: true
  # retirer le bloc rabbitmq.operator