When the cloud was just about virtual machines, tools like Chef or Puppet helped us easily prepare our VMs. The only thing that mattered was to provision instances that contained all of the code and data required. But now that Amazon Web Services has ballooned to more than 90 services, interacting with the AWS API becomes the major part of the work.

How should we manage AWS infrastructure, and what interfaces should we use? Most beginners start with AWS Console, the default GUI, while seasoned sysadmins generally prefer a command-line interface (CLI). Problem is, the AWS CLI is not user friendly. Because it integrates the entire AWS API, it exposes an enormous surface area in terms of commands, flags, and options.

Awless is born from our need for a fast, powerful, and easy-to-use CLI to manage AWS. With Awless, you can create and run an AWS infrastructure, starting from scratch, and always get readable output (for both humans and programs), explore and query all cloud resources (even offline), connect to instances, and create, update, and delete cloud resources. Beyond single command lines, Awless supports templates that enable higher levels of automation. Last, but not least, Awless aims to ensure smart defaults and security best practices.

Because there are so many AWS services, it is often important to find and display a hierarchy of services from the command line. We can group services by functionality—such as compute and database. But going through each of them exhaustively is tedious as there are, as of this writing, no fewer than 15 services around storage and database, not counting four data migration services and nine analytics services that are directly related to data usage.

with AdministratorAccess rights. Carefully note your access key and secret key.

Install Awless

Awless is available at . We provide and Homebrew packages for MacOS:

>brew tap wallix/awless 
>brew install awless

You can check that Awless is properly installed by running:

. Here we will use the script available on :

>awless create instance subnet=@wordpress-public-subnet keypair=johnkey name=wordpress-instance userdata=https://raw.githubusercontent.com/zn3zman/AWS-WordPress-Creation/16a52aef4f618d558d61197df4e4eca4c015277f/WP-Setup.sh securitygroup=@wordpress-secgroup

You can use awless show to get information about any resource, such as the public IP address of our WordPress instance:

>awless show wordpress-instance

You can connect to the IP address from the command output to access your WordPress service (though you might have to wait a few minutes for the instance to be provisioned properly).

WordPress Foundation

Our initial launch of WordPress.

By default, Awless will create a type t2.micro (1 vCPU, 1GB RAM) using Amazon Linux. You can update default values by using awless config set:

>awless config set instance.type m4.large 
>UBUNTU_AMI=$(awless search images canonical:ubuntu —id-only —silent)
>awless config set instance.image $UBUNTU_AMI

To this point, we have built several resources. Using awless list, we can list users, instances, subnets, and all other types of resources (provided your AWS profile has sufficient rights of course). For example, we can list instances:

>awless list instances 
|       ID ▲        |   ZONE   |        NAME        | UPTIME  |
|-------------------|----------|--------------------|---------|
|i-00268db26b0d0393c|us-west-1c| wordpress-instance | 57 mins |
[...]

Awless provides a powerful feature that enables easy connections to instances with SSH. Behind the scenes, Awless will automatically get the instance IP address, guess the username, and connect with the keypair we created earlier:

>awless ssh wordpress-instance

If you want to delete the WordPress instance, you can run awless delete instance id=@wordpress-instance. You can do it now, as we will create a more advanced deployment in the next challenge.

How to use Awless templates

All the steps in this challenge can be described as a sequence of Awless commands, where the results of previous commands (for instance, the ID of the Internet gateway) are used as inputs to subsequent commands. Because Awless provides a built-in templating system, you could encapsulate all of Challenge 1 in a template and run it with:

>awless run https://raw.githubusercontent.com/wallix/awless-templates/bcd0dd41b1524eeac1e53d12b2998bc56689c517/simple_wordpress_infra.aws

Awless offers a powerful feature that enables you to revert most changes applied to an AWS infrastructure. For instance, you can delete the whole infrastructure created by a template in a single command: awless revert revert-id. To find a given revert-id, awless log lists all of the commands previously applied to the cloud infrastructure, with both their output and their ID:

>awless log # find the ID to revert >awless revert 01BM6D1YRZ5SSN5Z09VEEGN0HV

Challenge 2: Use AWS managed services

Our previous deployment is functional, but pretty artisanal. Our blog is powered by a single instance in a single Availability Zone (AZ). We now want to build a highly available blog, with a load balancer, two instances in different AZs, and a replicated database that is shared by our instances. Instead of running our own database in an instance, we will use , Amazon’s managed service for SQL databases. Using a managed service provides many advantages including clustering, managed security, and backups.

aws ec2 rdsWallix

Our goal for Challenge 2 is to set up a highly available infrastructure with a managed and replicated database.

In order to have highly available resources, we need to distribute them in subnets in different availability zones (AZs) and balance the load through .

aws ec2 elbWallix

We want our WordPress instances to be able to fail gracefully (one at a time).

For this challenge, we will create the following:

  • One load balancer to distribute the load between the instances
  • Two public subnets to associate with the Internet-facing load balancer
  • Two private subnets in different AZs (e.g. us-east-1a, us-east-1e) to host the instances
  • One auto scaling group to manage the scaling of WordPress instances
  • One NAT gateway in one public subnet to enable outbound calls for instances provisioning
  • One public fixed IP (Elastic IP) for the NAT gateway
  • One RDS for MariaDB instance automatically replicated in the private subnets

We will build this infrastructure by running Awless templates. The first template creates subnets and routing. The {hole} notation allows parameters to be filled dynamically during the running of the template. The $reference notation enables back references of created resources.