Hello, my name is Madison Scott-Clary and I'm an engineer on the Juju UI team at Canonical.  Today, I'd like to show some new features in the juju gui that let you more effectively work with the infrastructure of your cloud.  Both the GUI features and some of the features within Juju are work in progress, so expect to see them soon.

For this example, let's deploy the popular blogging platform, Ghost, along with MySQL and haproxy for scalability.  However, since this will be our "development" environment and we need to worry about how much resources we use for setting up our service, let's keep our usage as low as possible.

Here, you can see that I have a Juju environment already up and running in Amazon EC2.  I've got the latest and greatest version of the Juju GUI deployed to my state server, a small instance, so that currently, I'm not using much in the way of resources.  Deploying our services works in much the same way that it always has:  I'll drag Ghost...MySQL...and haproxy onto the canvas, and add relations between the three of them, then expose haproxy.  "What's with the blue border?" you might be wondering.  Well, one of the new features in the GUI is the ability to stage a set of changes to be committed at a later point, letting you get your entire environment set up just how you want it before sending everything to Juju.  We'll get more into that in a moment, but next, let's look at the infrastructure of our service.

This is the new Juju GUI machine view, which lets you organize just how your services are deployed to the cloud.  As I mentioned, we want to minimize our resource usage for our development environment, so let's deploy all three of our services to a single machine.  First things first, we'll create a machine with enough memory - say, at least two gigabytes - for our service to live on...there.  Next, let's work a bit of magic here and create two LXC containers on our machine...one of them will host our database, MySQL, and the other will hold our Ghost blog.  Containers help maintain separation between different services - while we could deploy all three services to the same machine, a technique we've been calling "Hulk smash", there would be no separation between any of the units; they would all live colocated on the single machine.

Over here on the left, you can see that we have three unplaced units, one each for Ghost, MySQL, and haproxy.  Just as one drags services onto one's canvas, you can drag these units to place them wherever they need to go.  I'll put haproxy on the root container so that it can be seen by the world...then ghost in the first LXC...and MySQL in the second LXC.

Remember, all of our changes are currently uncommitted.  If you look down at the bottom, you will see [x] pending changes in the new Deployer Bar.  If we expand that, we can see what exactly will be done [list pending changes].  Once we're sure this is what we want, we can commit these changes...and they will all be sent to juju, which will provision our machine and three units for us.  That will take a little bit of time to run, so I'm going to go make a cup of coffee.

Latte in hand, I'm back at my desk to see that the three services have finished deploying.  If I go back to the service view, I can see that they're all in good health.  If I investigate haproxy, expose it, and visit the public URL of the running unit...I can see my new Ghost blog up and running, just as it would be in our production environment, but with minimal resources here in development land.

The deployer bar and machine view are new and powerful additions to the Juju GUI, and we'll hope they'll be of use to you, however you choose to set up your cloud. Keep an eye out for containerization in Juju, and a new and improved Juju GUI soon!