Gitops: Diving Into Some More Madness

Illustrated guides to become better engineers

The problem with computing is that knowledge of tools is also necessary. Sometimes for a particular aspect, knowledge of tools is all that is necessary. DevOps is like a world coded in YAML.

The shelf life of such knowledge is sometimes 2, 3 years. Then the concepts and tools are out of the window. The best we can take from this kind of post is the concepts, frozen as templates for later ideas.

This post explores Gitops, using ArgoCD and Harbor as examples. You can read this post if Kubernetes is unfamiliar to you.

The purpose of this newletter is to break down not-so-beginner-level concepts.

Gitops

Gitops is a concept. It is about using Git as the source of truth for infrastructure.

GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation.

— read more on Gitlab

A typical scenario looks like this. Notice the Gitops operator. It is reponsible to apply changes in config files to our infrastructure. The merge trigger and workflow can be implemented using Github actions.

Workflow

A typical workflow involves building a new image and pushing it to an image repository on app code change. Then notifying the Gitpos operator.

Git repos

A typical implementation contains 2 repos. One for the app and one for the infra. The app repo contains the app files as well as a Docker image config file. The infra one contains our helm charts or whatever K8s config files we are using.

Image tagging

Images have tags to identify them.

One approach is to tag images based on commit SHA so that we can auto-tag the image upon app code changes.

In the case we want a build to trigger on release, the image tag becomes the release tag.

The advantage of per-release tagging is that you save on image space compared to per-commit builds.

ArgoCD

Argo is an umbrella terms for many projects, including ArgoCD.

ArgoCD is typically used in a Continuous Delivery pipeline.

ArgoCD enables us to rollback on changes. If we have manual sync enabled by default, we must sync then apply the sync.

But, if we want our configs to be applied immediately, we can enable auto-sync. Auto-sync uses a webhook to push updates to ArgoCD, which in turn applies them.

How it goes

Using a per-commit image push approach, the flow is like this, when we merge a pull request, an image is created in the image hub. Here image 1.

A second, PR merged, a second image is created. Here image 2.

Then, when we wish to use an image in production, we update our infrastructure repo. We specify the new image. ArgoCD is then notified.

ArgoCD uses the K8s api to apply the changes. The image is then pulled.

Image repositories

Typically, for a light project, Docker hub might be great. However, if you need something self-hosted with more options, Harbor is nice.

Conclusion

Versioning and auto-sync of infrastructure allows us to have repeatable, easily managed pieces. The downside is learning and setting up a deluge of tools, an underestimated point.