Un abonnement Event Broker sait réagir à la création d’une VM, mais il ne rend pas le CI CMDB visible comme une composante du service. Si le CI manque, dérive ou refuse sa suppression, le déploiement ne porte aucun état dédié permettant à l’opérateur de comprendre ce qui s’est passé. Une Custom Resource change ce contrat : l’objet externe devient une ressource gérée avec son propre cycle Create, Read et Destroy.
Dans ce sixième volet, Custom.CMDB.CI rejoint le Blueprint WebShop. Nous allons concevoir son schéma, trois workflows Orchestrator idempotents, une action de resynchronisation et surtout une bascule mono-writer depuis l’abonnement CMDB transitoire de l’article Event Broker.
Contrat à valider sur l’instance cible
La capacité New schema et son cycle de vie sont documentés pour VCF Automation 9.1. Le schéma, les mappings de workflows, les identifiants d’environnement et le comportement précis en cas de panne doivent être validés sur le build installé. Les appels CMDB ci-dessous sont du pseudocode.
TL;DR
- Choisis New schema pour une API REST sans objet d’inventaire Orchestrator ; Read devient alors obligatoire et relit la vérité externe.
- Utilise une clé stable
deploymentIdentity + logicalName, jamais le seul nom d’affichage, et rends Create comme Destroy idempotents. - Supprime les anciens déploiements de test, désactive l’abonnement CMDB writer, puis active la Custom Resource. Les deux mécanismes ne doivent jamais écrire simultanément.
Du callback à une ressource de premier rang
Une subscription répond à un événement ; une Custom Resource représente un objet. Ce choix convient lorsque le CI est une partie obligatoire du service livré, que son état doit être lisible depuis le déploiement et que sa suppression doit être orchestrée avec celle de la VM. L’abonnement peut rester utile pour une notification ou un audit, mais ne doit plus créer ni mettre à jour le CI.
Broadcom décrit deux modèles dans la documentation Custom Resources in VCFA Blueprints. Orchestrator inventory type expose un objet SDK connu du plug-in ; Create doit retourner cet objet, pas une primitive. New schema expose des propriétés définies en YAML ou JSON Schema et exige un workflow Read. Pour une CMDB appelée en REST sans plug-in d’inventaire, New schema est le chemin le plus direct.
Dynamic Types devient intéressant si les opérateurs doivent parcourir les CI dans l’inventaire Orchestrator et les sélectionner comme objets typés. Il n’est pas nécessaire pour exposer chaque API REST. Commence par le contrat minimal et ajoute un type dynamique seulement lorsque la navigation d’inventaire crée une vraie valeur.
Définir un schéma minimal
Le type doit commencer par Custom. et rester unique. Ne recopie pas le modèle complet de la CMDB : le déploiement n’a besoin que des entrées métier et de quelques sorties observables.
type: object
properties:
deploymentIdentity:
type: string
logicalName:
type: string
environment:
type: string
enum: [dev, test, prod]
owner:
type: string
costCenter:
type: string
criticality:
type: string
enum: [low, medium, high]
externalId:
type: string
readOnly: true
lifecycleState:
type: string
readOnly: true
lastSync:
type: string
readOnly: true
configurationHash:
type: string
readOnly: true
ownerMechanism:
type: string
enum: [custom-resource]
readOnly: true
required: [deploymentIdentity, logicalName, environment, owner, costCenter]Les sorties restent petites et non sensibles. Ni token, ni mot de passe, ni réponse HTTP complète ne doit revenir dans les propriétés ou logs. La connexion CMDB utilise HTTPS/TLS, valide le nom d’hôte et une chaîne de certificats approuvée dans le truststore approprié. Ne désactive jamais la vérification, même pour diagnostiquer un certificat expiré ; corrige la chaîne et surveille sa rotation.
Les bindings automatiques ne sont pas disponibles pour CCI.Supervisor.Resource dans le périmètre documenté. La VM et le CI reçoivent donc des inputs métier communs. Le mécanisme exact qui fournit deploymentIdentity doit être observé et validé dans l’éditeur 9.1 ; ne recycle pas un ancien chemin resourceId issu d’Aria Automation 8.x.
Écrire Create, Read et Destroy comme des convergences
Create doit supporter un retry après timeout. Il calcule une clé stable, recherche le CI, puis crée ou met à jour uniquement les champs dont ce service est propriétaire.
key = stableKey(deploymentIdentity, logicalName)
ci = cmdb.findByKey(key)
if ci is absent:
ci = cmdb.create(key, managedValues)
else:
ci = cmdb.updateManagedFields(ci, managedValues)
return externalId, lifecycleState, lastSync,
hash(managedValues), ownerMechanism="custom-resource"Read reçoit externalId, appelle la CMDB avec un timeout court et retourne l’état observé. Un 404 devient MISSING. Une erreur transitoire produit une erreur récupérable ; elle ne fabrique pas un état vert. Read ne recrée jamais le CI, car une lecture qui écrit annulerait une suppression volontaire sans audit. Quelques centaines de ressources pollées suffisent à charger une API : limite les champs, les retries et mesure la latence.
Destroy relit d’abord le CI. S’il est déjà absent ou retiré, il termine avec succès. S’il ne porte pas la clé et le marqueur de gestion attendus, il s’arrête pour revue humaine. Sinon, il applique la politique d’entreprise — souvent Retired plutôt qu’une suppression physique — puis relit l’état final. Le seul nom logique ne suffit jamais à décider une suppression.
Read observe, Resynchroniser répare
Séparer les deux opérations rend la dérive visible. Read expose MISSING, un hash différent ou une CMDB indisponible ; l’action Day‑2 effectue ensuite une écriture explicite, autorisée et auditée.
Basculer vers un writer unique
Le risque principal n’est pas le YAML, mais la transition. L’abonnement iaas-vm-create-cmdb écrit déjà dans la CMDB. Activer la Custom Resource en parallèle peut produire un doublon ou une alternance de valeurs, même si les deux workflows sont séparément idempotents.
Exécute la bascule dans cet ordre :
- bloque les nouvelles demandes de la version précédente du Blueprint ;
- supprime ses déploiements de test et prouve que le nettoyage AD/CMDB historique est terminé ;
- recherche les CI
ownerMechanism=eventrésiduels et les traite selon la politique ; - désactive
iaas-vm-create-cmdbet attends la fin de tous ses runs ; - adapte
iaas-vm-delete-externalpour conserver AD mais ignorer les CIownerMechanism=custom-resource; - active
Custom.CMDB.CIuniquement dansprj-webshop-dev; - publie une nouvelle version du Blueprint et déploie une seule instance canari ;
- prouve qu’un seul CI existe avant d’élargir le partage.
Cette frontière de propriété doit être visible dans le code, la CMDB et le runbook. Une subscription d’audit peut rester active, à condition qu’elle ne réalise aucune écriture de cycle de vie.
Ajouter la ressource au Blueprint
Le fragment volontairement court partage l’identité logique et les métadonnées métier avec la VM. Sans dépendance CCI supportée, il ne suppose aucun ordre entre les deux créations.
variables:
deploymentIdentity: ${env.deploymentName}-${env.shortDeploymentId}
vmResourceName: webshop-${input.vmRole}-dev-${env.shortDeploymentId}
resources:
cmdbCi:
type: Custom.CMDB.CI
properties:
deploymentIdentity: ${variable.deploymentIdentity}
logicalName: ${variable.vmResourceName}
environment: dev
owner: team-platform
costCenter: cc-042
criticality: lowLa syntaxe finale doit être validée contre le schéma généré par l’instance. Le premier déploiement doit exposer externalId, lifecycleState, lastSync et configurationHash, puis une lecture directe de la CMDB doit retrouver exactement le même objet.
L’action Resynchroniser CMDB, conçue dans l’article Day‑2, réutilise le cœur de Create mais demande un motif, contrôle le projet et conserve externalId. Une panne de l’endpoint après création doit laisser la VM fonctionner et faire échouer Read de manière explicite. Après restauration, la resynchronisation retrouve le même CI et le prochain Read redevient cohérent. Une panne avant Create est différente : si le CI est obligatoire dans le Blueprint, ne promets pas un provisioning non bloquant. Observe si le déploiement échoue, reste incomplet ou part en rollback, puis inventorie les ressources partielles.
Décommissionner sans orphelin
Teste la suppression avec le Project Administrator. Observe séparément Destroy de Custom.CMDB.CI et l’abonnement DeleteSuccess responsable d’AD ; aucun ordre entre ces nettoyages ne doit être supposé. Interroge ensuite VCF Automation, VM Service, AD, IPAM/DNS et la CMDB. Le déploiement disparu de l’interface ne prouve pas que tous les systèmes externes sont propres.
Le rollback retire d’abord le partage de la nouvelle version, puis désactive les hooks et l’action sans supprimer les workflows. Inventorie toutes les instances par externalId, supprime les déploiements canaris un par un pour exercer Destroy, traite manuellement les échecs avec traçabilité et désactive la définition seulement lorsqu’aucune instance active n’en dépend. Le secret CMDB est révoqué en dernier.
Sources officielles
Le contrat produit vient des pages Broadcom sur les Custom Resources dans les Blueprints, la préparation des Blueprints aux opérations Day‑2 et les subscriptions Event Broker All Apps. La clé stable, le marqueur ownerMechanism et l’ordre de bascule restent des choix d’architecture à valider avec la CMDB et le build cible.
Identité stable
Create, Read et Destroy corrèlent le même externalId ; un nom d’affichage ne suffit pas.
Observation honnête
Read consulte la CMDB, expose la dérive et ne répare rien sans action auditée.
Bascule mono-writer
L’abonnement writer est arrêté avant le premier déploiement utilisant la Custom Resource.
La plateforme possède maintenant une VM et un CI avec des cycles de vie corrélés. Le dernier article transforme ces mécanismes en recette rejouable : chemin nominal, rôles Day‑2, panne CMDB, rollback et preuve de suppression distribuée.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
