Architecture for CloudBees CI on modern cloud platforms

CloudBees CI on modern cloud platforms consists of the following components:

Table 1. Components of CloudBees CI on modern cloud platforms

Component

Description

Managed Master

A type of master that uses CloudBees’ proprietary tools and enterprise features to provide enhanced functionality for coordinating builds.

Managed Masters are provisioned and managed by the operations center, which creates all the necessary Kubernetes resources needed for provisioning and managing masters.

A Managed Master is specific to CloudBees CI on modern cloud platforms.

Managed Masters offer the following functionality:

  • Built-in fault tolerance, which automatically restarts Managed Masters when they are unhealthy

  • Role-based access control, which can be configured on a master or on the operations center, with administer, develop, and browse default roles

  • Sophisticated team authorization strategies with Managed Masters and Folders, with credentials typically used to access secured external resources in Pipeline projects and jobs

Team Master

A type of master that uses CloudBees’ proprietary tools and enterprise features to provide enhanced functionality for coordinating builds. Team Masters provide CloudBees customers with a new user experience for onboarding their development teams.

Team Masters are provisioned and managed by the operations center. A Team Master is specific to CloudBees CI on modern cloud platforms.

A Team Master is similar to a Managed Master, but lacks the full role-based access control and other configuration capabilities of a Managed Master.

Team Masters allow for the following three default roles:

  • TEAM_ADMIN

  • TEAM_MEMBER

  • TEAM_GUEST

In most cases, Managed Masters are preferable to Team Masters. Use Team Masters if you have small teams (less than 20 members) and do not require fine-grained access control.

External Client Master

An existing Client Master that is connected to a CloudBees CI cluster.

Existing masters that are connected to operations center lack key benefits of Managed Masters, such as high availability and automatic agent management. Whenever possible, administrators should use a Managed Master with CloudBees CI on modern cloud platforms rather than connecting an existing Client Master. The use case for external Client Masters is if you migrate from CloudBees CI on traditional platforms to CloudBees CI on modern cloud platforms.

operations center

An instance that provides centralized management of Managed Masters and Team Masters and a central view into a CloudBees CI cluster. The operations center creates all the necessary Kubernetes resources to provision and manage a Managed Master or Team Master. The operations center includes built-in fault tolerance, which automatically restarts the operations center when it is unhealthy.

The operations center provides the following management functionality for Managed Masters and Team Masters:

  • Ability to use operations center to manage the entire lifecycle of the Managed Master

  • Licenses and single sign-on

  • Security and role-based access controls, which control access to different Managed Masters and Team Masters, as well as various Pipeline projects and jobs on each Managed Master or Team Master

  • Access to shared build agents

  • Cross-master triggers

  • Cluster operations

  • Industry-standard CLI for managing clusters

  • Ability to create Managed Masters of any size

Build agent

A machine, container, or pod that handles the tasks of running builds, at the direction of a master. Within the context of a CloudBees CI cluster, a build agent can be a shared resource for Managed Masters or Team Masters. A build agent can also be dedicated to a specific master.

Two types of agents are available:

  • Kubernetes agents, which can be:

    • Defined at the operations center level as a shared cloud for all masters

    • Defined at the master level to be used by a master

    • Defined as code to be used by one or multiple masters

  • Static agents, which can be:

    • Shared by multiple masters

    • Dedicated for a master

CloudBees CI on modern cloud platforms leverages the scaling abilities of Kubernetes to schedule build agents. Kubernetes build agents are contained in pods, where a pod is a group of one or more containers sharing a common storage system and network. A pod is the smallest deployable unit of computing that Kubernetes can create and manage. Pods are defined using pod templates.

Figure 1. Distributed build environment with CloudBees CI on modern cloud platforms

The simplest configuration needed to get started in CloudBees CI on modern cloud platforms consists of the operations center and a Managed Master or Team Master that can provision ephemeral agents. CloudBees recommends that all jobs are executed in agents and not in masters.

As the complexity of your organization’s requirements and build projects increases, CloudBees recommends provisioning more Managed Masters or Team Masters using the operations center for a distributed CI architecture.

Existing Client Masters can be connected to your operations center in Kubernetes to facilitate the migration and promotion of jobs between Client Masters and Managed Masters/Team Masters. After an existing Client Master is connected to an operations center in CloudBees CI on modern cloud platforms, it is called an external Client Master.

Static agents can also be connected to your Managed Masters/Team Masters or operations center (if it is a shared agent) to build jobs that do not use ephemeral agents (Kubernetes pods).

Figure 2. Physical architecture

To understand which Kubernetes resources are deployed in your installation and learn important information about agent and master provisioning, and ports needed, refer to the reference architecture for your Kubernetes platform.