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
$ 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 10.0.8.162 80/tcp mysql/0* unknown idle 1 10.0.8.86 3306/tcp Machine State DNS Inst id Series AZ 0 started 10.0.8.162 juju-d9db38-0 trusty 1 started 10.0.8.86 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