Déploiements et conteneurs

Le problème

Un conteneur est une chose en cours d’exécution : il a une identité, une durée de vie, et il meurt. Ce que vous souhaitez réellement décrire n’est pas un conteneur, mais l’intention derrière lui — cette image, ce nombre de copies, joignable ici, structuré ainsi — et faire en sorte que quelque chose d’autre maintienne cette intention vraie tandis que les conteneurs individuels apparaissent et disparaissent.

L’écart entre les deux est l’endroit où se situent la plupart des erreurs d’orchestration. Modifiez la mauvaise chose et vous avez modifié un conteneur en cours d’exécution qui sera remplacé dans une heure. Modifiez la bonne chose sans précaution et vous avez remplacé des conteneurs que vous souhaitiez seulement relabelliser.

Comment la plateforme résout le problème

Un déploiement est la description. Un conteneur est une copie en cours d’exécution de celui-ci. Vous modifiez la description ; la plateforme décide ce que cela signifie pour les copies.

Cette décision est calculée, pas jugée. Tout ce qui façonne un conteneur est haché, et une modification du hachage signifie que le conteneur est remplacé plutôt qu’ajusté. Une modification de quoi que ce soit en dehors de celui-ci — l’orchestration autour du conteneur, la tenue de registres — prend effet sans toucher ce qui est en cours d’exécution. Les tables de référence portent cette réponse par champ, dans la colonne de mutabilité, et elle est mesurée en exécutant la fonction de hachage plutôt qu’affirmée dans une phrase : voir le manifeste de déploiement.

La description est également la totalité de l’intention. La plateforme ne lit pas le conteneur en cours d’exécution et n’adopte pas ce qu’elle trouve. Si un conteneur dérive, la description l’emporte.

Envoyer une partie d’une description

Une mise à jour peut ne porter que sur une partie d’un déploiement et non sur la totalité, et la règle comporte deux facettes qu’il est facile de confondre.

Un champ que vous omettez conserve sa valeur stockée. C’est ce qui fait d’un changement d’image une requête à un seul champ : rien d’autre ne doit être lu au préalable, et rien d’autre ne bouge.

Un champ que vous envoyez remplace celui stocké intégralement. Les collections ne sont pas fusionnées. Envoyer une map d’une variable d’environnement n’ajoute pas cette variable à la map stockée — elle devient la map entière, et tout le reste disparaît. Il en va de même pour les volumes, les réseaux et les labels.

Ainsi, modifier une seule entrée d’une collection implique de lire la collection stockée, de la modifier localement, puis de la renvoyer dans son intégralité. C’est délibéré — envoyer un champ signifie « voici désormais sa valeur » — mais c’est le seul endroit où une requête partielle peut supprimer une configuration que personne ne souhaitait supprimer, ce qui explique pourquoi cela est indiqué ici plutôt que laissé à la découverte.

secrets est la seule exception délibérée : il est fusionné, et non remplacé. Un PUT qui envoie secrets est une opération lecture-modification-écriture — les refs que vous envoyez sont appliquées, et toute ref stockée que votre corps ne mentionne pas est conservée plutôt que supprimée. La raison est une classe de perte de données, et non une préférence : chaque autre collection ici peut être écrasée en toute sécurité car sa valeur entière est visible dans la même requête, mais un appelant qui renvoie une ref pour ajouter un identifiant supprimerait silencieusement les autres, et le workload démarrerait SANS eux plutôt que d’échouer bruyamment. Comme conserver une ref est un changement que vous n’avez pas explicitement demandé, il est signalé sous forme d’avertissement nommant ce qui a été conservé — voir rejets et altérations. Omettre une ref de secrets ne la supprime donc jamais ; pour en supprimer une réellement, envoyez "secrets": [] pour vider le tableau, puis envoyez les refs que vous souhaitez conserver.

Not this

Cette page n’énumère pas les champs, leurs types ou leurs valeurs par défaut. Ceux-ci sont générés à partir du schéma et se trouvent dans la référence du manifeste de déploiement ; les réécrire ici créerait une seconde copie qui pourrait contredire la première.

Il ne couvre pas non plus le travail qui s’exécute jusqu’à son terme plutôt que de rester actif — voir travail planifié — ou comment un changement est déployé progressivement, ce qui est mises à jour progressives.

Où l’observer

• Chaque champ d’un déploiement : manifeste de déploiement.
• Ce qu’un changement refusé vous indique : rejets et altérations.