Cloud Templates, Custom Forms et extensions : reconstruire le service All Apps

Un Cloud Template VM Apps ressemble à un fichier YAML que l’on pourrait simplement copier dans une organisation All Apps. C’est l’interprétation la plus risquée de la migration. Le document contient des types de ressources, des identifiants, des hypothèses de placement, des payloads d’événements et des hooks de cycle de vie propres au plan de contrôle source. Copier la syntaxe peut préserver toutes les dépendances cachées tout en changeant la plateforme qui les exécute.

La bonne unité de travail est donc le contrat de service : ce que le consommateur WebShop choisit, ce que la plateforme garantit, quels systèmes externes sont modifiés et comment la suppression les nettoie. Cet article reconstruit ce contrat sous la forme d’un design de Blueprint All Apps et d’un contrat de comportement concret pour un Custom Form dynamique. Il sépare aussi les artefacts utiles à la reconstruction des bindings qui doivent recevoir de nouvelles preuves.

TL;DR

• Ne traduis pas les ressources Cloud.* une à une. Préserve les inputs métier et le cycle de vie observable, puis implémente-les avec les services All Apps réellement activés dans la Region cible.
• Considère l’export d’un Custom Form comme une aide à la reconstruction, pas comme une preuve de portabilité entre organisations. IDs, actions, credentials, policies et autorisation serveur demandent de nouvelles preuves.
• Commence avec un contrat de demande WebShop, une action Orchestrator en lecture seule et une matrice qui teste aussi le tampering, le timeout et la suppression.

Reconstruire le service, pas le document

Le catalog item source expose un résultat simple : un déploiement WebShop pour dev, test ou prod. Derrière ce résultat, le template VM Apps peut utiliser Cloud.vSphere.Machine, des cloud zones, des mappings d’image et de flavor, des network profiles, des approval policies, des actions ABX, des subscriptions et des Custom Resources. All Apps introduit une autre hiérarchie de consommation : organisation, projet, Region quota, Namespace, VPC et services comme VM Service. Un même nom d’input peut donc déclencher un placement et une autorisation différents.

Écris une fiche de parité avant le Blueprint cible. Pour chaque comportement source, nomme le mécanisme cible et la preuve qui démontrera la parité :

Comportement consommateur	Implémentation source	Décision cible	Preuve requise
choisir l’environnement	input et contrainte projet	input stable environment	une demande acceptée par valeur autorisée
choisir le placement	cloud zone, tags, profiles	Region, Namespace Class, infrastructure policy	Namespace, VM Class, stockage et réseau effectifs
configurer la VM	mappings image/flavor	image Content Library et VM Class	spécification créée et condition Ready
approuver la production	approval policy	nouvelle policy All Apps	demande bloquée, approuvée puis reprise
enregistrer les objets externes	subscriptions, ABX, Custom Resources	workflows Orchestrator, writer unique	objets DNS, IPAM et CMDB corrélés
supprimer le service	lifecycle du deployment	nettoyage cible idempotent	aucun orphelin, seconde suppression sans effet

La documentation Broadcom sur formatVersion est nécessaire, mais le numéro de version n’est pas un outil de migration. Un template legacy se reconnaît à ses ressources et dépendances, pas seulement à formatVersion: 1. Génère ou inspecte un exemple cible sur le build exact, vérifie le CRD VM Operator servi par le Supervisor, puis seulement versionne le manifeste All Apps.

Le contrat visible du consommateur doit rester volontairement petit :

inputs:
  application:
    type: string
    default: webshop
    readOnly: true
  environment:
    type: string
    enum: [dev, test, prod]
  dataClassification:
    type: string
    enum: [internal, confidential]
  migrationMode:
    type: string
    enum: [rebuild, repackage]
  changeId:
    type: string

Les IDs de projet, Namespace Classes, VM Classes, Storage Classes, VPC et subnets sont des détails d’implémentation. Le formulaire les résout ; le serveur les vérifie de nouveau. Un changement ultérieur de cible ne casse ainsi pas l’API métier du catalog item.

Broadcom documente des Blueprints All Apps d’exemple ainsi que Content Hub. Le flux Stateful Blueprint documenté importe des fichiers .OVA, .OVF et .YAML. L’export est une autre opération : un Blueprint valide, ses images et ses dépendances forment un ZIP réimportable, tandis que les fichiers ISO sont ignorés. Aucun de ces mécanismes ne prouve qu’une instance déployée dans VM Apps, un binding de formulaire ou un objet externe accompagne l’archive.

Un Custom Form dynamique concret

Le formulaire WebShop ci-dessous reprend le contrat de série examples/custom-form-dynamic-contract.yaml. Il s’agit volontairement d’une spécification de comportement, pas de la promesse que ce YAML est directement importable. L’utilisateur choisit trois valeurs métier. La production révèle le champ de changement. Une action VCF Operations Orchestrator en lecture seule calcule un profil cible éligible. Les champs techniques restent cachés, mais caché ne veut jamais dire fiable.

form: webshop-migration-request
visible_fields:
  application:
    value: webshop
    read_only: true
  environment:
    values: [dev, test, prod]
    required: true
  data_classification:
    values: [internal, confidential]
    required: true
  migration_mode:
    values: [rebuild, repackage]
    required: true
  change_id:
    visible_when: environment == "prod"
    required_when: environment == "prod"
    validation_pattern: "^CHG[0-9]{7}$"

dynamic_action:
  name: com.corp.vcfa.forms.getMigrationTargetProfile
  side_effects: none
  inputs:
    application: "${application}"
    environment: "${environment}"
    data_classification: "${data_classification}"
    migration_mode: "${migration_mode}"
  returns:
    allowed: boolean
    reason: string
    target_profile:
      project: string
      namespace: string
      namespace_class: string
      vm_class: string
      storage_class: string
      vpc: string
      subnet_front: string
      subnet_application: string
      subnet_data: string
      approval_required: boolean

submission_controls:
  disable_when_action_fails: true
  revalidate_target_server_side: true
  reject_modified_hidden_values: true

Prenons une demande prod + confidential + rebuild. L’action peut retourner le projet prj-webshop-modern, le Namespace ns-webshop-prod, la Namespace Class nsclass-prod-confidential, le VPC vpc-webshop-prod, trois subnets applicatifs, une Storage Class chiffrée et approval_required: true. L’utilisateur voit un résumé lisible de la cible et doit saisir une valeur comme CHG1234567. Une demande dev + internal + rebuild rejoint le Namespace de développement et ne demande pas d’approbation. Si aucun profil conforme n’existe, allowed vaut false, la soumission reste désactivée et le formulaire présente la raison retournée.

L’action doit avoir quatre propriétés non fonctionnelles : lecture seule, déterminisme à inputs et catalogue identiques, absence de secret dans la réponse et timeout borné puis testé. Elle interroge un registre contrôlé de cibles ; elle ne découvre pas la capacité en créant provisoirement de l’infrastructure. À la soumission, le workflow recalcule ou réautorise le profil. Un utilisateur peut modifier les champs cachés dans son navigateur : seule l’autorisation côté serveur constitue une frontière fiable.

La documentation Broadcom sur les Custom Forms All Apps couvre les valeurs externes et les dépendances. L’article officiel sur les bonnes pratiques de développement aide à concevoir le formulaire. Il faut néanmoins vérifier IDs de champs, rafraîchissement des dépendances, présentation des timeouts, accessibilité et rôles sur le build cible. La KB 437466 documente aussi une limite 9.x de personnalisation du nom de deployment dans certains contextes de tenancy. Utilise une clé de corrélation distincte et stable pour la CMDB et l’idempotence au lieu de transformer un libellé d’affichage en identité technique.

La frontière de portabilité

Un formulaire exporté peut accélérer la reconstruction si le build source supporte l’opération. Il ne démontre pas à lui seul la portabilité. Revois chaque field ID, input cible, valeur par défaut, contrainte, règle de visibilité, référence d’action externe, ID d’organisation ou de projet, rôle, erreur et valeur sensible. Recrée les credentials et la confiance des certificats. Conserve le checksum source pour l’audit, mais attribue de nouveaux IDs à la cible.

La même règle s’applique à l’extensibilité :

• Exporte les packages Orchestrator par le mécanisme supporté, puis reconfigure endpoints, plugins, certificats, credentials et identifiants. L’API Packages de VCF Operations Orchestrator documente le service de packages, pas une compatibilité comportementale entre environnements.
• Remplace les actions ABX au lieu de supposer que leur runtime suit le service. Broadcom documente la dépréciation d’ABX ; préserve triggers, retries, idempotence et effets observables dans une implémentation cible supportée.
• Recrée les subscriptions à partir de payloads observés dans l’Event Log All Apps. La documentation des subscriptions All Apps ne rend pas automatiquement valide un topic ou filtre Aria Automation 8.x.
• Recrée chaque définition de Custom Resource avec contrats Create, Read, Destroy, Day‑2, scope et idempotence. Pour un CI déjà présent dans la CMDB, enregistre une décision adopt, reconcile ou replace ; la ressource Custom.* legacy n’est pas une instance automatiquement transférée.
• Reconstruis approval, Day‑2, lease et infrastructure policies dans un ordre sûr. Teste chaque persona : une policy d’inclusion peut retirer une action à un rôle non couvert.

Pendant la coexistence, affecte un writer unique à chaque objet externe. Si VM Apps possède le DNS et All Apps la CMDB pendant le pilote, documente ce partage. Ne laisse jamais les deux générations créer le même compte ordinateur AD ou le même membre de load balancer sans clé de réconciliation.

Valider tout le cycle de vie

La matrice minimale dépasse largement « le formulaire a été soumis ». Exécute dev/internal/rebuild, prod/confidential/rebuild avec changement valide, changements absent et mal formé, aucune cible éligible, timeout de l’action, modification des valeurs cachées par un project user, rejet d’approbation, livraison dupliquée d’un événement et suppression après enregistrement externe partiel. Répète les cas comme organization admin, project admin et project user.

La preuve doit relier la demande catalogue, le Namespace, la VM, la décision de policy, le run du workflow et l’objet externe grâce à une seule clé de corrélation. Archive le schéma d’événement All Apps au lieu de le paraphraser. Montre que Read retourne la vérité externe et que Destroy est idempotent. Enfin, dépublie la version cible, désactive les nouvelles subscriptions et ne retire que les objets pilotes identifiés pour tester le rollback avant production.

Conclusion

La migration réussit lorsque WebShop Modern possède un contrat consommateur stable et une implémentation nouvellement prouvée, pas lorsque le YAML source est devenu syntaxiquement acceptable. Préserve les choix métier, reconstruis les bindings cibles et rends chaque effet externe observable et réversible.