Job hardware requirements
System requirements for Continuous Delivery job hardware depend on the size of your Continuous Delivery installation, the type of jobs you run, and how frequently you run them.
The size of the load placed on a job hardware server determines how robust the server's resources must be. Due to the number of variables involved in estimating this (such as the number of jobs running concurrently and the languages the jobs are written in), it's impossible to provide universal system requirements for job hardware.
Instead, we've created a sizing guide based on the estimated number of concurrent jobs you expect your job hardware server to handle regularly. While this guide represents our best estimates and understanding, it's only a starting point. Through testing and experience, you can fine-tune your job hardware and determine the optimum resource configuration for your Continuous Delivery installation.
Estimated concurrent job load | Memory | Disk storage | CPUs |
---|---|---|---|
2 - 4 concurrent spec tests | 4 GB | 100 GB | 2 |
4 - 8 concurrent spec tests | 8 GB | 100 GB | 4 |
6 - 12 concurrent spec tests | 8 GB | 100 GB | 6 |
When setting up your job hardware, keep in mind:
- Disk storage requirements are minimal and don't increase with added load. After a job run is complete, the job's log is passed to the object storage, and all data related to the job run is erased from the job hardware.
- You can run more jobs concurrently without increasing CPUs, but the jobs run slower.
Job hardware requirements for containerized jobs
To run containerized jobs, your job hardware must have a modern
version of Docker CE, Docker EE, or podman installed. The puppetlabs/docker
module (from the Forge) is our recommended way to install Docker and keep it updated.
Global shared job hardware uses a shared container image
set in the root console. The default image used for containerized jobs is puppet/puppet-dev-tools:4.x
. You can find details on the available commands in the image documentation.
Install container images on offline nodes
When using containerized jobs in an airgapped environment, you need to download the images using a machine with internet access then manually copy the images onto the offline nodes.
To install the puppet/puppet-dev-tools:4.x
image onto an offline
node, use the installed Docker or podman runtime:
- From a node with access to the internet, download the image from Docker Hub using:
<runtime> pull puppet/puppet-dev-tools:4.x
- Export the image as a file using:
<runtime> save puppet/puppet-dev-tools:4.x > puppet-dev-tools-4x
. - Move the
puppet-dev-tools-4x
file onto the offline node in a manner compliant with your security protocols. - From offline node, import the image from file:
<runtime> import puppet-dev-tools-4x puppet/puppet-dev-tools:4.x