How Argo CD and OpenShift Enable GitOps for Developers
Kubernetes and Red Hat OpenShift open up a world of possibilities for administrators and operations folk, but getting developers onto such a platform takes time and effort. For many, it means completely changing the developer workflow to include new tools, platforms and intermediaries. This is why GitOps has become fashionable to infrastructure management: Git makes sense of distributed workflows that generate textual assets, whether code, configuration or data.
For Kubernetes users, administrators can use Argo CD to enforce their git-based will upon their clusters. But doing the same for developers is a bit trickier. OpenShift takes this complexity away and extends Argo CD’s capabilities, which are restricted by namespace, to developers.
So what exactly is Argo CD? In the simplest terms, it’s a piece of code that runs inside your cluster and keeps it locked into whatever configuration is delineated on git. Thus, if someone logs into your cluster and changes the configuration, Argo CD will automatically revert everything back to whatever versions of configuration files are in the git repository associated with the cluster.
Argo CD does more than that, of course, but from a cluster management perspective, it’s the gatekeeper to changes of configuration, forcing those changes to happen on git, where they’ll be recorded and tracked.
However, Argo CD isn’t just about continuous deployment for administrators looking to enable their clusters for their developers. Argo CD can be deployed for developers to use as well. With the right configuration inside OpenShift GitOps, Argo CD can be restricted to only work inside namespaces, allowing it to be used by individual developers on individual applications.
That’s an important set of restrictions that Argo CD can implement. For administrators, Argo CD is almost a security tool despite simply performing the last mile of continuous deployments. For developers, Argo CD is almost like a robotic systems administrator, bound completely to the configuration files designated by the developer.
Developers can use Argo CD to keep their deployment environments in line and online with minimal effort. Once properly configured and integrated into a proper CI/CD pipeline, Argo CD can become a part of a one-click-deployment operation for developers, or even get out of the way and stay invisible behind the git workflows that developers are already using. Given that developers are already familiar with git and how it works, expanding that workflow to cover actual test environments and production deployments can only serve to speed up overall development velocity, by removing additional steps.
Argo CD in the Enterprise
This is all a part of the appeal Argo CD has for enterprise users. In the world of compliant business software, companies often must prove that certain applications are running and keeping track of things. They must also keep a rigorous track of changes made to that software in case something goes wrong and compliance needs to be verified for legal reasons.
Bringing all software changes to git, by way of Argo CD, also helps to consolidate these changes into a single git location, allowing those changes to be verified, tracked and associated with a user. It’s almost impossible for a stealth change to be made to code inside a git repository, so simply building a process around this platform enhances security and record-keeping.
That’s why Red Hat OpenShift has embraced the GitOps methodology and tooling across its entire platform. OpenShift GitOps uses Argo CD to push changes to clusters and to keep untracked changes from being implemented. OpenShift also includes the ability to restrict developers’ use of Argo CD to their namespace, allowing them to gain all the benefits without requiring everyone on the cluster to use it.
That’s what enterprises need from their software: compliance and traceability. For developers, this can become a burden when deployment routines require that they follow 80-page guides and fill in numerous forms to verify the integrity of the software they’ve built.
Since humans are fallible, removing them entirely from the deployment pipeline can help to bring more predictability to the process and consolidate the troubleshooting to a single linear track of behavior, rather than some sort of impossible-to-trace waterfall method.
Argo CD even has the ability to give alerts, so it can also be tied into alerting systems. If your administrators want to know every time a new version of an application is deployed, Argo CD can give that alert. If those same admins want to know when Argo CD redeploys something because a change has been made inside the cluster, it can also give an alert for that.
This all ties back into the needs of the enterprise to deploy more applications and innovative features faster and more securely. As the center of most revenue streams, business applications directly drive the bottom line, and interruptions in service do the same. Security concerns complicate the entire affair, adding risk to every deployment.
But when those deployments are heavily tracked, monitored and coming from code that’s stored in what is basically an incorruptible medium for software storage, git uses a hash of the file as its internal identifier. Therefore the ID changes if the file changes in any way. The very act of using git enhances security in numerous ways that are mathematically provable. For example, taking a piece of software and modifying it, then attempting to get it to generate the same hash as the previous version of the software is essentially more difficult than actually exploiting the software itself.
Indeed, git comes with a number of security features built into it at the foundational level: a benefit of it being written by Linus Torvalds. Argo CD takes advantage of these built-in security capabilities and features, and extends them throughout your software lifecycle. Instead of introducing some other layer specifically focused on security, Argo CD simply extends the existing protections out to the deployment process.
By tying it to a namespace, it can extend those protections out to the development process — and to the development team as a whole. GitOps is a common buzzword these days, but in the future it will likely become as generic as the term Band-Aid or Kleenex. Instead of being a prescriptive method of running CI/CD, it’ll simply be the way we all develop and deploy software. It’s simply too compelling and too powerful a workflow to not become the default, just as git has become the default distributed source code repository.
