I recently took the Argo CD course on Kodekloud. Which I fully recommend. It has video lessons + labs where you can practice what you learn in a sandbox environment. The last lesson was about how to integrate argoCD with a jenkins CI/CD workflow and I wanted to replicate that with my own resources and using AzureDevOps Pipelines instead of Jenkins, because I am already familiar with that.
So, to do this project, I also want to document it and write it in a tutorial format, for myself in the future and for whoever might find it useful here on the internet. It is not such a big project, maybe the name "mega" is too much. But I do anticipate I wil split it in several parts, maybe 5 or more.
Here is the plan
Spin up a kubernetes cluster in my own AWS account. With the help of terraform
Automate the infrastructure using an Azure pipeline.
Install argocd on such cluster
Fork the repo of k8's manifest files with example apps
Create an example app that was demo in the course,
solar-system
app, using an existing docker imageFork the solar-system php source code to have a development repo and be able to publish my own docker image.
Create a CI pipeline in AzDo to be able to automate the development process
Edit the deployment.yml to point to my own docker image
Add a step to the CI pipeline to update the image tag using GitVersion
Add a step to the CI pipeline to update the K8's yaml file with the new image tag
Add a script step to the CI pipeline to create a PR programmatically in the K8's repo
Test the workflow
ArgoCD is a very robust tool that helps you manage kubernetes deployments and all kinds of components. It works with a pull mechanism, polling on your source code and applying the changes automatically when needed, this is called syncing.
I created a diagram of how a CI/CD workflow of updating your kubernetes deployments would look like without ArgoCD.
In this architecture, we will have two separate repositories.
The repository for the solar-system app code (php files and Dockerfile)
The repository with the Kubernetes manifests yml files that describe how to deploy this app
For each repository, a manual human intervention is needed, let's say you want to add a feature to your app, you would create a new branch, commit to the branch, create a PR, merge it, and then the CI pipeline would run, testing your code, building it, and publishing a docker image of it in docker hub with a new tag.
solar-system:1.0.1 -> solar-system:1.0.2
Then, you would need to do another human commit to the K8's repo, in a new branch, create a PR and merge it. This commit would be updating the tag reference in the yaml file
spec:
containers:
- name: solarsystem
image: solar-system:1.0.2
After this PR is approved and the branch merged, we would have a CD pipeline in place to run kubectl apply
and update our deployment with the new app image reference.
This is a system that works perfectly fine, but to get all the advantages or ArgoCD. Let's examine how much our workflow would change and improve.
In this Diagram, we can see that we still have to use the same two repositories, but there is only one pipeline in place that we maintain and run.
The CI pipeline has expanded its functionality to not only push the image to docker hub, but also it automates the tag update in the K8's manifest repository. This will be done with a sed
command inside the pipeline. Additionally, we will use the Azure Pipelines API to create a Pull request (PR) programatically.
Therefore, there is less human intervention, we still need that a human approves this PR but it will be a much smoother process.
With ArgoCD in place, it knows about our K8's repository and it is polling for changes. When this PR is approved and merged, argoCD will automatically sync the changes and reflect them on our K8's infrastructure.
This is all for this first blog post in the series. Stay posted to my blog to read the next steps!