Cloud Providers
Using Boot on different Kubernetes providers
Jenkins X Boot uses the following approach:
Create your Kubernetes cluster using Terraform. Please check out our Cloud Providers Guide on our recommendations for your cloud provider. To verify you can communicate correctly with your Kubernetes cluster run:
kubectl get ns
Run the jx boot command:
jx boot
You will now be prompted for any missing parameters required to install, such as your admin user/password, the Pipeline git user and token etc.
Then Jenkins X should be installed and set up on your Kubernetes cluster.
If one of the steps in jx boot
fails for some reason, instead of running all the steps, you can start boot from that
particular step in two ways:
JX_BOOT_START_STEP
: JX_BOOT_START_STEP=<name of the step> jx boot
--start-step
or it’s shorthand -s
flag: jx boot -s=<name of the step>
Alternatively, you can also end jx boot
at a step by using the environment variable JX_BOOT_END_STEP
.
jx boot
The jx boot interprets the boot pipeline using your local jx
binary.
The underlying pipeline for booting Jenkins X can later be run inside Kubernetes via Tekton.
If ever something goes wrong with Tekton you can always jx boot
again to get things back up and running (e.g., if someone accidentally deletes your cluster).
Before any installation is attempted, Boot runs the jx step verify preinstall command to check everything looks OK. It will also check whether your installed package versions are within the upper and lower version limits.
Once the installation has completed the jx step verify install command is run to verify your installation is valid.
At any time you can re-run jx boot to re-apply any changes in your configuration.
To do this git clone your development environment git repository, change directory into the git clone and run jx boot
. e.g.
git clone https://github.com/myuser/environment-mycluster-dev.git
cd environment-mycluster-dev
jx boot
So just edit anything in the configuration you like and re-run jx boot - whether that’s to add or remove apps, to change parameters or configuration, or upgrade or downgrade versions of dependencies.
Note that you can also just submit a Pull Request on your development git repository which if merged, will trigger a pipeline to run the above commands to apply the changes.
There is a file called jx-requirements.yml which is used to specify the logical requirements of your installation; such as:
This is the main configuration file for jx boot
where you make most of your changes.
You may want to review the jx-requirements.yml file and make any changes you need.
If you’re looking for a UI check out Octant the open source web UI for Jenkins X
Using Boot on different Kubernetes providers
How does Jenkins X Boot work
Configure secret storage - local vs Vault
Configure SCM Providers / Git providers supported by Jenkins X
Configure long term storage for logs and reports
Configure Ingress, DNS and TLS
Configure Webhooks
Configure various artifact repositories used by 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.