Un tutoriel d’automatisation commence souvent par un Blueprint. Dans un vrai private cloud, c’est presque le dernier élément qui devient utile. Un manifeste parfaitement valide échoue encore si le projet ne voit pas la région, si le namespace n’expose pas la VM Class choisie ou si l’image est référencée par son titre commercial au lieu de l’identifiant servi par l’API.
Cette première partie ne crée donc aucune VM. Elle prépare le socle gouverné du fil rouge WebShop DEV : organisation, projet, rôles, namespace, VPC, subnet, classes de capacité, image et stockage. Le livrable est un contrat d’inventaire que l’article suivant pourra consommer sans rien deviner.
Procédure reconstituée
Cet article assemble la documentation Broadcom disponible au 10 août 2026. Le parcours n’a pas été exécuté sur une plateforme VCF Automation 9.1. Les comportements documentés sont séparés des valeurs proposées pour WebShop ; chaque écran, identifiant et résultat devra être capturé sur le build cible avant de présenter ce contenu comme un lab validé.
TL;DR
- Considère la Namespace Class et le namespace existant comme le contrat du service, pas comme de simples prérequis cachés derrière le Blueprint.
- La panne coûteuse n’est pas une erreur YAML : c’est l’exposition d’une mauvaise capacité, image, politique de stockage ou frontière réseau au projet.
- Dès lundi, construis une fiche d’inventaire et remplace chaque valeur dépendante de l’environnement par un identifiant réellement observé dans Services ou dans la vue d’administration concernée.
Le socle possède deux propriétaires
Le provider et l’administrateur d’organisation ne contrôlent pas la même frontière. Le provider alloue une région et sa capacité sous-jacente à l’organisation All Apps. L’administrateur d’organisation crée ensuite les projets, affecte les groupes, sélectionne les services autorisés et prépare le contrat du namespace. L’utilisateur du projet doit consommer ce contrat, pas choisir librement l’infrastructure.
Le modèle suivant est volontairement réduit. Il garde la série lisible tout en respectant la séparation réelle des responsabilités.
| Persona | Responsabilité dans ce lab | À ne pas déléguer par accident |
|---|---|---|
| Provider Administrator | Région, capacité provider, Supervisor et disponibilité du VPC | Suppression de l’infrastructure globale ou allocation sans limite |
| Organization Administrator | Projet, groupes, Namespace Class, contenu et politiques | Configuration de la fabric provider |
| Project Administrator | Exploitation courante du projet et du namespace | Politiques de toute l’organisation |
| Project User | Demande et exploitation du service WebShop | Contournement des choix d’image, stockage ou réseau |
Broadcom décrit l’organisation All Apps et son modèle d’administration dans Organization Management pour VCF 9.1. Les libellés de menus peuvent changer selon la langue ou le niveau de correctif ; le type d’organisation et les capacités affectées sont plus fiables qu’un texte vu sur une capture.
Construire les frontières dans le bon ordre
Commence par confirmer que acme-all-apps est une organisation All Apps et que region-paris lui est bien allouée. L’organisation doit exposer les projets, les namespaces et le contenu requis par VM Service. Si une capacité manque, arrête-toi à la frontière provider au lieu de compenser dans le Blueprint.
Crée prj-webshop-dev et affecte des groupes plutôt que des utilisateurs nominatifs durables. Un modèle minimal utilise un groupe de consommateurs et un groupe d’administrateurs. Il faudra ensuite tester avec un membre de chacun : l’écran d’un administrateur ne prouve pas qu’un Project User reçoit la bonne expérience.
La Namespace Class est le principal garde-fou. Elle combine les quotas avec les VM Classes, Storage Classes et contenus qu’un namespace peut consommer. Broadcom décrit son assistant dans Create a Namespace Class. Pour cette étude, commence avec une classe économique, une Storage Class et une image approuvée. Multiplier les choix avant la première demande fonctionnelle augmente le nombre de combinaisons en erreur sans prouver davantage de valeur.
Des valeurs comme 10 GHz de CPU, 10 GB de mémoire ou 100 GiB de stockage sont des hypothèses de design, pas des valeurs par défaut VCF ni des recommandations de sizing. Remplace-les par des limites dérivées de l’image, du besoin WebShop et de la capacité du projet. La vraie preuve est leur visibilité et leur application, pas leur similitude avec cet article.
Crée ou conserve ns-webshop-dev comme namespace partagé. Le prochain Blueprint le référencera avec existing: true ; supprimer un déploiement WebShop ne devra donc pas signifier supprimer ce namespace. Cette décision de propriété est essentielle, car le même namespace peut contenir des objets issus d’un autre catalogue.
Rendre réseau et contenu sélectionnables avant le code
Associe le namespace à vpc-webshop-dev et rends snet-web-front visible pour le projet. Note le CIDR du subnet, la source d’adresses et le propriétaire du DNS. Ne réserve pas une IP fixe pour accélérer une démo. L’article 3 vérifiera l’allocation puis la restitution de l’adresse par le chemin IPAM retenu.
La documentation VPC de VCF Automation fait autorité sur le parcours supporté. Un nom affiché dans l’interface ne suffit pas : le manifeste pourra demander un nom de ressource et un type comme Subnet ou SubnetSet. Conserve ce que la vue Services du build cible génère réellement.
Pour l’image, sélectionne une distribution Linux explicitement préparée pour VM Service, avec l’intégration invitée nécessaire et la capacité d’exécuter cloud-init. Si le contenu Canonical est disponible dans l’organisation, Broadcom documente le parcours dans Subscribe to a Canonical Content Library. La disponibilité, l’état de synchronisation et les identifiants restent propres au build et à l’environnement.
Ne copie pas le titre marketing « Ubuntu 24.04 » dans le Blueprint. Ouvre Services, génère ou inspecte le manifeste VM, puis relève le VirtualMachineImage.metadata.name exact. Applique la même discipline à la VM Class et à la Storage Class.
Figer un contrat de lab sans secret
Conserve les valeurs observées dans un petit contrat local. C’est de la documentation, pas un coffre-fort : aucun mot de passe, clé SSH privée ou jeton de compte technique ne doit y apparaître.
organization: acme-all-apps
project: prj-webshop-dev
region: region-paris
namespace: ns-webshop-dev
vpc: vpc-webshop-dev
subnet: snet-web-front
dnsDomain: corp.example
vmClass: <VM_CLASS_OBSERVEE>
guaranteedVmClass: <VM_CLASS_GARANTIE_OBSERVEE>
vmImage: <NOM_VIRTUAL_MACHINE_IMAGE_OBSERVE>
storageClass: <STORAGE_CLASS_OBSERVEE>
application: webshop
environment: dev
owner: team-platform
costCenter: cc-042Les chevrons sont des emplacements éditoriaux volontaires. Ils ne doivent jamais être présentés comme des valeurs ayant fonctionné. Lorsque la plateforme sera accessible, remplace-les localement, valide la demande et ne publie que des identifiants anonymisés si les vrais noms révèlent la topologie interne.
Utiliser un gate de préparation
Le socle autorise le passage à l’article 2 seulement si les sept points suivants sont vrais :
- le type d’organisation et le build VCF Automation exact sont enregistrés ;
- le Project User accède à
prj-webshop-dev; ns-webshop-devexiste et expose VM Service ;- le VPC et le subnet attendu sont visibles depuis ce namespace ;
- la VM Class, l’image et la Storage Class sont sélectionnables ;
- le contrat de l’image annonce cloud-init, qui sera testé plus tard ;
- aucun secret n’apparaît dans l’inventaire ni dans les futures variables du Blueprint.
Capture un écran ou une réponse API par point. Une unique page de déploiement verte ne prouverait ni la bonne identité, ni les quotas, ni la propriété lors de la suppression.
Pièges & points de vigilance
Ne transforme pas les décisions plateforme en inputs
Permettre au demandeur de saisir un identifiant d’image, une Storage Class ou un subnet simplifie la première démo, mais déplace la gouvernance dans la couche la moins contrôlée. Garde ces références comme variables appartenant à la plateforme et n’expose qu’une intention métier, par exemple le rôle de la VM.
Ne confonds pas non plus le fournisseur LDAP de l’organisation avec l’adhésion de la machine au domaine. Le premier authentifie des personnes. Le compte ordinateur et la jonction effective du système invité constituent deux opérations de cycle de vie distinctes, traitées plus loin dans la série.
Enfin, le rollback ne doit pas détruire les ressources provider. Retire une association projet ou namespace seulement après avoir vérifié la propriété. Région, VPC et contenus partagés peuvent servir d’autres tenants ; leur comportement exact de détachement et de suppression devra être vérifié sur la plateforme cible.
Conclusion
Le premier artefact utile de cette série n’est pas une VM. C’est un contrat court et révisable qui montre ce que la plateforme autorise WebShop à consommer et qui possède chaque frontière. Dès que tous les identifiants viennent du service réel plutôt que d’un article, le premier Blueprint devient une expérience contrôlée au lieu d’un pari syntaxique.
Gouverner avant
Projet, namespace et classe définissent l’enveloppe du service avant l’arrivée du YAML.
Observer les noms
Classe, image, stockage et réseau viennent du build cible, jamais d’un exemple copié.
Prouver la préparation
Sept contrôles explicites ouvrent le passage vers la VM minimale de l’article 2.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
