Shared publicly  - 
 
Docker orchestration with Juju

As we scale-out Docker containers its important to make sure that each new container is started with the proper connections and credential information for communicating with its dependencies. In Juju we call the modelling of this flow of information 'Relations'. These are 1st class citizens in our model and can automatically ensure the right information is passed to the proper services, even in the case of horizontal scaling.

Here we've created a pattern that we use a number of places in Juju which encapsulates service restarts to happen only once all of their dependencies have provided all the data they depend on. For example only once your web-app container has been passed the DB connection will the container be started and passed through the firewall. Adding new front-end app containers will likewise obtain their information from the same relationship.

Following our previous experiments with Docker orchestration we've updated the RethinkDB charm to use our services framework. This means that for the most part a single data driven method drives all the Docker orchestration.  If you are unfamiliar with Juju charms you can start by looking at https://github.com/bcsaller/juju-docker/blob/master/hooks/common.py#L39 (the manage method). This single method is called by all the normal Juju lifecycle events and just 'does the right thing'. If others adopt this pattern, some of the helper code here would be moved out of this hook file and directly into charm-helpers (a Python library to help author charms). This would further simplify the orchestration code.

This work expands on what was previously mentioned in
https://plus.google.com/117270619435440230164/posts/XEcbYX5tHBM and includes a number of lessons learned.

We're always interested in feedback (and pull requests!), if you have questionsfeel free to join the juju mailing list or find us on freenodes #juju .

ML: https://lists.ubuntu.com/mailman/listinfo/juju
24
21
Katherine Cox-Buday's profile photoGustavo Niemeyer's profile photoRichardson Lima's profile photoAlexander Grafov (Axel)'s profile photo
 
Awesome stuff. Will spend some time looking into this in detail.

Some questions, based on my own experiments with using docker and juju

1) Any way to specify a private repository? Using the public docker one makes this a no go in our production environment (and I suspect many others).

2) Given that using docker in juju implies one VM <-> one docker container (as opposed to many containers running on one host), have you considered using host networking (--net=host) to avoid the need for portmapping, and faster network IO?

I'm sure I'll have more questions when I've had a chances to go through the code a bit more :)
 
Thanks for your questions.

1) There is nothing in this model that precludes running a private docker repo but it doesn't have any code to help with that. If we wished to extend it in a Juju specific way we could add a relationship to a private docker repo charm (which we haven't done yet afaik) and a services framework context that massaged that into the cmdline for docker if/when the relation was present.  It could just as easily be a config setting on the charm (docker-repo: ...)

2) While this isn't currently written to support a density scenario handling the port mapping now doesn't preclude it. Switching to --net=host seems like its more limiting, one day (soon?) we'd like to efficiently manage many containers per unit.

Cheers
Add a comment...