VCF Automation 9.1 All Apps : intégrer AD et une CMDB avec Event Broker

La VM WebShop du volet réseau et cloud-init est maintenant connectée et configurée, mais les systèmes d’entreprise n’en savent toujours rien. Ajouter un appel Active Directory directement dans le chemin de provisioning semble pratique jusqu’au jour où AD devient indisponible, où une reprise crée un doublon ou lorsqu’un exploitant doit décider si une VM saine doit être supprimée parce qu’une API CMDB a répondu en erreur.

Cet article choisit un contrat asynchrone. Un événement de cycle de vie IaaS déclenche des workflows VCF Operations Orchestrator indépendants qui font converger un compte ordinateur AD et un CI CMDB transitoire. Le provisioning reste autonome, tandis que les échecs deviennent des opérations visibles et rejouables sans danger.

TL;DR

• Utilise trois abonnements non bloquants limités au projet : création AD, création CMDB transitoire et nettoyage externe protégé lors de la suppression.
• Capture un événement réel dans Event Log avant d’écrire l’adaptateur. L’enveloppe documentée ne garantit pas un chemin universel pour chaque donnée métier.
• Construis chaque workflow autour d’un identifiant de ressource stable et d’un marqueur de gestion. Un événement répété doit converger, et une suppression ne doit jamais rechercher l’objet par son seul nom.

Fixer la frontière avant de créer les abonnements

Le résultat de cet incrément est volontairement limité. Sur CreateSuccess, un workflow garantit l’existence d’un compte ordinateur dans l’OU autorisée du projet, tandis qu’un second garantit l’existence d’un CI CMDB portant ownerMechanism=event. Sur DeleteSuccess, un workflow de nettoyage retire indépendamment l’objet AD géré et le CI appartenant au mécanisme événementiel.

Créer un compte ordinateur AD ne prouve pas que le système d’exploitation a rejoint le domaine. La jonction du guest nécessite une mécanique distincte et liée à l’image : cloud-init, fichier unattend, agent de configuration ou workflow authentifié dans l’invité. Elle exige aussi sa propre preuve depuis la machine et une façon sûre d’obtenir des informations d’identification à courte durée de vie. Cet article ne revendique pas ce résultat.

Broadcom répertorie IaaS resource event parmi les topics Event Broker de VCF Automation All Apps. Ce topic n’est pas bloquant. Cette propriété empêche une panne AD ou CMDB de transformer le déploiement de la VM en panne de plateforme, mais elle signifie aussi qu’aucune transaction ne restaure les deux côtés ensemble et qu’aucun ordre n’est garanti entre les abonnements. La fiabilité doit donc provenir de la convergence rejouable, de la corrélation et d’un chemin de reprise visible par l’exploitant.

Les trois abonnements sont les suivants :

Abonnement	Déclencheur	Responsabilité
iaas-vm-create-ad	VM CreateSuccess	garantir un compte ordinateur géré dans l’OU associée
iaas-vm-create-cmdb	VM CreateSuccess	créer ou mettre à jour un CI marqué ownerMechanism=event
iaas-vm-delete-external	VM DeleteSuccess	tenter séparément le retrait AD et CMDB avec des garde-fous

Le writer CMDB est intentionnellement temporaire. L’article Custom Resource CMDB donnera à Custom.CMDB.CI la propriété des opérations Create, Read et Destroy. Avant cette bascule, les déploiements de test devront être nettoyés et iaas-vm-create-cmdb désactivé. Deux mécanismes ne doivent jamais posséder simultanément le cycle de vie du même CI.

Établir confiance, moindre privilège et scope projet

Dans VCF Operations Orchestrator, enregistre le serveur AD avec le workflow d’intégration pris en charge et un compte de service dédié. Délègue uniquement les opérations nécessaires dans l’OU de lab WebShop : lecture, création, déplacement puis désactivation ou suppression des comptes ordinateurs selon la politique retenue. Un compte Domain Admin n’est ni nécessaire ni acceptable pour cette expérimentation.

Utilise LDAPS avec validation du nom d’hôte et de toute la chaîne de certificats. Importe la chaîne appropriée dans le truststore de la plateforme et corrige les erreurs de confiance à leur source ; ne désactive jamais la vérification TLS pour obtenir une démonstration fonctionnelle. Applique le même niveau d’exigence à l’endpoint CMDB en HTTPS. Les secrets résident dans l’intégration configurée ou le mécanisme de secrets, jamais dans le Blueprint, la condition Event Broker, les journaux du workflow ou les propriétés personnalisées.

La KB Broadcom 393273 fournit un exemple d’automatisation Active Directory avec Orchestrator et une association projet-vers-OU. Réutilise le principe, pas les hypothèses non vérifiées d’un autre environnement. Le package joint provient d’une publication antérieure ; son import, ses actions et ses types d’entrée doivent être validés sur l’instance 9.1 exacte.

Externalise le mapping dans un élément de configuration Orchestrator :

PROJECT_TO_OU = {
  "ID_PROJET_OBSERVE": "OU=WebShop-DEV,OU=VCFA,DC=corp,DC=example"
}
ALLOWED_OUS = {
  "OU=WebShop-DEV,OU=VCFA,DC=corp,DC=example"
}

Utilise l’identifiant immuable du projet observé dans l’événement, pas son nom d’affichage. Une correspondance absente doit produire un rejet contrôlé et une trace d’audit utile. Elle ne doit jamais envoyer silencieusement le compte ordinateur dans une OU par défaut.

Observer l’événement avant d’écrire son adaptateur

La documentation de gestion des abonnements documente l’accès via event.data et décrit l’enveloppe de l’événement. Elle ne promet pas que chaque build cible expose l’identifiant du projet, celui de la ressource et le nom de la VM sous un chemin métier universel.

Crée un abonnement de diagnostic limité à prj-webshop-dev, déploie une VM jetable, puis inspecte son événement CreateSuccess dans Event Log. Masque les valeurs sensibles avant de conserver l’exemple. Relève :

• les identifiants d’événement et de corrélation ;
• les identifiants de l’organisation, du projet et du déploiement ;
• le nom affiché de la VM et un identifiant stable de la ressource ;
• kind et reason tels qu’ils sont réellement reçus ;
• l’objet transmis à l’exécution Orchestrator ;
• les données encore disponibles lors de DeleteSuccess.

Écris ensuite un seul adaptateur, fromIaasResourceEvent(), qui traduit le payload observé dans un contrat interne. Les workflows métier consomment ce contrat stable au lieu de reproduire partout des chemins de payload fragiles.

VmLifecycleContext:
  eventId: string
  correlationId: string
  organizationId: string
  projectId: string
  deploymentId: string
  resourceId: string
  vmName: string
  eventReason: CreateSuccess | DeleteSuccess
  observedAt: ISO-8601

Ces noms de propriétés sont des choix internes au design ; ils ne représentent pas le schéma Event Broker de Broadcom. Conserve des exemples d’événements anonymisés et couvre l’adaptateur avec des tests. Si une évolution de la plateforme change un chemin, seuls l’adaptateur et ses tests devraient être modifiés.

Rendre la convergence AD et CMDB rejouable

Le workflow AD reçoit VmLifecycleContext, résout l’OU à partir de l’élément de configuration et recherche un objet portant le marqueur resourceId stable. Une deuxième exécution doit retourner unchanged, pas créer un autre compte.

Le nom de la VM WebShop peut dépasser la limite NetBIOS traditionnelle de 15 caractères. Une troncature simple est dangereuse, car deux noms longs peuvent aboutir à la même valeur. Une piste raisonnable consiste à utiliser wsd- suivi des 11 premiers caractères hexadécimaux d’un SHA-256 de resourceId. Le résultat compte 15 caractères et reste déterministe, mais la convention et le traitement d’une collision doivent encore être approuvés par les responsables AD.

assert context.eventReason == CreateSuccess
ou = projectToOu.lookup(context.projectId)
assert ou is in ALLOWED_OUS

computerName = "wsd-" + sha256(context.resourceId).hex[0:11]
computer = ad.findByManagedResourceId(context.resourceId)

if computer is absent:
    computer = ad.createComputer(computerName, ou)
    ad.setManagedResourceId(computer, context.resourceId)
else if computer.ou differs and computer.ou is managed:
    ad.move(computer, ou)

return created | moved | unchanged

Le workflow CMDB adopte la même forme : recherche par identité stable, création en cas d’absence, mise à jour uniquement si une donnée change, puis retour de l’enregistrement courant. Il fixe ownerMechanism=event comme constante interne, jamais comme choix du demandeur.

Lors de la suppression, retrouve les objets grâce au marqueur stable. Si un compte AD se trouve hors d’une OU autorisée ou que son marqueur ne correspond pas, retourne manual-review. Si l’objet n’existe plus, retourne already-absent avec succès. La branche CMDB ne peut retirer qu’un CI dont le propriétaire est event. Les deux branches doivent être tentées même si l’une échoue, avec des résultats séparés et un statut final agrégé.

Configurer les trois abonnements limités au projet

Suis le parcours documenté New Subscription pour sélectionner le topic, la condition, le workflow Orchestrator, le scope projet et l’état actif. La page Broadcom Créer un abonnement Event Broker constitue la référence pour l’interface.

Le filtre de création suivant est le point de départ donné par la documentation des topics 9.1 :

event.data.object.involvedObject.kind == 'VirtualMachine' &&
event.data.object.reason == 'CreateSuccess'

Utilise-le pour iaas-vm-create-ad et iaas-vm-create-cmdb, chacun relié à son propre workflow. L’abonnement de suppression commence avec :

event.data.object.involvedObject.kind == 'VirtualMachine' &&
event.data.object.reason == 'DeleteSuccess'

Même si ces propriétés de condition sont documentées, compare-les à l’événement de diagnostic avant activation. Limite les trois abonnements à prj-webshop-dev. N’utilise pas Any Project tant que chaque projet éligible ne dispose pas d’une politique explicite pour son OU et la CMDB. Ajoute une description qui précise la politique d’échec non bloquante et identifie l’abonnement CMDB comme transitoire.

Active un abonnement après l’autre. Prouve d’abord la création AD et son rejeu. Prouve ensuite l’upsert CMDB et son rejeu. Active enfin la suppression, crée une nouvelle VM et vérifie les deux branches de retrait. Cette activation séquentielle constitue une stratégie de test ; elle ne crée aucun contrat d’ordre pendant l’exploitation.

Exploiter les échecs et préparer la bascule CMDB

Les scénarios dégradés font partie du design :

1. Réalise une création nominale et corrèle événement, exécution Orchestrator, compte AD et CI CMDB.
2. Rejoue la même entrée et prouve qu’aucun doublon n’apparaît.
3. Utilise un projet sans mapping d’OU et attends un rejet contrôlé.
4. Teste un nom de VM long et vérifie la règle déterministe du compte.
5. Rends AD puis la CMDB indisponibles et prouve que chaque intégration peut être relancée sans modifier la VM.
6. Supprime une VM après le retrait manuel de l’un des objets externes ; attends already-absent.
7. Déplace un objet AD géré hors de l’OU autorisée et prouve que le nettoyage demande une revue humaine.
8. Génère ou inspecte CreateFailure et prouve que les workflows de création ne démarrent pas.

L’historique des exécutions ne constitue pas, à lui seul, une file de réconciliation. Définis qui reçoit l’alerte, comment l’exploitant rejoue le contexte normalisé d’origine et comment le résultat est audité. Le prochain article sur le Day‑2 pourra exposer une action de resynchronisation contrôlée, mais le workflow doit déjà être assez sûr pour être appelé deux fois.

Avant d’introduire la Custom Resource CMDB plus tard dans la série, bloque les nouvelles demandes de test, supprime les déploiements de test afin d’exercer le nettoyage normal, traite les éventuels CI ownerMechanism=event résiduels, vérifie les résultats, désactive iaas-vm-create-cmdb et attends la fin de ses runs. Publie seulement ensuite le Blueprint qui contient Custom.CMDB.CI. Le workflow de suppression doit ignorer les CI marqués custom-resource : leur action Destroy devient propriétaire de leur cycle de vie.

Pièges & points de vigilance

• Ne mappe aucun champ qui n’a pas été capturé dans Event Log sur le build 9.1 cible.
• Ne suppose aucun ordre entre les abonnements non bloquants.
• N’utilise pas un compte privilégié sur tout le domaine lorsqu’une délégation limitée à l’OU suffit.
• Ne journalise pas payloads et erreurs d’intégration sans vérifier la présence de secrets et d’identifiants sensibles.
• Ne supprime pas un compte AD ou un CI à partir d’un nom dérivé ; exige identité stable, propriété gérée et garde-fous de scope.
• Ne laisse pas le writer événementiel actif après que la Custom Resource devient propriétaire de la CMDB.

Conclusion

Le service WebShop possède désormais un cycle de vie d’entreprise sans transformer AD et la CMDB en dépendances de provisioning. Event Broker transmet le signal asynchrone ; l’adaptateur Orchestrator isole le schéma réellement observé ; les workflows idempotents font converger chaque système externe ; les mappings projet et marqueurs de gestion limitent le rayon d’impact.

Le prochain article rendra ce modèle exploitable par le consommateur de plateforme et par le support. Des actions Day-2 exposeront un chemin de resynchronisation contrôlé, tandis que les policies décideront qui peut l’invoquer et sur quelles ressources.