You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Dave Brondsema <da...@brondsema.net> on 2015/04/14 23:10:59 UTC
[allura:tickets] #7806 Create a docker image for Allura
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] 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 dev@allura.apache.org 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.
Re: [allura:tickets] #7806 Create a docker image for Allura
Posted by Dave Brondsema <da...@brondsema.net>.
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" <da...@brondsema.net> 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 dev@allura.apache.org 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 : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: [allura:tickets] #7806 Create a docker image for Allura
Posted by Nicholas Bollweg <ni...@gmail.com>.
+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" <da...@brondsema.net> 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 dev@allura.apache.org 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.
>