GitHub Actions and Argo CD to Establish a GitOps Workflow

There’s a good reason why GitOps is becoming more and more popular these days. Utilizing Git repositories as the last source of truth for application infrastructure and configuration is encouraged by the tenets of the GitOps methodology. The idea behind this is to use a Git repository as the core location for deployment management, where all application-related files and manifests are kept. You may greatly enhance your deployment workflow and accelerate the shipping operations to produce faster and more effective outcomes by fusing the ideas of GitOps with declarative continuous delivery technologies like Argo CD.

But many people find that this method is too difficult to implement, so they start off by making unnecessary complicating it and give up. My goal in writing this piece is to Challenge this misconception and show how easy it is to get going.

What Our Final Outcome Would Look Like

Before we get into the specifics of putting up a GitOps workflow, let’s take a moment to envision the ultimate outcome. Our goal is to fully automate the delivery pipeline. Once the setup is complete, developers may focus solely on developing code. When a commit is merged into our main branch, our workflow will be as follows:

1. Begin the image creation process
2. Upload it to an image registry.
3. Update our manifests with the most recent tag.
4. Allow Argo CD to perform cluster updates.

You might ask, ‘Why do we use ArgoCD?

The best part of Argo CD is that we just need to change our application manifests — which are kept in a Git repository — when we use it. These modifications are automatically identified by Argo CD and applied to the Kubernetes cluster. It does not require a human “push” of updated manifests to the cluster; instead, it “pulls” from the Git repository and treats it as the desired state. This strategy is far superior because:

1. Version control makes it easier to track changes over time.
2. Increases transparency and security by limiting cluster updates to pull requests alone.
3. Allows for simple rollback to prior versions, making it easy to undo changes by simply reverting commits.
4. Monitors the cluster to guarantee that deployed apps precisely correspond with Git repository manifests, successfully maintaining the desired state.

To assist you in visualizing the flow that we will be establishing with Argo CD, here is a diagram:

Establishing Our Pipeline for Continuous Integration and Delivery

In the sample project we’ll be using in the tutorial, I’ve already put this GitOps procedure into practice. It will aid in your comprehension of how things operate and provide as motivation for you to establish your own ventures. The example application is a straightforward GCP , GKE clust that says “Hello, DevOps!,” which we deploy to Kubernetes from the directory: https://github.com/Emmylong1/DevOps-Assessment- Test.git

The repository’s : https://github.com/Emmylong1/DevOps-Assessment-Test/blob/main/README.md has detailed instructions, including how to install the software. concentrate on comprehending the overall operation.

Let’s divide it into three sections.

Creating and Propel the Container Image

We will mostly A commit that is merged into our master branch triggers our GitHub action’s build task. It takes care of generating a container image from the Dockerfile and uploads it to the image registry we’ve chosen — in this example, Docker Hub https://hub.docker.com/repository/docker/emmylong1/devops-interview/general

You will need to retrieve a token from your container registry in order to allow your GitHub action to push the created image. You can find instructions on how to accomplish this for Docker Hub here https://docs.docker.com/security/for-developers/access-tokens . It is recommended that you add the token to your repository secrets along with your login as soon as you obtain it. The official GitHub documentation may be found here https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository for step-by-step instructions on accomplishing this.

This workflow triggers on every push to the main branch, builds the Docker image, and pushes it to Docker Hub. Adjust the image name and other details based on your project requirements.

Updating Our Manifests

With the update job in our GitHub action, we’ve solved the second puzzle piece. View our helm chart to see that the image name is not hardcoded. Rather, we use the values.yaml file for that purpose.

After successfully building our image in the previous step, the next task is to deploying the new manifests.

Deploying The New Manifests

Argo CD installation on our cluster is the last missing component. To manage your production cluster, you can install Argo CD in a different cluster or on top of the production cluster because it allows numerous configurations. I’ll install it in just that cluster to keep things simple. The README.md https://github.com/Emmylong1/DevOps-Assessment-Test/blob/main/README.md repository contains installation instructions and a log-in guide for the Argo CD UI.

After that is completed, you must access the user interface, select “New App” from the menu in the upper right corner, then select “Edit as YAML” and paste the configuration that follows. You are ready to go after you save it and create the app!

Understanding the setup should not be too difficult. We specify the cluster name as “in-cluster” in the destination, indicating that the deployment will take place on the same cluster as Argo CD. Additionally, we instruct Argo CD to create the “prod” namespace if it doesn’t already exist in the syncPolicy section and state that we want this app to be deployed under that namespace. The source section is another item to be aware of.Here, we give the location of our app manifests — the repository and the folder. This is significant because, for this application, Argo CD will only search that particular path for updates. Therefore, for this specific application, it won’t matter if you have other manifests in a separate folder. Take advantage of this to have the manifests for all your apps in one repository and provide different paths for each one, provided that you have separate repos for each application code and manifest (which you should!).

Once you create this app, Argo CD will be ready to monitor your repo and automatically make changes to the cluster. Let’s see it in action!

Seeing How Our Workflow Works

Now that I visit my application, I can see that it says “Django Administration!”. Making use of a dashboard login

When I merge that contribution to the main branch, our GitHub action will be triggered. Build and publish to Dockerhub.

If you go to the Docker Hub after that, you will see that your images have been pushed.

If you check out the Argo CD UI now, the system will automatically reconcile these differences and apply the latest manifests from the repository by starting the synchronization process.

Once everything is back in sync, you can visit the URL or use the provided IP/port number to explore our updated application. Pretty cool, right?

As a best practice, implement extensive testing before releasing your code to production. The options are limitless! This is just a taste of the options available by exploring deeper into Argo CD and GitHub Actions. In comparison to what I’ve presented here, I’m convinced that you’ll create a solution that is not just secure but also robust. The main message is that getting started with GitOps on your own is a doable path. So go ahead and experiment and make some fantastic stuff!

Conclusion:

GitOps is a popular approach to application infrastructure and configuration, focusing on using Git repositories as the core location for deployment management. This method can enhance the deployment workflow and accelerate shipping operations by fusing GitOps with declarative continuous delivery technologies like Argo CD. The final outcome of a GitOps workflow is to fully automate the delivery pipeline, allowing developers to focus solely on developing code. The workflow involves a commit merged into the main branch, image creation, uploading to an image registry, updating manifests, and allowing Argo CD to perform cluster updates.

Argo CD automatically changes application manifests stored in a Git repository, applying them to the Kubernetes cluster without human intervention. This strategy offers version control, increased transparency and security, simple rollback to prior versions, and monitoring the cluster to ensure that deployed apps correspond with Git repository manifests.

The GitOps workflow is divided into three sections: creating and deploying the container image, generating a Dockerfile, and uploading it to the image registry. To push the created image, a token is needed from the container registry, which can be retrieved from the container registry.

To update our Manifests, we use the values.yaml file instead of hardcoding the image name. After building the image, we deploy the new manifests using Argo CD installation on our cluster. The README.md repository provides installation instructions and a log-in guide for the Argo CD UI. To create the app, select “New App” and paste the configuration. The cluster name is specified as “in-cluster” in the destination, and Argo CD will search for updates in the specified path. The source section specifies the location of our app manifests, which Argo CD will only search for updates in that specific path. Once created, Argo CD will monitor your repo and automatically make changes to the cluster. To test our application, merge the contribution to the main branch, build and publish to Dockerhub, and check the Argo CD UI. Extensive testing before releasing code to production is recommended. Getting started with GitOps on your own is a doable path, and experiment and make the most of the options available.