Juju charms and some kind of cache

Kapil Thangavelu kapil.thangavelu at canonical.com
Sat Apr 5 12:06:55 UTC 2014


Hi Sebastian,

I'm also interested in having docker and juju play nice together.

On Fri, Apr 4, 2014 at 6:44 PM, Sebastian <sebas5384 at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140405/71e39c70/attachment.html>


More information about the Juju mailing list