CloudBees CI in a multicloud environment

Version:Starting with 2.222.2.1

Who needs it?

Shared services teams and administrators who are tasked with supporting multicloud or multicluster development environments need to easily scale their CI/CD tools across cloud providers.

The problem

The inability to centrally control and provision controllers across multiple clusters and multiple clouds means limiting the scalability of the system and perpetuating silos of tools across clouds or subjecting teams to vendor lock-in. This is very disruptive for companies who are separated into divisions or business units.

CloudBees can help

We know that a significant percentage of Kubernetes users deploy applications to multiple clouds and require multicluster capabilities. Perhaps you have separate clusters for development, frontend, etc., in separate namespaces. Improved separation of concerns for security, charge-back, cost management, disaster recovery, and per-VPC billing are all use cases for multicluster.

We work with hundreds of customers to migrate from on-premises to cloud. This hybrid cloud reality is also true of our own development teams here at CloudBees. Since CI is the mechanism for integrating all development work, it follows that the ability to manage across the clusters and clouds where this work is occurring is paramount. CloudBees CI is built on Jenkins-the number one CI engine in the world, which makes us uniquely qualified to solve this multicloud problem for continuous integration.

The solution

CloudBees CI controllers on multiple Kubernetes clusters allows users to run a "controller of controllers" on a main Kubernetes cluster that manages controllers across other Kubernetes clusters. These clusters can be hosted on all the major cloud providers.

You can provision, update, and manage CloudBees CI controllers on multiple Kubernetes clusters (also known as multicluster) from a common CloudBees CI operations center (formerly known as CloudBees Jenkins Operations Center) via Helm charts.

This allows users to centrally manage CloudBees CI across multiple Kubernetes clusters instead of requiring users to create a single large Kubernetes cluster to host all CloudBees CI controllers or to have multiple instances of CloudBees CI, which negates the value of centralized management.

Use cases

  • Improved separation of concerns for security, charge-back cost management, DR and other considerations

  • Separate prod from non-prod for automation servers

  • IDE isolation and security

  • Per VPC billing