diff --git a/crowdsec/values.yaml b/crowdsec/values.yaml index d2dd07e..58bff15 100644 --- a/crowdsec/values.yaml +++ b/crowdsec/values.yaml @@ -23,6 +23,11 @@ crowdsec: &crowdsec_config - name: TZ value: Europe/Paris lapi: + # Source stable pour le CUSTOM_HOSTNAME défini plus bas : un fieldRef ne sait + # lire qu'un champ du pod, et tous ceux que le chart expose varient (le nom) + # ou disent autre chose (`k8s-app`, `type`). Ce label n'existe que pour ça. + podLabels: + machine-name: crowdsec-lapi strategy: type: Recreate env: @@ -59,17 +64,42 @@ crowdsec: &crowdsec_config # (/etc/crowdsec est un lien vers le PVC crowdsec-config), donc la # comparaison sur `.login` tient dans le temps. # - # ⚠ Cette entrée DOIT rester dans `lapi.env` : le chart émet sa propre - # définition de CUSTOM_HOSTNAME AVANT d'injecter `.Values.lapi.env`, et en - # cas de doublon Kubernetes retient la DERNIÈRE. C'est ce qui permet de - # surcharger un champ que le chart n'expose pas. `kubectl apply` avertit - # « hides previous definition », c'est attendu. + # ⚠ POURQUOI UN fieldRef VERS UN LABEL, ET PAS UN SIMPLE `value:`. # - # Ne pas « corriger » en supprimant le rolloutRestartTargets : les + # Le chart émet sa propre définition de CUSTOM_HOSTNAME AVANT d'injecter + # `.Values.lapi.env`. On se retrouve donc avec deux entrées de même nom, et + # au RUNTIME Kubernetes retient bien la dernière — un pod de test le + # confirme. Mais ce n'est pas le runtime qui décide ici : c'est l'APPLY. + # + # `env` est une liste à clé de fusion (`name`). Un strategic merge patch + # FUSIONNE donc les deux entrées en une seule. Avec un `value:` en face du + # `valueFrom:` du chart, l'objet fusionné porte les deux, et l'API refuse : + # Deployment.apps "crowdsec-lapi" is invalid: + # spec.template.spec.containers[0].env[5].valueFrom: Invalid value: "": + # may not be specified when `value` is not empty + # Mesuré le 2026-09-20 : ArgoCD a bouclé cinq fois là-dessus, sync en échec, + # Deployment inchangé. `helm template` ne voit rien de tout ça — le rendu + # est parfaitement valide, c'est la fusion avec l'objet vivant qui casse. + # + # Avec un `valueFrom` des deux côtés, la fusion écrase proprement le + # fieldPath et laisse UNE entrée valide. Vérifié par + # `kubectl apply --dry-run=server -o json` : une seule occurrence, pointant + # sur metadata.labels['machine-name']. + # + # D'où le label `machine-name` posé via lapi.podLabels juste au-dessus : le + # fieldRef a besoin d'une source stable, et un label dédié se lit mieux que + # de détourner `k8s-app` ou `type`. + # + # ⚠ Ne pas « simplifier » en `value: crowdsec-lapi`. C'est exactement ce qui + # a échoué, et ça échoue à l'apply, pas au rendu. + # + # Ne pas « corriger » non plus en supprimant le rolloutRestartTargets : les # identifiants arrivent par secretKeyRef, qui ne se recharge pas à chaud. # Sans rollout, la LAPI garderait des identifiants révoqués par Vault. - name: CUSTOM_HOSTNAME - value: crowdsec-lapi + valueFrom: + fieldRef: + fieldPath: metadata.labels['machine-name'] # To enroll the Security Engine to the console - name: ENROLL_KEY value: "cmieq72i3000802jr1wx8kply"