Une plateforme self-service ne devient pas gouvernée parce qu’elle cache les boutons dangereux. Elle le devient lorsque chaque changement possède un mécanisme adapté, une population autorisée, une trace et un chemin de reprise. Sur WebShop, l’utilisateur doit pouvoir redémarrer sa VM et réparer son CI CMDB sans obtenir pour autant le droit de redimensionner, supprimer ou ajouter des disques.
Nous allons construire cette séparation dans une organisation All Apps VCF Automation 9.1. Le résultat est un catalogue Day‑2 volontairement court : opérations natives lorsque le produit les fournit, action Orchestrator pour la resynchronisation CMDB, et politiques d’inclusion par rôle.
Guide de construction, pas compte rendu de lab
Ce parcours est une reconstitution fondée sur la documentation VCF 9.1. Les noms d’actions, bindings et champs d’événements doivent être vérifiés sur le build installé avant une mise en production. Les résultats décrits ci-dessous sont des critères de recette, pas des observations revendiquées.
TL;DR
- Un état durable — taille, capacité, topologie — reste dans les inputs du Blueprint ; une opération ponctuelle devient une action Day‑2.
- Dès que la première Day 2 Action Policy existe, l’organisation passe à une logique d’inclusion : chaque rôle utile doit être couvert avant l’activation globale.
- L’action Resynchroniser CMDB converge vers un CI existant à partir d’une identité stable ; elle ne recrée jamais aveuglément l’objet externe.
Choisir le bon mécanisme
Le premier arbitrage précède l’interface. Si le changement doit rester vrai après une nouvelle application du Blueprint, il appartient au modèle déclaratif. Un nouveau profil de VM, une capacité de disque attendue ou une option de réseau doivent être exprimés par un input, puis appliqués par une mise à jour du déploiement. À l’inverse, démarrer une VM, prendre un snapshot avant maintenance ou rejouer une synchronisation sont des opérations ponctuelles.
Cette distinction évite une dérive classique : ajouter un disque manuellement, puis réappliquer un Blueprint qui ne le connaît pas. La documentation Broadcom sur la préparation des Blueprints aux opérations Day‑2 avertit qu’une mise à jour peut réconcilier l’état et supprimer une modification mutable. Une action pratique à court terme peut donc devenir une perte de données au prochain changement.
La règle d’équipe tient en une phrase : déclaratif pour l’état, action pour l’opération. Chaque exception doit préciser qui assume la dérive et comment elle sera résorbée.
Construire la matrice rôle × action
Commence par l’usage, pas par la liste de toutes les capacités. La page officielle des actions Day‑2 All Apps documente notamment l’alimentation, les consoles, snapshots, disques, suppression et redimensionnement des machines. Leur disponibilité exacte dépend néanmoins du type de ressource et du build.
| Rôle WebShop | Actions proposées | Raison |
|---|---|---|
| Project User | Power On/Off, Remote Console, Resynchroniser CMDB | exploitation courante, effet limité |
| Project Administrator | précédent + snapshots, disques, Resize, Delete | administration de capacité et du cycle de vie |
| Organization Administrator | même jeu pour la recette + administration des policies | contrôle et reprise de bout en bout |
Le Project User ne reçoit ni Delete, ni Resize, ni action sur les disques. Le Project Administrator peut supprimer le déploiement et exécuter le scénario complet de nettoyage. L’administrateur d’organisation n’est pas un raccourci pour les tests : conserve un compte utilisateur dédié afin de prouver que la politique fonctionne réellement.
Une action visible n’est pas une autorisation complète
Le workflow Orchestrator et l’API CMDB doivent revalider le projet, l’objet cible et l’identité de l’appelant. Masquer une action dans VCF Automation ne protège pas un endpoint externe appelé directement.
Les snapshots ont besoin d’une durée de vie et d’un propriétaire. Les disques ajoutés hors Blueprint ont besoin d’un plan de réintégration. Resize impose l’arrêt de la VM et une VM Class compatible. Associe ces contraintes au runbook, pas à la mémoire de l’opérateur.
Ajouter « Resynchroniser CMDB »
Dans l’article Event Broker précédent, l’abonnement CMDB est non bloquant : une panne externe ne doit pas empêcher la VM d’être livrée, mais elle peut laisser le CI absent. L’action personnalisée offre une reprise sans redéploiement. À ce stade de la série, elle cible la VM ; dans l’article suivant, elle ciblera Custom.CMDB.CI, qui deviendra le propriétaire unique des écritures CMDB.
Le workflow reçoit une ressource explicitement sélectionnée, résout son identité, lit l’état courant puis converge :
inputs: targetResource, reason, optionalChangeNumber
identity = resolveObservedIdentity(targetResource)
desired = readCurrentVcfaAndProviderState(identity)
ci = cmdb.findByStableIdentity(identity)
if ci is absent:
ci = cmdb.create(desired)
else:
ci = cmdb.updateManagedFields(ci, desired)
return ci.id, result, timestamp, correlationIdLe formulaire ajoute deux garde-fous. Une Value dynamique limite la sélection aux ressources du projet que l’appelant peut administrer. Une Validation Orchestrator refuse une cible hors projet, un motif vide ou un CI déjà retiré. La page Custom Resources dans les Blueprints VCFA documente les mécanismes Values et Validations.
Les bindings automatiques ne fonctionnent pas pour CCI.Supervisor.Resource dans le périmètre documenté. Le formulaire doit donc rendre la resélection explicite tant que le build cible ne prouve pas un autre comportement. C’est moins élégant, mais beaucoup plus honnête qu’une liaison supposée.
Activer les politiques sans lockout
Une Day 2 Action Policy est une liste d’inclusion. Sans policy, les utilisateurs voient les actions applicables ; dès que la première est créée, seules les inclusions effectives restent disponibles. L’ordre d’activation devient donc une opération de changement.
policies:
- id: webshop-developer-actions
role: Project User
scope: prj-webshop-dev
allow: [power-on, power-off, remote-console, resynchronize-cmdb]
- id: webshop-project-admin-actions
role: Project Administrator
scope: prj-webshop-dev
allow: [power-on, power-off, remote-console, resynchronize-cmdb,
snapshot-create, snapshot-revert, snapshot-delete,
add-disk, remove-disk, resize, delete]
- id: webshop-organization-admin-actions
role: Organization Administrator
scope: org-webshop
allow: [power-on, power-off, remote-console, resynchronize-cmdb,
snapshot-create, snapshot-revert, snapshot-delete,
add-disk, remove-disk, resize, delete]Ces identifiants sont le contrat éditorial du lab, pas des IDs produit garantis. Sélectionne les actions publiées par ton instance. Prépare les trois définitions et le plan de retour avant d’en activer une. Dans une fenêtre de changement, rends d’abord effective la policy de l’identité d’administration de contrôle, vérifie son chemin de reprise, puis active sans délai les policies Project User et Project Administrator. Teste enfin avec chaque identité dédiée. Cette séquence évite de laisser l’organisation dans un état intermédiaire où seule la population utilisateur est incluse. Simule aussi les recouvrements Soft/Hard avant d’utiliser une priorité Hard.
Pour les opérations sensibles, les topics Event Broker All Apps blocables Deployment resource action requested et completed peuvent appeler Orchestrator avant et après l’action. Utilise le premier uniquement pour un contrôle obligatoire, par exemple valider un numéro de changement avant Resize. Pour un journal d’audit, préfère le traitement après action : une panne de l’outil d’audit ne devient pas une panne du catalogue.
Ne copie pas un filtre issu d’Aria Automation 8.x. Lance une action de test dans le projet, ouvre l’Event Log, identifie le champ observé qui porte l’action et l’ID stable de la ressource, puis écris le filtre à partir de ce payload 9.1.
Recette, panne et rollback
La recette compare le menu et l’effet réel. Le Project User ouvre la console et resynchronise le CI, mais ne voit pas Resize ou Delete. Le Project Administrator prend puis supprime un snapshot, arrête la VM avant Resize, et termine par Delete. L’Organization Administrator conserve un chemin de reprise connu. Pour chaque action, relève utilisateur, projet, déploiement, horodatage, Event Log, run Orchestrator et état final.
Injecte ensuite une indisponibilité CMDB dans une configuration de test. L’action doit produire un échec corrélé sans créer de doublon. Après restauration, le même appel doit retrouver la même clé stable et converger vers le même CI. Ce test mesure l’idempotence ; un bouton vert seul ne la démontre pas.
Le rollback se prépare avant l’activation : conserver l’export ou les captures des actions visibles, une policy minimale connue et un compte d’administration de contrôle. En cas de lockout, réapplique la policy minimale. Retire ensuite l’entitlement de l’action personnalisée, désactive les abonnements de contrôle, attends les runs en cours et traite toute ressource partielle avec une trace de changement. Ne supprime pas toutes les policies au hasard : le retour à l’absence de policy change à nouveau le modèle d’accès.
Sources et suite
Les capacités et précautions produit de cet article s’appuient sur les pages Broadcom consacrées aux Day 2 Action Policies, au catalogue d’actions, aux topics Event Broker et aux Custom Resources.
État durable
Il reste dans le Blueprint afin que la prochaine réconciliation ne le détruise pas.
Action minimale
Native d’abord, personnalisée seulement pour une opération métier ponctuelle et idempotente.
Preuve complète
Visibilité, autorisation, effet externe et rollback sont testés séparément pour chaque rôle.
L’étape suivante remplace le writer CMDB transitoire par une ressource de premier rang. Le CI disposera alors de ses propres opérations Create, Read et Destroy, et l’action de resynchronisation agira sur cet objet plutôt que sur la VM.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
