Welcome to the latest edition of CloudBolt Quick Tips! Today, I’m sharing a feature in our platform that handles blueprints in remote source control systems.
The term Infrastructure as Code (IaC) has been a hot topic recently. The challenge with IaC is that it is quite difficult to store complex and ever-changing state in source control systems, especially when that state can change due to actions taken outside the source control system (ex. someone changes a VM directly from the Amazon Web Services console).
Even worse, divergences between the state that is stored and the actual state of the real world can cause tools to make unintended changes, relying on IaC can be dangerous for critical systems.
The CloudBolt approach is to store the “how” in source control, but not the “what,” and instead to check the state of the environment for changes on a frequent basis. Orchestration as Code (OaC) takes the best aspects of IaC and leaves behind the aspects that lead to discrepancies and unintended changes.
CloudBolt has the ability to point blueprints at a remote URL as the canonical definition of that blueprint. This allows admins to store their blueprints within the source control system of their choice (gitlab, bitbucket, github, etc), and take advantage of branching, change history, reverting, and collaboration features.
It also allows multiple CloudBolt instances to use a common definition of blueprints, enabling development methodologies like git flow for creating and iterating on blueprints. This process can include human review and automated testing, where merging a pull request for a blueprint to master automatically promotes it to production.
Adopting OaC means that CloudBolt customers get to take advantage of all of CloudBolt’s capabilities as a hybrid cloud orchestration platform, while also benefiting from all that source control offers.
Check out the video below for more information on how this capability works within CloudBolt, and check out our previous video on the plug-in debugger.
