This is the last delivery of a blog series where we explore how we could use vRealize Automation and Terraform in effective ways and also how vRealize Automation already handles and solves many challenging issues that other modern IaC Enterprise or OpenSource solutions and platforms are trying still to solve.
Managing the infrastructure state is critical in any Automation Framework in order to provide an effective Life Cycle management of the resources, in the case of Terraform OpenSource, by default, it records infrastructure status in a Terraform State File, and there are other mechanisms to enhance this behavior, such as using workspaces and remote backends and yet, there are still challenges, such as, collaboration by maintaining a shared storage, managing locking states and separating state files.
Today, let’s dig deeper on how vRealize Automation deals with this challenging issue, in particular when using the Terraform OpenSource, preventing state conflicts, data loss and corruption.
As you may know vRealize Automation provides multi-tenancy, which presents to multiple Organizations with their own vRealize Automation out of a single HA vRealize Automation implementation, however you don’t really need to enable multi-tenancy to manage resource isolations and state, vRealize Automation provides the concept of Projects and Cloud Zones that we have explored in the previous blogs and many others, but this is also relevant when discussing Infrastructure State, as I could deploy the very same Cloud Templates, as many times as need among all those projects and within the projects without concerned that I may affect somebody else resources, in fact with the granular RABC controls, Policies and 2nd day actions / entitlements I can control, when and what can be changed and what about if anyone access the Cloud Infrastructure directly and say, power offs or delete a resource ? vRealize Automation has the ability to detect those changes and via collection process and updates the state of the deployments accordingly furthermore when you perform the integration to vRealize Operations a more sophisticated process is in place.
And all this is present not only for native vRealize Automation but also when you have Terraform Resources, not matter if they are all part of single Cloud Template, this is, when you combine native Cloud Template constructs with Terraform configuration files
Let’s see it in an example:
I deployed 3 Virtual machines in AWS, essentially the same resource, however I am using different vRealize Automation constructs triggered by the same Cloud Template
- Agnostic Cloud Machine
- AWS EC2
- Terraform
vRealize Automation view:
AWS view:
There are different advantages for using one or another which we could explore in a different blog however I want to showcase here that regardless the type of IaC, vRealize Automation has the ability to monitor, present and manage the state in similar fashion
First of all, another member of my time could modify this very deployment by updating the code ( store at GitLab ) and indicate perhaps we would want to use a previously provisioned VPC then ask vRealize Automation to meet the new state, I could have another member to power off one of those resources and those operations could be controlled by vRealize Automation to prevent race conditions, more over, if we changed our mind, we could simple roll back our code changes and apply them again, and only team members could access and inspect the detailed data provided by these resources, which it is safely store inside vRealize Automation, while preventing the access to anyone else and better yet I could deploy multiple instances out of the same Cloud Template, even share it with other teams so they could deploy it in their own Projects and Cloud Resources without affecting my team
As mentioned above I can access independently to any of the status and data from those different constructs by accessing the deployment and I would like to emphasize that in our specific Terraform analysis, the Terraform State data, I mean, the same data we would find when running a “terraform show” or inspecting the “terraform.tfstate” is the one displayed at the deployment for the resource created with the Terraform OpenSource interface
but what if you wanted to see this information in Terraform format, that’s very possible and simple by issuing the operation called “Get Terraform State” right there from the deployment Actions
And what if anyone got direct access to the AWS and modified by mistake the state of our deployments, let’s say our VMs were power off… well , remember I mentioned vRealize Automation is continuously collecting the current state of their managed deployments and comparing to its actual inventory? , so if that happened my deploy would report it ( and enable the actions to power on back)
and well for VMs, that’s simple but for some Terraform resources, specially those created with not so common Terraform providers, the state could be more complex to discover however you normally could issue a simply “terraform refresh”, that’s also available by, yes you guessed right, as a deployment action name “Refresh Terraform State”
So there you have it, whether you need to work only with native vRealize Automation or Terraform Configuration files or a mix of both, vRealize Automation will be able to manage the state efficiently, preventing state conflicts, data loss and corruption.
If you missed the previous Cloud Automation Essentials you can find them here:
vRealize Automation & Terraform : Cloud Automation Essentials – Part 1
vRA – Terraform : Infrastructure as Code & Catalog Broker – Part 2
vRealize Automation – Terraform : Consistent Governance & Workload LifeCycle Management – Part 3 – COMING SOON
vRealize Automation – Terraform : Pipelining | DevOps – Part 4 – COMING SOON
I also would like to invite you to examine how vRealize Automation leverages its native features in conjunction with all Terraform OpenSource Capabilities such as modules and providers, with a few practical use cases in the vRealize Automation – Terraform OpenSource : Practical Examples – Part 5 blog.
