Thanks for the feedback, Nick. Sounds like docker-compose is definitely the way to go. Good to have the vote of confidence in it.
And I was thinking that we should use this both for production deployments and for development. Production desperately needs it, since we don't have good docs/config explaining how to stand up a production-ready Allura. Development can replace Vagrant, if we use docker-machine (which I just learned about) or boot2docker directly. I think docker's a little more interesting than vagrant, plus we'll be able to share between the production & development compositions. On 4/17/15 8:58 AM, Nicholas Bollweg wrote: > +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. >> > -- Dave Brondsema : [email protected] http://www.brondsema.net : personal http://www.splike.com : programming <><
