1) Introduction to GitOps
GitOps is a methodology and tools to help organisations make Git their single source of truth for production infrastructure. The goal is to provide secure and reliable access control, automated deployment, observability, compliance tracking and auditing capabilities, all through simple declarative policies in Git repositories. GitOps favours people over machines (over DevOps), open source over proprietary tools (over Cloud Native), and trust over control (over security). The end result is an environment in which everyone can see everything that is going on, enabling better collaboration between teams.
2) Infrastructure as Code (IaC)
Construction and infrastructure procurement are areas where you can use IaC. The reasons are twofold: it’s tedious to type all that code, but it also means you have less opportunity to introduce inadvertent errors. Git is a version control system (VCS) built on Linus Torvalds’ BitKeeper software. Unlike centralized VCS systems such as Subversion or Mercurial, Git works by tracking every change made in its repository since its creation. This makes it particularly effective for managing large projects with many contributors over long periods of time - exactly what we need in our IaC toolkit. With tools like chef-solo , Ansible , and SaltStack , we can declaratively specify the appearance of an environment via a collection of files tracked by our repository - we don’t actually perform these steps until we want to update our target environment with the changes in our repository! This method encourages us to be explicit about how we want something configured; there is no misunderstanding when things go wrong or when another team member has slightly different expectations from us.
3) Testing the IaC
Infrastructure as code is great, but it only works if your development team uses it. You need to monitor them, whether through pull requests or code reviews. When changes are made manually, it is difficult to know what has changed and when. This can make it extremely difficult to determine which version is causing a failure or other problem, making troubleshooting and patching more complicated than necessary. The solution is simple: use open-source continuous integration software (such as GitLab) and create tests for every change you make in IaC - for example, if you’re using Jelastic CloudScripting to deploy new stacks, test your changes before committing them by updating a pre-existing (pre-prod) stack instead of creating a new one.
4) What does this have to do with Git?
Git, specifically the git repository management tools, is typically used to track code changes. Git’s powerful branching capabilities and distributed architecture make it easy to manage multiple branches of code. If we apply these same concepts and methods to non-code resources, such as infrastructure configuration files and remote job execution scripts, we can create a single source of truth that will enable automation. Imagine thousands of servers being automatically updated with new configurations at 1am every Sunday, or every time a commit is pushed to master on your GitHub project. The benefits are many: faster deployment times and less human error, to name just two!
5) Branch management
Plugging in is a good thing, it allows us to work on several features and changes at once, and merge them later when we are ready. For example, let’s say you’re working on improving the performance of your site. You may want to modify some CSS styles in addition to making changes to your server configuration. You can make these CSS changes on their own branch (for example, /css-perf) and push it to GitHub or GitLab with git push origin /css-perf . You can then make your changes on the server without fear of breaking the CSS changes! Branches are great! That said, there is one thing you need to be aware of: Branches make it very difficult to track the history.
