Synchronizing repository changes with GitOps
Special Ops
In the DevOps world, everybody is talking about GitOps. Its increase in popularity in recent years makes it clear that it's not just a passing fad, but a consistent trend offering significant advantages over legacy approaches.
What GitOps Is Not
Before I move on to specific examples of GitOps principles in practice, it is important to understand what GitOps is and, perhaps more importantly, what it is not. It's probably easier to start with what it isn't, because many people see GitOps as a panacea for all problems in managing applications and their infrastructure. Not only is this belief false – in fact, implementing a GitOps strategy usually involves introducing additional steps and software into your usual workflow, which may make it more complex – but if you don't have experienced staff, things can break more often.
You might also think that because GitOps has "Git" in name, it has to be somehow related to Git. In fact, GitOps can be realized in any version control system (VCS). Because Git is currently very popular, it only makes sense to use it instead of, say, SVN or Subversion; however, nobody forbids you from creating a GitOps solution with these legacy VCS options.
Finally, just because Git allows you to revert operations doesn't mean you can as easily bring your infrastructure to a previous state. One of the complications is the persistent data stored in your infrastructure. Take, for example, an Amazon Simple Storage Service (S3) bucket: If you accidentally delete it, you can recreate it later when you discover your mistake (provided someone else hasn't used that particular bucket name), but obviously the objects that had been there will all have disappeared. Therefore, for persistent data, and databases in particular, you need a specific approach that I briefly explain later. In short, GitOps doesn't make backups and all other good practices redundant,
...Buy this article as PDF
(incl. VAT)