Hi Sebastian, I'm also interested in having docker and juju play nice together.
On Fri, Apr 4, 2014 at 6:44 PM, Sebastian <[email protected]> wrote: > I'm woking with Docker now too, and one of the advantages is the images, > which are used to deploy the containers. > > In the Juju ecosystem, docker images are like charms, but the difference > is that for each deployed charm, it haves to run all the download and > install staff, taking again all that time and machine effort to deploy the > same kind of charm. > > Maybe I'm just tripping, but I imagine a feature Juju ecosystem based in > Docker, check this out: > One of the nice things about juju is that its tool agnostic and that charms can be constructed using whatever mechanism (ansible, puppet, and docker). In fact there are several docker based charms already extant. From generic docker charms that can launch any docker registry image ( http://manage.jujucharms.com/~niemeyer/raring/docker-seed) to orchestration of specific docker images. Here's a rethinkdb based docker charm https://plus.google.com/117270619435440230164/posts/XEcbYX5tHBM and https://github.com/bcsaller/juju-docker. Its important to keep mind that dockers images are generally not reusable imo without deep image specific knowledge, most have no help, no metadata, and limited config. So its not possible to take any random image off the registry and apply orchestration from outside, the images need to be specific construction i think for this use case or at the least better config options then appear in the vast majority of extant published images. As far as more native support, it would be good to have docker supported as a native juju container type (along side kvm, lxc) using os containers (ubuntu-upstart docker image). This is a bit different then the default recommendation of the docker community of single process charms, ie. instead run it as though it were a full os container like a cloud vm instance. The additional overhead of an os container is minimal and the benefits (upstart for multiprocess instead of supervisord, syslog, runtime change response) make a nice portability and flexibility win. Also keep in mind some of a charm's installs can be local network cached, though it depends on the charm in question. I typically setup a squid-deb-proxy and set it as apt-http-proxy on the environment which will cache downloads. Its not even close to an image workflow's speed potential. > *Charms = Images*: Where you have Docker files, each step of the build > can be cached, and creates automatically a commit. > > *Charm units = Docker containers*. > +1 to both of those. > > *Charms relations = Link containers*: > http://docs.docker.io/en/latest/use/working_with_links_names and > http://docs.docker.io/en/latest/use/ambassador_pattern_linking > It's not the same, but! it's nice to that Docker know about link services. > Apples and oranges. Links are static (one shot communication) and one directional for config. Relations are dynamic bi-directional and convey presence and changes. Also keep in mind again that most images published are pretty poor wrt to reuse (lack metadata, config, docs), and that it takes either deep knowledge of an image or a new image to achieve reuse. > *Exposing ports*: http://docs.docker.io/en/latest/use/port_redirection > > *Reusing data volumes*: > http://docs.docker.io/en/latest/use/working_with_volumes > +1 to both and also to informing juju so it can create the nesc iaas resources. > *Spawning services into the container*: > http://docs.docker.io/en/latest/examples/using_supervisord > This is a rather poor substitute for using an os container (see ubuntu-upstart docker registry image) and just using upstart. > > *Docker haves a nice API*: http://docs.docker.io/en/latest/reference/api > indeed. > > *Charm hooks = ?*: Docker doesn't haves that, instead is expecting > something like Puppet or Ansible. > I think its bit strong to say docker expects puppet or ansible.. There are two solutions for charm hooks and docker imo. If using docker as a generic container type then the juju unit agent is running in the container and can call hooks normally. The other is to have the hooks run outside of the container to effect changes and then restart the container to propagate changes to them (the rethinkdb docker charm does the latter). > > and of course there's more where Juju and Docker can work. > > My ideia, is making Juju work *with* Docker, and not in parallel, or into > a deployed charm. > > I'm from the Drupal and PHP community and one of the best things just > happened is the adoption of Symfony to build Drupal features on top. Now we > are *Drupal+Symfony* communities working together to bring the best > things of each one, for example, the charms hooks into docker containers. > > So, thats it for now, if someone is interested in this topic, please!! > lets talk :D > Definitely interested. cheers, Kapil
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
