VCF Automation 9.1 All Apps : tester et exploiter le service IaaS

Une VM marquée Completed ne prouve pas que le service IaaS fonctionne. Il faut encore démontrer que la bonne version a été demandée, que VM Service et cloud-init ont convergé, que les effets AD et CMDB sont rejouables, que les actions correspondent au rôle et que la suppression ne laisse aucune ressource externe.

Ce dernier article transforme WebShop DEV en recette exécutable. Son produit final n’est pas une capture flatteuse du catalogue, mais un dossier de preuves versionné que l’équipe plateforme peut rejouer après une modification du Blueprint, d’un workflow Orchestrator ou du build VCF Automation.

TL;DR

• Teste quatre couches de convergence : déploiement VCFA, VirtualMachine Ready, cloud-init terminé et /healthz en HTTP 200.
• Lis la vérité dans chaque système externe. Un run Orchestrator réussi ne prouve pas à lui seul que l’objet AD, l’adresse IP ou le CI est correct.
• Une release n’est acceptable qu’après un test de panne, une vérification des rôles et une suppression suivie d’une recherche d’orphelins.

Établir le contrat de recette

Le point de départ doit être immuable : nom et version du Blueprint, commit source, build VCF Automation, projet, Namespace, VPC, subnet, classes et image. Si deux exécutions ne désignent pas exactement les mêmes artefacts, leur comparaison n’a pas de valeur.

test_run:
  id: aa91-20260810-01
  operator: platform-validation
  vcfa_build: "9.1.x-recorded-at-run-time"
  blueprint:
    name: webshop-dev-vm-with-cmdb
    version: "1.0.0-rc1"
    source_commit: "record-the-tested-commit"
  scope:
    project: prj-webshop-dev
    namespace: ns-webshop-dev
    vpc: vpc-webshop-dev
    subnet: snet-web-front
  inputs:
    vmRole: web
    sshPublicKeyFingerprint: "record-the-fingerprint-only"
  evidence: []
  anomalies: []
  release_decision: not-evaluated

Ne verse jamais token, mot de passe, clé privée ou valeur de Secret dans Git. Pour prouver l’usage d’un secret, conserve son nom logique, sa version ou son empreinte et le statut de l’opération. Les captures masquent adresses internes, DN, identifiants personnels et contenu des payloads.

Avant Deploy, vérifie la capacité du projet, l’accès au Namespace existant, la VM Class, l’image, la StorageClass, le réseau et la santé d’Orchestrator. Une lecture sans effet de bord dans AD et la CMDB distingue une panne de prérequis d’une panne provoquée par le test.

Précontrôle	Source de vérité	Critère
Version publiée	historique du Blueprint	correspond à la fiche
Capacité	quotas et consommation	marge pour VM, stockage et IP
Dépendances CCI	Namespace/Supervisor	classe, image et stockage accessibles
Réseau	VPC et subnet	nom et kind attendus
Orchestration	run de santé	succès horodaté, sans écriture

Le KB Broadcom 426105 documente la référence explicite à un subnet VPC par son nom et son kind. Conserve néanmoins le manifeste réellement accepté par ton build comme preuve de la syntaxe.

Prouver le chemin nominal en quatre couches

Demande le Blueprint avec un Project User, pas avec un administrateur. Relève immédiatement testId, deploymentId, version, heure de soumission, nom de la VirtualMachine et identifiant de corrélation disponible dans Event Log.

La convergence se lit du contrôle-plane vers l’application :

1. VCF Automation termine le déploiement et expose ses ressources ;
2. VM Service publie les conditions de la VirtualMachine et l’adresse observée ;
3. l’invité annonce cloud-init status: done sans erreur finale ;
4. WebShop répond 200 sur /healthz depuis un point d’observation documenté.

Lorsque l’accès au Namespace est autorisé, ces commandes donnent une vue utile :

kubectl -n ns-webshop-dev get virtualmachine
kubectl -n ns-webshop-dev describe virtualmachine VM_NAME

Dans l’invité, vérifie l’initialisation et l’application :

cloud-init status --long
sudo tail -n 80 /var/log/cloud-init-output.log
curl --fail --show-error http://127.0.0.1/healthz

Une commande inaccessible depuis le poste de test n’est pas automatiquement un échec. Note si l’observation passe par console distante, bastion SSH ou workflow autorisé. La documentation Broadcom sur les Blueprints All Apps et les exemples de Blueprints encadre le modèle ; ton manifeste observé reste la preuve du build réel.

Vérifier les vérités externes et l’idempotence

Pour chaque effet, interroge directement son propriétaire. Le nom de VM est une étiquette utile, pas une identité globale.

Effet	Corrélation conservée	Réussite
compte ordinateur AD	deploymentId, correlationId, DN/ID masqué	un objet déterministe dans l’OU attendue
DNS/IPAM	allocation ID, IP/FQDN masqué	bon bloc, pas de doublon
CI CMDB	deploymentId, externalId, lastSync	un CI actif, owner correct
Custom Resource	externalId, hash, run Read	état VCFA aligné sur la CMDB

Le KB Broadcom 393273 automatise le cycle de vie d’un compte ordinateur AD après la dépréciation d’ABX ; cette création ne prouve pas que Linux a rejoint le domaine. Si une jonction OS existe, traite-la comme un test séparé. Pour la CMDB, rejoue Resynchroniser CMDB : externalId doit rester identique et seul lastSync ou un champ réellement en dérive doit changer. Une seconde exécution qui crée un autre CI échoue la recette.

Les subscriptions non bloquantes encore actives — ici AD et, éventuellement, audit — s’exécutent en parallèle. Ne déduis aucun ordre de leurs timestamps. Corrèle chaque run à la demande et vérifie l’état final dans la cible. L’ancien writer iaas-vm-create-cmdb reste désactivé : Custom.CMDB.CI est le seul mécanisme autorisé à écrire le cycle de vie du CI.

Tester trois rôles et une panne utile

Ouvre une session séparée pour Organization Administrator, Project Administrator et Project User. Le Project User doit voir alimentation, console et resynchronisation, mais pas Delete, Resize ou les disques. Le Project Administrator doit pouvoir exercer snapshots, Resize sur VM éteinte et Delete. L’administrateur d’organisation prouve le chemin de reprise et l’administration des policies. Compare les actions effectives aux IDs webshop-developer-actions, webshop-project-admin-actions et webshop-organization-admin-actions définis dans l’article Day‑2.

Injecte ensuite une panne contrôlée : rends l’endpoint CMDB de test indisponible après la création. Le prochain Read de la Custom Resource Custom.CMDB.CI doit signaler une erreur récupérable sans modifier externalId, tandis que la VM et /healthz restent disponibles. Restaure l’endpoint, lance la resynchronisation et vérifie que le même CI redevient cohérent.

Un second test, isolé, coupe la CMDB avant une nouvelle demande. Parce que Custom.CMDB.CI est une ressource obligatoire, n’attends pas un succès partiel maquillé. Observe si le build échoue, laisse le déploiement incomplet ou exécute un rollback, puis inventorie VM, CI, compte AD et IP. Cette observation devient une règle de runbook propre à ton build.

Supprimer et démontrer zéro orphelin

Le Project Administrator demande la suppression. Observe séparément Destroy de Custom.CMDB.CI et iaas-vm-delete-external pour AD ; ce dernier doit toujours ignorer les CI portant ownerMechanism=custom-resource. Puis interroge chaque source de vérité : déploiement absent, VirtualMachine absente, Secret cloud-init supprimé uniquement s’il appartenait au déploiement, compte AD retiré selon politique, allocation IP libérée ou archivée, CI retiré ou supprimé. Un Secret précréé et partagé doit rester intact.

Le choix delete, disable ou archive appartient à la politique de l’entreprise. La recette juge la conformité à cette politique et compte les orphelins. L’option qui ignore les erreurs de suppression peut faire disparaître le déploiement de VCFA tout en laissant un objet ; elle exige toujours une recherche externe finale.

Le rollback de release suit un ordre sûr : retirer la version fautive du catalogue, désactiver seulement l’intégration dangereuse, conserver les lectures et nettoyages utiles, restaurer la version publiée précédente, rechercher les objets créés entre les timestamps, puis réconcilier avec des workflows idempotents. Répète ce chemin avant le go-live ; un rollback seulement écrit est une hypothèse.

Décider la publication

La décision de release rassemble neuf preuves : version et inputs, déploiement, conditions VM, cloud-init et santé, Event Log, runs Orchestrator, objets externes, menus Day‑2 et recherche d’orphelins. Chaque écart a un propriétaire, une sévérité et une décision explicite. La série est terminée lorsque le service peut être demandé, exploité, cassé, réparé et supprimé de façon répétable — pas lorsque la première VM apparaît.

Sources officielles

Le protocole combine les pages Broadcom sur les Blueprints All Apps, les subscriptions Event Broker, les Day 2 Action Policies et les Custom Resources. Les états de panne et libellés de conditions restent des résultats à observer sur l’instance, pas des comportements revendiqués.