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 controller (formerly known as Managed Master)

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

Managed controllers are provisioned and managed by the Operations Center, which creates all the necessary Kubernetes resources needed for provisioning and managing controllers.

A managed controller is specific to CloudBees CI on modern cloud platforms.

Managed controllers offer the following functionality:

  • Built-in fault tolerance, which automatically restarts managed controllers when they are unhealthy

  • Role-based access control, which can be configured on a controller or on the Operations Center, with administer, develop, and browse default roles

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

Team controller (formerly known as Team Master)

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

Team controllers are provisioned and managed by the Operations Center. A team controller is specific to CloudBees CI on modern cloud platforms.

A team controller is similar to a managed controller, but lacks the full role-based access control and other configuration capabilities of a managed controller.

Team controllers allow for the following three default roles:

  • TEAM_ADMIN

  • TEAM_MEMBER

  • TEAM_GUEST

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

External client controller

An existing client controller that is connected to a CloudBees CI cluster.

Existing controllers that are connected to Operations Center lack key benefits of managed controllers, such as high availability and automatic agent management. Whenever possible, administrators should use a managed controller with CloudBees CI on modern cloud platforms rather than connecting an existing client controller. The use-case for external client controllers 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 controllers and team controllers, and a central view into a CloudBees CI cluster. The Operations Center creates all the necessary Kubernetes resources to provision and manage a managed controller or team controller. 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 controllers and team controllers:

  • Ability to use Operations Center to manage the entire lifecycle of the controller

  • Licenses and single sign-on

  • Security and role-based access controls, which control access to different managed controllers and team controllers, as well as various Pipeline projects and jobs on each managed controller or team controller

  • Access to shared build agents

  • Cross-controller triggers

  • Cluster operations

  • Industry-standard CLI for managing clusters

  • Ability to create managed controllers of any size

Build agent

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

Two types of agents are available:

  • Kubernetes agents, which can be:

    • Defined at the Operations Center level as a shared cloud for all controllers

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

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

  • Static agents, which can be:

    • Shared by multiple controllers

    • Dedicated for a controller

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.

Distributed build environment with CloudBees CI on modern cloud platforms
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 controller or team controller that can provision ephemeral agents. CloudBees recommends that all jobs are executed in agents and not in controllers.

As the complexity of your organization’s requirements and build projects increases, CloudBees recommends provisioning more managed controllers or team controllers using the Operations Center for a distributed CI architecture.

Existing client controllers can be connected to your Operations Center in Kubernetes to facilitate the migration and promotion of jobs between client controllers and managed controllers/team controllers. After an existing client controller is connected to an Operations Center in CloudBees CI on modern cloud platforms, it is called an external client controller.

Static agents can also be connected to your managed controllers/team controllers or Operations Center (if it is a shared agent) to build jobs that do not use ephemeral agents (Kubernetes pods).

Physical architecture
Figure 2. Physical architecture

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