If you remember, earlier in our group_vars definition, we had a key variable (ssh_key_name: swarm_key) that at this point becomes relatively important as without a working key we can neither deploy nor start our VM, so let's do that now. We will use awscli and jq--a JSON parsing tool that will reduce the amount of work we do, but it is possible to do without it as well through the GUI console:

$ # Create the key with AWS API and save the private key to ~/.ssh directory
$ aws ec2 create-key-pair --region us-west-1 
                          --key-name swarm_key | jq -r '.KeyMaterial' > ~/.ssh/ec2_swarm_key

$ # Check that its not empty by checking the header
$ head -1 ~/.ssh/ec2_swarm_key 
-----BEGIN RSA PRIVATE KEY-----

$ # Make sure that the permissions are correct on it
$ chmod 600 ~/.ssh/ec2_swarm_key

$ # Do a sanity check that it has the right size and permissions
$ ls -la ~/.ssh/ec2_swarm_key
-rw------- 1 sg sg 1671 Oct 31 16:52 /home/sg/.ssh/ec2_swarm_key

With the key in place, we can finally run our deploy script:

$ ansible-playbook deploy.yml 
 [WARNING]: provided hosts list is empty, only localhost is available


PLAY ***************************************************************************

TASK [Setting up VPC] **********************************************************
ok: [localhost]

TASK [set_fact] ****************************************************************
ok: [localhost]

TASK [Setting up the subnet] ***************************************************
ok: [localhost]

TASK [Setting up the gateway] **************************************************
ok: [localhost]

TASK [Setting up routing table] ************************************************
ok: [localhost]

TASK [Setting up security group] ***********************************************
ok: [localhost]

TASK [Provisioning cluster node] ***********************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost : ok=7 changed=1 unreachable=0 failed=0 

$ # Great! It looks like it deployed the machine!

$ # Let's see what we have. First we need to figure out what the external IP is
$ aws ec2 describe-instances --region us-west-1 
                             --filters Name=instance-state-name,Values=running 
                             --query 'Reservations[*].Instances[*].PublicIpAddress'
[
    [
        "52.53.240.17"
    ]
]

$ # Now let's try connecting to it
ssh -i ~/.ssh/ec2_swarm_key [email protected]

<snip>
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '52.53.240.17' (ECDSA) to the list of known hosts.
<snip>

ubuntu@ip-172-31-182-20:~$ # Yay! Do we have Docker?
ubuntu@ip-172-31-182-20:~$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

ubuntu@ip-172-31-182-20:~$ # Create our single-server swarm
ubuntu@ip-172-31-182-20:~$ sudo docker swarm init
Swarm initialized: current node (n2yc2tedm607rvnjs72fjgl1l) is now a manager.
<snip>

ubuntu@ip-172-31-182-20:~$ # Here we can now do anything else that's needed
ubuntu@ip-172-31-182-20:~$ # Though you would normally automate everything

Looks like everything is working! At this point, we could literally deploy our previously built 3-tier application if we wanted to. As we are done with our example and since we have our mini PaaS working, we can go back and clean up things by running the destroy.yml playbook:

ubuntu@ip-172-31-182-20:~$ # Get out of our remote machine
ubuntu@ip-172-31-182-20:~$ exit
logout
Connection to 52.53.240.17 closed.

$ # Let's run the cleanup script
ansible-playbook destroy.yml 
 [WARNING]: provided hosts list is empty, only localhost is available


PLAY ***************************************************************************

TASK [Finding VMs to delete] ***************************************************
ok: [localhost]

TASK [Deleting instances] ******************************************************
changed: [localhost] => <snip>

TASK [Finding route table info] ************************************************
ok: [localhost]

TASK [set_fact] ****************************************************************
ok: [localhost]

TASK [Removing security group] *************************************************
changed: [localhost]

TASK [Deleting gateway] ********************************************************
changed: [localhost]

TASK [Deleting subnet] *********************************************************
changed: [localhost]

TASK [Deleting route table] ****************************************************
changed: [localhost]

TASK [Deleting VPC] ************************************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost : ok=9 changed=6 unreachable=0 failed=0 

And with that, we have automated deployments and teardowns of our infrastructure with single commands. While the example is pretty limited in scope, it should give you some ideas on how to expand beyond that with auto-scaling groups, orchestration management AMIs, registry deployment, and data persistence that would turn this into a full-fledged PaaS.