Advanced configuration

Advanced configuration settings for Continuous Delivery for PE help you fine-tune aspects of the software that can impact runtime and operation speed.

Adjust available memory

Adjust the amount of memory available to Continuous Delivery for Puppet Enterprise (PE) based on repository size and workflow complexity.

In some cases, the amount of memory allocated to the Continuous Delivery for PE application by default isn't sufficient. Memory consumption scales with repository size and the number of jobs running concurrently.

To adjust the amount of memory allocated to Continuous Delivery for PE:
  1. Navigate to the Config page in Puppet Application Manager (PAM).
  2. In the Advanced configuration and tuning section, adjust the Memory available for CD4PE (in MiB) setting.

Adjust the timeout period for snapshots

When creating a snapshot, Puppet Application Manager (PAM) makes backup copies of various Continuous Delivery for Puppet Enterprise (PE) components. You can change the amount of time PAM spends making each component's backup copy.

You can learn more about creating and using snapshots in the PAM documentation.

To configure timeout periods, navigate to the Config page in PAM, and edit these settings in the Advanced configuration and tuning section:
  • Object store backup timeout: The amount of time a running snapshot spends attempting to backup the Continuous Delivery for PE object store. The default is 30 minutes.
  • Continuous Delivery for PE database backup timeout: The amount of time a running snapshot spends attempting to backup the Continuous Delivery for PE database. The default is 10 minutes.
  • Nodes database backup timeout: The amount of time a running snapshot spends attempting to backup the database for the Nodes page. The default is 10 minutes.

Improve job performance by caching Git repositories

If you have large Git repositories, you can enable Git repository caching to improve job performance. By default, repository caching is disabled.

To enable repository caching:
  1. In Puppet Application Manager (PAM), navigate to the Config page.
  2. In the Advanced configuration and tuning section, enable Git Repo caching.

The cached repository's files and data are stored on the container running Continuous Delivery for PE at /<DEFAULT_ROOT_STORAGE_DIRECTORY>/repos. The entire repository is cloned from source control, including branches; therefore, caching requires space equivalent to the size of the uncompressed repository.

Cached repositories are not automatically deleted. When attempting to read from the cached repository, if the cached version is missing object ID references, or if the previous cache attempt failed, then the cached version is deleted and re-cloned.

Including the .git directory in cached repositories

The .git directory is automatically omitted when copying cached Git repositories to job hardware. This means that the job cannot perform Git actions on the code. If needed, you can adjust this setting so that the .git directory is included in the cached repository.

To include the .git directory in copies of cached Git repositories sent to job hardware:
  1. In PAM, navigate to the Config page.
  2. In the Advanced configuration and tuning section, enable Include Git history for jobs.

Adjust the timeout period for jobs

In some circumstances, such as when working with large Git repositories, you may need to adjust the length of the job timeout period. Use the settings in this section to customize the job timeout period.

To configure timeout periods, navigate to the Config page in PAM, and edit these settings in the Advanced configuration and tuning section:
  • Repo cache retrieval timeout (minutes): Sets the timeout period for a thread attempting to access a cached Git repository. The default is 28 minutes.
    Note: This is only available if you enabled Git repository caching.
  • Job HTTP read timeout (minutes): Sets the timeout period for a job connecting to an endpoint. The default is 29 minutes.
  • Job global timeout (minutes): Sets the global default timeout period for jobs. Once this time elapses, the job fails and a timeout message is printed to the log. The default is 30 minutes.
  • Bolt PCP read timeout (seconds): Sets the Bolt PCP read timeout period. The default is 60 seconds.
    Note: Jobs cannot proceed while file sync is running. If a file sync operation is not completed before the Bolt PCP read timeout period elapses, the job fails. Increase the Bolt PCP read timeout period to prevent these job failures.
Important: To ensure useful error messages are printed to the logs, make sure that the value of Job global timeout is larger than the value of Job HTTP read timeout, and that both are larger than the value of Repo cache retrieval timeout.

Configure LDAP server search result limits

By default, Continuous Delivery for Puppet Enterprise (PE) requests 500 search results at a time from a connected LDAP server. If your LDAP server's search result limitation is below 500, you can configure Continuous Delivery for PE to match the LDAP server's search result threshold.

Navigate to the Config page in Puppet Application Manager (PAM) and set the LDAP group search size limit in the Advanced configuration and tuning section.

Adjust HTTP timeout periods

If necessary, you can adjust the timeout periods for various HTTP operations.

To configure HTTP timeout periods, navigate to the Config page in PAM, and edit these settings in the Advanced configuration and tuning section:
  • Global HTTP connection timeout (seconds): Sets the timeout period for all external HTTP connections. The default is 120 seconds.
  • Global HTTP read timeout (seconds): Sets the timeout period for all external HTTP read actions. The default is 120 seconds.
    Note: This value is also used as the value for the CD4PE_MODULE_DEPLOY_READ_TIMEOUT environment variable in deployment tasks.
  • Global HTTP write timeout (seconds): Sets the timeout period for all external HTTP write actions. The default is 120 seconds.
  • Global HTTP request timeout (seconds): Sets the total amount of time an external HTTP request remains open. The default is 300 seconds.

Configure login attempt limits

By default, Continuous Delivery for PE limits the number of unsuccessful login attempts users can make within a certain timeframe. If the user exceeds the allowed number of unsuccessful login attempts within that timeframe, their account is temporarily locked. You can customize login attempt limits for your installation.

To configure login attempt settings, navigate to the Config page in PAM, and edit these settings in the Advanced configuration and tuning section:
  • Max login attempts before lockout: The number of unsuccessful login attempts a user can make before the account is locked. The default is 10 attempts.
  • Time period (minutes) to look at for failed logins: The amount of time that must elapse before the failed login count resets. The default is 15 minutes.
  • Time period (minutes) to lock an account: How long user accounts are locked after exceeding the number of unsuccessful login attempts within the failed login timeframe. The default is 120 minutes.

Configure data retention settings

Configures Continuous Delivery for PE to keep pipeline or value reporting data for a period of time. By default, data is retained indefinitely. When these settings are set to values other than 0, Continuous Delivery for PE runs a task on startup and every 24 hours which deletes data older than the configured retention period.

To configure data retention settings, navigate to the Config page in PAM, and edit these settings in the Advanced configuration and tuning section:
  • Number of days to retain historical pipelines data: The number of days to retain historical pipelines data, which includes pipeline runs, deployments, jobs, job logs, and impact analysis reports. By default this is set to 0, which retains historical pipelines data indefinitely.
  • Number of days to retain historical value reporting data: The number of days to retain historical value reporting data, which only includes the daily activity data on the Value reporting page. By default this is set to 0, which retains historical value reporting data indefinitely.

Use custom TLS certificates

By default, Continuous Delivery for Puppet Enterprise (PE) uses automatically generated certificates. Your organization's security policies might require using custom certificates or adding additional certificates. Use these steps to configure custom TLS certificates for the Continuous Delivery for PE web UI connection and, optionally, the Continuous Delivery for PE webhooks connections.

Before you begin
It is recommended to do this after you Deploy Continuous Delivery for PE, but you could do this during initial setup.
  1. Obtain a custom certificate and accompanying key pair. You need the entire certificate, including the header and footer, and the private key. Most configurations also need a CA certificate chain.
    Make sure you have configured the DNS names you want to use for Puppet Application Manager (PAM) and Continuous Delivery for PE. When you generate and sign the CSR, make sure it includes enough subject alternative names to capture both applications.
  2. In PAM, go to the Config page for your Continuous Delivery for PE installation.
  3. In the Optional configuration section, select View options for certificates, and select Provide my own certs.
  4. In the TLS certificate field, paste the entire certificate, including the header and footer.
  5. In the TLS private key field, paste the entirety of the private key corresponding with your custom certificate.
  6. Enter a CA certificate chain in the CA certificate field so Puppet agents trust your certificate.
    There are some situations where you might not need to provide the CA certificate chain. This depends on your certificate configuration.
  7. To use your custom certificate for Continuous Delivery for PE webhooks, select View options for using a proxy or external load balancer, and then select Use TLS for Webhook Service. This uses the same certificate you provided above.
    This option is not available if you chose Use an Ingress with a hostname when you deployed Continuous Delivery for PE.
  8. Click Save config > Go to updated version. Once preflight checks are done, deploy the updated version.
    For details about preflight checks and deploying a new version, refer to Deploy Continuous Delivery for PE.
  9. Optional: Use OpenSSL or curl commands to verify your certificates.
What to do next
If you want to go back to using the automatically generated certificates, under Optional configuration, switch to Use generated certs.

To use custom TLS certificates for PAM, refer to Update the PAM TLS certificate.

To use a custom certificate for your Continuous Delivery for PE SAML SSO configuration, refer to Configure SAML.

Enable compiler maintenance mode

You can tell Continuous Delivery for Puppet Enterprise (PE) to skip offline or unavailable compilers and replicas when deploying code.

CAUTION: With this setting enabled, Code Manager deployments are reported as successful as long as the code was deployed to the primary server. Continuous Delivery for PE does not tell you if it skipped a compiler or replica. You are only notified if the deployment to the primary server failed.

You must manually monitor the status of your compilers and replicas to ensure they're in sync with the primary server. If a compiler or replica is out of sync, you'll need to manually deploy code to that compiler or replica.

To enable this setting:
  1. In the Continuous Delivery for PE web UI, navigate to Settings > Puppet Enterprise.
  2. Locate the PE instance you want to configure and click More actions > Edit integration.
  3. In the Compiler maintenance mode section, enable Ignore unavailable compilers or replicas when deploying code.
  4. Click Save changes.
Important: This setting allows your pipelines to continue while compilers are undergoing maintenance or experiencing transient issues. When enabled, Code Manager deployments report as successful as long as the code was deployed to the primary server. Therefore, you must manually track that the code on your compilers and replicas is in sync.

Use the Code Manager API GET /v1/deploys/status endpoint to make sure your compilers and replicas are in sync with the primary server. The file-sync-client-status portion of the response contains all servers with code synced. In the deployed array for each server, compare the deploy-signature and date for each deployment. The deploy-signature is the hash of the git commit that was last synced to the server. If a compiler or replica has a different hash that the primary, you must Deploy code manually to the desynchronized compiler or replica.

Disable Vault

You can disable Vault to improve job performance. By default, Vault is enabled to allow for migrations on older Continuous Delivery for PE releases (4.19.0 and older).

Note: Continuous Delivery for PE no longer uses Vault. It is enabled by default to support older releases (4.19.0 and older). If you do not need to support an older release, please disable Vault to free the resources it uses.
To disable Vault:
  1. In Puppet Application Manager (PAM), navigate to the Config page.
  2. In the Advanced configuration and tuning section, disable Enable Vault.