VCF Automation 9.1 All Apps : déployer une première VM avec un Blueprint

Le socle est maintenant défini, mais il ne prouve encore rien sur le chemin de déploiement. Cet article construit volontairement le plus petit incrément utile : un input de catalogue, un namespace existant et une ressource VirtualMachine confiée à VM Operator. Aucun cloud-init, subnet explicite, DNS, Active Directory ou CMDB ne doit masquer un défaut du chemin principal.

La cible est un Blueprint All Apps en formatVersion: 2 avec des ressources CCI.Supervisor.*. Ce n’est pas un Cloud Template Aria Automation 8 simplement renommé, et le parcours n’utilise pas Cloud.vSphere.Machine.

TL;DR

• Garde les identifiants d’infrastructure dans les variables du Blueprint ; le demandeur renseigne seulement le rôle métier de la VM.
• Un déploiement terminé, un objet VM créé, une condition Ready=True et une adresse IPv4 sont quatre points de contrôle distincts.
• Commence par générer un manifeste VM depuis Services, compare son API et ses champs avec l’exemple, puis adapte les trois variables propres à l’environnement.

Suivre le chemin natif All Apps

La documentation Broadcom Creating Blueprints décrit le designer et ses ressources Supervisor. Les Sample Blueprints for All Apps établissent le pattern actuel : une ressource namespace fournit le contexte à une ressource Supervisor générique qui contient le manifeste Kubernetes.

Deux états différents comptent. VCF Automation orchestre le déploiement et attend la condition configurée. VM Operator possède le cycle de vie de la VM. Le système invité peut encore démarrer après la création de l’objet, et son IPv4 peut apparaître après le premier rendu du déploiement. Fusionner ces instants en un seul feu vert produit des captures trompeuses et une automatisation fragile.

Créer le Blueprint minimal

Dans prj-webshop-dev, ouvre le designer, crée webshop-dev-vm-minimal, puis remplace la classe, l’image et le stockage par les valeurs observées dans l’article sur les fondations. La référence complète reste volontairement assez courte pour être relue d’un bloc.

formatVersion: 2
name: webshop-dev-vm-minimal
description: Première VM WebShop DEV sur VCF Automation 9.1 All Apps.

metadata:
  deploymentSettings:
    hideDisabledDay2Actions: true

inputs:
  vmRole:
    type: string
    title: Rôle de la VM
    default: web
    minLength: 2
    maxLength: 20
    pattern: '^[a-z0-9]([-a-z0-9]*[a-z0-9])?$'

variables:
  namespaceName: ns-webshop-dev
  vmResourceName: webshop-${input.vmRole}-dev-${env.shortDeploymentId}
  vmClassName: <VM_CLASS_OBSERVEE>
  vmImageName: <NOM_VIRTUAL_MACHINE_IMAGE_OBSERVE>
  storageClassName: <STORAGE_CLASS_OBSERVEE>

outputs:
  vmName:
    value: ${resource.virtualMachine.object.metadata.name}
  namespaceName:
    value: ${resource.namespace.name}
  __deploymentOverview:
    value: |
      ## WebShop DEV — VM minimale
      - Namespace : `${resource.namespace.name}`
      - VM demandée : `${variable.vmResourceName}`
      - VM observée : `{{resource.virtualMachine.object.metadata.name}}`
      - IPv4 observée : `{{resource.virtualMachine.object.status.network.primaryIP4}}`

resources:
  namespace:
    type: CCI.Supervisor.Namespace
    properties:
      name: ${variable.namespaceName}
      existing: true

  virtualMachine:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.namespace.id}
      manifest:
        apiVersion: vmoperator.vmware.com/v1alpha3
        kind: VirtualMachine
        metadata:
          name: ${variable.vmResourceName}
          labels:
            app.kubernetes.io/name: webshop
            app.kubernetes.io/component: web
            platform.corp.example/environment: dev
            platform.corp.example/owner: team-platform
            platform.corp.example/cost-center: cc-042
        spec:
          className: ${variable.vmClassName}
          imageName: ${variable.vmImageName}
          storageClass: ${variable.storageClassName}
          powerState: PoweredOn
          powerOffMode: TrySoft
      wait:
        conditions:
          - type: VirtualMachineCreated
            status: 'True'

Les valeurs entre chevrons sont des emplacements de publication, pas des valeurs par défaut. Ne les expose pas dans le formulaire. Si l’utilisateur peut saisir n’importe quelle image ou Storage Class, le service gouverné est devenu une API passe-plat.

Le nom conserve env.shortDeploymentId afin que deux demandes portant le rôle web ne se percutent pas. Les labels posent les informations de propriété et de coût utilisées plus tard pour les filtres. Ils ne remplacent pas le contrôle d’accès, mais facilitent la corrélation entre VCF Automation et le Supervisor.

Le namespace porte existing: true. C’est une déclaration de propriété : le déploiement consomme ns-webshop-dev mais n’en possède pas le cycle de vie. Le binding context place ensuite la ressource Supervisor générique dans ce namespace.

Valider avant de publier

Utilise quatre contrôles séparés au lieu de cliquer immédiatement sur Deploy.

Commence par la validation syntaxique du Blueprint. Elle détecte la structure et les expressions erronées, mais ne prouve pas l’existence d’une classe ou d’une image. Compare ensuite le manifeste à celui généré par Services sur la plateforme cible. La version CRD réellement servie et les champs acceptés priment sur cet article.

Publie ensuite une version numérotée du Blueprint. Une demande sans version figée ne peut pas être rejouée correctement. Le premier formulaire doit rester volontairement sobre : vmRole est le seul choix du consommateur. Termine en demandant une instance avec un Project User, et non avec le compte qui a écrit le Blueprint.

Prouver chaque couche

Un résultat crédible contient quatre observations corrélées :

1. la demande indique le projet, la version du Blueprint et l’identifiant du déploiement ;
2. VCF Automation affiche la référence du namespace et la ressource VM sans réconciliation en erreur ;
3. le Supervisor contient l’objet VirtualMachine attendu ;
4. VM Operator finit par indiquer un état Ready et un statut réseau cohérent avec le namespace.

Ne revendique pas encore la disponibilité applicative. Cette VM ne contient aucune configuration WebShop. Elle peut recevoir une adresse du réseau par défaut du namespace, mais l’article 3 rendra le subnet et le contrat de bootstrap explicites.

Pour diagnostiquer, progresse du plan de contrôle vers l’invité. Si le namespace ne se résout pas, vérifie le scope du projet et le nom existing. Si l’admission rejette le manifeste, compare API, classe, image et stockage avec l’exemple généré. Si l’objet existe sans devenir Ready, lis les conditions VM Operator et les événements provider. S’il est Ready sans IPv4, examine le réseau du namespace et l’intégration invitée au lieu de modifier le YAML au hasard.

Supprimer et vérifier la propriété

Supprime le déploiement depuis VCF Automation. Si l’opération se bloque, conserve les événements ; détruire directement la VM dans vCenter masquerait le défaut de réconciliation et laisserait un état mensonger dans VCF Automation.

L’état final attendu est précis mais demeure non vérifié ici : la VirtualMachine a disparu, son déploiement aussi, et ns-webshop-dev existe toujours. Note les trois résultats. Un namespace conservé ne suffit pas si la VM est devenue orpheline ; une VM absente ne suffit pas si VCF Automation croit encore la gérer.

Pièges & points de vigilance

Les autres pièges sont de copier un nom d’affichage au lieu du VirtualMachineImage.metadata.name, de retirer le suffixe unique, d’exposer les variables d’infrastructure comme inputs ou de supposer qu’un exemple documentaire correspond à chaque patch 9.1. Chaque raccourci diminue la valeur du test minimal.

Conclusion

Le Blueprint minimal répond à une seule question : le chemin déclaratif natif All Apps sait-il créer puis retirer une VM dans le namespace gouverné ? Une fois ce chemin isolé, l’article réseau et cloud-init pourra ajouter le choix réseau et le bootstrap sans confondre une panne de guest avec un problème d’admission ou de placement.