[ Docs ] - Charming with Docker

Fri Sep 25 15:14:05 UTC 2015

Kapil,

Great points, and we covered some of these pre-planning steps with users at
the Charmer Summit. What I came away with was the following, and it falls
in alignment with your analysis as well:

Actions for doing Image Garbage Collection
Actions for doing Container Garbage Collection in blue/green deployment
scenarios
Logspout based log shipping to start, with syslog and PAAS connectors (see:
papertrail sub) as stretch goals
Auto-scale with Swarm when swarm config=true (no additional charm, no
additional work on the end user. "magic")
Relation with private registry (pending) to alter behavior to always
poll/pull from a PR
-Experimental- LibNetwork based layers to extend the behavior to include
Weave, Calico, Flannel, Fan as options

These were 1:1 with what you outlined, and what our user base I was
communicating with over the summit agreed upon. So really good tip in terms
of what you want to see from the stack.

I'm still working through getting the spec put together, and working
through some of the sample code for what this looks like in terms of how
the layers will piece together, what lives where, and how many resulting
charms we gain from the layers + subscribable events for consuming app
containers charm layers.

All the best,

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 8:17 PM, Kapil Thangavelu <kapilt at gmail.com> wrote:

>
>
> 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/20150925/76bc07f2/attachment.html>