If you’re interested in receiving interviews with thought leaders and a digest of exciting ideas from the world of DevOps straight to your inbox, subscribe to our 0800-DEVOPS newsletter!

###

When we started experimenting with private cloud, we first went for a PoC (or Proof of Concept) as anyone else would do. The goal was to bring up an OpenShift cluster and try out some apps to see how easy it is to develop cloud-native applications. We have installed a bunch of apps, a ton of cloud-ready databases, a couple of messaging tools, EIP tools… to cut things short – we have experimented a lot! In the end, the PoC was a big success, but…

Since there were more than 7 engineers involved, each doing their own experiments, the biggest problem was that there were little to none documented procedures. Typically, when a PoC ends, you start preparing several “enterprise” grade clusters – you want to bring up test and production environments as a minimum. Imagine how many manual tasks one would have to perform to repeat the installation of every app/tool that a PoC found worth using. And to do it in every environment. How error-prone is that?! Of course, we eventually did it all manually. How else do you think we could learn that much about OpenShift!?

A good engineer (and we’re still getting there :)) “hates repetition” so we opted to follow GitOps concepts. The supreme goal was to:

#1 Have application definitions and configurations in a declarative format
#2 Have versioned application definitions and configurations
#3 Have an automated deployment of those definitions and configurations
#4 Have an audit mechanism
#5 Give developers an option to request changes via pull-request
#6 Have one source-of-truth (that being the Git repository)
#7 Be able to integrate it into the existing DevOps pipeline

Those 7 requirements are all illustrated in the following picture.

To be honest, the first idea that came to our mind was to build our own solution with oc tool (OpenShift CLI client) but after realizing that it would take too long to build it the way we wanted it, we opened our browsers and started googling.

Luckily for us, our Dr. Milan stumbled upon an interesting tool many months ago but we didn’t have time to investigate it (or better said: any urgent need to). The tool was Argo CD.

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. What to say more?

Did it help us with our needs? Let’s see:

Need #1: Have application definitions and configurations in a declarative format.

Since Argo CD processes those resources (configuration files) we had to export them and store them into a Git repository.

Need #2: Have versioned application definitions and configurations.

Since we are now using Git to store them, yeah, Argo CD helped.

Need #3: Have an automated deployment of those definitions and configurations.

This is where Argo CD’s true power comes in. Argo CD has this neat functionality where it can automatically synchronize configurations in the Git repository with the ones at the target cluster. Sync can be triggered with webhooks or in a timed fashion (every N seconds).

Need #4: Have audit mechanism

Again, since we are working with Git repository this comes out of the box.

Need #5: Give developers an option to request changes via pull-request.

Just to elaborate a bit more on what this need actually means; we want to enable everyone with access to the GitOps repository to be able to “request” configuration changes. Those changes might be adding more resources to pods (changing limits), or adding more applications to the namespace. After evaluating “request” and approving it, Argo CD will automatically apply those changes to the cluster without any further actions. This means that the “merge” button now “deploys” new changes. So, yes, Argo CD helped.

Need #6: Have one source-of-truth (that being the Git repository).

It may seem that I’m repeating myself but the importance of a Git repository here really needs to be emphasized. Git is the GitOps cornerstone and without it, we are not talking about GitOps – it is even in its name. To answer the question, yes, with Git repository we have only one source-of-truth. Argo CD helps us with one other thing that, to be honest, is a result of a DevOps engineer being lazy or a production hotfix(es). Argo CD monitors configuration changes on the cluster and when configuration in Git repository does not match the one on the cluster it marks the project (project being a logical set of configurations) as “Not in sync” or “drifting”. We can even get notified about those changes via Slack, mail and many other channels. This is the most valuable functionality that gave us almost instant insight and a reminder to keep configurations in sync. If we forgot to update the configuration, Argo CD would, with its “prune” option, on the next sync remove everything that is not in Git repository. Having this healthy “fear” of losing your work is the same fear of a computer disk failure with unpushed Git changes.

Need #7: Be able to integrate it into the existing DevOps pipeline.

Having an awesome UI to see all project statuses does not benefit a lot to automating if we have to “click” something manually. With its command-line tool, Argo CD has given us an option to cover configuration updates that are, for eg. a result of the application being released. A common use-case is when we want to deploy a specific application version. Detailed examples can be found here.

I hope that this article, despite being too long and too short at the same time, can guide and encourage you to start with GitOps. Argo CD helps us tremendously with our in-house day-to-day work. We are now a big step closer to having an environment that has a real disaster recovery scenario ready.

If you are interested in more details about Argo CD, take a look at this overview, I’m sure you’ll find something useful.

Live long and prosper!