A while back I wrote about VMware Cloud Automation Services and how to set up Cloud Assembly with a vSphere environment. Now, in this post I will show you how to add AWS in mix. I will go over the process of setting up a cloud account and cloud zone with AWS. In the end I will show a default blueprint and deploy it to AWS. Of course you also need access to AWS, in my previous post I go over the process of getting started with AWS Free Tier.
AWS Access
The first thing we need is access into the AWS account. For this we need to create a user in IAM with programmatic access that we can use in Cloud Assembly to provide access. I would say it is a best practice to use a special account just for Cloud Assembly.
First log in to your AWS account and go to the IAM service. From there go to users and click on Add User. Now, name the user and make sure Programmatic access is checked.
Next we need to give permissions to the new user. Because we can automate almost everything from Cloud Assembly we need the user to have enough permissions to perform all actions we throw at it. There are a few options to choose from when adding permissions. Add to group, attach access policy directly or copy from existing user. I chose to add the user to the PowerUsers group.
In the third step we can add tags so we can organise, track and control objects within AWS.
After this you will complete the user creation but before you are done you will need to save the Access Key ID and Secret Access Key. Do this by downloading the provided CSV file and save this in a secure location. Please note that this is the only time you are able to save this information. If you loose it you will need to re-create the user account and update this on the Cloud Assembly side as well.
Cloud assembly
Now that we have an account setup in AWS we can move on to Cloud Assembly and setup the cloud account for our AWS environment. To do this we log in to the VMware Cloud Console and go to Cloud Assembly.
Once logged in to Cloud Assembly go to the infrastructure tab and go to cloud accounts. From here we can determine the type of service we want to connect to.
Since we are adding an account for AWS we click Amazon Web Services. Don’t use VMware Cloud on AWS, this is a different service.
In the next step we will need to provide the information we saved during the creation of the AWS account along with some other details like name and description. This is also the place where we configure what AWS region(s) we want to use for this cloud account. If everything is filled out click validate and add to create the cloud account.
Note the checkbox that says it will create a cloud zone, cloud zones are needed to tie resources (in this case AWS cloud resources) to projects. Projects hold the users or departments, so with cloud zones you give access to these users or departments.
Let’s see what is in the cloud zone. The Summary page has some general information about the Cloud Zone and the Projects page show all projects assigned to this Cloud Zone. The interesting part is the compute page, this is where you see all available AWS availability zones. This is where you can tag the AZ’s and orchestrate where deployments go based on tagging.
The next things we need are flavour and image mappings. Remember that flavour mappings are basically used to define standard deployment sizes like AWS t2.micro. Image mappings are used to define what template is being used.
If you want to get more context around flavour and image mappings you can check out my getting started with Cloud Automation Services blog post.
Deploying to AWS
Now, to put this all together we will deploy a Cloud Assembly blueprint to AWS. I have created a simple cloud agnostic blueprint which in theory could be deployed to different types of clouds (AWS, Azure, vSphere, etc.). As you know Cloud Assembly is heavily focussed on a DevOps way of working and supports the creation of blueprints solely in code. The below YAML code creates a blueprint that uses flavour and image mappings to determine what needs to be deployed. It also has some inputs to set username and password on the deployed EC2 instance.
formatVersion: 1
inputs:
username:
type: string
title: Username
default: cloudadmin
password:
type: string
title: Password
encrypted: true
resources:
Cloud_Machine_1:
type: Cloud.Machine
properties:
image: wvanede-aws-ubuntu
flavor: wvanede-aws-general
constraints:
- tag: wvanede-aws
cloudConfig:
ssh_pwauth: 'yes'
chpasswd:
list: |
${input.username}:${input.password}
expire: false
users:
- default
- name: '${input.username}'
passwd: '${input.password}'
lock_passwd: false
sudo:
- 'ALL=(ALL) NOPASSWD:ALL'
groups:
- wheel
- sudo
- admin
shell: /bin/bash
runcmd:
- 'echo "Defaults:${input.username}'From the blueprint I chose the deploy option to directly deploy this blueprint to AWS.
After a short period the blueprint is deployed in AWS and we can use the IP address to establish a SSH session. Remember that we chose the username and password during deployment and we can successfully log in with these credentials.
Conclusion
This concludes this blog post on setting up Cloud Assembly with Amazon Web Services. As you can see it is pretty straight forward and you will be developing and deploying blueprints to AWS in no time. The same process applies to different clouds so setting up Azure for instance will follow roughly the same steps. If at anytime you need guidance in this process remember that within Cloud Assembly there is a guided setup option that takes you past all components you need to set up. And if this isn’t enough, there is always the option to chat directly with VMware from the console.
