Thought it’d be good to quickly show you how to get your Jenkins X cluster up and running using JX Boot and using the specific jx version below. You’ll also notice, I am using the Replicator App which is one of many you can use in this repository. The Replicator App helps you keep secrets in sync between Kubernetes namespaces.
To get started, you will need to have the following in place:
- A GCP account, with admin rights, or have the ability to create resources.
jxbinary. On OS X, simply issue
brew install jenkins-x/jx/jx. For others take a look here.
- You have
jxinstalled and a cluster running in GKE for example.
My environment has the following versions installed.
➜ jx version NAME VERSION jx 2.0.1116 Kubernetes cluster v1.13.11-gke.14 kubectl v1.16.0 helm client Client: v2.13.1+g618447c git 2.21.0 Operating System Mac OS X 10.14.6 build 18G103
jx create cluster gke --skip-installationWe are creating the Kubernetes cluster using the CLI. However, you can provision your cluster using whatever methods are acceptable in your environment. I am a big fan of Terraform! Be sure to have RBAC enabled.
NOTE: The Git repositories are private by default. One way to handle this, is to cancel the boot command once you get this warning. At this point the boot git repo has been pulled locally to your current directory where you executed the command. Simply add
environmentGitPublic: trueunder the
clusternode on the
jx-requirements.yaml, then run jx boot again to continue. This is kinda painful, but there is an open issue to make it possible to customize the
jx-requirements.yamlbefore executing boot.
If you are using a custom domain, execute the following command to create a GCP Cloud DNS Zone
jx create domain gke -d cjxd.sharepointoscar.com(in my case).
Update jx-requirements.yaml ingress to use your custom domain and enable TLS, it should look similar to the following
gitops: true ingress domain: cjxd.sharepointoscar.com externalDNS: true namespaceSubDomain: . tls: email: firstname.lastname@example.org enabled: true production: true
In the background the
devrepository is being modified via a PR and a pipeline is being triggered to make the changes to your actual Kubernetes cluster.
The end results in my case is as follows:
# check ingress objects using kubectl >$ kubectl get ing NAME HOSTS ADDRESS PORTS AGE chartmuseum chartmuseum.cjxd.sharepointoscar.com 18.104.22.168 80, 443 73m deck deck.cjxd.sharepointoscar.com 22.214.171.124 80, 443 73m hook hook.cjxd.sharepointoscar.com 126.96.36.199 80, 443 73m nexus nexus.cjxd.sharepointoscar.com 188.8.131.52 80, 443 73m tide tide.cjxd.sharepointoscar.com 184.108.40.206 80, 443 73m # check ingress objects using jx cli >$ jx get urls NAME URL deck https://deck.cjxd.sharepointoscar.com hook https://hook.cjxd.sharepointoscar.com nexus https://nexus.cjxd.sharepointoscar.com tide https://tide.cjxd.sharepointoscar.comg
Add the secret replicator app which makes it easy to keep secrets across Kubernetes namespaces in sync. Execute
jx add app jx-app-replicator -v 1.0.16 --repository https://storage.googleapis.com/chartmuseum.jenkins-x.io
Trigger a pipeline to replicate secrets into staging and production namespaces. Execute
jx step replicate secret "tls-*" -r jx-staging -r jx-production --create-namespace
Congratulations, you now have a fully functional cluster!
What is CJXD?
I mentioned it on the title of this post, but what is it?
CloudBees Jenkins X Distribution provides a stable, predictable release line for teams building cloud native Kubernetes-based applications with Jenkins X. It comes battle tested and ready for production workloads with support and documentation vetted by CloudBees. As Jenkins X rapidly evolves, so will CloudBees Jenkins X Distribution with stability and reliability in the forefront. - Cloudbees
You can use it to deploy it in large enterprise environments where change management is in place, and you want to have more control of the platform. Learn how to easily install it at the docs site.