To set up an integration between your Puppet Enterprise (PE) instance and Continuous Delivery for PE, you must first set up a dedicated PE user with appropriate permissions, then add your PE instance's credentials to Continuous Delivery for PE.
- You must enable Code Manager on the PE instance before integrating with Continuous Delivery for PE. For instructions, see Configuring Code Manager.
- The Puppet master certificate must have
dns_alt_namesconfigured. To confirm whether your certificate is configured correctly, run:
If no output is returned, the master certificate must be regenerated before PE is integrated with Continuous Delivery for PE. For instructions, see Regenerate master certificates in the PE documentation.
openssl x509 -in $(puppet config print hostcert) -text |grep -A 1 "Subject Alternative Name"
Create a Continuous Delivery user and user role in PE
Create a "Continuous Delivery" user and user role in PE. This allows you to view a centralized log of the activities Continuous Delivery for PE performs on your behalf. You'll also use this user account when generating the PE authentication token required by the setup process.
- To begin, create a new user. In the PE console, click > .
- Enter a full name (such as Continuous Delivery User) and a login name (such as cdpe_user) and click Add local user.
- Next, create a user role containing the permissions the Continuous Delivery User needs when operating Continuous Delivery for PE. In the PE console, click > .
- Enter a name and (optional) description for new role, such as CDPE User Role, then click Add role.
- Select the user role you've just created from the list on the User roles page.
Click Permissions. Assign the following permissions to the user
Type Permission Object Job orchestrator Start, stop, and view jobs - Node groups Create, edit, and delete child groups All Node groups View All Node groups Edit configuration data All Node groups Set environment All Nodes View node data from PuppetDB - Puppet agent Run Puppet on agent nodes - Puppet environment Deploy code All Puppet Server Compile catalogs for remote nodes - Tasks Run tasks At a minimum,
cd4pe_jobs::run_cd4pe_job, which is required when running job hardware using a Puppet agent.
- Once all the permissions have been added, click Commit changes.
- Add your Continuous Delivery user to the user role. Click Member users. Select the name of the user you created earlier, and click Add user, then commit your change.
Your user is now set up and has been given the permissions needed to operate Continuous Delivery for PE. Before proceeding, create a password for the Continuous
- Return to the Users page.
- Find and click the full name of your newly created user, then click Generate password reset.
- Follow the link created and create a password for the user. You'll use this password when adding your PE credentials to Continuous Delivery for PE.
Add your Puppet Enterprise credentials
Establishing an integration with your Puppet Enterprise (PE) instance allows Continuous Delivery for PE to work with PE tools such as Code Manager and the orchestrator service to deploy Puppet code changes to your nodes.
- In the Continuous Delivery for PE web UI, click Settings.
- Click Puppet Enterprise. Click + Add new credentials.
In the New Puppet Enterprise credentials pane, enter a
unique friendly name for your Puppet Enterprise
If you need to work with multiple PE installations within Continuous Delivery for PE, these friendly names help you to differentiate which installation's resources you're managing, so choose them carefully.
Enter the fully qualified domain name (FQDN) you use to access the PE console (such as
sample.pe.instance). The FQDN must match the certname of your PE primary server or an alias included in the
dns_alt_namesentry in your
Select Basic authorization or API
token and enter the required information:
For Basic authorization, enter the username and password for your "Continuous Delivery" user. Continuous Delivery for PE uses this information to generate an API token for you. The username and password are not saved. Optionally, change the token's lifetime by clicking Change.
For API token, generate a PE access token for your "Continuous Delivery" user using
puppet-accessor the RBAC v1 API, and paste it into the API token field.
For instructions on generating an access token, see Token-based authentication.Tip: To avoid unintended service interruptions, create an access token with a multi-year lifespan.
Click Save changes.
Continuous Delivery for PE uses the information you provide to look up the endpoints for PuppetDB, Code Manager, orchestrator, and node classifier, and to access the primary SSL certificate generated during PE installation. Once your credentials are successfully added, click Edit credentials to view this information.
Your PE instance is now integrated with Continuous Delivery for PE.
To enable impact analysis for this instance, see Configure impact analysis.
Create environment node groups
In order for code deployments managed by Continuous Delivery for PE to work correctly, your environment node groups should be set up in a specific hierarchy.
Continuous Delivery for PE deploys changes to environment node groups. By setting up environment node groups, you define the groups of nodes that you can choose to deploy changes to.
- In the PE console, click Node groups (or Classification in PE versions prior to 2019.8.1).
If your node classification does not already include an All Environments node
group, create one.
Note: The All Environments node group is added automatically in new installations of PE version 2018.1.5 and newer. If you're running an older version or have upgraded your PE instance, you must create this node group yourself.Click Add group... and create a new node group with the following specifications:
Parent name: All Nodes
Group name: All Environments
Environment group: yes
Description: Environment group parent and default
Open the All Environments node group and add a new rule:
- Edit the Agent-specified environment node group so that All Environments is its parent. This group should have no rules, and won't match any nodes.
- Edit the Production environment node group so that All Environments is its parent. If necessary, modify its rules so that it matches only the correct nodes.
For each of your environment groups (such as testing, staging, and production),
create an environment node group.
- Create a Git branch to represent the environment.
puppet code deploy <ENVIRONMENT_NAME>.
Create a new environment node group with the following
Parent name: All Environments
Group name: <ENVIRONMENT_NAME>
Environment group: Yes
Associate the relevant nodes with the environment group by creating
rules or pinning nodes.
Best practices for associating nodes with environment node groups:
pp_environmenttrusted fact, or a similar custom fact, to define which environment each node belongs to. Write a rule in each environment group that uses
pp_environmentor your custom fact to match nodes.
See if other facts or trusted facts can be used to create rules that match nodes to one and only one environment group
If trusted facts, custom facts, or other facts cannot be used to determine node environments, use pinning. Pin each node to only one environment group.
- Specify the Git branch corresponding to the environment.
For each of your newly created environment groups, create a child environment
group. Nodes from the parent environment group are allowed to drop into this
exception group to test code from Git feature
branches. Give each child environment group the following specifications:
Parent name: All <ENVIRONMENT>
Group name: <ENVIRONMENT> one-time run exception
Environment group: Yes
Description: Allow <ENVIRONMENT> nodes to request a different Puppet environment for a one-time run
Once the child environment node group is set up, give it the rule
(agent_specified_environment ~ .+). Do not pin any nodes to this node group.
The resulting environment node groups has a format similar to this:
Now that your environment nodes groups are configured, we can deploy new code to your nodes.