Sommaire
Une VM sous tension n’est pas encore un service livré. Elle peut exister dans vCenter alors que son interface n’a pas d’adresse exploitable, que sa route par défaut est incorrecte ou que cloud-init attend toujours un dépôt de paquets. Dans ce troisième incrément WebShop, le succès signifie que le demandeur déploie la VM, que la plateforme sait justifier son adresse IP et que l’exploitant obtient une réponse de santé sans ambiguïté.
Nous allons prolonger le Blueprint All Apps minimal de l’article précédent sans transformer les décisions d’infrastructure en champs de formulaire. Le lecteur choisit un rôle et fournit une clé SSH publique ; l’équipe plateforme garde la maîtrise du namespace, de l’image, de la VM Class, de la Storage Class, du subnet et du domaine DNS.
Un design documenté, pas un résultat de lab
Cet article assemble la documentation Broadcom de VCF Automation 9.1 sur les Blueprints, VM Service et IP Management dans un parcours concret. Il n’a pas été exécuté sur un lab. Chaque valeur d’écran, version d’API VM Operator, adresse IP, enregistrement DNS et réponse /healthz décrits ci-dessous constituent une preuve à collecter, jamais une observation déjà réalisée.
TL;DR
- Prouve d’abord le chemin réseau par défaut, puis ajoute la référence explicite
SubnetouSubnetSetcopiée depuis Services ; ne devine ni le nom ni le type. - Traite création de la VM, allocation de l’IP et bootstrap du guest comme trois contrôles distincts, sans oublier la restitution de l’adresse après suppression.
- Garde cloud-init court, idempotent et sans secret. La dépendance à un dépôt de paquets accessible est une contrainte du lab, pas une stratégie d’image de production.
Partir du manifeste généré par Services
Les exemples de Blueprints All Apps montrent formatVersion: 2, CCI.Supervisor.Namespace, CCI.Supervisor.Resource et un manifeste VM Operator. Ces exemples forment la base éditoriale de la série, mais le Supervisor cible reste l’autorité à l’exécution.
Avant de modifier le Blueprint, ouvre Services, prépare une VM avec l’image, la classe, le stockage et le réseau publiés dans ns-webshop-dev, puis inspecte le YAML généré. Relève exactement l’apiVersion, la hiérarchie des champs, la VM Class, l’identifiant de l’image, la Storage Class, le nom de l’objet réseau et son type. L’exemple publié peut utiliser vmoperator.vmware.com/v1alpha3 alors qu’un autre build 9.1 sert une version ultérieure. Changer uniquement la chaîne d’API n’est pas une migration : si le schéma généré diffère, adapte le manifeste complet.
Cette séparation aide directement au diagnostic. VCF Automation pilote le déploiement, VM Operator réconcilie la ressource VirtualMachine, le réseau VPC et l’IPAM fournissent la connectivité, puis cloud-init agit dans le système invité. Un échec HTTP ne prouve donc pas un défaut IPAM, et une adresse allouée ne prouve pas que cloud-init a terminé.
Ne conserve que deux entrées côté demandeur :
vmRole, encadré par la convention de nommage ;sshPublicKey, qui doit être une clé publique et jamais une clé privée.
Place les identifiants de plateforme dans des variables du Blueprint maintenues par revue de code. Le consommateur ne peut ainsi ni choisir un subnet non gouverné ni saisir une image que le namespace n’est pas autorisé à utiliser.
Passer du réseau par défaut au subnet explicite
Commence par un déploiement de diagnostic qui omet spec.network.interfaces. VM Operator peut alors raccorder l’interface au réseau par défaut du namespace. Ce test volontairement limité indique si l’image, le stockage, la classe et le bootstrap fonctionnent avant l’introduction d’une référence réseau explicite.
Une fois ce socle validé, ajoute le bloc généré pour l’environnement cible. L’extrait suivant représente le design WebShop ; les valeurs entre chevrons doivent être remplacées par les observations réalisées dans Services.
variables:
subnetName: <NOM_RESEAU_OBSERVE>
networkKind: <SUBNET_OU_SUBNETSET_OBSERVE>
dnsDomain: corp.example
resources:
webVm:
type: CCI.Supervisor.Resource
properties:
context: ${resource.namespace.id}
manifest:
apiVersion: vmoperator.vmware.com/v1alpha3
kind: VirtualMachine
metadata:
name: ${variable.vmResourceName}
spec:
className: ${variable.vmClassName}
imageName: ${variable.vmImageName}
storageClass: ${variable.storageClassName}
network:
hostName: ${variable.vmResourceName}
domainName: ${variable.dnsDomain}
interfaces:
- name: eth0
network:
name: ${variable.subnetName}
kind: ${variable.networkKind}
La KB Broadcom 426105 illustre le modèle de sélection explicite d’un réseau VPC. Le détail décisif est que network référence un objet ; ce champ ne sert pas à inventer une adresse IP. Confirme si le service expose un Subnet ou un SubnetSet et respecte la casse. Si le déploiement ne résout pas la référence, retourne au manifeste généré au lieu d’ajouter une adresse en dur.
La valeur du domaine mérite elle aussi une vérification. Renseigner domainName dans la spécification de VM ne prouve pas, à lui seul, qu’un enregistrement existe dans le DNS faisant autorité. L’IPAM natif et l’automatisation DNS sont des services liés, mais ils ne constituent pas le même résultat. Fais de l’enregistrement DNS un critère d’acceptation distinct lorsque la plateforme cible est configurée pour le fournir.
Rendre l’IPAM natif mesurable
VCF Automation 9.1 expose blocs d’adresses, quotas et allocations dans IP Management. Avant le déploiement, documente le bloc qui alimente le VPC, ses plages utiles et ses exclusions, le quota accordé à l’organisation ou au VPC, ainsi que la capacité disponible. Ne copie pas un CIDR d’exemple dans le lab : une plage privée locale au VPC, une plage Private-TGW et une plage externe n’ont pas le même contrat de routage.
Exécute le contrôle d’allocation sous la forme avant/pendant/après :
- Capture le bloc, le quota et la capacité libre avant la demande.
- Déploie une VM WebShop et attends que la ressource expose son IPv4 principal.
- Corrèle cette adresse avec l’allocation présentée dans IP Management, puis avec
ip addressdans le guest. - Vérifie la passerelle et la route avec
ip route; une adresse seule ne garantit aucune connectivité utile. - Supprime le déploiement, attends la réconciliation et prouve que l’adresse a été libérée.
La cinquième étape compte autant que la seconde. Un lab qui crée et détruit régulièrement des workloads peut sembler sain tout en épuisant lentement une plage avec des allocations orphelines.
Infoblox constitue un second chemin facultatif
N’ajoute Infoblox qu’après avoir compris l’allocation et la libération natives. Dans l’intégration DDI documentée pour VCF Networking 9.1, le provider doit configurer la connectivité, les certificats et les blocs concernés ; Infoblox reste la source de vérité. Si ce chemin est activé, corrèle la même adresse et le FQDN attendu dans Infoblox. Ne laisse jamais entendre qu’il existe dans un environnement où l’intégration n’est pas configurée.
Broadcom présente cette capacité dans VCF Networking 9.1 — Seamless DDI Integration with Infoblox. Cette publication soutient le concept d’intégration ; toute future capture doit néanmoins provenir d’un lab autorisé et anonymisé.
Garder cloud-init court, idempotent et observable
Le bootstrap suivant est une reconstitution WebShop, pas une application publiée par Broadcom. Il installe Nginx avec apt-get ou dnf, détecte la racine statique réellement déclarée par Nginx, crée un endpoint de santé, écrit un journal horodaté et dépose un marqueur de fin. Ce marqueur rend une relance accidentelle inoffensive, mais cloud-init reste un mécanisme de premier démarrage. En production, les paquets communs devraient généralement être intégrés à l’image et les évolutions continues confiées à un outil de gestion de configuration.
bootstrap:
cloudInit:
sshAuthorizedKeys:
- ${input.sshPublicKey}
cloudConfig:
write_files:
- path: /usr/local/sbin/webshop-bootstrap.sh
owner: root:root
permissions: '0750'
content: |
#!/bin/sh
set -eu
state_dir=/var/lib/vcf-webshop
[ -f "$state_dir/bootstrap.done" ] && exit 0
mkdir -p "$state_dir"
if ! command -v nginx >/dev/null 2>&1; then
if command -v apt-get >/dev/null 2>&1; then
DEBIAN_FRONTEND=noninteractive apt-get update
DEBIAN_FRONTEND=noninteractive apt-get install -y nginx
elif command -v dnf >/dev/null 2>&1; then
dnf install -y nginx
else
echo "No supported package manager found" >&2
exit 1
fi
fi
web_root="$(nginx -T 2>&1 | awk '/^[[:space:]]*root[[:space:]]+/ {gsub(/;/, "", $2); print $2; exit}')"
case "$web_root" in
""|*\$*) echo "Unable to determine a static Nginx document root" >&2; exit 1 ;;
esac
mkdir -p "$web_root"
printf 'ok\n' > "$web_root/healthz"
systemctl enable --now nginx
date -Is > /var/log/vcf-lab-bootstrap.log
touch "$state_dir/bootstrap.done"
runcmd:
- [sh, /usr/local/sbin/webshop-bootstrap.sh]
La forme bootstrap.cloudInit, ses clés et le sélecteur de Secret sont décrits par la documentation VM Operator sur la personnalisation cloud-init et le contrat API v1alpha3. Le manifeste généré par le Supervisor cible reste prioritaire si une version ultérieure est servie.
Ce contrat suppose une image avec cloud-init et VMware Tools, un DNS fonctionnel, une heure correcte et un accès sortant au dépôt de paquets. Si l’une de ces hypothèses est volontairement absente, intègre Nginx à l’image ou utilise un dépôt interne. N’affaiblis pas les règles de sécurité réseau pour obtenir une démonstration verte.
Pour une configuration plus longue, VM Operator accepte aussi une référence rawCloudConfig vers une clé d’un Secret Kubernetes existant. La référence permet de sortir le document volumineux du Blueprint, mais base64 n’est pas un chiffrement. Cet article n’affirme pas non plus que VCF Secret Store crée automatiquement le Secret exact consommé par VM Operator. Valide ce raccord sur la plateforme cible, applique le moindre privilège et la rotation, puis veille à ne jamais afficher le contenu résolu dans les outputs.
Prouver la chaîne complète
Collecte les preuves par couche et conserve les identifiants nécessaires à leur corrélation par un autre exploitant.
| Couche | Preuve à capturer | Panne typique à rechercher |
|---|---|---|
| Provisioning | état du déploiement, objet VM et condition réconciliée | classe, image ou Storage Class indisponible |
| Réseau/IPAM | objet réseau exact, IPv4, route, allocation puis libération | mauvais type, quota épuisé ou plage inutilisable |
| Guest | fin de cloud-init et horodatage du journal de bootstrap | image inadaptée, erreur de dépôt ou de DNS |
| Service | requête HTTP vers /healthz répondant ok |
Nginx absent, firewall ou chemin réseau incorrect |
Dans le guest, adapte les commandes à la distribution choisie. Une séquence Linux raisonnable comprend cloud-init status –wait, ip address, ip route, l’inspection de /var/log/cloud-init-output.log et curl http://127.0.0.1/healthz. Depuis un client autorisé sur le bon chemin réseau, répète ensuite la requête HTTP vers l’adresse allouée. Le test local prouve le service ; le test distant prouve en plus sa joignabilité.
Après suppression, capture l’absence de l’objet VM et la capacité IP restituée. Si l’automatisation DNS est activée, vérifie que l’enregistrement associé est retiré conformément à sa politique. Ces observations transforment une démonstration de catalogue séduisante en vrai test du cycle de vie.
Pièges & points de vigilance
Ne diagnostique pas chaque panne dans cloud-init
Une VM qui attend encore sa création est plus probablement bloquée par la classe, l’image, le stockage ou la politique réseau. Une VM adressée mais sans endpoint oriente vers le guest, l’accès au dépôt ou la configuration du service. Repars de la première couche dépourvue de preuve, puis avance dans l’ordre.
- Ne remplace pas
v1alpha3par une chaîne plus récente sans comparer le schéma généré complet. - N’expose pas subnet, image, classe ou stockage comme entrées libres du demandeur.
- Ne code pas une adresse en dur pour cacher une référence réseau non résolue ou un quota épuisé.
- Ne confonds pas allocation IP et preuve DNS ; vérifie séparément l’enregistrement faisant autorité.
- Ne publie pas un résultat attendu comme une observation. Une capture reste annoncée comme future tant qu’elle n’a pas été produite sur le lab.
Conclusion
Le Blueprint WebShop décrit maintenant davantage qu’une VM : il sélectionne un réseau gouverné, délègue le choix de l’adresse à l’IPAM, configure le guest et expose un endpoint observable. Sa robustesse vient de la séparation de ces responsabilités et de l’exigence d’une preuve pour chacune.
Dans le prochain article, cette VM saine produira des événements de cycle de vie à destination des systèmes d’entreprise. Event Broker et VCF Operations Orchestrator réconcilieront un compte ordinateur Active Directory et un enregistrement CMDB transitoire sans rendre ces systèmes externes bloquants pour le provisioning.
Réseau
Copie le nom et le type depuis Services ; le Blueprint n’invente jamais une adresse.
IPAM
Prouve allocation et libération en corrélant la même IP entre plateforme et guest.
Guest
Garde le premier démarrage court, idempotent, sans secret et observable séparément.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.



