Getting started with Juju 2.0 on AWS

This is a bit of a first timers guide to setting up Juju 2.0 to work with AWS.  To be honest, it’s been quite a while since I really messed with Juju and AWS (or anything outside of MAAS), and this is the first time I’ve really looked at Juju 2.0 anyway.  So this is me sharing the steps I had to take to get Juju 2 talking to my AWS Virtual Private Cloud (VPC) to spin up instances to prototype things.

First, let’s talk about the parts here.   You should already know what Amazon Web Services is, what a Virtual Private Cloud is, and have an account at Amazon to use them.  You should know a bit about what Juju is as well, but as this is a first timer guide, here’s all you really need to know to get started.  Juju is an amazing tool for modeling complex workload deployments.  It takes all the difficult bits of deploying any workload that has a “Charm” in minutes.  All the brain-share needed to install and configure these workloads is encapsulated in the “Charm”.  To configure, you can pass YAML files with full deployment configuration options, use Juju commands to set individual configuration options, or pass them via the juju gui.  Juju is very extensively documented at https://jujucharms.com, and I highly recommend you RTFM a bit to learn what Juju can do.

From AWS you’ll need your Access Key and Secret Key.  You can store these on your system in environment variables, or in a YAML file.  I chose the latter method.  So set up the YAML like this:
bladernr@galactica:~$ cat .juju-cloud-credentials.yaml
credentials:
aws:
default-credential: bladernr
default-region: us-east-1
bladernr:
auth-type: access-key
access-key: <access key from AWS>
secret-key: <secret key from AWS>

Then you need to import them using the command juju add-credential aws -f mycredentials.yaml
From there, you should be able to view the current imported credentials using juju list-credentials
The output should look something like this:
Output of the 'juju list-credentials' command

At this point, you should be ready to create the controller, which you do with the command juju bootstrap [local controller name] aws
The local controller name is just an arbitrary name you create to identify this particular controller. You could, thus, have controllers in multiple AWS zones by using a different zone identifier each time you issue the command, such as juju bootstrap aws-west-3 aws

You should see something like this on your console when the task is complete:Output of command juju bootstrap

To check what controllers you have active, use the command juju list-controllers
Output from command juju list-controllers

As you can see, I now have juju controllers in two different AWS zones.  This is verified by looking at the Amazon Dashboard for US East and US West:

Image of AWS Dashboard US East Image of AWS Dashboard US West

And that’s it.  Now you’re ready to deploy services into AWS in either of those two zones.  The juju docs and how-to’s cover the basics, but to get you started, all you need to do to deploy wordpress is juju deploy wordpress
juju deploy mysql
juju add relation mysql wordpress

This will trigger juju to spin up two new instances in AWS, one running WordPress and one running MySQL. Adding the relation causes WordPress to use the MySQL instance as it’s database backend.
You can track the progress using the command juju status
Once the services are deployed, you should see their status as “running” in the

[Units]

section of the output. Once the deployment is complete, the output should look like this:

bladernr@galactica:~$ juju status 
[Services] 
NAME       STATUS  EXPOSED CHARM                 
mysql      unknown false   cs:mysql-55           
wordpress  unknown true    cs:trusty/wordpress-4 

[Relations] 
SERVICE1    SERVICE2  RELATION     TYPE    
mysql       mysql     cluster      peer    
mysql       wordpress db           regular 
wordpress   wordpress loadbalancer peer    

[Units]     
ID          WORKLOAD-STATUS JUJU-STATUS VERSION   MACHINE PORTS    PUBLIC-ADDRESS MESSAGE 
mysql/0     unknown         idle        2.0-beta7 1       3306/tcp 52.36.252.234          
wordpress/0 unknown         idle        2.0-beta7 0       80/tcp   52.39.200.6            

[Machines] 
ID         STATE   DNS           INS-ID     SERIES AZ         
0          started 52.39.200.6   i-b82dc42c trusty us-west-2a 
1          started 52.36.252.234 i-a023940f trusty us-west-2b

and wordpress is ready to configure!

Browser showing deployed wordpress installation.

So there you have it. When I started this article, I mentioned it had been a while since the last time I used Juju with AWS. In the “old days” configuring this meant a lot of manual editing of a YAML file to set up the region and credentials and other things necessary. Juju 2.0 streamlines this entire process so that if you have your keys configured as ENV Vars, you could go from zero to fully deployed in minutes.

Bookmark the permalink.

Leave a Reply

Your email address will not be published.