In this third part of the DevOps for Infrastructure series, we’ll start exploring some of the principles of GitOps. If you missed part one (DevOps for Infrastructure: From VI Admin To DevOps Champion) or part two (DevOps for Infrastructure – Demystifying Infrastructure-as-Code) of this series, this post builds on the content so I’d recommend reading those first. The webinar version of this blog post is also available here – DevOps for Infrastructure – Iterative Development with GitOps.
GitOps extends our Infrastructure as Code to allow us to use Git as the single source of truth for desired state within our environment. Because the environments are described in declarative code, changes to environments are made using pull requests to Git, whether creating, updating or destroying. We should also be able to observe the deployed environment and detect if the desired state and observed state are the same (converged) or different (diverged).
Iterative Blueprint Development with GitOps
If we look back to the first webinar in this series I talked about the diagram below, in which we move a blueprint through three different environments in vRealize Automation – Development, Staging and Production. In the Infrastructure as Code webinar and blog post, we looked at how that blueprint described the desired state, and how we could manually use git to move the code through the environments. In this post (and related webinar), we’re adding the Blueprint Release Pipeline and triggering that using webhooks from the Git repository.
In the webinar I white-boarded this process to explain. Version 1 (v1) of the blueprint YAML code is committed to the Version Control System (VCS), which in this case was GitHub. Cloud Assembly synchronises with the Git repository and creates a new Blueprint (v1). Multiple v1 environments are then deployed from the blueprint.
On top of this, we configure the Git repository to trigger a Code Stream pipeline using a web hook. The Code Stream pipeline will run when a new pull request is made to the repository, and make API calls to Cloud Assembly to update the existing deployments.
Now, if I make a change to the blueprint YAML – let’s say I add a second VM and increase the version to v2 – and merge it into the Git repository via a push. Cloud Assembly will synchronise with the repository and create a new version of the blueprint. At the same time the Git webhook will trigger the pipeline to begin upgrading my existing deployments to the version 2 blueprint. Cloud Assembly will then take this new infrastructure as code model and bring the deployments up to match.
To see this all in action, I’d strongly recommend watching the DevOps for Infrastructure – Iterative Development with GitOps webinar version of this post which walks through this in a step-by-step demo in a way that I can’t here.
Other parts of this webinar series:
