You can add a cloudConfig section to Automation Assembler template code, in which you add machine initialization commands that run at deployment time.

cloudConfig command formats

  • Linux—initialization commands follow the open cloud-init standard.
  • Windows—initialization commands use Cloudbase-init.

Linux cloud-init and Windows Cloudbase-init don't share the same syntax. A cloudConfig section for one operating system won't work in a machine image of the other operating system.

What cloudConfig commands can do

You use initialization commands to automate the application of data or settings at instance creation time, which can customize users, permissions, installations, or any other command-based operations. Examples include:

  • Setting a hostname
  • Generating and setting up SSH private keys
  • Installing packages

Where cloudConfig commands can be added

You can add a cloudConfig section to cloud template code, but you can also add one to a machine image in advance, when configuring infrastructure. Then, all cloud templates that reference the source image get the same initialization.

You might have an image map and a cloud template where both contain initialization commands. At deployment time, the commands merge, and Automation Assembler runs the consolidated commands.

When the same command appears in both places but includes different parameters, only the image map command is run.

See Learn more about image mappings in VMware Aria Automation for additional details.

Syntax in cloudConfig commands

Faulty cloudConfig commands can result in a resource that isn't correctly configured or behaves unpredictably.

To cancel a deployment when there is a syntax error in #cloud-config statements, add the following property.

      cloudConfigSettings:
        deploymentFailOnCloudConfigRuntimeError: true

In the following cloud template, the - mkdir command isn't on a new line under runcmd: as required, so the directory will never be created. The deploymentFailOnCloudConfigRuntimeError: true property fails the deployment because of the error.

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

If you omit the property or set it to false, deployment continues even if cloudConfig commands fail.

In addition, the property requires the #cloud-config line. If you omit the line, deployment continues regardless of the property setting.

Correct:

      cloudConfigSettings:
        deploymentFailOnCloudConfigRuntimeError: true
      cloudConfig: |
        #cloud-config
        runcmd:- mkdir -p /tmp/test-dir

Incorrect:

      cloudConfigSettings:
        deploymentFailOnCloudConfigRuntimeError: true
      cloudConfig: |
        runcmd:- mkdir -p /tmp/test-dir

Example cloudConfig commands

The following example cloudConfig section is taken from the WordPress use case cloud template code for the Linux-based MySQL server.

Note:

To ensure correct interpretation of commands, always include the pipe character cloudConfig: | as shown.

      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

If a cloud-init script behaves unexpectedly, check the captured console output in /var/log/cloud-init-output.log when troubleshooting. For more about cloud-init, see the cloud-init documentation.

Commands and customization specifications might not mix

When deploying to vSphere, proceed carefully if you attempt to combine embedded cloudConfig command and customization specification initialization. They aren't formally compatible and might produce inconsistent or unwanted results when used together.

For an example of how commands and customization specifications interact, see vSphere static IP addresses in Automation Assembler.