Installing Jenkins X Using GitOps Principles
In this lesson, we will see how to install Jenkins X in accordance with GitOps principles and using the Jenkins X Boot.
We'll cover the following...
- Taking a look at the GitHub repository
- Defining variables
- Cloning the repository
- Exploring and modifying the jx-requirements.yml file
- The cluster section
- The gitops value
- The environments section
- The ingress section
- The kaniko value
- The secretStorage value
- The storage section
- The versionsStream section
- The webhook value
- Alternatives for Prow
- Adding additional information for EKS
- Did we miss any values?
- Installing Jenkins X with jx boot
How can we install Jenkins X in a better way than what we’re used to? Jenkins X configuration should be defined as code and reside in a Git repository, and that’s what the community created for us. It maintains a GitHub repository that contains the structure of the definition of the Jenkins X platform, together with a pipeline that will install it, as well as a requirements file that we can use to tweak it to our specific needs.
Taking a look at the GitHub repository
Let’s take a look at the repository.
open "https://github.com/jenkins-x/jenkins-x-boot-config.git"
We’ll explore the files in it a bit later. Or, to be more precise, we’ll explore those that you are supposed to customize.
Defining variables
Next, we’ll define a variable CLUSTER_NAME
that will, as you can guess, hold the name of the cluster we created a short while ago.
⚠️ In the commands that follow, please replace the first occurrence of
[...]
with the name of the cluster and the second with your GitHub user.
export CLUSTER_NAME=[...]export GH_USER=[...]
Cloning the repository
Now that we forked the Boot repo and we know what our cluster is called, we can clone the repository with a proper name that will reflect the naming scheme of our soon-to-be-installed Jenkins X.
git clone \https://github.com/jenkins-x/jenkins-x-boot-config.git \environment-$CLUSTER_NAME-dev
Exploring and modifying the jx-requirements.yml
file
The key file that contains (almost) all the parameters that can be used to customize the setup is jx-requirements.yml
. Let’s take a look at it.
cd environment-$CLUSTER_NAME-devcat jx-requirements.yml
The output is as follows.
cluster:clusterName: ""environmentGitOwner: ""project: ""provider: gkezone: ""gitops: trueenvironments:- key: dev- key: staging- key: productioningress:domain: ""externalDNS: falsetls:email: ""enabled: falseproduction: falsekaniko: truesecretStorage: localstorage:logs:enabled: falseurl: ""reports:enabled: falseurl: ""repository:enabled: falseurl: ""versionStream:ref: "master"url: https://github.com/jenkins-x/jenkins-x-versions.gitwebhook: prow
As you can see, that file contains values in a format that resembles requirements.yaml
file used with Helm charts. It is split into a few sections.
🔍 The format of the
jx-requirements.yml
file might have changed since I wrote this section, so your output might be different. Nevertheless, what I’m describing should give you a good enough grip over the values you can tweak, and you should be able to extend that knowledge to those not represented here.
The cluster
section
First, there is a group of values that define our cluster
. You should be able to figure out what it represents by looking at the variables inside it. It probably won’t take you more than a few moments to see that we have to change at least some of those values, so that’s what we’ll do next.
Please open jx-requirements.yml
in your favorite editor and change the following values.
- Set
cluster.clusterName
to the name of your cluster. It should be the same as the name of the environment variableCLUSTER_NAME
. If you already forgot it, executeecho $CLUSTER_NAME
. - Set
cluster.environmentGitOwner
to your GitHub user. It should be the same as the one we previously declared as the environment variable$GH_USER
. - Set
cluster.project
to the name of your GKE project, only if that’s where your Kubernetes cluster is running. Otherwise, leave that value intact (empty). If you used one my Gists to create a GKE cluster, the name of the project should be in the environment variablePROJECT
, so feel free to output it withecho $PROJECT
if you are forgetful. - Set
cluster.provider
togke
or toeks
or to any other provider if you decided that you are brave and want to try currently unsupported platforms. Or, the things might have changed since I wrote this chapter, and your provider is indeed supported now. - Set
cluster.zone
to whichever zone your cluster is running in. If you’re running a regional cluster (as you should) then the value should be the region, not the zone. If, for