What happens during installation
The Jenkins X CLI will do the following when installing the Jenkins X platform:
Install client binaries to manage your cluster
Homebrewto install the various CLI. It will install it if not present.
kubectl is the CLI of Kubernetes. It allows you to interact with your Kubernetes cluster via the API server.
Jenkins X will install the helm client - (either helm 2.x or helm 3), if it does not already exist in your command shell path. Helm is used for packaging applications/resources (called charts) on Kubernetes, and is rapidly becoming the default standard for doing so.
Install cloud provider CLI
If you are using a public cloud, there will be an associated CLI for interacting with it. When install is called via the jx create cluster command, the associated binary to your cloud provider will also be installed, if not present on your command shell path.
azfor AKS cluster (Azure)
gcloudfor GKE cluster (Google Cloud)
kopsfor AWS cluster (Amazon Web Services)
eksctlfor AWS EKS cluster
ocifor OKS cluster (Oracle Cloud)
If you want to run Jenkins X locally via minikube or minishift, the following binaries are added:
oc(OpenShift CLI) and
minishiftfor a local minishift cluster (OpenShift)
minikubefor a local minikube cluster
Last but not least, Jenkins X will install the VM driver when required, typically
xhyve for Mac OS X or
hyperv for Windows. Other drivers (VirtualBox, VMWare…) must be installed manually.
Create the Kubernetes cluster
The cluster is then created using the cloud provider CLI (for example
az aks create command for Azure).
Setup the Jenkins X platform
Create the Jenkins X namespace
Then Jenkins X install will create a namespace for the Jenkins X platform where all the Jenkins X infrastructure components will reside. The default is jx
Install Tiller (optional, only for Helm 2)
Tiller, the server part of Helm, is then deployed on the kube-system namespace. Helm is THE package manager of Kubernetes and is used subsequently to deploy all other components of Jenkins X.
Setup the Ingress controller
In a Kubernetes cluster, services and pods have IPs that are only routable from by the cluster network. In order for traffic to flow into the cluster, an Ingress must be created. An ingress is a collection of rules for routing traffic to your services inside Kubernetes. The ingress rules are configured in an ingress resource held on the Kubernetes API server, and an ingress controller has to be created to fulfil those ingress rules. Jenkins X does all this for you by setting up an ingress controller and associated backend plus ingress rules for the following services (once deployed):
jx upgrade ingress --cluster
Configure git source repository
Jenkins X requires a git repository provider to be able to create the environment repositories. It defaults to GitHub if you did not provide a git-provider-url parameter. You need to provide a username and a token that would be used to interact with the git, especially Jenkins.
Create Admin secrets
Jenkins X generates an administration password for Monocular/Nexus/Jenkins and save it in secrets. It then retrieves git secrets for the helm install (so they can be used in the pipelines).
Clone the cloud environments repo
The cloud environment repository holds all the specific configuration and encrypted secrets that will be applied to the Jenkins Platform on your Kubernetes cluster. The secrets are encrypted and unencrypted by the Helm package manager.
Install the Jenkins X platform
The Jenkins X Platform holds the Helm charts for installing the components that provide the Jenkins X true CD solution. These include
- Jenkins a CI/CD pipeline solution
- Nexus an artifact repository
- ChartMuseum - a Helm Chart repository
- Monocular which provides a Web UI for searching and discovering charts deployed into your cluster via Jenkins X.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.