Configure Puppet Enterprise integration in Automation Assembler

Automation Assembler supports integration with Puppet Enterprise configuration management.

When you add Puppet Enterprise to Automation Assembler 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

Select Infrastructure > Connections > Integrations and click Add Integration.
Select Puppet.
Enter the required information on the Puppet configuration page.
For Puppet integration to work properly, the provided credentials must be valid for both the SSH and the API account. Also, the specified OS and application user accounts must have the same username and password.
If you need a cloud proxy, click NEW CLOUD PROXY and enter the required information. Typically, a cloud proxy is required only if you are using vSphere. See Add a cloud proxy to a vCenter in Automation Assembler.
Click Validate to check the integration.
Click Add.

Results

Puppet is available for use with cloud templates.

What to do next

Add Puppet components to the desired cloud templates.

On the Automation Assembler, Design tab 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

Note: Though the user defined here is root, the cloud template can be configured with any user that is included in the sudoers list.

In some cases, VMware Aria 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, VMware Aria 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, VMware Aria Automation will proceed with deletion. If VMware Aria 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.

If you want to set up Puppet integration for a non-root user with Sudo privileges, that user should be enabled to run the following commands.

The user should be enabled to create a new Puppet facts directory and file:

sudo mkdir -p /etc/puppetlabs/facter/facts.d 
       sudo tee /etc/puppetlabs/facter/facts.d/puppet_cloudassembly_facts.json

The user should be enabled to run Puppet:

sudo /opt/puppetlabs/bin/puppet resource service puppet ensure=stopped
       sudo /opt/puppetlabs/bin/puppet agent --test --color=false --detailed-exitcode

The user should be enabled to delete Certificate Signing Request(CSR) files, including the csr_attributes.yaml and CSR pem:
```
 sudo rm /etc/puppetlabs/puppet/csr_attributes.yaml
       sudo rm -f /etc/puppetlabs/puppet/ssl/certificate_requests/*
```