XXX reduce scope and tighten up XXX more about why it's great - sell!

I've been working on Juju project at Canonical for a while now and thought it was about time that I write about it. There's a lot of aspects to Juju and the surrounding ecosystem. I'll try to describe Juju' core philosophy and its high level concepts, hopefully without too much assumed knowledge.

Overview - Juju deploys and manages server applications in cloud infrastructure. It also provisions and manages the resources (e.g. compute, storage, networking) required to support applications running in a cloud.

XXX operations commodisation / sharing

Juju is model-driven meaning that you tell it how you would like your deployments to look like and it takes the steps required to make it happen. This gets the user away from having to worry about low level details and provides a consistent experience regardless of the cloud infrastruture.

Juju is cloud-agnostic. It has built-in support for deploying applications to public clouds such as AWS, GCE, Azure and Rackspace. It can also deploy to private clouds based on OpenStack or MAAS. For development and testing, Juju can also deploy to the local machine using the awesome LXD hypervisor.

The process for deploying is the same regardless of the cloud being used. You can test out a set of cloud applications on your laptop and then deploy them to production in exactly the same way. If you use multiple cloud providers, Juju gives you the same interface for the all of them. There's no lock-in to a given cloud provider.

Uniquely, Juju can model the relationships between different cloud applications. XXX

Example - So what's it like to use Juju? Assuming you've already bootstrapped a Juju controller, here's the command line interaction for deploying MediaWiki, backed by MySQL.

First let's create a new model to deploy into:

$ juju add-model notproduction
Added 'notproduction' model with credential 'default' for user 'admin'

A Juju "model" is simply a workspace for deploying a related set of application in to.

Now let's deploy some software:

$ juju deploy mediawiki
Located charm "cs:trusty/mediawiki-5".
Deploying charm "cs:trusty/mediawiki-5".
$ juju deploy mysql
Located charm "cs:mysql-55".
Deploying charm "cs:mysql-55".

This causes quite a lot to happen. For each deploy command, Juju fetches the charm for the application from http://jujucharms.com (a charm describes what the application is and how to deploy it, more on this later), creates a machine for it to run on in the cloud being used and deploys the application into that machine.

Spinning up machines and deploying software manually is involved and time-consuming. Juju eliminates all this effrot because it knows how to talk to the cloud infrastructure, and the charms for each application know how to deploy the application.

At this point we have MediaWiki running, but it needs a database, and we have MySQL running, waiting for clients to connect but not doing anything. We need to introduce them to each other:

$ juju relate mediawiki:db mysql:db

When the "relate" command XXX

XXX status:

$ juju status
Model          Controller  Cloud/Region  Version
notproduction  Z           lxd           2.0.1

App        Version  Status   Scale  Charm      Store       Rev  OS      Notes
mediawiki           unknown      1  mediawiki  jujucharms    5  ubuntu
mysql               unknown      1  mysql      jujucharms   55  ubuntu

Unit          Workload  Agent  Machine  Public address  Ports     Message
mediawiki/0*  unknown   idle   0      80/tcp
mysql/0*      unknown   idle   1       3306/tcp

Machine  State    DNS         Inst id        Series  AZ
0        started  juju-d9db38-0  trusty
1        started   juju-d9db38-1  trusty

Relation  Provides   Consumes  Type
db        mediawiki  mysql     regular
cluster   mysql      mysql     peer


The aptly named charms is where a lot of the magic happens


configuration System Agnostic




Platform Support


Comments powered by Disqus