+1 for docker-compose. I like to think of a Dockerfile as the simplest possible representation of a running system component and a docker-compose.yml as the simplest possible representation of a running system. So basically, docker-compose fufills the same role as supervisord, but also your provision, build, vagrant, etc. And Allura is definitely a system!
I wasn't too interested in the Docker ecosystem until I heard that fig was being "promoted" to a docker-branded tool. Since then It's becoming one of my favorite development/documentation tools, as you can show what your system is made of extremely succinctly, and helps you think like a production engineer sooner... no shortcuts! Among the disadvantages of rolling your own megabox that runs everything, starting from the base OS: - docker build -t allura . && docker run -t allura is slightly more verbose than docker-compose up - you lose much of the work that the rest of the community has done... the selection of boxes out there is pretty remarkable. Even if you end up rerolling your own component images, it's faster to just start adding stuff from the registry, then mature the components as you need. - if one dependency changes "early" in provisioning, you have to rebuild everything - the logs coming off compose are labeled by their container, if you just have one, you don't get this added help One question: are you building a production-ready instance that someone would use to push out to, say, EC2, or are you building a vagrant-like thing for supporting the developer? One key distinction here is whether you "bake-in" the code from Allura itself (ADD/COPY), or if you mount it (VOLUME). If you bake it in, you will defeat the "works on my machine" issues, as the system can't start if the build isn't reproducible. But for a project of Allura's size, that build may take an unacceptably long time between saves (think tweaking CSS) etc. Perhaps the right answer is "both", so you'd have a docker-compose.yml and a docker-compose-dev.yml. Certain boxes could be reused between the two with the extends property: so if mongo is the same in either case, but has more logging in dev, you can tweak that at startup with an environment variable. One interesting tidbit: some projects (IPython) embed their test execution <https://github.com/ipython/ipython/blob/master/Dockerfile#L65> in the Dockerfile itself, such that if the tests fail, the image can't build. I think there is a kernel of awesome in that, but it also has certain limitations. If someone builds on your image downstream, they get to use your certifiably-tested stuff, but necessarily are bringing along your whole build environment. On Apr 14, 2015 5:11 PM, "Dave Brondsema" <[email protected]> wrote: > At PyCon I learned about supervisord as a way to run multiple services > from one single command. This could be used if we want to have a single > docker box run everything. > https://docs.docker.com/articles/using_supervisord/ > > However it sounds like the better way to use Docker is as-intended, one > box per service. This would be needed anyway for us to have a realistic > production deployment option. > > Fig has been superseded by Docker Compose, which is probably the way we > should go. > ------------------------------ > > * [tickets:#7806] <https://forge-allura.apache.org/p/allura/tickets/7806> > Create a docker image for Allura* > > *Status:* open > *Milestone:* unreleased > *Labels:* getting-started > *Created:* Fri Dec 05, 2014 07:02 PM UTC by Dave Brondsema > *Last Updated:* Fri Feb 20, 2015 07:46 PM UTC > *Owner:* nobody > > > http://blog.dscpl.com.au/2014/12/hosting-python-wsgi-applications-using.html > has a good starting point. > > Would be nice to support development config (supplanting our Vagrant > image) as well as a production-ready config (for which we don't have any > good docs/images currently) > ------------------------------ > > Sent from forge-allura.apache.org because [email protected] is > subscribed to https://forge-allura.apache.org/p/allura/tickets/ > > To unsubscribe from further messages, a project admin can change settings > at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if > this is a mailing list, you can unsubscribe from the mailing list. >
