2026 CI Mac distant : Helm OCI & Chart Registry — rotation des jetons, concurrence et backoff

Contrairement à l’ancien modèle helm repo add + index YAML, le chemin oci:// suit le protocole OCI : résolution de tag ou digest, téléchargement du manifeste, puis des blobs du chart (et parfois de la provenance). Un pipeline transfrontalier casse donc selon quelques familles stables ; les mélanger dans un seul « retry aveugle » empile des correctifs incompatibles (par exemple augmenter la concurrence pendant une tempête de 429).

Authentification et dérive de jeton. Le HTTP 401 indique souvent un robot expiré, un PAT révoqué hors bande, ou un chart référencé dans un projet où le compte n’a pas le scope pull. Sur Mac partagé, un HELM_CONFIG_HOME persistant peut conserver un login valide « hier » et masquer une régression jusqu’à ce qu’un worker froid révèle l’erreur.

Débit et hotspots. Le HTTP 429 survient lorsque plusieurs jobs lancent helm pull ou helm upgrade --install vers le même frontal registry, ou lorsque des reprises automatiques ignorent Retry-After. Sans jitter, les pipelines se resynchronisent et aggravent la limitation.

TLS, inspection et noms. Les autorités internes, MITM d’entreprise ou enregistrements DNS qui ne correspondent pas au SAN du certificat produisent des erreurs x509 ou des coupures au milieu d’un blob. Mélanger IP et FQDN dans oci:// est une cause fréquente d’échecs intermittents.

Concurrence Helm / cluster. Des helm upgrade parallèles sur la même release, ou une tempête de résolutions de dépendances, peuvent saturer le cache local et les quotas API du plan de contrôle — ce qui ressemble à un registry défaillant alors que le goulot est côté cluster. Traitez le backoff registry et le throttle Kubernetes comme deux budgets distincts.

Le tableau ci-dessous est un point de départ pour Helm 3 sur Mac CI en 2026. Mesurez deux semaines le taux de 429, le p95 des helm pull et la part d’échecs avant de glisser vers une colonne plus agressive.

Lorsque le chart déclenche en plus des pulls d’images, croisez cette matrice avec les réglages couches du guide GHCR & registry privé pour unifier backoff images et charts.

Remplacez les placeholders en MAJUSCULES. Exécutez sous le même utilisateur que la CI pour que HELM_CONFIG_HOME reflète la production.

1. Isoler la configuration par job (recommandé sur Mac partagés) :

export HELM_CONFIG_HOME="${WORKSPACE}/.helm-config"
export HELM_CACHE_HOME="${WORKSPACE}/.helm-cache"
mkdir -p "$HELM_CONFIG_HOME" "$HELM_CACHE_HOME"

2. S’authentifier au registry OCI (non interactif) :

echo "${REGISTRY_TOKEN}" | helm registry login "${REGISTRY_HOST}" \
  --username "${REGISTRY_USER}" --password-stdin

3. Tirer un chart avec version figée (échec rapide si le tag bouge) :

helm pull "oci://${REGISTRY_HOST}/${CHART_PATH}" \
  --version "${CHART_VERSION}" \
  --destination "${WORKSPACE}/charts"

4. Installer depuis l’OCI avec attentes explicites (ajustez au SLA cluster) :

helm upgrade --install "${RELEASE_NAME}" "oci://${REGISTRY_HOST}/${CHART_PATH}" \
  --version "${CHART_VERSION}" --namespace "${NAMESPACE}" --create-namespace \
  --wait --timeout 20m --atomic

Registry HTTP de labo : n’ajoutez --plain-http à helm pull / helm install que sur hôtes approuvés. Ne croisez jamais ces identifiants avec des namespaces de production.

Esquisse de retry (bash) : entourez helm pull d’une boucle ; appliquez l’échelon 429 de la matrice ; parsez Retry-After lorsque le registry l’expose. Ajoutez du jitter (par ex. $((RANDOM % 5)) secondes) pour éviter que N jobs ne se réalignent à la même seconde.

Variables d’environnement utiles : HELM_CONFIG_HOME, HELM_CACHE_HOME, et si besoin SSL_CERT_FILE pointant vers une PEM de CA interne livrée avec le runner. Gardez HTTPS_PROXY / NO_PROXY cohérents entre helm registry login et helm pull pour éviter le scénario « une fois OK, ensuite 401 » derrière proxy d’entreprise.

Exemple minimal de timeouts et concurrence dans le shell du job (à adapter à votre orchestrateur) :

export HELM_CACHE_HOME="${WORKSPACE}/.helm-cache"
export HELM_CONFIG_HOME="${WORKSPACE}/.helm-config"
export CURL_CONNECT_TIMEOUT="15"
export CURL_MAX_TIME="120"
# Si plusieurs sous-jobs helm sur un même hôte, exportez un verrou ou une variable de sémaphore maison, ex. :
# export HELM_CI_MAX_PARALLEL="${HELM_CI_MAX_PARALLEL:-2}"

429 Too Many Requests. Vérifiez si la limite vient du registry, d’un CDN amont ou de votre NAT de sortie. Réduisez les jobs Helm parallèles par hôte, respectez les en-têtes de backoff, espacez les branches de matrice et envisagez un cache pull-through régional si la même version de chart est tirée des dizaines de fois par heure.

401 Unauthorized. Contrôlez le périmètre du robot, la visibilité du projet chart et la cohérence entre l’hôte utilisé dans helm registry login et la référence oci://. Sur runners partagés, effacez ou isolez HELM_CONFIG_HOME par job ou injectez systématiquement des identifiants neufs.

Erreurs de certificat ou poignée TLS. Importez la CA du registry dans le magasin de confiance utilisé par Helm, alignez le nom DNS sur les SAN, testez avec openssl s_client -connect hôte:443 -servername hôte depuis le Mac. Évitez --insecure-skip-tls-verify hors environnements jetables.

Encore bloqué ? Croisez avec la FAQ stabilité des pulls pour les motifs génériques de retry, et le guide accélération Git & Docker pull lorsque le chart déclenche de grosses images à l’installation.

Une CI Helm OCI efficace sur Mac distant repose sur trois leviers : auth par job avec rotation avant que des identifiants partagés ne pourrissent, une ligne de matrice alignée sur votre WAN (pas sur votre poste portable), et des reprises bornées qui honorent la sémantique 429 au lieu de l’amplifier. Ajoutez des plafonds sur disque et install parallèles pour que la croissance du cache Helm et les quotas API ne simulent pas une panne registry.

Choisir un nœud MacPull pour des pulls transfrontaliers : privilégiez une capacité Apple Silicon dédiée dans la région la plus proche de votre registry ou miroir afin que TLS et caches chauds amortissent la latence ; n’utilisez le pool partagé qu’après avoir imposé un HELM_CONFIG_HOME par job et la ligne « Prudent » du tableau. Comparez les offres publiquement, puis augmentez le parc lorsque le p95 des pulls cesse de s’améliorer malgré le backoff.