Nodepool enables Zuul to support a multi-cloud environment by launching single-use test nodes from the most compatible node resource available.
Zuul is built for testing! The flexible configurations that Zuul provides are key differentiating factors of the tool against other generic automation tools. Zuul provides test environment provisioning via Nodepool. Nodepool is a part of a comprehensive suite of tools for testing which includes Zuul itself, each performing a specific function in the job execution workflow.
Nodepool is a system for managing test node resources. Nodepool itself has two components which run as daemons, Nodepool-builder and Nodepool-launcher. Here we are covering the actions of the launcher daemons and how it works with Zuul.
In the given context, Nodepool acts as a companion pool manager, used for clean and reproducible nodes to execute Zuul jobs. Nodepool retrieves and launches single-use test nodes upon Zuul's request. It has access to nodes from different cloud providers and also manages pre-defined and pre-existing nodes. Therefore, Zuul is not limited to only your infrastructure provider and is compatible with a wider range via Nodepool. Nodepool supports the following resources:
- OpenStack Driver
- Static Driver
- Kubernetes Driver
- Openshift Driver
- Openshift Pods Driver
- AWS EC2 Driver
As mentioned earlier, this support is made available for Zuul users when Nodepool launches a fresh node for every new test. Therefore, AWS Zuul is just one of many other deployment options available to Zuul users. To better understand how Zuul and Nodepool work together, their functions can be broken down into the following steps:
- The code review system sends events to Zuul. These events trigger Zuul's decision of executing jobs. Events can range from creation, update or merger of reviews or pull-requests.
- Based on the events and the configuration of Zuul's scheduler, Zuul requests services from its components, in this case, Nodepool.
- Nodepool's launchers look for requests from Zuul and fulfill them by retrieving a node or a node provider. Nodepool can reserve an existing node or spawn a new one and notify that the required node is available.
- Using the Ansible playbook, Zuul executor runs the job against the given node.
- Once the job execution is over, Zuul releases the node to be deleted.
This is an example of a standard workflow when a single job is to be run. In the case of multiple jobs, the corresponding number of nodes is requested from Nodepool. A single job can also be classified as a multi-nodes job if more than one node is required for the execution process and subsequently the required amount of resource is requested. Since fresh nodes are requested for each job execution, it reduces job erraticness and ensures a robust workspace.
On the other hand, Nodepool-builder daemon is used for building and uploading images to providers. The diskimage-builder is responsible for building the underlying images. Also, Nodepool is able to build cloud instances from these images created.
The configuration file for Nodepool also follows the YAML syntax, making it just as well integrated with Ansible. Due to this, the multi-cloud merging process is efficiently automated. This further ensures
effective coordination between workloads and the management of hybrid workflows.
If Zuul is something you need or are interested in, check out our Managed Zuul solution offering and contact us for any queries!
How to Up Your DevOps Game with Project Gating: Zuul - A CI/CD Gating Tool
Download White Paper
