Troubleshooting Continuous Delivery for PE

Use this guidance to troubleshoot issues you might encounter with your Continuous Delivery for Puppet Enterprise (PE) installation.

Important: If your PE instance has a replica configured for disaster recovery, Continuous Delivery for PE is not available if a partial failover occurs. Learn more at What happens during failovers in the PE documentation. To restore Continuous Delivery for PE functionality, you must promote the replica to primary server.

Look up a source control webhook

Continuous Delivery for PE creates a webhook and attempts to automatically deliver it to your source control system when you add a new control repo or module to your workspace. You can look up this webhook if you ever need to manually add (or re-add) it to your source control repository.

In the Continuous Delivery for PE web UI, click Control Repos or Modules, and select the control repo or module whose webhook you want to view.
In the Pipelines section, click Manage pipelines.
If you're using pipelines-as-code, click Manage in the web UI. This temporarily converts your pipeline code to the web UI format so you can copy the webhook. After copying the webhook, don't save any changes and make sure you switch back to Manage as code before exiting the page.

Tip: If you use pipelines-as-code, make sure you don't save any changes, and make sure you switch back to Manage as code before exiting the page. Your pipeline code isn't affected as long as you don't save.
In the Automation webhook section, copy the full webhook URL. This URL represents the unique webhook that connects this control repo or module in Continuous Delivery for PE with its corresponding repository in your source control system.

What to do next

Add the webhook to the corresponding repository in your source control system, according to the source control provider's documentation. Usually, webhooks are managed in the repository's settings.

Manually configure a Puppet Enterprise integration

When you add credentials for a Puppet Enterprise (PE) instance, Continuous Delivery for PE attempts to look up the endpoints for PuppetDB, Code Manager, orchestrator, and node classifier, and it attempts to access the primary SSL certificate generated during PE installation. If this information can't be located, such as in cases where your PE instance uses customized service ports, you must enter it manually.

This task assumes you have completed the steps in Add your Puppet Enterprise credentials and have been redirected to the manual configuration page.

In the Name field, enter a unique friendly name for your PE installation.

Tip: If you need to work with multiple PE installations within Continuous Delivery for PE, the friendly names help you differentiate which installation's resources you're managing.
In the API token field, paste a PE access token for your "Continuous Delivery" user. Generate this token using the puppet-access command or the RBAC v1 API.
For instructions on generating an access token, see Token-based authentication in the PE documentation.

In the five Service fields, enter the endpoints for your PuppetDB, Code Manager, orchestrator, and node classifier services:

In the PE console, go to Status and click Puppet Services status.

Copy the endpoints from the Puppet Services status monitor and paste them into the appropriate fields in Continuous Delivery for PE. Omit the https:// prefix for each endpoint, as shown in the table below:


Service	PE console format	Continuous Delivery for PE format
PuppetDB service	`https://sample.host.puppet:8081`	`sample.host.puppet:8081`
Puppet Server service	`https://sample.host.puppet:8140`	`sample.host.puppet:8140`
Code Manager service	`https://sample.host.puppet:8170`	`sample.host.puppet:8170` Important: Use port `8170` for Code Manager in Continuous Delivery for PE.
Orchestrator service	`https://sample.host.puppet:8143`	`sample.host.puppet:8143`
Classifier service	`https://sample.host.puppet:4433`	`sample.host.puppet:4433`

Tip: The Puppet Server service is used for impact analysis, among other processes. You can run impact analysis tasks on a compiler or load balancer instead of the primary server. This is strongly recommended for PE installations that use compilers or load balancers as part of their architecture. To do this, in the Puppet Server service field, enter the hostname of the compiler or load balancer at :8140. For example: loadbalancer.example.com:8140

To locate the master SSL certificate generated when you installed PE, run:
```
curl https://<HOSTNAME>:8140/puppet-ca/v1/certificate/ca --insecure
```
The <HOSTNAME> is your PE installation's DNS name.
Copy the entire certificate (including the header and footer) and paste it into the CA certificate field in Continuous Delivery for PE.
Click Save Changes.
Optional: Once the main PE integration is configured, Configure impact analysis.

What to do next

If you want code deployments to skip unavailable compilers, go to Enable compiler maintenance mode.

Restart Continuous Delivery for PE

Restarting the pod is an appropriate first step when troubleshooting Continuous Delivery for PE.

To restart the pod, run:

systemctl restart <podman/docker>-{pipelinesinfra,ui,query,postgres}

Stop Continuous Delivery for PE

In rare circumstances, you might need to shut down, or force stop, Continuous Delivery for Puppet Enterprise (PE).

CAUTION:

Force stopping Continuous Delivery for PE can cause errors. Only use these commands under specific circumstances, preferably with guidance from Support.

We recommend that you initially try to Restart Continuous Delivery for PE, which is different and less disruptive than a force stop.

To stop Continuous Delivery for PE, run:

systemctl stop <podman/docker>-{pipelinesinfra,ui,query,postgres}

To start Continuous Delivery for PE after a force stop, run:

systemctl start <podman/docker>-{pipelinesinfra,ui,query,postgres}

Logs

Generate a support bundle for Continuous Delivery for PE that contains logs and other useful information for support.

Follow the instructions in Generate a support bundle to create a file that includes the logs for Continuous Delivery for PE.

Trace-level logging

To enable or disable trace-level logging, in the data/common.yaml file, update the containers.pipelinesinfra.log_level setting in Hiera. For example:

 containers: 
    pipelinesinfra: 
      log_level: "trace" 
      max_log_size_mb: 200 
      keep_log_files: 5

Looking up information about Continuous Delivery for PE

Use container runtime commands to access information about your Continuous Delivery for PE installation.

Look up the environment variables in use

Follow the instructions in Generate a support bundle to create a file that includes the environment variables for Continuous Delivery for PE.

To manually list the environment variables in use on your installation, run:

<podman/docker> inspect pipelinesinfra |jq ".[].Config.Env"

Note: For information on using environment variables to tune your Continuous Delivery for PE installation (such as adjusting HTTP and job timeout periods, changing the size of LDAP server searches, or enabling Git repository caching), refer to the Configuration reference.

Look up your Continuous Delivery for PE version

To print the version of Continuous Delivery for PE running in your installation, run:

<docker/podman> inspect pipelinesinfra |jq ".[].ImageName"

Generate a support bundle

When seeking support, you might be asked to generate and provide a support bundle. This bundle collects a large amount of logs, system information, and application diagnostics.

To create a support bundle:

From the root of your Continuous Delivery for PE Bolt project run:

bolt plan run cd4peadm::support_bundle

The plan may take several minutes to run depending on the size of the environment and configured log retention policies. Once the plan is complete it prints the path to the generated support bundle to send to your support representative.

Tip: If you are unable to generate a support bundle because the plan failed, give the bolt-debug.log file in your Bolt project to your support rep as well as any errors that were printed to the console.