App Stack Formation : capturer le Namespace WebShop sans capturer ses défauts

Capturer trop tôt est une manière très efficace d’industrialiser une erreur. Une VM de diagnostic oubliée dans le périmètre, une adresse codée en dur ou une base copiée en pleine écriture se retrouvera dans chaque futur clone. App Stack Formation ne transforme pas automatiquement une application en produit propre ; il sérialise ce que l’équipe lui présente.

Dans notre fil rouge, WebShop a déjà quitté VM Apps : ses trois tiers fonctionnent dans ns-webshop-prod et le cutover précédent a été accepté. C’est une frontière essentielle. App Stack Formation 9.1 capture un Namespace All Apps éligible sous forme de Stateful Blueprint ; ce n’est pas un convertisseur de deployment VM Apps. Le parcours ci-dessous est une reconstitution non exécutée fondée sur les TechDocs 9.1. Les libellés de l’interface, le contenu précis des artefacts et la cohérence applicative doivent être vérifiés sur le build utilisé.

TL;DR

• Lancez App Stack Formation seulement après stabilisation complète du service dans All Apps ; la fonction ne capture pas directement le legacy VM Apps.
• Pour un produit de catalogue répétable, préférez une capture personnalisée et régénérez identités, secrets et données ; le mode identique doit rester isolé.
• Dès lundi, construisez l’unique VM Group complet, préparez la Content Library projet et les VM Classes requises, puis planifiez l’arrêt contrôlé nécessaire au preflight documenté.

Ce qu’App Stack Formation capture réellement

La documentation Broadcom sur les Stateful Blueprints décrit le chemin général : un Namespace self-service actif, exactement un VM Group contenant toutes les VM du Namespace, des VM initialisées et éteintes, les VM Classes requises, au moins une Content Library associée au projet, un preflight, puis une capture identique ou personnalisée. Le résultat est un Blueprint et des artefacts qui devront encore être déployés et testés.

Le périmètre documenté n’est pas un filtre sélectif à l’intérieur du Namespace : chaque VM du Namespace doit appartenir à cet unique VM Group. La capture ne garantit pas, à elle seule, la cohérence transactionnelle applicative, la portabilité d’une licence liée à la machine, l’absence de collision de hostname ou la validité sur une autre Region. Les TechDocs indiquent aussi des blockers : un Namespace contenant un cluster VKS, un Avi Load Balancer ou des vSphere Pods n’est pas éligible au parcours documenté.

Le VM Group est votre première décision produit

Pour WebShop, vg-webshop-core contient webshop-web-aa-01, webshop-app-aa-01 et webshop-db-aa-01, car ce sont toutes les VM restant dans ns-webshop-prod. Une machine migration-helper, une VM de diagnostic ou une restauration temporaire doit être retirée du Namespace ou déplacée avant la capture. La laisser hors du VM Group ne satisfait pas le prérequis documenté.

capture_scope:
  namespace: ns-webshop-prod
  namespace_vm_inventory:
    - webshop-web-aa-01
    - webshop-app-aa-01
    - webshop-db-aa-01
  vm_group:
    name: vg-webshop-core
    members:
      - webshop-web-aa-01
      - webshop-app-aa-01
      - webshop-db-aa-01
  namespace_vm_group_count: 1
  ungrouped_namespace_vms: []

La revue du groupe doit partir du fonctionnement applicatif. Une VM oubliée peut héberger un scheduler, un agent de licence ou un relais de fichiers indispensable. À l’inverse, une machine temporaire laissée dans le Namespace devient une dépendance permanente et consomme capacité, licence et surface d’attaque dans chaque clone. L’équipe application explique chaque membre ; l’équipe plateforme vérifie sa portabilité et confirme qu’aucune VM du Namespace ne reste hors groupe.

Identique ou personnalisé ?

Le mode identique exige un Namespace actif lié à un VPC dédié dans le parcours documenté. C’est cohérent : plus la copie conserve d’identité réseau, plus elle doit être isolée. Pour WebShop Environment, le mode personnalisé est le défaut de design. Il permet de produire des hostnames uniques, de choisir des classes autorisées par projet, de définir ou générer des mots de passe, d’appliquer des scripts de bootstrap et de configurer la jonction de domaine Windows. Le mode identique peut servir à une répétition topologique protégée ; il ne constitue ni une copie forensique ni une stratégie de reprise après sinistre.

Pour une capture identique, Broadcom indique que le champ de bootstrap des VM est effacé et que les ressources Secret référencées par la personnalisation du système invité ne sont pas recréées. Les secrets stockés dans les disques capturés restent un sujet distinct de revue et de rotation.

Construire un preflight à deux étages

Le premier étage reprend les prérequis plateforme : Namespace self-service actif, exactement un VM Group complet, toutes les VM du Namespace initialisées et éteintes, VM Classes requises disponibles et au moins une Content Library associée au projet. Les blockers VKS, Avi Load Balancer et vSphere Pods doivent être absents. Le second étage appartient au design applicatif : backup cohérent et restaurable, identité régénérable, licence clonable, certificats renouvelables et dépendances externes maîtrisées.

app_stack_preflight:
  namespace: ns-webshop-prod
  documented_gates:
    namespace_active: pass
    self_service_namespace: pass
    project_content_library: pass
    namespace_vm_group_count: 1
    all_namespace_vms_in_single_group: pass
    all_namespace_vms_initialized: pass
    all_namespace_vms_powered_off: pass
    required_vm_classes_available: pass
    vks_cluster_present: false
    avi_load_balancer_present: false
    vsphere_pods_present: false
  application_controls:
    restore_rehearsal: lab-required
    machine_identity_regeneration: design-approved
    hard_coded_addresses: none-detected
    license_clone_right: owner-approved
  execution_status: not-performed

Cette distinction évite une affirmation trompeuse. Le moteur peut déclarer la plateforme capturable sans garantir que PostgreSQL est transactionnellement cohérent ou que le contrat de licence autorise dix copies. Un contrôle ajouté par votre équipe doit rester présenté comme tel, même s’il est aussi important qu’un blocker natif.

Rechercher les identités qui ne doivent pas voyager

Pour chaque VM, inspectez hostname, FQDN, compte ordinateur AD, IP, MAC, route statique, certificat, clé privée, machine-id, SID, activation logicielle, comptes de service, agents de monitoring et de backup, CI CMDB et secrets conservés sur disque. Affectez à chaque élément une stratégie : préserver dans une cible isolée, régénérer, paramétrer, tourner ou exclure.

Un secret absent du YAML peut rester dans l’image capturée. La revue ne s’arrête donc pas au Blueprint généré. Elle examine aussi les disques, les scripts de démarrage, l’historique de configuration et la destination de chaque agent. C’est le point où sécurité, application et plateforme doivent travailler ensemble.

Protéger la donnée et modéliser l’ordre

Pour la base PostgreSQL du fil rouge, utilisez une méthode applicative supportée pour atteindre un état cohérent, prenez un backup et vérifiez sa restauration. Arrêtez ensuite Web, Application puis base de données, et vérifiez que chaque VM du Namespace est initialisée et éteinte avant la capture. Ce prérequis documenté d’état des VM exclut une capture de VM en fonctionnement ; la séquence exacte de quiesce et de backup reste un contrôle de design applicatif soumis à l’approbation du propriétaire de la donnée et à la validation en lab.

L’ordre de démarrage proposé est base, application, puis Web ; l’arrêt suit l’ordre inverse. Mais une séquence n’est utile que si elle attend une condition réelle. webshop-app-aa-01 ne doit pas démarrer simplement trente secondes après PostgreSQL : il doit attendre un check de disponibilité. De même, le tier Web attend /readyz de l’application avant que /healthz puisse rendre le service éligible au trafic.

stack_lifecycle:
  startup:
    - component: database
      ready_when: postgresql-accepts-connections
    - component: application
      ready_when: http-200-readyz
    - component: web
      ready_when: http-200-healthz
  shutdown:
    - web
    - application
    - database

Le mécanisme exact permettant d’exprimer ou d’observer ces conditions doit être vérifié sur VCF Automation 9.1 dans le build cible. Ce code décrit le contrat attendu, pas une syntaxe produit garantie.

Capturer, relire, exporter

Le parcours opérationnel reconstitué est le suivant : terminer le backup applicatif, effectuer l’arrêt contrôlé, vérifier que toutes les VM du Namespace sont initialisées et éteintes, sélectionner le Namespace et son unique groupe complet vg-webshop-core, exécuter le preflight, résoudre chaque blocker, choisir le mode, définir les personnalisations et l’ordre, sélectionner cl-prj-webshop-modern, puis lancer une capture nommée webshop-appstack-v1. Conservez l’identifiant de tâche, les événements, la durée observée et la liste des artefacts. Les libellés précis de l’UI restent à valider ; une illustration synthétique ne doit pas être présentée comme une capture d’écran du produit.

Le Blueprint généré devient du code à relire. Vérifiez qu’il ne contient ni adresse source involontaire, ni secret en clair, ni helper, et que ses VM Classes, Storage Classes, VPC, subnets, permissions, inputs et outputs correspondent au projet cible. Ajoutez une métadonnée de version, l’owner, la date et l’identifiant du Namespace source. La génération par la plateforme n’exonère pas de revue de code.

La documentation d’import et d’export distingue bien les sens. L’import accepte .OVA, .OVF ou .YAML ; une OVA contenant un média ISO n’est pas prise en charge à l’import. L’export d’un Blueprint valide, de ses images et dépendances produit un ZIP réimportable, mais les images de VM au format ISO sont omises pendant l’export. Archivez ce ZIP avec un checksum, le task ID, les IDs de Content Library et les limitations connues. L’export transporte l’artefact, pas l’historique du deployment qui lui a donné naissance.

Échecs utiles à provoquer avant publication

Gate de fin : l’artefact existe, le produit pas encore

Si la capture échoue après l’arrêt, conservez les événements et redémarrez WebShop selon la séquence normale base de données → Application → Web lorsque le plan de changement approuvé prévoit le rétablissement du service. Supprimez uniquement les artefacts incomplets clairement identifiés, corrigez l’inventaire du Namespace, le groupe ou la library, puis relancez avec un numéro de version différent. Une capture ne justifie aucune suppression de la source All Apps.

Conclusion

App Stack Formation réduit le travail nécessaire pour transformer un stack existant en Blueprint, mais il ne remplace ni l’architecture, ni la sécurité, ni la protection des données. La bonne capture part d’un Namespace stable, d’un unique VM Group complet, de VM éteintes et d’identités explicitement portables. Son résultat reste une hypothèse jusqu’à ce qu’un clone autonome vive puis disparaisse proprement.

Le cutover WebShop explique comment atteindre ce Namespace stable. L’article suivant montre comment personnaliser le clone et promouvoir l’App Stack dans le catalogue.

Sources officielles : Working with Stateful Blueprints · Import or Export a Stateful Blueprint · Capture a Namespace as a Blueprint · présentation App Stack Formation 9.1.