Juju charms and some kind of cache

[Sebastian]

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 <kapil.thangavelu at canonical.com>:

>
> 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/20140407/2613e3a0/attachment.html>