Cloud Assembly supports integration with Puppet Enterprise configuration management.
When you add Puppet Enterprise to Cloud Assembly as an external system, by default it is available on all projects. You can restrict it to specific projects.
To add a Puppet Enterprise integration, you must have the Puppet master name and the hostname or IP address of the master.
You can find Puppet logs at the following location in case you need to check them for errors or information purposes.
| Description | Log Location |
|---|---|
| Log for create and install related events | Logs are on the deployed machine at `~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ | head -1)/`. Refer to the log.txt file for full logs. For detailed Puppet agent logs, refer to https://puppet.com/docs/puppet/4.8/services_agent_unix.html#logging |
| Log for Puppet delete and run related tasks | Logs are on the PE at `~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ | head -1)/`. Refer to the log.txt file for full logs. |
Procedure
Results
What to do next
Add Puppet components to the desired cloud templates.
- Under Cloud Templates in Cloud Assembly, select Puppet under the Content Management heading on the cloud template menu and drag the Puppet component to the canvas.
- Enter Puppet Properties on the pane to the right.
Property Description Master Enter the name of the Puppet primary machine used with this cloud template. Environment Select the environment for the Puppet primary machine. Role Select the Puppet role to be used with this cloud template. Agent Run Interval The frequency at which you want the Puppet agent to poll the Puppet primary machine for configuration details to be applied to deployed virtual machines related to this cloud template. - Click the Code tab on the right pane to view the YAML code for the Puppet configuration properties.
When you add a Puppet component to a cloud template, you can add the installMaster property to the YAML file to point to a Puppet install master, also known as a compile master. The value of this property can be the IP address or the hostname of the Puppet compile master. Using this property provides access to enhanced capabilities for deployed Puppet virtual machines and also supports additional day two actions.
Puppet_Agent:
type: Cloud.Puppet
properties:
account: PEIntegrationAccount
environment: production
role: 'role::linux_webserver'
host: '${CentOS-Puppet.*}'
username: root
password: password123!
installMaster: my-pe-compile-master.example.com
agentConfiguration:
certName: '${CentOS-Puppet.address}'
osType: linux
count: 1
In some cases, vRealize Automation passes some machine related information to Puppet virtual machines as facts by default. Custom facts are not supported for Windows machines. On Linux machines some information is passed by default, and users can pass additional information using custom properties.
There are some limitations on what is passed to Puppet machines under Linux. Custom properties on host resources and on the Puppet agent are passed to Puppet virtual machines. Custom properties on network resources are not passed to the virtual machine. Items passed include simple properties, boolean properties as well as custom named and complex types such as nested maps with arrays.
The following example shows how various custom resources can be called on host resources:
resources:
Puppet-Host:
type: Cloud.AWS.EC2.Instance
properties:
customer_specified_property_on_ec2_resource: "property"
customer_specified_property_on_network_resource_that_should_also_be_a_fact_and_is_boolean: true
CustomerNameStuff: "zone A"
try_map:
key: value
keytwo: value
nested_array:
- one
- two
- true
try_array:
- one
- two
-three:
inner_key: value
If a Puppet purge command results in errors, in most cases, vRealize Automation will ignore purge errors for nodes and proceed with deletion of the node. Even if a certificate is not found for a specific node, vRealize Automation will proceed with deletion. If vRealize Automation cannot proceed with the node deletion for some reason, you can click Delete on the Deployments page Actions menu to open a dialog that will enable you to proceed with the node deletion. A similar workflow is executed when you remove a Puppet integration from a cloud template and then apply the template to the deployment. This workflow triggers a node purge operation that is handled as described above.
Integration with Puppet Enterprise requires a public IP address. If there is no public IP address configured for the Puppet Enterprise machine, the IP address of the first NIC is used.
If the NIC of a Puppet provisioned machine running on a vSphere machine has multiple IP addresses, you can use the primaryAddress YAML property in cloud templates to specify which IP address to use for connections. When the primaryAddress property is assigned to a NIC, then the IP address of this NIC is used by Puppet. Only one NIC can be designated as primary. See the following YAML snippet for an example of how the primaryAddress property is used.
BaseVM:
type: Cloud.vSphere.Machine
properties:
image: photon
count: 2
customizationSpec: Linux
cpuCount: 1
totalMemoryMB: 1024
networks:
- network: '${resource.dev.id}'
deviceIndex: 0
primaryAddress: true
assignment: static
- network: '${resource.prod.id}'
deviceIndex: 1
assignment: static
If the primaryAddress property is not set for any virtual machine NIC, the cloud template logic will default to the current behavior for IP address selection.
