Sujet : deployment
-
Quelles règles de rétention limitent la taille d'un registre de conteneurs sans supprimer les images encore déployées ?
Question ouverte : le ramasse-miettes des registres ne supprime que les blobs qu'aucun manifeste ne référence, et les politiques de cycle de vie font expirer les images selon leur ancienneté, leur nombre ou un motif de tag ; quelle combinaison de règles des équipes ont-elles utilisée pendant des années sans croissance illimitée ni échec de retour arrière dû à la disparition de l'image nécessaire ?
-
Quelle stratégie de déploiement fonctionne sur un hôte unique avec Docker Compose et un reverse proxy ?
Question ouverte : les déploiements progressifs, blue-green et canary sont décrits pour les orchestrateurs, mais beaucoup de petits services tournent sur un seul hôte avec Docker Compose derrière Traefik, nginx ou Caddy. Quelles adaptations — second conteneur avec basculement de règle du proxy, répartition pondérée, start-first — les équipes ont-elles exploitées pendant des mois, qu’est-ce qui les a mises en défaut et à partir de quelle taille un orchestrateur devient-il avantageux ?
-
Tags et releases : tags légers versus tags annotés, et comment ils se propagent
Un tag léger n'est qu'un nom pour un commit ; un tag annoté est un objet portant l'auteur du tag, une date, un message et une signature optionnelle, ce pourquoi git describe ignore par défaut les tags légers et pourquoi les releases devraient utiliser des tags annotés ou signés ; les tags ne sont pas poussés avec les branches à moins d'utiliser --follow-tags ou --tags, et un tag publié ne devrait jamais être déplacé.
-
Arrêt propre : gérer SIGTERM dans les services
Les runtimes de conteneurs envoient SIGTERM et attendent un délai de grâce avant SIGKILL ; un service doit cesser d'accepter du nouveau travail, terminer ou restituer le travail en cours, fermer ses connexions, et se terminer dans ce délai. Ignorer le signal transforme chaque déploiement en interruption de service.
-
Concevoir le retour arrière avant le déploiement
Rédiger un arbre de décision de récupération avant le déploiement, en distinguant les changements de configuration réversibles des migrations de données qui nécessitent une compensation.
-
Modifications de base de données sans interruption de service : expand et contract
Modifier un schéma en trois étapes livrables séparément : étendre (créer une nouvelle colonne ou table, conserver l'ancienne), migrer (écrire en double et rattraper par lots), puis réduire (supprimer l'ancien dès que tout le code utilise le nouveau) ; éviter les verrous longs en ne réécrivant jamais une table entière dans une seule instruction, et en limitant chaque attente avec lock_timeout.
-
Changer un comportement par canari avant le déploiement général
Exposer une cohorte bornée à un nouveau comportement, la comparer à une base de référence et l'arrêter selon des conditions d'échec définies à l'avance.
-
Mode maintenance en lecture seule : servir les lectures pendant que les écritures sont suspendues
Pour les déplacements de stockage, les bascules et les migrations longues, un service peut continuer à servir les lectures et refuser les écritures avec un message clair plutôt que de s'éteindre complètement ; default_transaction_read_only de PostgreSQL rend les nouvelles transactions en lecture seule au niveau de la base de données comme filet de sécurité, et le code HTTP 503 avec Retry-After indique aux clients quand réessayer. Le mode nécessite un interrupteur, un message destiné aux utilisateurs et une simulation.
-
Déploiements progressifs, bleu-vert et canari comparés
Les déploiements progressifs (rolling) remplacent les instances graduellement dans des limites de surcapacité et d'indisponibilité ; le bleu-vert fait tourner la pile complète nouvelle à côté de l'ancienne et bascule le trafic d'un coup ; le canari envoie une petite part du trafic réel vers la nouvelle version et promeut sur preuve. Le choix dépend de la capacité, de la vitesse de retour arrière et de la possibilité, ou non, que deux versions servent en même temps.
-
L'application à douze facteurs comme liste de contrôle pour les services
Les douze facteurs décrivent des conventions pour les services déployables : une seule base de code, des dépendances déclarées, une configuration dans l'environnement, des services annexes traités comme des ressources attachées, une séparation stricte entre construction, publication et exécution, des processus sans état, et des journaux traités comme des flux d'événements.
-
Gérer les secrets en dehors du dépôt
Les identifiants doivent se trouver dans une configuration protégée injectée à l'exécution, jamais dans le contrôle de source, les images ou les journaux ; les faire tourner selon un calendrier et en cas de suspicion, et en attribuer un jeu distinct à chaque service.
-
Faire progresser un même build à travers les environnements : promotion de configuration et parité dev-prod
Construire un artefact une seule fois, lui donner une identité immuable, et faire progresser cet artefact exact du test à la préproduction puis à la production en ne changeant que la configuration propre à chaque environnement ; maintenir les environnements semblables en services annexes et en topologie, afin qu'une étape réussie soit prédictive de la suivante.
-
Les migrations de schéma avec un lock_timeout court et une reprise automatique provoquent moins d'incidents au déploiement
Hypothèse : la plupart des formes d'ALTER TABLE posent un verrou ACCESS EXCLUSIVE qui se met en file d'attente derrière toute transaction longue tout en bloquant chaque requête ultérieure ; les migrations exécutées avec un lock_timeout de quelques secondes et une boucle de reprise bornée produisent donc des interruptions de déploiement moins nombreuses et plus courtes que les mêmes migrations exécutées avec l'attente illimitée par défaut, au prix de quelques migrations qui doivent être relancées manuellement.
-
Déployer un service worker en toute sécurité : portée, caches versionnés, worker en attente et interrupteur d'arrêt
Un service worker qui met en cache du HTML peut figer les utilisateurs sur d'anciennes versions du code après un déploiement. L'enregistrer avec une portée explicite, récupérer le script à neuf à chaque vérification de mise à jour, versionner les caches par build et supprimer les anciens à l'activation, choisir des stratégies par type de ressource, décider comment le worker en attente prend le relais, et livrer un interrupteur d'arrêt testé avant la première mise en production.
-
Lesquels des contrôles pré-déploiement ont réellement empêché une mauvaise publication l'année dernière, et lesquels ne se sont jamais déclenchés ?
Question ouverte : les pipelines accumulent des portes de contrôle (tests, scans, vérifications de fumée, analyse canary, validations manuelles, délais de déploiement), et la documentation Kubernetes indique qu'un Deployment bloqué est seulement signalé, non annulé automatiquement ; quelles portes ont concrètement stoppé une mauvaise publication, lesquelles ne se sont jamais déclenchées, et lesquelles ne se sont déclenchées qu'à tort ?
-
Interrupteurs de fonctionnalités : types, durée de vie et nettoyage
Les interrupteurs de fonctionnalités découplent le déploiement de la mise en production, mais chaque interrupteur est une branche dans le code ; il faut les classer par finalité (mise en production, expérimentation, exploitation, permission), leur attribuer un responsable et une date de suppression.
-
Changements de schéma sans interruption de service, avec l'approche extension-contraction
Modifier un schéma en trois étapes déployables : extension (ajouter la nouvelle colonne ou table, conserver l'ancienne), migration (écriture double et remplissage rétroactif par lots), contraction (supprimer l'ancienne une fois que tout le code utilise la nouvelle) ; éviter les verrous longs en ne réécrivant pas les tables en une seule instruction.
-
Construire des images de conteneur petites et reproductibles
Épingler les images de base par leur empreinte (digest), installer à partir de fichiers de verrouillage avec vérification des empreintes, ne copier que ce dont l'exécution a besoin, s'exécuter avec un utilisateur non root, ajouter un contrôle de santé, et garder les secrets hors des couches et des arguments de build.
-
Tags versus empreintes des images de conteneur : noms mutables et adresses de contenu
Un tag est un pointeur lisible par les humains qui peut être déplacé vers un autre manifeste à tout moment ; une empreinte est le hash des octets du manifeste et identifie exactement une image pour toujours. Construire et tester par tag, déployer et épingler par empreinte, et consigner l'empreinte dans chaque note de version.
-
Exécuter un service sous systemd
Un fichier d'unité déclare comment un service démarre, redémarre et est confiné ; utiliser Type, Restart=on-failure, des limites de ressources et des directives de sandboxing, et lire les journaux avec journalctl plutôt que d'écrire sa propre démonisation.
Lisible par machine : JSON