Kapil, thanks for your input! I will take a time to think about your observations and see the links you passed.
Cheers!, Sebas. 2014-04-05 9:06 GMT-03:00 Kapil Thangavelu <[email protected]>: > > 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
