Packaging Docker Packs

[JasonGiedymin]

How do we package base docker packs?

[automatelife]

Thanks. Was looking into this last night trying to formulate an approach.

[JasonGiedymin]

Lets now look at deis

-Jason

On Aug 29, 2013, at 6:38 AM, automatelife notifications@github.com wrote:

Thanks. Was looking into this last night trying to formulate an approach.

— Reply to this email directly or view it on GitHub.

[JasonGiedymin]

Custom Yaml to drive mesos docker executor + chef = good to go (doc on wiki will be up soon)

[JasonGiedymin]

To test this, we need to move the strider docker script down to mesos.

To play around:

http POST http://10.10.10.10:8080/v1/apps/start \
id=multidis instances=2 mem=512 cpus=1 \
executor=/var/lib/mesos/executors/docker \
cmd='strider/strider'

This will still create a docker JUST like the existing strider script, even going so far as to live as a docker container JUST like it is now BUT it will be managed and provision through marathon & mesos. This is the management interface we don't have to build. :-)

[JasonGiedymin]

Options for 'deployment packs' are:

1. do what deis did and use heroku build packs using buildstep
2. do what dotcloud does here
3. write custom yml based (like travis) to add a few more options and node configs (for use with mesos/marathon) and use in combination with buildstep OR use chef -- see wiki page i wrote here

Note

The problem with buildstep and with heroku build packs is it goes against the things we've learned as a community in using chef. The major issue that most users are feeling these days (because technology moves so fast) is that proprietary stuff is slow and fails. Buildbacks are proprietary. Chef is not. More people write chef/puppet than they do buildpacks. Here is one users feedback. It is all about control, not just 'scale'. Which is why I do like dotcloud's format. However, when it comes to deploying customer apps I want them and us to use Chef/puppet. C/P runs our stuff, C/P runs their stuff. Community, dog food, yum. Sail with the current In the water, not against it, but along side it.

My Vote

I vote for the custom route. The reason is I think we can abstract away the config (more than deis or dotcloud). In fact we must. I would like to abstract away the config so that it appeals to these users:

• the layman - in which case he may only specify a pre-built application
• the dev - he specifies the runtime, his repo, and runs a single or simple cluster
• the expert dev - complete control of setup, install, run, logs, analysis, provisioning orchestration and timing

We won't be ready for the experts at first, there is a lot of security questions that need answered (and built) before we roll out to this user group (even if we had all the features).

side note, man i really like how dotcloud works