About on JayeX - Cloud Native CI/CD Built On Kubernetes

What is JayeX?

Mon, 01 Jan 0001 00:00:00 +0000

JayeX automates and accelerates Continuous Integration and Continuous Delivery for developers on the cloud, so they can focus on building awesome software.

Embracing popular open source projects JayeX automates the setup and management to provide an integrated Cloud Native solution teams can use to develop better software faster and more reliably than traditional non cloud solutions.

Open Source projects that JayeX integrates with:

Kubernetes target platform JayeX is installed onto, optionally deploy and run applications built with JayeX
Tekton Cloud Native pipeline orchestration
Kuberhealthy Periodic health checks of the systems
Grafana [optional] Centralised logs and Observability
Jenkins [optional] traditional pipeline orchestration
Nexus [optional] artifact repository

At a high level JayeX can be split into a few areas:

Changes

Mon, 01 Jan 0001 00:00:00 +0000

You may also find the Roadmap and Maturity Matrix documents useful:

Breaking Changes

we have noticed a regression in the auto upgrade jobs which causes them to fail with an error like this:

updatebot WARNING: no $GIT_SECRET_MOUNT_PATH environment variable set                      
updatebot error: failed to setup git: failed to clone the cluster git URL: failed to clone cluster git repository https://github.com/myorg/myrepo.git: failed to clone cluster git repo https://github.com/
updatebot fatal: could not read Username for 'https://github.com': No such device or address

you can fix this by following the workarounds on this issue which should get you past this and working auto upgrade jobs again

Maturity Level Matrix

Mon, 01 Jan 0001 00:00:00 +0000

This maturity matrix describes the tentative plan post JayeX v3.0 GA release. This matrix will continue to evolve as we progress further.

Benefits

Mon, 01 Jan 0001 00:00:00 +0000

We can use vanilla tools like helm 3, helmfile, kustomize, kpt to install, update or delete charts in any namespace without needing helm 2.x or tiller or custom code to manage helm template.
- We can avoid all the complexities of the jx step helm apply logic we used in JayeX 2.x
- Instead we can replace this with vanilla helmfile to allow optional templating of values.yaml files when using helm
The new Getting Started approach is much simpler, easier to configure and customise and is cleanly integrated with tools like Terraform and works well with different cloud infrastructure platforms.
- The default install/upgrade pipelines check in all the generated kubernetes resources and custom resources as YAML so its easy to understand
- You can read more about the git layout here
  - The config-root/cluster folder contains all the global cluster level resources like ClusterRole, Namespace or Custom Resources
  - The config-root/namespaces/jx folder contains all the namespaced resources in the jx namespace
- This makes it easy to use flexible apply logic in different boot Jobs with different RBAC (or a system admin could apply the cluster level resources for you by hand) - to make it easier to install JayeX on more locked down and restricted clusters
We use Kubernetes External Secrets to provide a single way to manage secrets which supports the following back end systems:
- Alibaba Cloud KMS Secret Manager
- AWS Secrets Manager
- Azure Key Vault
- GCP Secret Manager
- Hashicorp Vault
It opens the door to a flexible multi-cluster support so that every cluster can be managed in the same canonical GitOps approach from a single git repository
The new getting started approach runs the boot pipeline as a Job inside the Kubernetes cluster. This ensures consistency in tooling used and also improves security by avoiding having the secrets on a developers laptop.
- The only thing you run on your local machine when installing JayeX is installing the git operator which is a simple helm chart.
Everything is now an app. So if you want to remove our nginx-ingress chart and replace it with another ingress solution (knative / istio / gloo / ambassador / linkerd or whatever) just go ahead and use the apps commands to add/remove apps and have boot manage everything in a consistent way
- e.g. here’s an example of removing chartmusem and nexus and replacing it with bucketrepo via a single simple yaml change.
You can install an app in a specific namespace if you wish
- This also opens the door to using boot to setup multi-team installations where multiple teams use different namespaces but share services in the same cluster
The cluster GitOps repository is simpler and easier to keep in sync/rebase/merge with the upstream git repositories.
- We use kpt to do that for us
- We now include the version stream inside your GitOps repository too inside the versionStream directory after installation so that all the information about your installation is inside a single git repository so its simpler to test changes & ensure consistency.
We can avoid composite charts to simplfiy configuration and upgrades
We no longer use exposecontroller, instead use regular helm configuration to create Ingress resources and override domain names
secret handling is currently much simpler using Kubernetes External Secrets for any secrets in any namespace or cluster for your own apps or for those used by JayeX.

Comparison

Mon, 01 Jan 0001 00:00:00 +0000

This document outlines the similarities and differences of the 3.x approach for those who are aware of jx boot with helm 2 in 2.x of JayeX.

Similarities between 2.x and 3.x

Just like classic boot with the jenkins-x-boot-config git repository, this new helmfile solution supports:

you can install and upgrade JayeX via GitOps
you can reuse helm charts from the internet, local charts or charts built by JayeX in any environment
a YAML file is used to store all the charts that are applied during install/upgrade

Differences with in 3.x

we support any permutation of tools such as: helm 3, helmfile, kustomize and/or kpt to create the kubernetes resources
in 3.x the installation/upgrade of JayeX is run inside the kubernetes cluster via a Job rather than on a developers laptop which helps with consistency and security.
in 3.x we use a single git repository for each cluster; which can manage as many teams/namespaces as you like within the cluster
- so any local environments like Staging which reside in the same kubernetes cluster are defined in the same git repository in 3.x - whereas in 2.x we used a separate git repository for Dev, Staging and Production when sharing the same cluster.
- if Dev, Preprod and Production environments are in separate kubernetes clusters then those will have a git repository each.
any helm chart can be deployed in any namespace (previously we used a single namespace for all charts in the env/requirements.yaml)
instead of using env/requirements.yaml we now use a simple and more powerful helmfile.yaml file which is similar but supports:
- we can specify a namespace on any chart
- we can add extra values files to use with the chart to override the helm values.yaml files
instead of copying lots of env/$appName/values*.yaml files into the boot config like we do in these folders such as the lighthouse/values.tmpl.yaml we can instead default all of these from the version stream at apps/jenkins-x/lighthouse - which means the boot config git repository is much simpler, we can share more configuration with the version stream and it avoids lots of git merge/rebase issues.
adding and removing apps in your GitOps repository causes those resources to be properly installed or uninstalled
- you can also review exactly what kubernetes resources will change on the Pull Request
we no longer use a composite chart for env/Chart.yaml and instead deploy each chart independently
- this means that each chart has its own unique version number you can see in the helmfile.yaml file
we have done away with the complexity of jenkins-x-platform (a composite chart containing logs of dependencies like jenkins + chartmuseum + nexus etc) so that each chart can be added/removed independently or swapped out with a different version/distribution

Removing complexity and magic

Removing complexity out of JayeX and reusing other solutions wherever possible. JayeX 2.x was tightly coupled to helm 2 for example. There were jx CLI steps that wrapped helm commands when installing applications into the cluster which injected secrets from an internal Vault and ultimately made it very confusing for users and maintainers.

How it works

Mon, 01 Jan 0001 00:00:00 +0000

How it works

The GitOps repository templates contain the source code, scripts and docs to help you get your cloud resources created (e.g. a kubernetes cluster and maybe buckets and/or a secret manager).

Once you have created the GitOps repository from one of the available templates and followed the instructions to set up your infrastructure you install the git operator via the jx admin operator command:

    jx admin operator

That command essentially installs the git operator chart, passing in the git URL, username and token to run the boot process.

Extending

Mon, 01 Jan 0001 00:00:00 +0000

JayeX has a number of extension points you can use to extend the CI/CD platform to suit your needs:

Charts

Helm charts are the standard way to package applications for kubernetes.

It’s easy to use GitOps to add charts to any of your clusters and customize them however you need.

You can also easily add one or more kubernetes resources to a cluster via a source layout chart

Plugins

The jx command line in version 3 is build on plugins.