Jenkins X 3 and Argo CD
There have been a number of requests from the Jenkins X community to use Argo CD for the last mile deployment phase of their continuous delivery pipelines. This blog explains some of the advantages of using Jenkins X and Argo CD all together.
- Jenkins X for Cloud Infrastructure using Terraform, core installation management with GitOps, external secret management, ingress controller, quickstarts, automated CI + CD pipelines, ChatOps
- Tekton for pipeline orchestration
- Argo CD for end users application deployments (not the main installation)
Argo CD provides a declarative GitOps approach to deploying Kubernetes based applications. There is a GUI which helps construct the deployment definition (in the form of an
Applicationcustom resource) which offers a number of configuration options, as well and providing insight into your clusters applications.
You might be wondering why you would want to use BOTH Jenkins X and Argo CD together. Jenkins X aims to embrace OSS, where possible providing a nice UX to integrate with other projects and help provide better solutions for building, developing and running software on Kubernetes. Jenkins X indeed does have a git operator that applies Kubernetes YAML from a Git repository but there are some differences:
Jenkins X uses GitOps principles for the entire installation, i.e. the starting point is a Git repository which is used to provision a cluster and manage (automatic if users wish) upgrades whereas today Argo CD uses a manual
kubectl applyto manage the Argo installation itself.
External Secrets integration for Vault, Google Secrets manager etc is something that Jenkins X provides out of the box. When Kubernetes based applications require a secret we prefer the source is stored in a secrets manager and the value synchronised automatically into the cluster enabling easier secret rotation, avoiding local secrets on machines and an easier UX for working with secrets. When adding an Application via Argo CD users can leverage the Jenkins X approach to working with secrets and rely on Argo to manage the deployments. If users prefer to work with SOPS that is totally fine too and will work in the same way as they are used to.
If you do not wish to expose direct access for the Kubernetes cluster to developers then using a combination of Jenkins X UI for accessing logs and Argo CD for managing application deployments may be enough.
Using the Jenkins X approach to promoting via automated pull requests via pipelines to add new helm charts and update chart release version numbers.
In a Jenkins X multi cluster setup you can choose to use jx-git-operator or Argo CD in the remote cluster to syncronise promoted applications into the staging or production clusters. This way you get all the benefits of the integrated Jenkins X experience to manage the build infrastructure and provide the developer experience like preview environments and chatops etc.
This is done by creating a new Git repository that will contain a number of Argo CD
Application Kubernetes resources. This also means we handle disaster recovery scenarios and are able to recover the Jenkins X installation which includes Argo CD plus any applications managed by Argo CD itself.
There may be a couple of models to try but here we are going to describe an approach we have validated when using Jenkins X to manage the core Kubernetes installation, using Tekton for Continuous Integration, Jenkins X for application promotion and Argo CD for deployments.
Install Argo CD with Jenkins X
- Prerequisite is a working Jenkins X 3 installation
- Add a Argo CD helmefile to your Jenkins X cluster git repository:
mkdir -p helmfiles/argocd
Create a new file
namespace: argocd releases: - chart: argocd/argo-cd name: argocd - chart: ../../charts/argo-applications name: argo-applications
Edit the root
./helmfile.yaml and add a new path reference to the helmfile above
- path: helmfiles/argocd/helmfile.yaml
Jenkins X will resolve default helm values from the Jenkins X version stream.
Create a new git repository to contain the Argo CD
ApplicationKubernetes resources, this means we can use Jenkins X pipelines to promote users applications via GitOps.
Back in your clusters Git repository create a new folder:
mkdir -p charts/argo-applications
create a file in the new folder and replace the
repoURL: with the Git URL from step 2 above.
apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: staging namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: destination: name: '' namespace: argocd server: 'https://kubernetes.default.svc' source: path: . repoURL: 'https://github.com/$REPLACE_WITH_GIT_OWNER/ $REPLACE_WITH_GIT_REPO' targetRevision: HEAD directory: recurse: true project: default syncPolicy: automated: prune: true selfHeal: true syncOptions: - Replace=true - CreateNamespace=true
- commit your changes and push
git add helmfiles/argocd/helmfile.yaml git add charts/argo/applications.yaml git commit -m 'feat: enable Argo CD' git push
If you are on a fork then PR your changes
- Follow Jenkins X admin logs to ensure Argo CD is installed
jx admin logs
- Get the Argo CD UI password using something like ksd or
base64 -Dto decode the value:
kubectl get secret argocd-initial-admin-secret -n argocd -oyaml | ksd
- Get the Argo CD UI hostname and login using the
adminusername + passowrd from step 6 above (you may need to accept insecure TLS browser prompt if not using production TLS)
kubectl get ing argocd-server -n argocd
- Create a new quickstart or update an existing Jenkins X applications
./lighthouse/jenkins-x/release.yamlpipeline, replaceing the Tekton
promote-jx-promotestep to use argo instead:
- image: uses:jenkins-x/jx3-pipeline-catalog/tasks/updatebot/release.yaml@versionStream name: promote-release script: | #!/usr/bin/env sh source .jx/variables.sh jx updatebot argo promote --target-git-url https://github.com/$REPLACE_WITH_GIT_OWNER/$REPLACE_WITH_GIT_REPO
Now merge a change to your application or manually trigger a release pipeline
jx pipeline start to get a new release and promote using Argo CD.
Once the release pipeline finished for your application you should see a new
application.yaml resource in your uber application Git repository we created in step 2 above.
Once this change is merged to the main branch Argo detects the new chart / version and applies it to the cluster. You will be able to track the status and health of the deployment via the GUI that you logged in with step 7 above.
I really did like the experience of Argo CD, there’s some overlaps with Jenkins X across the wider projects however I think there’s enough of a differentiation for both to complement each other. What I loved was that both projects as well as others like flux promote the use of GitOps. Anyways, congratulations to the Argo project and I hope users from both communities find this blog useful and / or interesting.