Vous pouvez ajouter une section cloudConfig au code de modèle de cloud Cloud Assembly, où vous ajoutez des commandes d'initialisation de machine qui s'exécutent au moment du déploiement.
Formats de commande cloudConfig
- Linux : les commandes d'initialisation suivent la norme cloud-init ouverte.
- Windows : les commandes d'initialisation utilisent Cloudbase-init.
Les commandes cloud-init de Linux et Cloudbase-init de Windows ne partagent pas la même syntaxe. Une section cloudConfig pour l'un des systèmes d'exploitation ne fonctionnera pas dans une image de machine de l'autre système d'exploitation.
Possibilités des commandes cloudConfig
Les commandes d'initialisation vous permettent d'automatiser l'application des données ou des paramètres au moment de la création de l'instance, ce qui peut personnaliser les utilisateurs, les autorisations, les installations ou toute autre opération basée sur une commande. Les exemples incluent notamment :
- Définition d'un nom d'hôte
- Génération et configuration de clés privées SSH
- Installation des modules
Où les commandes cloudConfig peuvent-elles être ajoutées
Vous pouvez ajouter une section cloudConfig au code de modèle de cloud, mais vous pouvez également en ajouter une à une image de machine à l'avance, lors de la configuration de l'infrastructure. Ensuite, tous les modèles de cloud qui font référence à l'image source obtiennent la même initialisation.
Vous pouvez disposer d'un mappage d'image et d'un modèle de cloud contenant tous deux des commandes d'initialisation. Au moment du déploiement, les commandes fusionnent et Cloud Assembly exécute les commandes ainsi regroupées.
Lorsque la même commande figure dans les deux emplacements mais inclut des paramètres différents, seule la commande du mappage d'image est exécutée.
Consultez En savoir plus sur les mappages d'image dans vRealize Automation pour plus d'informations.
Syntaxe dans les commandes cloudConfig
Les commandes cloudConfig défectueuses peuvent entraîner une ressource qui n'est pas correctement configurée ou qui se comporte de manière imprévisible.
Pour annuler un déploiement en cas d'erreur de syntaxe dans les instructions #cloud-config, ajoutez la propriété suivante.
cloudConfigSettings:
deploymentFailOnCloudConfigRuntimeError: true
Dans le modèle de cloud suivant, la commande - mkdir n'est pas sur une nouvelle ligne sous runcmd: comme requis. Par conséquent, le répertoire ne sera jamais créé. La propriété deploymentFailOnCloudConfigRuntimeError: true fait échouer le déploiement en raison de l'erreur.
formatVersion: 1
inputs: {}
resources:
Cloud_vSphere_Machine_1:
type: Cloud.vSphere.Machine
properties:
image: img1
cpuCount: 1
totalMemoryMB: 1024
cloudConfigSettings:
deploymentFailOnCloudConfigRuntimeError: true
cloudConfig: |
#cloud-config
runcmd:- mkdir -p /tmp/test-dir
Si vous omettez la propriété ou si vous la définissez sur false, le déploiement se poursuit même si les commandes cloudConfig échouent.
En outre, la propriété requiert la ligne #cloud-config. Si vous omettez la ligne, le déploiement se poursuit quel que soit le paramètre de propriété.
Correct :
cloudConfigSettings:
deploymentFailOnCloudConfigRuntimeError: true
cloudConfig: |
#cloud-config
runcmd:- mkdir -p /tmp/test-dir
Incorrect :
cloudConfigSettings:
deploymentFailOnCloudConfigRuntimeError: true
cloudConfig: |
runcmd:- mkdir -p /tmp/test-dir
Exemples de commandes cloudConfig
L'exemple de section cloudConfig suivant est extrait du code de modèle de cloud du cas d'utilisation de WordPress pour le serveur MySQL basé sur le système d'exploitation Linux.
Pour garantir une interprétation correcte des commandes, incluez toujours le caractère cloudConfig: | (barre verticale) comme indiqué.
cloudConfig: |
#cloud-config
repo_update: true
repo_upgrade: all
packages:
- apache2
- php
- php-mysql
- libapache2-mod-php
- php-mcrypt
- mysql-client
runcmd:
- mkdir -p /var/www/html/mywordpresssite && cd /var/www/html && wget https://wordpress.org/latest.tar.gz && tar -xzf /var/www/html/latest.tar.gz -C /var/www/html/mywordpresssite --strip-components 1
- i=0; while [ $i -le 5 ]; do mysql --connect-timeout=3 -h ${DBTier.networks[0].address} -u root -pmysqlpassword -e "SHOW STATUS;" && break || sleep 15; i=$((i+1)); done
- mysql -u root -pmysqlpassword -h ${DBTier.networks[0].address} -e "create database wordpress_blog;"
- mv /var/www/html/mywordpresssite/wp-config-sample.php /var/www/html/mywordpresssite/wp-config.php
- sed -i -e s/"define( 'DB_NAME', 'database_name_here' );"/"define( 'DB_NAME', 'wordpress_blog' );"/ /var/www/html/mywordpresssite/wp-config.php && sed -i -e s/"define( 'DB_USER', 'username_here' );"/"define( 'DB_USER', 'root' );"/ /var/www/html/mywordpresssite/wp-config.php && sed -i -e s/"define( 'DB_PASSWORD', 'password_here' );"/"define( 'DB_PASSWORD', 'mysqlpassword' );"/ /var/www/html/mywordpresssite/wp-config.php && sed -i -e s/"define( 'DB_HOST', 'localhost' );"/"define( 'DB_HOST', '${DBTier.networks[0].address}' );"/ /var/www/html/mywordpresssite/wp-config.php
- service apache2 reload
Si un script cloud-init se comporte de manière inattendue, vérifiez la sortie de la console capturée dans /var/log/cloud-init-output.log lors du dépannage. Pour plus d'informations sur cloud-init, reportez-vous à la documentation cloud-init.
Les commandes et les spécifications de personnalisation peuvent ne pas mélanger
Lors d'un déploiement sur vSphere, procédez avec prudence si vous tentez de combiner une commande intégrée cloudConfig et l'initialisation de spécification de personnalisation. Ils ne sont pas officiellement compatibles et peuvent produire des résultats incohérents ou indésirables lorsqu'ils sont utilisés ensemble.
Pour obtenir un exemple de l'interaction entre les commandes et les spécifications de personnalisation, consultez Adresses IP statiques vSphere dans Cloud Assembly.
