Installation

This section provides detailed instructions on installing CloudBees CD/RO within Kubernetes. Depending on your needs, you can install CloudBees CD/RO:

Install CloudBees CD/RO demo server: Install a non-production version of CloudBees CD/RO using the default values.yaml as a preconfigured cluster to experiment with.
Install CloudBees CD/RO production server: Install CloudBees CD/RO with Helm charts you configured as a project-specific cluster that can be used in production.

To help you get started, you can also watch our demo installation:

Installing CloudBees CD/RO in Kubernetes demo

Getting started

The following items are important prerequisites for installing CloudBees CD/RO:

These instructions assume you are familiar with Kubernetes concepts and the tooling required for establishing a Kubernetes cluster. If you are not, review the Kubernetes documentation.
The Kubernetes version you are using must be supported. For supported versions, refer to Supported platforms for CloudBees CD/RO on Kubernetes.
Ensure you are able to satisfy the Kubernetes cluster and storage requirements.
If all of your Kubernetes nodes are tainted, you must have at least one untainted node to run the flow-server-init-job pod. If you create a new node or remove the taint from an existing one, you can delete or taint this node after installation is complete.

The following items are product details for installing CloudBees CD/RO:

For production environments, Helm charts are released for each CloudBees CD/RO version in SonaType Nexus. These charts contain the configurations for all components in a values.yaml at the top level of the package and a separate values.yaml for each component in the charts/<component-subdirectory>.
The values.yaml files released for a CloudBees CD/RO version include all available settings and their default values for each component. You may use these charts in project-specific values files by either replacing default values with your own or extracting only the subsets of configurations you need.
When configuring the default values.yaml for your project, CloudBees strongly suggests you save it in a project-specific myvalues.yaml under version control. This is to help avoid confusion with the default values.yaml, track updates, and compare changes between releases.
In production installations, you must configure an external database, which requires a CloudBees CD/RO enterprise license.

Install CloudBees CD/RO demo server

Before starting, ensure you have met the applicable requirements in Getting started.

The CloudBees CD/RO demo server is installed using cloudbees-flow Helm charts from YAML files available in the CloudBees examples repository. There are several platform versions of the demo available, each with demo included in the YAML file name.

The following CloudBees CD/RO components are included with the demo installation:

The CloudBees CD/RO server (flow-server)
The CloudBees CD/RO web server (flow-web)
The CloudBees Analytics server (flow-devopsinsight)
The repository server (flow-repository)
A bound agent that is the local agent for the CloudBees CD/RO and repository servers (flow-bound-agent)
A NGINX Ingress Controller
A MariaDB database

These components are installed as a single node CloudBees CD/RO cloudbees-flow server and allow you to experiment with many of CloudBees CD/RO’s features.

If you are using minikube to install the demo, ensure:

The Kubernetes version you are using is supported. For supported versions, refer to Supported platforms for CloudBees CD/RO on Kubernetes.
- To set the Kubernetes version, run:
  minikube start --kubernetes-version=<K8s-version/example:v1.24.9>
  ▼
If you are running minikube in a Docker container, ensure the Docker Container Resources are enough to fulfill the CloudBees CD/RO server requirements. The Container Resources must be set high enough to support both your minikube cluster and Docker core functions.
When starting a cluster in minikube, the default values are not sufficient to run all components. For a demo with a minimal workload, the suggested minimum values are 4 CPUs and 12GB of memory.
- To increase the CPUs and memory to the suggested values use:
  minikube start --cpus 4 --memory 12000
  ▼

To install the CloudBees CD/RO demo server in your Kubernetes cluster:

Download a copy of the cloudbees-cd-demo.yaml from the CloudBees examples repository.

There are several platform versions of the demo available, each with demo included in the YAML file name. If you use one other than cloudbees-cd-demo.yaml, use its file name as the helm install -f values file. If you make changes to the file, CloudBees recommends you save it as a project-specific myvalues.yaml to avoid confusion with the default chart.

Add the public CloudBees repository:

helm repo add cloudbees https://public-charts.artifacts.cloudbees.com/repository/public/
helm repo update▼

If you have not already done so, create a namespace in your cluster:
```
kubectl create ns <demoserver-namespace>▼
```

Run the following Helm commands to install CloudBees CD/RO:

helm install <demoserver-releasename> cloudbees/cloudbees-flow \
      -f <path/to/cloudbees-cd-demo.yaml> \
      --namespace <demoserver-namespace> \
      --timeout 10000s▼

The installation may take several minutes. Once the pods are all running, you can track the progress of the CloudBees CD/RO server initialization, via the flow-server-init-job log in the Kubernetes dashboard. Once all pods are initialized, you can expose the CloudBees CD/RO server flow-web service URL and use your browser to experiment with CloudBees CD/RO.

Migrating from a non-production to production environment requires a CloudBees CD/RO enterprise license and seperate database configuration.

Before you install CloudBees CD/RO production server

A cloudbees-flow Helm chart is released with each CloudBees CD/RO version. This chart includes the installation instructions and configurations for the following components:

The CloudBees CD/RO server (flow-server)
The CloudBees CD/RO web server (flow-web)
The CloudBees Analytics server (flow-devopsinsight)
The repository server (flow-repository)
A bound agent that is the local agent for the CloudBees CD/RO and repository servers (flow-bound-agent)
A NGINX Ingress Controller
A Zookeeper ensemble

By default, the values.yaml includes a built-in database for testing. However, for production environments, you must configure CloudBees CD/RO to connect with your project-specific database. For information on supported databases, refer to Supported platforms for CloudBees CD/RO on Kubernetes.

Using a project-specific database requires a CloudBees CD/RO enterprise license. To avoid installation errors, your CloudBees CD/RO server licence and database connections should both be configured in the same installation of the cloudbees-flow values chart in your project-specific myvaules.yaml. Failing to do so generates error messages about an unsupported configuration or a license requirement, depending on which is omitted.

If CloudBees CD/RO is initially installed with the built-in database, you can reconfigure it to use a separate database at any time. For more information on configuring CloudBees CD/RO to use your external database, refer to Configuring CloudBees CD/RO to Use an Alternate Database.

If your database connection fails, ensure the license is valid for CloudBees CD/RO, and the database configuration is correct. For information on configuring an external database for use by CloudBees CD/RO, refer to External database configuration.

Configure CloudBees CD/RO server values

A default values file (values.yaml) is released for each CloudBees CD/RO version that contains all default values for the CloudBees CD/RO server installation as part of the cloudbees-flow Helm chart. However, for production environments, there are many project-specific values that must be set in the cloudbees-flow Helm chart according to your project’s implementation.

Your project-specific values, which are only a subset of the default values, are normally set in a seperate myvalues.yaml. This has the major advantage of reducing the amount of overall configuration you must track and maintain.

During installation, you can specify your project-specific myvalues.yaml when running helm install. Doing so, overwrites the default values in the values.yaml with the project-specific values in your myvalues.yaml, while still using the default values for items you did not customize.

CloudBees provides two ways to get started with your myvalues.yaml:

You can start with the values.yaml and extract only the project-specific parts you need. To get started, refer to Use the default values file to create your project-specific values file.
You can start with an example production values file and adapt it to fit your needs.To get started, refer to Use an example production values file to create your project-specific values file.

Use the default values file to create your project-specific values file

To get started using the values.yaml to create your myvalues.yaml chart:

Visit SonaType Nexus, find the latest release of cloudbees-flow, and download the package.
Open the package and, in the top-level of the directory, locate the values.yaml.

In the charts directory of the package, you can find charts for individual components within their subdirectory.
Save the file as a project-specific myvalues.yaml.

Go through your myvalues.yaml and update it to meet your project-specific needs. Specifically, configure your database, storage, license information, and CloudBees CD/RO credentials before installing it. For information on available configuration options, refer to cloudbees-flow chart configuration values.

(Optional) If you are using a multi-node deployment for the CloudBees Analytics server, a common node certificate infrastructure is required. Refer to Configure CloudBees Analytics server certificates to learn how to configure common node certificate infrastructure in your project-specific values file.
(Optional) Place your myvalues.yaml under version control. CloudBees strongly suggests you do this to track updates and compare changes between releases.

(Optional) Any configurations not specified in your myvalues.yaml are automatically taken from the values.yaml during installation. This means, you can also delete any configuration options in your myvalues.yaml that are not specifically required by your project. This helps to reduce the overall configurations maintained in this file.

While deleting unneeded configuration options, ensure you maintain valid tag nesting and syntax. Failing to do so may cause your installation to fail or produce unpredictable behavior on your platform.

After you have configured your myvalues.yaml, refer to Install CloudBees CD/RO production server.

Use an example production values file to create your project-specific values file

Preconfigured production Helm chart examples are available in the CloudBees examples repository to get you started. These files include:

Values file Description

Values file	Description
`cloudbees-cd-prod.yaml`	File for use with production installations. You must configure your database, storage, and CloudBees CD/RO credentials in a local project-specific values file before it can be used. For information on available configuration options, refer to cloudbees-flow chart configuration values.
`cloudbees-cd-defaults.yaml`	File listing all Helm chart values along and their default value. Use as a reference when specifying additional configurations in your local project-specific values file. For information on available configuration options, refer to cloudbees-flow chart configuration values.

cloudbees-cd-prod.yaml

File for use with production installations. You must configure your database, storage, and CloudBees CD/RO credentials in a local project-specific values file before it can be used. For information on available configuration options, refer to cloudbees-flow chart configuration values.

cloudbees-cd-defaults.yaml

File listing all Helm chart values along and their default value. Use as a reference when specifying additional configurations in your local project-specific values file. For information on available configuration options, refer to cloudbees-flow chart configuration values.

There are several platform versions of the production example Helm charts available in the CloudBees examples repository, each with prod in the YAML file name.

To create your myvalues.yaml based on the example production chart:

Go to the CloudBees examples repository and save a copy of the example production chart you want to use as your project-specific myvalues.yaml.

(Optional) If you are using a multi-node deployment for the CloudBees Analytics server, a common node certificate infrastructure is required. Refer to Configure CloudBees Analytics server certificates to learn how to configure common node certificate infrastructure in your project-specific values file.
(Optional) Place your myvalues.yaml under version control. CloudBees strongly suggests you do this to track updates and compare changes between releases.

After you have configured your myvalues.yaml, refer to Install CloudBees CD/RO production server.

For more information on options to configure your project-specific Helm chart, refer to Configuring Helm charts.

Install CloudBees CD/RO production server

Before starting, ensure you have met the applicable requirements in Getting started.

To install a CloudBees CD/RO production server:

Configure your myvalues.yaml file for your CloudBees CD/RO production server. For more information on configuring your myvalues.yaml, refer to Configure CloudBees CD/RO server values.

Add the public CloudBees repository:

helm repo add cloudbees https://public-charts.artifacts.cloudbees.com/repository/public/
helm repo update▼

If you have not already done so, create a namespace in your cluster:
```
kubectl create ns <production-server-namespace>▼
```

Run the following Helm command to install CloudBees CD/RO:

helm install <production-server-releasename> cloudbees/cloudbees-flow \
      -f <production-server-myvalues.yaml> \
      --namespace <production-server-namespace> \
      --timeout 10000s▼

The installation may take several minutes. Once the pods are all running, you can track the progress of the CloudBees CD/RO server initialization, via the flow-server-init-job log in the Kubernetes dashboard. Once all pods are initialized, you can expose the CloudBees CD/RO services URLs in your environment and begin working with CloudBees CD/RO.

Update CloudBees CD/RO production servers

If you want to make changes to the project-specific server:

Make any changes and save them in your project-specific myvalues.yaml.

Run:

helm upgrade <production-server-releasename> cloudbees/cloudbees-flow \
      -f <production-server-myvalues.yaml> \
      --namespace <production-server-namespace> \
      --timeout 10000s▼

The installation may take several minutes. Once the pods are all running, you can track the progress of the CloudBees CD/RO server initialization, via the flow-server-init-job log in the Kubernetes dashboard. Once all pods are initialized, you can expose the CloudBees CD/RO services URLs in your environment and begin working with CloudBees CD/RO.

Configure CloudBees Analytics server certificates

CloudBees CD/RO uses transport layer security (TLS) encryption and certificates to protect data between nodes on the CloudBees Analytics server. Required certificates are generated automatically for single node deployments. You must specify the common node certificate infrastructure for multi-node deployments by defining pre-generated certificates before installation.

CloudBees recommends that you specify certificates by generating a key store containing a root certificate authority (CA) certificate, an intermediate CA signing certificate, and its private key. With this method, all additional required certificates are automatically generated.

Use the cbflow-tools image and the following command to create the key store:

docker run --rm cloudbees/cbflow-tools:<docker tag> generate-certificates▼

This command returns the key store in base64 format. You must set this string as the value of the dois.certificates.bundle property in your local values file.

You can also create a secret key with the corresponding data. Use the following command to create a cbcd-analytics-certificates secret key:

kubectl create secret generic cbcd-analytics-certificates \
      --from-literal=CBF_DOIS_CRT_BUNDLE=$(docker run \
      --rm cloudbees/cbflow-tools:<docker tag> generate-certificates)▼

You can specify this secret key in the value of the dois.certificates.existingSecret property in your local values file, or as a parameter for the installation command.

--set dois.certificates.existingSecret=cbcd-analytics-certificates▼

If the recommended configuration is not suitable for your environment, CloudBees CD/RO also supports the following alternative certificate sets:

A root CA certificate and its private key
A root CA certificate, an intermediate CA signing certificate, and its private key
A root CA certificate, an intermediate CA signing certificate, and node and administrative certificates with their private keys

You must check the corresponding comments in the values file for the corresponding properties.

Install and update CloudBees CD/RO agents

The following instructions describe how to install CloudBees CD/RO agent(s) only. Before you start, you must already have the CloudBees CD/RO server installed in your cluster. If you need to install the CloudBees CD/RO server, refer to CloudBees CD/RO server installation and upgrade before proceeding with the agent installation. Once you have the CloudBees CD/RO server installed, you may install multiple agents and configure them to fit your needs.

Configure CloudBees CD/RO agent values

A cloudbees-flow-agent Helm chart is released for each CloudBees CD/RO version and may be used as a starting point for installation. For production environments, there are many project-specific values that may need to be changed in the cloudbees-flow-agent Helm chart to meet the needs of your project’s implementation. You can specify your own project-specific myvalues.yaml for your agent when running helm install.

To create your custom myvalues.yaml chart:

Go to SonaType Nexus, find the latest release cloudbees-flow, and download the package.
Open the package, navigate to charts/cloudbees-flow-agent, and locate the values.yaml.

In the charts directory of the package, you can find individual charts for other components.
Save the file as a project-specific myvalues.yaml

Go through your myvalues.yaml and update it to meet your project-specific needs.

If you are configuring multiple replicas in your values file using the replicas value, ensure your resourceName template is correctly defined so all replicas are registered properly. For more information, refer to Agent resource name templates.

(Optional) Place your myvalues.yaml under version control. This is strongly suggested to track updates and compare changes between releases.

Configure agent third-party tools

CloudBees CD/RO agents often need, use, or access third-party tools to accomplish tasks. In traditional deployments, these tools are installed directly on the agent machine. However, for agents running in a Kubernetes cluster, third-party tools can be deployed in an agent container, so they are immediately accessible by the agent. Configuring an agent’s third-party tools, is typically done by one of the following options:

Install the agent with a project-specific custom container.
Configure the tools within a project-specific script and dynamically install them with the agent.

Install a project-specific agent image

For installations with third-party tools that are well-defined and static, you may choose to use the CloudBees CD/RO agent image as the base image and create your own container with the required third-party tools added. Below is an example Dockerfile configuring the custom container.

FROM cloudbees/cbflow-agent:<agent-image>

USER root
RUN yum update -y && yum -y install git && \
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl \
      -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl && \
chmod +x ./kubectl && \
mv ./kubectl /usr/local/bin
USER cbflow▼

Install third-party tools from script

CloudBees CD/RO agents are not installed as a root user. Not all Kubernetes installations allow you to change the agent’s access to root. This may prevent your project-specific installation from using this option to install third-party tools.

For installations needing a more flexible method where the set of tools may vary, you may use the helm command option --set-file to load your installation script into the container using the customScript key.

For instance, the example below contains commands to install git, and other tools, in the pod using the yum or dnf package manager.

yum update -y && yum -y install git && \
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl \
      -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl && \
chmod +x ./kubectl && \
mv ./kubectl /usr/local/bin▼

To reference your script’s file when running helm install or helm upgrade, use set-file with the customScript directive:

--set-file customScript=<customScript-file>▼

By default, agents do not run as root. To allow your agent to run custom scripts that require root access, such as package installers, you must set the Helm security context:

--set securityContext.enabled=true --set securityContext.runAsUser="0"▼

Install CloudBees CD/RO agent

Before you start:

Your agent(s) are installed in the same namespace as the CloudBees CD/RO server, so you must already have the CloudBees CD/RO server installed in your cluster before proceeding. If you need to install the CloudBees CD/RO server, refer to CloudBees CD/RO server installation. The following commands refer to this namespace file as <production-server-namespace>.
Agents may need project-specific values set in the cloudbees-flow-agent Helm chart before installation. If you have not already done so, refer to Configure CloudBees CD/RO agent values. The following commands refer to this values file as <production-agent-myvalues.yaml>.
Agents may need project-specific third-party tools to accomplish the intended tasks they are installed to do, refer to Configure agent third-party tools. These tools may be included as a container in your cluster or dynamically loaded when you install the agent (--set-file customScript). The following command examples include the [--set-file customScript=<customScript>] option, but you can omit it if it doesn’t apply to your installation.

To get started installing the agent:

Ensure the CloudBees repo is up-to-date:
```
helm repo update▼
```

Ensure you have the correct namespace for the CloudBees CD/RO server. You can get the current namespaces by running:

kubectl get namespace▼

In the following command, the namespace is referenced as <production-server-namespace>. You must install the agent in the same namespace as the CloudBees CD/RO server instance where you want to connect.

Once you have your project-specific values file and have confirmed the CloudBees CD/RO server namespace, to install the agent run:

helm install <agentReleaseName> cloudbees/cloudbees-flow-agent \
      -f <production-agent-myvalues.yaml> \
      --namespace <production-server-namespace> \
      --timeout 10000s \
# Optional if you need to add or update third-party tools:
      --set-file customScript=<customScript-file>▼

The installation takes several minutes. Once the pods are all running, you can track the progress of the CloudBees CD/RO agent initialization, via the Kubernetes dashboard. Once all pods have been initialized, you can begin working with the CloudBees CD/RO agent.

Update CloudBees CD/RO agent

If you want to make changes to the project-specific agent:

Make any changes and save them in your project-specific myvalues.yaml.

Run:

helm upgrade <agentReleaseName> cloudbees/cloudbees-flow-agent \
      -f <production-agent-myvalues.yaml> \
      --namespace <production-server-namespace> \
      --timeout 10000s \
# Optional if you need to add or update third-party tools:
      --set-file customScript=<customScript-file>▼

The installation takes several minutes. Once the pods are all running, you can track the progress of the CloudBees CD/RO agent initialization, via the Kubernetes dashboard. Once all pods have been initialization, you can begin working with the CloudBees CD/RO agent.

Custom settings required for Red Hat OpenShift installations

Red Hat OpenShift installations require a service account named cbflow, and must be associated with the OpenShift project.

Service Account:

Ensure the account is being created in the project.
The account can be configured by navigating to User Management Service Accounts Create Service Account.
Enter cbflow as the name and select Create.

Required settings:

dois.openshiftNodeTuning=true
ingress.route=true
nginx-ingress.enabled=false (Kubernetes versions 1.21 and earlier)
ingress-nginx.enabled=false (Kubernetes versions 1.22 and later)

Settings to disable running CloudBees CD/RO containers in privileged mode:

dois.sysctlInitContainer.enabled=false
volumePermissions.enabled=false
mariadb.securityContext.enabled=false
mariadb.volumePermissions.enabled=false

Setting to disable Ingress controller:

Since CloudBees CD/RO depends on OpenShift routes to expose services, you can disable the creation of an Ingress controller by setting nginx-ingress.enabled=false for Kubernetes versions 1.21 and earlier or ingress-ngnix.enabled=false for Kubernetes versions 1.22 and later.

Load balancing with AWS Application Load Balancer (ALB)

Beginning with CloudBees CD/RO v10.3.2, support has been added for AWS Application Load Balancer (ALB). ALB can be used for application layer (layer 7) load balancing and includes several features for CloudBees CD/RO deployments on EKS, including:

Simplified deployment of microservices and container-based applications
Content-based routing
Redirects

Prerequisites

ALB support requires access to AWS with administrative privileges as it involves IAM configuration.

Follow the steps from AWS Load Balancer Controller to install the ALB controller in the EKS cluster.

ALB support requires EKS version 1.19 or later and AWS Load Balancer Controller 2.2.0 or later.
Create a certificate in AWS Certificate Manager for the required domain name. For example, cloudbees-cd.example.com.
Set up External-DNS using the tutorial for AWS.

Configuring `values.yaml` for ALB support

The following stanza from the values.yaml configuration enables support for ALB.

ingress:
  enabled: true
  host: cloudbees-cd.example.com
  class: alb
  annotations:
      alb.ingress.kubernetes.io/certificate-arn: <certificate-arn>
platform: eks

nginx-ingress:
  enabled: false▼

Configuring external client component access with ALB enabled

The following endpoints are needed for user command-line access to the CD artifact repository and CD server:

flow-repository:8200
flow-server:8443
flow-server:61613

Agents running outside a cluster access these endpoints via the external gateway (bidirectional tcp port 7800). However, ALB does not support exposing non-web TCP ports. You must configure the required endpoints on an external load balancer service (ELB) using the following parameters that are set as false by default:

--set server.externalService.enabled=true
--set repository.externalService.enabled=true▼

To get the DNS of the external exposed load balancer, run the following commands, where <namespace> is the release namespace.

export DEPLOY_NAMESPACE=<namespace>

SERVER_LB_HOSTNAME=$(kubectl get service flow-server-external -n $DEPLOY_NAMESPACE \
      -o jsonpath="{.status.loadBalancer.ingress[0].hostname}")
echo "Available at: https://$SERVER_LB_HOSTNAME:8443/"


REPO_LB_HOSTNAME=$(kubectl get service flow-repository-external -n $DEPLOY_NAMESPACE \
      -o jsonpath="{.status.loadBalancer.ingress[0].hostname}")
echo "Available at: https://$REPO_LB_HOSTNAME:8200/"▼

Resolving an ingress class name conflict

If you have an ingress class name conflict during your upgrade, update the default ingress class name for the ingress-nginx controller with the additional values below.

ingress:
  enabled: true
  host: yourhost.example.com
  class: <ingress-class-name>

ingress-nginx:
  enabled: true
  controller:
    ingressClassResource:
      name: <ingress-class-name>
nginx-ingress:
  enabled: false▼

After you update the class name, patch the existing ingress by running the command below.

kubectl patch ingress/flow-ingress -p '{"spec": {"ingressClassName":"<ingress-class-name>" }}' -n <namespace>▼

If you have a DNS/SSL issue, restart your ingress-nginx pod to mount the local certificates by running the command below.

kubectl get deployments -n <namespace> | grep ingress-nginx
XXXXX-ingress-nginx-controller   1/1     1            1           56m
kubectl rollout restart deployment XXXXX-ingress-nginx-controller -n <namespace>▼

Your upgrade is complete.

Load balancing with ingress

This CloudBees CD/RO chart provides support for load balancing with the NGINIX Ingress controller, which allows simple host and URL-based HTTP routing. Note that an Ingress controller typically does not eliminate the need for an external load balancer—it simply adds a layer of routing and control behind the load balancer. With Ingress configured, all service endpoints, such as web, server, and repository, are exposed from the same domain name and load balancer endpoint.

As a best practice, configure the Ingress controller so that all CloudBees CD/RO services can be exposed through a single load balancer. By default, Ingress is enabled in the CloudBees CD/RO chart. Following is a summary of the settings:

To run CloudBees CD/RO with Kubernetes 1.22 and later, you must use the ingress-nginx controller with the following required settings:

ingress-nginx.enabled=true
ingress.class=nginx
nginx-ingress.enabled=false

Kubernetes versions 1.21 and earlier

nginx-ingress.controller.ingressClass

Default: flow-ingress

nginx-ingress.controller.publishService.enabled

Default: true

nginx-ingress.controller.scope.enabled

Default: true

nginx-ingress.enabled

Default: true

nginx-ingress.tcp.61613

CloudBees CD/RO server

Default: {{ .Release.Namespace }}/flow-server:61613

nginx-ingress.tcp.8200

CloudBees CD/RO repository

Default: {{ .Release.Namespace }}/flow-repository:8200

nginx-ingress.tcp.8443

CloudBees CD/RO web server

Default: {{ .Release.Namespace }}/flow-server:8443

nginx-ingress.tcp.9200

CloudBees Analytics Elasticsearch database

Default: {{ .Release.Namespace }}/flow-devopsinsight:9200

nginx-ingress.tcp.9500

CloudBees Analytics server

Default: {{ .Release.Namespace }}/flow-devopsinsight:9500

Kubernetes versions 1.22 and later

ingress-nginx.controller.ingressClass

Default: flow-ingress

ingress-nginx.controller.publishService.enabled

Default: true

ingress-nginx.controller.scope.enabled

Default: true

ingress-nginx.enabled

Default: true

ingress-nginx.tcp.61613

CloudBees CD/RO server

Default: \{\{ .Release.Namespace }}/flow-server:61613

ingress-nginx.tcp.8200

CloudBees CD/RO repository

Default: \{\{ .Release.Namespace }}/flow-repository:8200

ingress-nginx.tcp.8443

CloudBees CD/RO web server

Default: \{\{ .Release.Namespace }}/flow-server:8443

ingress-nginx.tcp.9200

CloudBees Analytics Elasticsearch database

Default: \{\{ .Release.Namespace }}/flow-devopsinsight:9200

ingress-nginx.tcp.9500

CloudBees Analytics server

Default: \{\{ .Release.Namespace }}/flow-devopsinsight:9500

Horizontal pod autoscaler

A HorizontalPodAutoscaler (HPA) automatically updates a workload resource to scale the workload to match demand. HPA deploys additional pods in response to an increased load.

For more information, refer to Horizontal Pod Autoscaling.

CloudBees CD/RO includes horizontal pod autoscaling support for the following deployment components:

CloudBees CD/RO server
Web server
Repository server

CloudBees CD/RO server

The CloudBees CD/RO server supports HPA only when clusteredMode is true.

To enable HPA for the CloudBees CD/RO server, add the following parameter values:

server:
  autoscaling:
    enabled: true # enable: true to enable HPA for server
    minReplicas: 1 # Min Number of Replicas
    maxReplicas: 3 # Max Number of Replicas to scale
    targetCPUUtilizationPercentage: 80 # CPU Threshold to scale up
    targetMemoryUtilizationPercentage: 80 # Memory Threshold to scale up
    templates: []
    # Custom or additional autoscaling metrics
    # ref: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics
    # - type: Pods
    #   pods:
    #     metric:
    #       name: repository_process_requests_total
    #     target:
    #       type: AverageValue
    #       averageValue: 10000m▼

server.autoscaling.minReplicas must match server.replicas.

Web server

The web server supports scaling in both cluster and non-cluster modes.

To enable HPA for the web server, add the following parameter values:

web:
  autoscaling:
    enabled: true # enable: true to enable HPA for web
    minReplicas: 1 # Min Number of Replicas
    maxReplicas: 3 # Max Number of Replicas to scale
    targetCPUUtilizationPercentage: 80 # CPU Threshold to scale up
    targetMemoryUtilizationPercentage: 80 # Memory Threshold to scale up
    templates: []
    # Custom or additional autoscaling metrics
    # ref: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics
    # - type: Pods
    #   pods:
    #     metric:
    #       name: repository_process_requests_total
    #     target:
    #       type: AverageValue
    #       averageValue: 10000m▼

web.autoscaling.minReplicas must match web.replicas.

Repository server

The repository server supports scaling in both cluster and non-cluster modes.

To enable HPA for the repository server, add the following parameter values:

repository:
  autoscaling:
    enabled: true # enable: true to enable HPA for repository
    minReplicas: 1 # Min Number of Replicas
    maxReplicas: 3 # Max Number of Replicas to scale
    targetCPUUtilizationPercentage: 80 # CPU Threshold to scale up
    targetMemoryUtilizationPercentage: 80 # Memory Threshold to scale up
    templates: []
    # Custom or additional autoscaling metrics
    # ref: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics
    # - type: Pods
    #   pods:
    #     metric:
    #       name: repository_process_requests_total
    #     target:
    #       type: AverageValue
    #       averageValue: 10000m▼

repository.autoscaling.minReplicas must match repository.replicas.

Installation

Getting started

Install CloudBees CD/RO demo server

Before you install CloudBees CD/RO production server

Configure CloudBees CD/RO server values

Use the default values file to create your project-specific values file

Use an example production values file to create your project-specific values file

Install CloudBees CD/RO production server

Update CloudBees CD/RO production servers

Configure CloudBees Analytics server certificates

Install and update CloudBees CD/RO agents

Configure CloudBees CD/RO agent values

Configure agent third-party tools

Install a project-specific agent image

Install third-party tools from script

Install CloudBees CD/RO agent

Update CloudBees CD/RO agent

Custom settings required for Red Hat OpenShift installations

Load balancing with AWS Application Load Balancer (ALB)

Prerequisites

Configuring values.yaml for ALB support

Configuring external client component access with ALB enabled

Resolving an ingress class name conflict

Load balancing with ingress

Kubernetes versions 1.21 and earlier

Kubernetes versions 1.22 and later

Horizontal pod autoscaler

CloudBees CD/RO server

Web server

Repository server

Configuring `values.yaml` for ALB support