Du Namespace capturé au produit de catalogue : personnaliser et versionner l’App Stack

Un ZIP exporté et un Blueprint généré ne sont pas encore un produit. Si le premier clone reprend le FQDN de production, le compte ordinateur de la source ou un disque contenant des données sensibles, App Stack Formation aura reproduit fidèlement le problème. La vraie industrialisation commence donc après la capture.

Nous partons de webshop-appstack-v1, produit dans l’article précédent à partir de ns-webshop-prod. L’objectif est de rendre WebShop Environment v1 demandable dans prj-webshop-modern, puis supprimable sans effet sur la production. La chaîne de promotion, le versionnement et les contrôles de nettoyage présentés ici constituent un modèle d’exploitation proposé, non une procédure exécutée dans un lab.

Le Namespace source appartient déjà à All Apps : App Stack Formation ne convertit pas un deployment VM Apps et ne remplace aucune étape de migration.

TL;DR

• Une capture devient un produit seulement lorsqu’elle régénère identités et secrets, sélectionne une donnée adaptée et supporte un lifecycle complet jusqu’au delete.
• Publiez d’abord dans un projet sandbox ; l’audience augmente après les preuves de démarrage, panne, Day-2 et nettoyage, jamais après le seul succès du provisioning.
• Dès lundi, définissez trois versions distinctes — état source, Blueprint technique, release catalogue — et interdisez le remplacement silencieux d’une version consommée.

Promouvoir par preuves, pas par confiance

Broadcom documente la capture d’un Namespace et la distribution de Blueprints, mais le rayon de publication reste une décision de gouvernance. Une capture issue de production ne doit jamais arriver directement dans un catalogue global. Elle traverse une revue à quatre voix, un clone isolé, une panne représentative et un delete contrôlé.

La revue rassemble plateforme, application, sécurité et données. Elle cherche les IP, MAC, hostnames, certificats, clés privées, tokens, comptes de service, endpoints CMDB/DNS/IPAM/AD, destinations de backup, règles firewall et dépendances à une Region, un VPC ou une classe indisponible. Elle couvre le Blueprint et les disques capturés : un secret absent du code peut toujours être présent dans une image.

Personnaliser le besoin, calculer l’infrastructure

Le formulaire doit parler le langage du consommateur : environnement autorisé, taille fonctionnelle, durée de vie, profil de données et centre de coût. Il ne doit pas exposer une liste brute de VM Classes, Storage Classes ou subnets. Ces choix sont calculés par la plateforme à partir du projet, de la Region, des quotas et des politiques.

Cette séparation réutilise le principe des Custom Forms dynamiques reconstruits pour All Apps : l’utilisateur décrit son intention et le backend revalide les valeurs autorisées. Une liste dynamique n’est jamais une frontière de sécurité ; l’action de provisioning doit refuser une classe ou un projet hors politique même si une requête contourne le formulaire.

clone_profile:
  environment: sandbox
  namespace_name: generated
  hostname_prefix: ws-sbx
  size: standard
  vpc_policy: dedicated-per-deployment
  credentials: generated-in-approved-secret-store
  data_source: sanitized-demo-snapshot
  external_registration: sandbox-only
  lease_days: 7

Les mots de passe ne deviennent jamais des valeurs par défaut du formulaire. Ils sont générés ou référencés par un mécanisme de secrets approuvé. Le dataset de production n’est pas une commodité de démonstration : un profil sanitized-demo possède un propriétaire, une version, une preuve d’assainissement et une règle de rétention.

Déployer le clone et prouver son indépendance

La première demande conserve l’identifiant de request, l’identifiant de deployment, le Namespace, le VPC, les VM, les volumes, la version du Blueprint, les paramètres non sensibles, les événements et les timestamps. Ce faisceau permet de relier une erreur au bon niveau au lieu de diagnostiquer seulement la dernière VM créée.

Les quatre identités suivantes doivent changer :

Le test le plus révélateur consiste à arrêter le clone. Si WebShop PROD perd une dépendance, un objet était partagé alors qu’il devait être isolé. Vérifiez aussi qu’aucun nom, IP ou certificat ne collisionne, que les logs portent le projet et le Namespace du clone, que le backup vise une destination sandbox et que la CMDB ne fusionne pas les deux CI.

La présentation officielle d’App Stack Formation 9.1 positionne le stack comme une unité exploitable, notamment autour d’actions telles que start, stop ou snapshot. Les actions exactes, leur portée et leur contrôle par policy restent à confirmer sur le build. Le test attendu démarre la base, attend son état prêt, démarre l’application, attend /readyz, puis rend le Web sain via /healthz. L’arrêt suit l’ordre inverse.

Injecter une panne avant d’élargir l’audience

Un produit de plateforme est défini autant par ses erreurs que par son chemin heureux. Rendez temporairement la Content Library indisponible, refusez un secret, saturez la Storage Class dans un environnement sûr ou interrompez le cleanup. Pour chaque injection, capturez le message utilisateur, les événements, la ressource bloquée, la remédiation et le reste éventuel.

Le diagnostic ne doit jamais « réparer » le clone en modifiant ns-webshop-prod. La source de capture reste une référence protégée. Une correction déclarative peut être appliquée au Blueprint puis testée ; une dérive importante ou mal comprise impose généralement une nouvelle capture et une nouvelle revue.

Tester le delete comme une fonction produit

Le succès d’un clone ne se mesure pas seulement à sa création. Après suppression, contrôlez le Namespace selon son ownership, les VM, le VPC et ses subnets dédiés, les volumes/PVC, les entrées DNS et IPAM, les comptes AD, le CI CMDB, le membership load balancer, les secrets temporaires et les sauvegardes.

Classez chaque reste : absent, retained ou orphan. Un volume volontairement conservé n’est pas un orphan si un owner, une durée, un coût et une procédure de destruction sont documentés. À l’inverse, une ressource « probablement utile » sans propriétaire constitue un échec de cleanup.

delete_evidence_template:
  evidence_status: expected-result
  validation_requirements:
    - timestamped-deletion-task
    - post-deletion-inventory
    - production-non-impact-check
  expected_state:
    namespace: absent
    virtual_machines: absent
    dedicated_vpc: absent
    volumes: retained-with-data-owner-for-7-days
    dns_ipam_ad_cmdb: absent
    temporary_secrets: revoked
    production_source_impact: none
  execution_status: not-performed

Ce bloc décrit le format de preuve attendu : cet article n’a exécuté aucune suppression. Après le test, remplacez les valeurs attendues par une preuve horodatée et un inventaire post-suppression.

Versionner trois objets différents

Une seule étiquette v1 est insuffisante. Conservez un tuple :

release_tuple:
  capture_source: webshop-prod@2026-08-10T20:00Z
  blueprint: webshop-appstack-v1.2
  catalog_release: 1.0.0
  audience: prj-webshop-modern
  deprecated_after: 2026-11-10

capture_source identifie l’état observé du Namespace. blueprint versionne l’artefact technique et ses personnalisations. catalog_release communique un contrat au consommateur. Ne remplacez pas v1 en silence : publiez v2, marquez v1 comme dépréciée, bloquez éventuellement ses nouvelles demandes et laissez les deployments existants suivre leur lifecycle.

Pour un changement majeur du stack vivant, recapturez et repassez toute la chaîne. Pour une petite correction déclarative, modifiez le Blueprint et retestez. Pour un changement de dataset seulement, versionnez la donnée sans recapturer l’infrastructure. Pour un nouveau runtime, créez un nouveau produit plutôt que de maquiller la rupture en version mineure.

Publication graduelle et rollback

La première release reste limitée à prj-webshop-modern. Appliquez selon le besoin les politiques All Apps d’approval, de lease, d’actions Day-2 et de ressources IaaS, puis configurez les quotas pour le périmètre visé. Affichez owner, support, coût estimé, limites, version et date de dépréciation. Le Global Catalog ou une audience plus large arrive seulement après plusieurs lifecycles observés.

Si le clone échoue, limitez ou dépubliez la release, conservez le deployment le temps de l’analyse si la sécurité l’autorise, supprimez-le via le lifecycle supporté, contrôlez les systèmes externes, puis restaurez la release précédente. Si une donnée sensible a été copiée, le delete du deployment peut ne pas suffire : backups et rétention suivent le processus d’incident du client.

Conclusion

App Stack Formation accélère le passage d’un service stable à un artefact réutilisable. Le travail de plateforme consiste ensuite à rendre cet artefact sûr, compréhensible, observable et supprimable. C’est la combinaison identité + donnée + Day-2 + delete + version qui crée un produit, pas le bouton Publish.

Revenez au preflight et à la capture du Namespace si un défaut se trouve dans l’artefact source. Une fois la release opérable, la dernière étape consiste à drainer, désactiver puis éventuellement supprimer l’organisation VM Apps.

Sources officielles : Capture a Namespace as a Blueprint · App Stack Formation 9.1 · Import or Export a Stateful Blueprint · Politiques approval, lease, Day-2 et ressources IaaS.