Un déploiement All Apps vert ne constitue pas encore une migration. Tant que les utilisateurs, les écritures et les systèmes externes désignent le WebShop VM Apps, la cible n’est qu’une répétition coûteuse. À l’inverse, basculer le DNS dès que trois VM affichent « Ready » transforme un exercice réversible en incident de données potentiel.
Ce chapitre construit donc le cutover comme un changement applicatif, pas comme une opération de déplacement de VM. Le cas étudié conserve webshop-prod-042 dans l’organisation VM Apps, déploie un WebShop distinct dans ns-webshop-prod, puis déplace le trafic et l’autorité d’écriture par étapes. Il s’agit d’une reconstitution de design non exécutée : les seuils, commandes, durées, RPO et RTO doivent être décidés et répétés dans le contexte client.
Ce que Broadcom documente — et ce qui reste à concevoir
Le design bimodal VM Apps / All Apps documente la coexistence progressive. Il ne choisit ni le mécanisme de réplication PostgreSQL, ni le TTL DNS, ni le seuil de rollback de WebShop. Ces décisions appartiennent au propriétaire applicatif et au plan de changement.
TL;DR
- Conservez la source exploitable jusqu’à la fin d’une période d’observation explicitement approuvée ; la suppression n’est jamais une étape du cutover.
- Le retour est généralement simple tant que les deux rails utilisent une autorité de données que le bleu peut reprendre. Après la première écriture engagée uniquement dans l’autorité de données cible, il dépend d’un chemin inverse réellement testé.
- Dès lundi, attribuez un propriétaire unique à chaque écriture DNS, IPAM, AD, CMDB, backup et base de données, puis répétez le runbook hors production.
Le contrat blue-green de WebShop
Le bleu est le service VM Apps existant : webshop-web-01, webshop-app-01 et webshop-db-01. Le vert est un nouvel ensemble All Apps avec des noms et identités propres : webshop-web-aa-01, webshop-app-aa-01 et webshop-db-aa-01. Les deux rails coexistent, mais un seul doit être propriétaire du trafic public et un seul doit accepter les écritures de référence à un instant donné.
Le consommateur doit dépendre de webshop.corp.example ou d’une VIP, jamais d’une IP de VM devenue contractuelle par accident. Dans le modèle All Apps, le périmètre organisation → projet → Namespace → VPC change les identifiants et les frontières réseau. La conservation de l’IP, de la MAC ou de l’identité du deployment source ne doit donc pas être une hypothèse du plan.
Trois stratégies de données, trois profils de risque
| Stratégie | Avantage | Coût réel | Usage raisonnable |
|---|---|---|---|
| DB legacy conservée temporairement | Web et App migrent d’abord ; retour de trafic simple | dépendance inter-modèles, latence et règles réseau temporaires | première vague si l’application le supporte |
| backup puis restauration | mécanisme borné et compréhensible | fenêtre sans écriture potentiellement longue | petite base avec RTO compatible |
| réplication | coupure réduite et lag mesurable | exploitation plus complexe ; chemin inverse obligatoire | service critique après répétition complète |
Le fil rouge retient deux vagues. D’abord, les tiers Web et Application All Apps consomment temporairement la base legacy. Ensuite, une nouvelle base est créée dans All Apps et alimentée par réplication. Une modernisation vers DSM serait un autre projet : la mélanger au changement de modèle d’automatisation multiplierait les variables et fragiliserait le rollback.
La frontière n’est donc pas la première requête d’écriture passée par le rail vert. Tant que les deux rails écrivent dans webshop-db-01, il n’existe qu’un historique de référence. La frontière est le transfert de l’autorité d’écriture à webshop-db-aa-01, c’est-à-dire la première transaction validée uniquement dans la base cible. Un canary pondéré ne peut transporter des écritures que si les deux rails utilisent cette même base de référence ; ne répartissez jamais les écritures entre deux bases actives.
Construire le vert sans créer de collision
Le déploiement cible doit être complet, mais non public. Il reçoit sa propre adresse, ses certificats, ses comptes ordinateur éventuels, ses objets de monitoring et son CI CMDB marqué pre-cutover. Il n’entre pas encore dans le pool public. Cette séparation rend possible le test du vrai service sans adopter silencieusement un objet source.
Avant toute bascule, comparez les deux rails sur les dimensions qui comptent : version applicative, configuration, capacité, flux entrants et sortants, chaîne TLS, groupes d’identité, sauvegarde, restauration, logs, alertes et actions Day-2. La parité ne signifie pas une copie bit à bit. Une VM Class ou une Storage Class différente est acceptable si le contrat de performance est tenu et si l’écart est enregistré.
Le test doit partir des réseaux utilisateurs réels. Une transaction lancée depuis le poste de l’administrateur ne prouve ni la résolution DNS des agences, ni le passage du proxy, ni les règles de firewall, ni le comportement de l’IdP. Le jeu minimal comprend /healthz, /readyz, une authentification, une transaction métier avec écriture, la corrélation des logs, le déclenchement d’une alerte et une restauration isolée. Avant le transfert d’autorité des données, ce test d’écriture doit utiliser la base legacy encore autoritative ou une donnée jetable supprimée avant la synchronisation finale.
cutover_contract:
application: webshop-prod
source_deployment: webshop-prod-042
target_namespace: ns-webshop-prod
traffic_switch: load-balancer-weight
data_strategy: postgresql-replication
source_recoverable_until: business-acceptance-plus-14-days
decision_authority: application-change-board
evidence_status: design-reconstruction
execution_status: not-performedCe contrat ne fournit pas une valeur universelle. « 14 jours » est ici un exemple de gouvernance lisible, pas une recommandation Broadcom. Le client doit l’aligner sur ses sauvegardes, sa licence, son coût de double run et la vitesse à laquelle une dépendance tardive peut apparaître.
Le point où le rollback change de nature
Tant que le vert reste en lecture seule ou écrit dans la même autorité de données que le bleu peut reprendre, revenir consiste généralement à remettre le poids du bleu à 100 % ou à restaurer l’enregistrement DNS. Après la première écriture autoritative engagée uniquement dans la donnée cible, les historiques de la source et de la cible peuvent diverger. Un retour sûr exige alors de geler la cible, d’identifier le delta, de le répliquer vers la source ou de restaurer selon une méthode prévue, puis de valider la transaction métier sur le bleu.
Un bouton de trafic n'est pas un plan de retour
Si la réplication inverse ou la restauration n’a jamais été exercée, annoncer un rollback après écritures est trompeur. Le critère de go/no-go doit vérifier le chemin des données, pas seulement la disponibilité de la VM source.
Le dossier de changement peut représenter la décision ainsi :
go_no_go:
go_if:
- source_and_target_health_green
- replication_lag_within_approved_rpo
- target_logs_alerts_and_backup_visible
- reverse_data_path_rehearsed
- application_data_network_and_rollback_owners_present
stop_if:
- unknown_critical_dependency
- target_identity_failure
- restore_evidence_missing
- concurrent_external_writer_detectedLes métriques doivent être chiffrées localement : taux d’erreur, latence p95, lag de réplication, nombre de transactions réconciliées et durée maximale du gel. Un adjectif comme « faible » ne permet ni à l’autorité de changement de décider, ni à l’astreinte de déclencher le retour.
Exécuter une bascule observable
Un load balancer pondéré est généralement plus contrôlable : cible ajoutée à poids nul, health checks validés, canary, puis paliers de trafic. Un canary capable d’écrire n’est sûr que tant que les deux rails utilisent la même base autoritative ; après transfert de l’autorité à la base cible, tous les writers doivent y être routés. Le DNS reste valable lorsque l’architecture ne dispose pas de ce levier, à condition d’abaisser le TTL assez tôt et de mesurer les caches qui ne le respectent pas. Ne modifiez pas DNS et load balancer en même temps : une seule variable de routage simplifie le diagnostic.
La séquence opérationnelle est courte sur le papier, mais chaque étape produit une preuve :
- annoncer la fenêtre et geler la configuration ;
- quiescer les écritures si la méthode de données l’exige ;
- terminer la synchronisation et réconcilier les comptes ou checksums métier ;
- déplacer un canary, puis le trafic approuvé ;
- exécuter les smoke tests depuis les réseaux utilisateurs ;
- surveiller erreurs, latence, authentification et transaction métier ;
- noter l’heure exacte à laquelle la cible devient l’unique autorité d’écriture ;
- déclarer un succès provisoire, jamais une suppression autorisée.
La bascule porte aussi sur les systèmes externes. DNS/LB désigne le vert, IPAM conserve les deux allocations pendant la garantie, AD conserve des comptes distincts, la CMDB passe la cible à active et la source à retiring, le monitoring route les alertes vers l’équipe cible, et le backup protège encore la source tant que le retour reste autorisé. Chaque système a un writer unique et un journal de changement.
Après acceptation provisoire, le catalog item VM Apps doit refuser les nouvelles demandes WebShop, tout en conservant les actions Day-2 nécessaires au service existant et au retour. Le message du catalogue renvoie vers le produit All Apps. Ce gel empêche la dette de croître sans détruire le filet de sécurité.
Rollback et incidents à répéter
Health check vert, transaction métier rouge
Une partie des utilisateurs reste sur le bleu
La cible est plus lente avec la base legacy
Deux objets CMDB ou AD se battent
Les données divergent après la bascule
La séquence de retour est : déclarer l’incident, geler les writes cible, mesurer le delta, exécuter le chemin inverse, remettre le trafic sur la source, tester la transaction et réaligner les writers externes. Le vert n’est pas détruit pendant l’incident : ses événements, ses disques et ses logs font partie des preuves.
Les preuves qui ferment la fenêtre
| Contrôle | Preuve attendue | Statut de cette étude |
|---|---|---|
| parité fonctionnelle | santé et transaction métier | à valider en lab |
| sécurité et identité | tests positifs et refus attendus | à valider en lab |
| sauvegarde cible | restauration isolée réussie | à valider en lab |
| chemin inverse des données | répétition horodatée | à valider en lab |
| bascule de trafic | poids ou résolution avant/après | résultat attendu |
| writer unique | matrice d’ownership | hypothèse de design |
| acceptation | décision métier signée | résultat attendu |
La fenêtre se ferme seulement lorsque la période d’observation est achevée, qu’aucun incident attribuable à la cible ne reste ouvert, que la sauvegarde cible est restaurable et que le propriétaire des données accepte la réconciliation. La source devient alors candidate au drainage décrit en fin de série ; elle n’est pas supprimée automatiquement.
Conclusion
Le blue-green donne du temps et de la visibilité, pas une garantie magique. Sa valeur vient de la séparation des identités, de l’observation simultanée des deux rails et d’un chemin de données réversible. Le moment important n’est pas le changement DNS : c’est la première écriture engagée uniquement dans l’autorité de données cible, car elle transforme le retour en opération de données.
Deux rails, un propriétaire
Source et cible peuvent coexister ; trafic, données et systèmes externes ne doivent jamais avoir deux autorités concurrentes.
Le retour se teste
Une source encore allumée n’est pas suffisante après les premières écritures propres à la cible. Réplication inverse ou restauration doit avoir été répétée.
Acceptation avant retrait
Le succès reste provisoire jusqu’aux preuves métier, backup, observabilité et ownership. La suppression appartient à une vague ultérieure.
La préparation déclarative du service est couverte dans l’article précédent sur les Cloud Templates et extensions. Une fois WebShop stabilisé entièrement dans son Namespace All Apps, l’étape suivante capture ce Namespace avec App Stack Formation.
Sources officielles : Bimodal Consumption Design · modèle multi-tenant All Apps.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
