The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

Docker orchestration with Juju As we scale-out Docker containers its important

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

(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

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




Continue reading on