Installation

7 minute readReference

CloudBees CD/RO server installation and upgrade

Overview

This option installs the CloudBees CD/RO server, built-in database, web server, and repository server into one cluster. A local bound agent and CloudBees CD/RO tools are also installed.

Make sure you are able to satisfy the cluster and storage requirements before proceeding.

In a production configuration, connect CloudBees CD/RO to a separate database. If CloudBees CD/RO is initially installed with the built-in database, you can reconfigure it to use a separate database at any time. Refer to Database configuration for further details.

Using a separate database requires a CloudBees CD/RO enterprise license. You must configure an external database at the same time as you install your enterprise license to prevent error messages about an unsupported configuration or a license requirement.

Installation

Create your custom values file to override Helm chart values for your installation. For your convenience, preconfigured values files are available here to get you started. Use these files as is, or use them as a starting point.

Best practice is to make a local copy of one of the preconfigured files and modify that local copy with your settings, as needed. That way, you have a record of your configuration when it comes time to update your installation.
If all of your Kubernetes nodes are tainted you require one node without a taint on which to run the flow-server-init-job pod. After the install is complete, that node can be tainted or deleted.
Values file Decription

cloudbees-cd-demo.yaml

File for use with non-production installations. It configures a single node CloudBees CD/RO server installation with a non-production license and installs MariaDB as the database.

cloudbes-cd-prod.yaml

File for use with production installations. You must configure your database, storage and CloudBees CD/RO credentials in a local copy of this file before it can be used.

cloudbees-cd-defaults.yaml

File listing all Helm chart values along with their default value. Use as a reference when specifying additional configuration in your local values file.

Add public CloudBees repository as follows:

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

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

helm install releaseName cloudbees/cloudbees-flow \ -f valuesFile --namespace nameSpace --timeout 10000s helm upgrade releaseName cloudbees/cloudbees-flow \ -f valuesFile --namespace nameSpace --timeout 10000s

where:

releaseName

A user-defined name for this particular installation. If not specified, one is generated for you.

valuesFile

The local YAML-formatted values file with your specific chart override values. Specify something like my-values.yaml. If not specified, default chart values are used, as defined in the cloudbees-example repo.

nameSpace

A user-defined name for the namespace under which CloudBees CD/RO components are installed.

CloudBees CD/RO installation takes several minutes. Once all the pods are running, you can track the progress of the CloudBees CD/RO server initialization,via the flow-server-init-job job log file in the Kubernetes dashboard.

CloudBees CD/RO agent installation and upgrade

Overview

This option installs the CloudBees CD/RO agent, only. This allows for configuring multiple agents separately to fit your particular needs. You must have already installed the CloudBees CD/RO server in the cluster. If you need to install the CloudBees CD/RO server, see CloudBees CD/RO server installation and upgrade before proceeding with the agent installation below.

Installation

Create your custom values file to override Helm chart values to use for installing the agents. For your convenience, preconfigured values files are available here to get you started. Use these files as is, or use them as a starting point.

Best practice is to make a local copy of one of the preconfigured files and modify that local copy with your settings, as needed. That way, you have a record of your configuration when it comes time to update your installation.

When multiple replicas are configured in the values file, via the replicas value, pay particular attention to the way in which the agent resource name template is defined so that all replicas are registered properly. See Agent resource name templates for complete information.
Values file Decription

cloudbees-cd-agent-example.yaml

Example file to use for an agent installation. You must configure your agent settings in a local copy of this file before it can be used.

cloudbees-cd-agent-defaults.yaml

File listing all Helm chart values along with their default value. Use as a reference when specifying additional configuration in your local values file. cloudbees-flow-agent chart configuration values for details about values in this file.

Add public CloudBees repository as follows:

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

Run the following Helm command to install or upgrade.

Before initiating an install operation, you must create a namespace, as follows.

kubectl create namespace <nameSpace>

Then proceed with the installation.

helm install <agentReleaseName> cloudbees/cloudbees-flow-agent \ -f <agentValuesFile> --namespace <nameSpace> --timeout 10000s \ [--set-file customScript=<customScript>] helm upgrade cloudbees/cloudbees-flow-agent \ -f <agentValuesFile> --namespace <nameSpace> --timeout 10000s \ [--set-file customScript=<customScript>]

where:

agentReleaseName

A user-defined name for this particular installation.

agentValuesFile

The local YAML-formatted values file with your specific chart override values. Specify something like my-values.yaml. If not specified, default chart values are used, as defined in the cloudbees-example repo.

nameSpace

A user-defined name for the namespace under which the CloudBees agent is installed. Specify the same name used for CloudBees CD/RO server namespace.

customScript

The local file path for a user-defined script to be installed in the agent container. See Configuring third-party tools.

Configuring third-party tools

CloudBees CD/RO agents typically do work using third-party tools installed on or accessible to the agent. In a traditional deployment, this typically means that the tools are installed locally on the agent machine. For agents running in a Kubernetes cluster, third-party tools can be deployed in agent container so they are immediately accessible by the agent. Configuration can be accomplished in one of the following ways: making a custom image or dynamically configuring the tools.

Making a custom container

For installations where the set of third-party tools is well defined and static, create your own container using the the CloudBees CD/RO agent image as the base image to which the third-party tools are added. Below is an example Dockerfile configuring the custom container.

Replace 10.0.1.143076_2.0.12_20200729 in the FROM directive below with the current tag found in the CloudBees CD/RO agent Helm chart default values file, cloudbees-cd-agent-defaults.yaml, found here.
FROM cloudbees/cbflow-agent:10.0.1.143076_2.0.12_20200729 RUN apt-get update && \ apt-get install git apt-utils apt-transport-https wget curl gnupg gnupg2 gnupg1 -y apt-get update && curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | \ apt-key add - && \ echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | \ tee -a /etc/apt/sources.list.d/kubernetes.list curl -L https://git.io/get_helm.sh | bash

Creating a custom script

For installations needing a more flexible method, where the set of tools may vary, use the --set-file option to the helm command to load the installation script into the container using the customScript key. The example custom script below contains commands to install git, and other tools, in the pod using the apt-get package manager.

apt-get update apt-get install git apt-utils apt-transport-https wget curl gnupg gnupg2 gnupg1 -y apt-get update && curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | \ apt-key add - && \ echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | \ tee -a /etc/apt/sources.list.d/kubernetes.list curl -L https://git.io/get_helm.sh | bash

By default, agents do not run as root. To run custom scripts that require root access, such as package installers, it is necessary to change the Helm security context using the following settings with the helm command.

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

Custom settings required for Red Hat OpenShift installations

Red Hat OpenShift installations require a service account named cbflow, and be must 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

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, disable creating an Ingress controller by setting nginx-ingress.enabled=false.

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.

  1. 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.

  2. Create a certificate in AWS Certificate Manager for the required domain name. For example, cloudbees-cd.example.com.

  3. 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/"

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 doesn’t eliminate the need for an external load balancer—it simply adds an additional layer of routing and control behind the load balancer. With Ingress configured, all service endpoints like 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:

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