[ Docs ] - Charming with Docker

Wed Sep 16 00:17:08 UTC 2015

On Tue, Sep 15, 2015 at 9:25 AM, Charles Butler <
charles.butler at canonical.com> wrote:

> I see your concerns about layering, reactive, et-al. for introductory/new
> charmers. I however raise you a value proposition, and will speak to
> the point we are generating the 'best practice' method, that we want to
> guide charmers down. The common feedback we've received from
> authors is "I'm not as concerned with the overhead of learning, I just
> want you to tell me the best way to do it." While this represents a small
> number from the overall community of people charming, we've delivered on
> this asked behavior. We're taking away some maintenance
> burdens, and exposing a scaffolded framework to deliver your app
> containerized workload.
>

That's fair, it feels pretty good as an intro to best practices guide for
writing reactive style python charms working in an ecosystem with reuse and
extensibility.

>
> While its arguably more complex than `curl get.docker.com | sh` - there
> are a few things happening here that should concern you already.
>
> - You're not verifying the payload, and blindly executing it via a shell.
> This violates charm store policy, and is a black hole into whats happening
> without tailing the unit logs.
>

> While the script is a replica of that installation method, (credit is
> given in the layer repository readme) it was deemed important to mimic
> their recommended install - when you look at the ansible based docker
> charm and its divergent history + issue log.
>
> The script has been modified to surface what the unit is doing via the
> newer `juju status-set` routines  for clear visibility. And we get the
> added benefit of supporting  cent/debian out of the box with this method.
> The ownership burden is on  us, the ~charmers that are maintaining
> the docker layer.
>

> I appreciate the feedback though Kapil, and thanks for acknowledging the
> raise in knowledge to 'get started' - you're right its not as straight
> forward as curling a bash script and piping to sudo. But we don't
> encourage that anyway :) We feel that you can learn and get productive with
> this
> fairly quickly, with minimal knowledge of whats actually happening layers
> below. Just look at what states become exposed and take action.
>
>
i think you misunderstood the download analogy, apt-get install docker is
equivalent in this context or downloading over ssl with checksum and cert
verification and pipe into shell. the concern and question was the best way
to introduce folks to using juju with docker when the alternative is two
lines of shell script.  ie. the comparison for the nginx example an install
hook.

apt-get install docker.io

and a start hook

docker run -p 80:80 dockerfile/nginx -v  html_dir:/var/www/html

> Give it a spin and let us know if you've changed your opinion at all, and
> I'll be happy to talk/work through the concerns.
>

as far as adoption goes, an easy on ramp up the learning curve matters.
docker, terraform, packer, ansible, all great examples of that, and for
onboarding people into writing charms that utilize docker i think that's
its important as well to show the simplest thing that works. as a framework
or layer for docker charms, i'd at least expect it handles some set of the
common concerns germane to using docker across multiple hosts, swarm,
networking, image gc, container gc, registry config, proxies, etc. as it is
the docker example isn't really about docker, its an intro to reactive
style python charm dev, but a docker guide of its own has value. if the
target audience is those working on integration with an ecosystem of charms
with lots of optional integrations and relations (openstack, bigdata,
container eco) then the reactive style scales in complexity well but it
doesn't really address atm anything wrt to docker usage concerns.

cheers,

-kapil

>
> - Charles
>
>
>
>
> Charles Butler <charles.butler at canonical.com> - Juju Charmer
> Come see the future of datacenter orchestration: http://jujucharms.com
>
> On Tue, Sep 15, 2015 at 7:46 AM, Kapil Thangavelu <kapilt at gmail.com>
> wrote:
>
>> i think participating in the burgeoning docker ecosystem is a worthwhile
>> goal by making it easier to write charms that utilize docker. I do have
>> some concerns though about the complexity of the layering that's taking
>> place in the charm ecosystem. I've found that juju has been fairly hard to
>> teach and adapt to real world usage and the layering of frameworks at the
>> charm authoring level makes learning and productivity for new users even
>> harder to achieve (ie those docs reference, charm helpers, reactive charm
>> helpers, docker reactive 'layer', charm composition), all of which are
>> fairly advanced concepts to a new user, and frankly is all of that
>> nescessary to understand running a shell script
>> https://github.com/juju-solutions/layer-docker/blob/master/scripts/install_docker.sh
>> which is effectively the jujuized version of (curl get.docker.com | sh)
>> .. now say i want to configure an insecure registry or any other docker cli
>> param i have to break apart the layer abstraction anyways. It does seem
>> like a useful intro to some of the advanced/additional concepts in charm
>> authoring ecosystem, but at the same time the burden seems high (ie. kiss
>> violation) for how to run a docker container.
>>
>> cheers,
>>
>> Kapil
>>
>>
>> On Fri, Sep 11, 2015 at 11:40 AM, Charles Butler <
>> charles.butler at canonical.com> wrote:
>>
>>> If anyone here is interested in delivering Docker App Containers with
>>> Juju, mbruzek and I have put together some documents around a hot new
>>> process using composer layers and the reactive framework.
>>>
>>> This is interesting because you the charm author will only be concerned
>>> with how to deliver your application layers logic. You don't need to worry
>>> about installing docker, or how to scaffold out a full charm boilerplate.
>>> This entire process reduces the total cost of ownership of the author to
>>> just managing their app layer + container.
>>>
>>>  https://github.com/juju/docs/pull/672
>>>
>>> And we've constructed/linked to an example charm using this process.
>>> There's probably holes in this document, and welcome feedback directly on
>>> the pull request to suss them out.
>>>
>>> We're fully interested in receiving your feedback about this, as its
>>> important that we are properly engaging our users that are interested in
>>> delivering their dockerized app with Juju, and that we've given you the
>>> proper lessons to do so easily, and made the right decisions in tooling.
>>>
>>> All the best,
>>>
>>>
>>> Charles Butler <charles.butler at canonical.com> - Juju Charmer
>>> Come see the future of datacenter orchestration: http://jujucharms.com
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150915/29d3d9f8/attachment.html>