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:
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 separatevalues.yaml
for each component in thecharts/<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-specificmyvalues.yaml
under version control. This is to help avoid confusion with the defaultvalues.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
|
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 thancloudbees-cd-demo.yaml
, use its file name as thehelm install -f
values file. If you make changes to the file, CloudBees recommends you save it as a project-specificmyvalues.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 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 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.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-specificmyvaules.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.
-
(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 thevalues.yaml
during installation. This means, you can also delete any configuration options in yourmyvalues.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 |
---|---|
|
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. |
|
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. -
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.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-specificmyvaules.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.
-
(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 yourmyvalues.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:
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 thevalues.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 yourresourceName
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:
|
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
. -
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 oringress-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: |
nginx-ingress.controller.publishService.enabled |
Default: |
nginx-ingress.controller.scope.enabled |
Default: |
nginx-ingress.enabled |
Default: |
nginx-ingress.tcp.61613 |
CloudBees CD/RO server Default: |
nginx-ingress.tcp.8200 |
CloudBees CD/RO repository Default: |
nginx-ingress.tcp.8443 |
CloudBees CD/RO web server Default: {{ .Release.Namespace }}/flow-server:8443 |
nginx-ingress.tcp.9200 |
CloudBees Analytics Elasticsearch database Default: |
nginx-ingress.tcp.9500 |
CloudBees Analytics server Default: |
Kubernetes versions 1.22 and later
ingress-nginx.controller.ingressClass |
Default: |
ingress-nginx.controller.publishService.enabled |
Default: |
ingress-nginx.controller.scope.enabled |
Default: |
ingress-nginx.enabled |
Default: |
ingress-nginx.tcp.61613 |
CloudBees CD/RO server Default: |
ingress-nginx.tcp.8200 |
CloudBees CD/RO repository Default: |
ingress-nginx.tcp.8443 |
CloudBees CD/RO web server Default: |
ingress-nginx.tcp.9200 |
CloudBees Analytics Elasticsearch database Default: |
ingress-nginx.tcp.9500 |
CloudBees Analytics server Default: |
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 .
|