Deploying Code without blocking requests to Puppet Server

When compiling code, Puppet Server typically blocks requests, including catalog compilation, until file sync is done updating the Puppet code directory. You can enable lockless deploys so the file sync client updates code into versioned code directories instead of blocking requests and overwriting the live code directory.

With lockless deploys enabled, each new deploy writes code to versioned directories at /opt/puppetlabs/server/data/puppetserver/filesync/client/versioned-dirs/puppet-code/. The standard code directory, /etc/puppetlabs/code is reconfigured to /etc/puppetlabs/puppetserver/code, which points via symlink to the most recent versioned code directory. If you disable lockless deploys after enabling it, your code directory moves back to the default location.

To conserve disk space, code written to version directories is optimized to reduce duplication, and directories older than the latest and its predecessor are cleaned up after 30 minutes. If you deploy code very frequently, you might prefer to decrease the versioned-dirs-ttl setting, which is specified, in minutes, in file-sync.conf within each file sync client.

Note: Lockless deploys are an experimental feature which might experience breaking changes in future releases. Test the feature in a non-production environment before enabling it in production.

Deploy code without blocking requests to Puppet Server

When compiling code, Puppet Server typically blocks requests, including catalog compilation, until file sync is done updating the Puppet code directory. You can enable lockless deploys so the file sync client updates code into versioned code directories instead of blocking requests and overwriting the live code directory.

With lockless deploys enabled, each new deploy writes code to versioned directories at /opt/puppetlabs/server/data/puppetserver/filesync/client/versioned-dirs/puppet-code/. The standard code directory, /etc/puppetlabs/code is reconfigured to /etc/puppetlabs/puppetserver/code, which points via symlink to the most recent versioned code directory. If you disable lockless deploys after enabling it, your code directory is moved back to the default location.

To conserve disk space, code written to version directories is optimized to reduce duplication, and directories older than the latest and its predecessor are cleaned up after 30 minutes. If you deploy code very frequently, you might prefer to decrease the versioned-dirs-ttl setting, which is specified, in minutes, in file-sync.conf within each repository.

Note: Lockless deploys are an experimental feature which might experience breaking changes in future releases. We recommend testing the feature in a non-production environment before enabling it in production.
  1. In the console, click Node groups and select the PE Master node group.
  2. On the Classes tab, in the puppet_enterprise::profile::master class, set versioned_deploys = true and click Add parameter.
  3. Commit changes.
  4. Run Puppet on your primary server and all compilers: puppet agent -t
Results
The next time you deploy code, your code directory is reconfigured from /etc/puppetlabs/code to /etc/puppetlabs/puppetserver/code, and versioned code directories are added at /opt/puppetlabs/server/data/puppetserver/filesync/client/versioned-dirs/puppet-code/.

System requirements for lockless deploys

Enabling lockless deploys increases the disk storage required on your primary server and compilers, because code is written to multiple versioned directories, instead of a single live code directory. Follow these guidelines for estimating your required system capacity.

You can roughly estimate your required disk storage with this equation:

(Size of typical environment)(Number of active environments)

For example, if your typical environment, when deployed, is 200 MB on disk, and you have 25 active environments, your disk storage calculation is 200 MB x 25 = 5,000 MB or 5 GB.

The number of times you deploy a given environment each day also impacts your disk use. Deploying multiple versions of the same environment uses approximately 25 percent more disk space than deploying multiple unique environments. To estimate the additional disk storage required for deploying environments multiple times a day, use this equation:

(Size of typical environment x .25)(Number of environments deployed multiple times per day)(Number of deployments per day)

Expanding on the previous example, if 10 of your active environments are deployed up to 10 times per day, your disk storage calculation is 50 MB x 10 x 10 = 5,000 MB or an additional 5 GB of disk space. In total then, you need 10 GB available for your primary server and each compiler.

Note: If you're using the Continuous Delivery for PE impact analysis tool, you might need additional disk space beyond these estimates in order to accommodate the short-lived environments created during impact analysis.