The DevOps Toolkit: Working with Jenkins X/

...

/

Installing Jenkins X Using GitOps Principles

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

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.

Press + to interact
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.

Press + to interact
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.

Press + to interact
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.

Press + to interact
cd environment-$CLUSTER_NAME-dev
cat jx-requirements.yml

The output is as follows.

Press + to interact
cluster:
  clusterName: ""
  environmentGitOwner: ""
  project: ""
  provider: gke
  zone: ""
gitops: true
environments:
- key: dev
- key: staging
- key: production
ingress:
  domain: ""
  externalDNS: false
  tls:
    email: ""
    enabled: false
    production: false
kaniko: true
secretStorage: local
storage:
  logs:
    enabled: false
    url: ""
  reports:
    enabled: false
    url: ""
  repository:
    enabled: false
    url: ""
versionStream:
  ref: "master"
  url: https://github.com/jenkins-x/jenkins-x-versions.git
webhook: 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 variable CLUSTER_NAME. If you already forgot it, execute echo $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 variable PROJECT, so feel free to output it with echo $PROJECT if you are forgetful.
  • Set cluster.provider to gke or to eks 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
...