Deploy Cloud Agnostic Applications with VMware vRealize Automation Cloud

Author: Riaz Mohamed, 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

Introduction:

As organizations try to migrate their workloads to the public cloud, they are faced with multiple challenges:

• Provisioning infrastructure to a public or private cloud environment
• Migrating workloads
  • Deciding on which workloads to move to the cloud
  • Identifying which workloads to refactor
• Securing the Public cloud environment
• Having a consistent pipeline to provision infrastructure, deploy workloads, test, view utilization, costs, etc.
• Deploying infrastructure and workloads to a multi-cloud environment without having to re-write existing code or retool

Before we go any further, it is important to understand the difference between configuration orchestration and configuration management.

• Configuration orchestration tools are designed to automate the deployment of servers and other infrastructure components. (e.g. CloudFormation, Terraform)
• Configuration management tools help configure the software and systems on the infrastructure that have been provisioned (i.e. Puppet, Chef, etc.)

VMware vRealize Automation Cloud (vRA Cloud) is a product suite that can be used for both configuration orchestration as well as configuration management of multiple public and private cloud environments. These services streamline application delivery, enable cloud flexibility and choice, and control costs. Additionally, these services facilitate collaboration and increase agility between traditionally siloed groups helping to further accelerate business innovation.

The VMware Cloud Assembly blueprinting engine, a module of vRA Cloud, can be used to consistently deliver VMs and applications across multiple clouds. To deliver VM guest configuration, Cloud Assembly natively uses cloud-init to bootstrap disk images. It enables you to specify actions that should happen to your instance at boot time.

Let’s look at an example.

Scenario Overview:

We have a two-tier app called Tito that has a front end and a DB. Tito simply calculates the commute time between two points. The user would enter a starting address and a destination address as well as the time of departure, and Tito will provide a number of stats about the trip such as the total trip time for each day of the week, the total trip time per week or per month, and more. The application uses Google Maps API to get transit time info (this is a paid service).

In this scenario, we would like to deploy the app to any public or private cloud of our choice (vSphere, VMC, AWS, GCP, Azure) including provisioning infrastructure, scaling the front end instances, and using a load balancer to control the flow of traffic to the multiple front end instances.

Solution Overview:

We will use VMware Cloud Assembly to create a cloud-agnostic blueprint that can provision our infrastructure to the cloud of our choice as well as completely deploy and configure our application using cloud-init within the blueprint. This cloud-agnostic blueprint allows us to provision infrastructure and deploy the application to any public or private clouds with no extra configuration.

In this specific scenario, we will provision our infrastructure and deploy Tito to a Virtual Private Cloud (VPC) with both private and public subnets. VPC provides us with a secure network that allows us to control workload placement and access using security groups. For more information on creating VPC on the public network, refer to https://github.com/riazvm/planespotterCloud.

Below is a screenshot of our sample blueprint:

In this blueprint, we place the database VM instance in a private subnet accessible only through the public subnet that hosts the front end. The front end could possibly have multiple instances, which is driven by the FECount input variable when deploying. A load balancer is also deployed and used to route the traffic to the front end instances.

Tito Cloud-agnostic Blueprint Details:

Let’s go more in-depth about the cloud-agnostic blueprint we have created for this sample scenario.

There are various infrastructure components that need to be configured in order to make the blueprint truly cloud-agnostic. These form the foundation blocks on which to create our blueprints.

• Cloud Account: Target cloud configurations (AWS, VMC on AWS, Azure, vSphere, GCP); tags are defined to identify the target cloud account. We will use these tags in our blueprint to identify the target to which to deploy to (i.e. target:aws, target:vmc, etc.).
  • When we deploy a blueprint, Cloud Assembly looks at the cloud accounts with a capability tag that is defined as a constraint in the blueprint.

• Projects: Projects control who has access to Cloud Assembly blueprints and where the blueprints are deployed.
• Cloud Zone: Cloud Zone signifies an availability zone within a provider; for the sample scenario, cloud zone has been used to differentiate our environments (i.e. dev, production, etc.); Cloud Assembly further identifies which cloud zone to place the compute engines based on the user input.

• Flavor Mapping: A flavor mapping groups a set of target deployment sizings for a specific Cloud Account/region in Cloud Assembly using natural language naming (i.e. small = 2 CPU, 2 GB RAM).

• Image Mapping: Determines the OS image to be used on the VM instance deployed (e.g. Ubuntu 1604, CentOS)
• Network Profile: Defines which network the VM instance deployed should be connected to; in our example, networks are tagged as “publicsubnet” or “privatesubnet”. We can further tag the networks to differentiate between the environments (e.g. Dev and Production). Cloud Assembly uses the tag to determine which network should be used. If no tags, the default network is used.

The infrastructure components can be reused by multiple blueprints within a project.

Cloud Agnostic Tito Blueprints

The Blueprints are written in YAML and use the following user inputs and resources.

• Input: Set of variables that is prompted for the user to input when the blueprint is deployed to a target cloud.
  • Application: Application Name
  • Environment: Used to differentiate the target environment (production / dev / test / UAT etc)
  • cloud_target: Target cloud to which infrastructure and app is deployed to
  • mapsapikey: Google Maps API key
  • SSHkey: SSH key to login to the VMs (https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys–2)
  • FECount: Number of front-end instances
  • wavefront_proxy: Proxy that streams metrics from app to Wavefront
• Resource: Infrastructure / software that would be deployed to the target environment; in the Tito blueprint, we make use of the following.
  • LoadBalancer: Load balancer for the front-end instances; gathers IPs of the front-end instances provisioned.
    • Instances: ‘${resource.FrontEnd.id}’
  • Compute Engine (FrontEnd): VM that runs the Tito front end components; the input FECount will determine the number of front end VMs Cloud Assembly creates.
  • Cloud-Init (Cloud Config): Installs necessary software (i.e. MySQL), pulls artifacts from Git, moves files to appropriate directories, modifies configuration file (i.e. IP of the DB machine), and restarts services; Wavefront integration scripts are also included.
  • Compute Engine (MySQL): VM that runs the Tito database
  • Public_Cloud_Network: Public Subnet (Hosts FE and LB)
  • Private_Cloud_Network: Private Subnet (Hosts DB)

Deploying the Tito Cloud Agnostic Blueprint

The idea is to use the cloud agnostic blueprint to deploy on multiple clouds by selecting different constraint tags. When deploying the Tito blueprint to a target cloud, Cloud Assembly follows the below workflow.

As illustrated in the provisioning image below, Cloud Assembly uses constraint tags within the blueprint to identify the Cloud Account, Zone, and Network to provision the resources to. The blueprint also uses cloud-init scripts to bootstrap the VM with the Tito application components on deployment.

A typical application requires configuration to communicate to the different components; in this case, the front end requires the IP of the database VM and the load balancer requires the array of IPs of the front-end instances.

We achieve this by using dependencies; the front end depends on DB and the load balancer depends on the front-end instances. Cloud Assembly ensures that chaining occurs in this case. We use the resource.MySQL.networks[0].address to get the private IP of the MySQL VM which can be accessed by the front end from a public subnet. Similarly, we pass the front end IPs to the load balancer using instances: ‘${resource.FrontEnd.id}’.  The deployments can be viewed and controlled from within Cloud Assembly.

Conclusion

VMware vRA Cloud makes it easy to configure infrastructure, develop cloud-agnostic blueprints and deploy to a target cloud efficiently and repeatedly. Infrastructure provisioned using blueprints can easily be deleted from the Cloud Assembly portal, and users can also monitor the costs of their environments. vRA Cloud makes it possible for seamless hybrid cloud and multi-cloud deployments.

If you haven’t already, you can get started with a free trial now!

Visit our website to learn more.

Detailed documentation for vRA Cloud can be found here.