By Darryl Cauldwell, VMware Solution Architect
Advanced Customer Engagement
Project Team:
Amanda Blevins, Mandy Botsko-Wilson, Carlos Boyd, Darryl Cauldwell, Paul Chang, Kim Delgado, Dustin Ellis, Jason Karnes, Phoebe Kim, Andy Knight, Chris Mutchler, Nikolay Nikolov, Michael Patton, Raghu Pemmaraju
vRealize Automation Cloud
VMware vRealize Automation Cloud is a product suite comprising of three separate modules, Cloud Assembly, Service Broker, and Code Stream. Cloud Assembly provides a blueprinting engine and manages connectivity to multiple cloud endpoints. Service Broker provides a unified catalog for publishing blueprints with role-based policies. Code Stream provides a release pipeline with analytics.
The Cloud Assembly blueprinting engine can be used to consistently deliver VMs and applications. To deliver VM guest configuration, Cloud Assembly natively uses cloud-init. This native VM guest configuration capability can be extended with desired state management tools like Puppet and Ansible. A major difference between the Puppet and Ansible is that Puppet requires an in-guest agent where Ansible operates agentless.
Ansible
In this blog post, I am going to focus on Cloud Assembly integration with Ansible. The Ansible engine is fully open source, but OSS RedHat also offers a license model and support package for Ansible engine. In addition to the Ansible engine, RedHat provides support for Ansible Tower which offers many enterprise grade features. A useful comparison can be found in the blog Red Hat Ansible Automation: Engine, Tower or both. Cloud Assembly supports integration directly with Ansible engine and does not depend on Ansible Tower.
The Ansible control node connects to managed nodes and pushing out small programs called “Ansible modules” to them. These programs are written to be resource models of the desired state of the system. Ansible then executes these modules (over SSH by default) and removes them when finished.
Ansible Headless Deployment Model
Ansible does not require a single controlling machine. Any Linux machine can run Ansible. A headless deployment model is where each machine runs as both the Ansible control node role and the Ansible controlled node. The absence of a central management server requirement can greatly increase availability, simplify disaster-recovery planning, and enhance security (no single point of control).
When we use this deployment model, each server has Ansible installed and has an inventory file with a single entry named localhost. We create a Cloud Assembly blueprint which includes cloud-init configuration to pull an Ansible playbook from a repository and execute it locally. Here the Ansible playbook is specific to the server role on which it will be run.
An example of how to deploy an application using this deployment architecture using Cloud Assembly is described here.
Central Ansible Control Node
While running Ansible without a central control node can be useful for some deployment scenarios, others are better suited to having a central Ansible controller node controlling multiple clients.
Typical factors which would drive a deployment architecture with a central control node would be the following:
- Windows guests as Ansible control node can only runs on Linux
- Large deployments that require centralized control for day two operations
When we use this deployment model, we deploy a central Ansible control node and on this we create SSH authorization private public key pair. We then configure this to be integrated with Cloud Assembly.
We create a Cloud Assembly blueprint which includes on each VM resource cloud-init configuration to create a local account named ansible which has an SSH public key of key pair on the Ansible control node. The Cloud Assembly blueprint then has Ansible resource added with details of the Ansible control node, the private key to use to connect, and which playbook to execute. Within the blueprint, the Ansible resource has a relationship formed with the appropriate VM resources. When the blueprint is deployed, the VM resources get added dynamically to the Ansible server inventory file and the playbook executed. In this model the Ansible playbook can be application-specific rather than server role-specific.
An example of how to deploy an application with this deployment architecture using Cloud Assembly is described here. This also includes a simplified example of how Ansible server can be used for day two operations for servers of a specific type.
Get Started
Managing your VMs through integration with popular configuration automation solutions is a small sample of what you can do with vRealize Automation Cloud.
I you are interested in the solution and want to get your hands on you can start a trial now. It’s free for 45 days without any commitments!
Visit our website to learn more.
Detailed documentation for vRA Cloud can be found here.
