[PATCH] docker: add Docker files for running an Apache mod_wsgi server

[Mads Kiilerich]

TL;DR:

This seems very useful for some very specific use cases. It deserves a 
life somewhere ... but I think it should be something else before it 
would be beneficial to let it live in the Mercurial repo. A life 
elsewhere would perhaps be better.

On 11/12/2014 05:37 AM, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc at gmail.com>
> # Date 1415766730 28800
> #      Tue Nov 11 20:32:10 2014 -0800
> # Node ID 09160f191fc370d779fea0c627dfe01240cefc83
> # Parent  18cc87e4375afaeb5986ef9e941854cefa893759
> docker: add Docker files for running an Apache mod_wsgi server
>
> I frequently find myself wanting to run hgweb in a production-like
> environment, with a real HTTP server and multiple WSGI workers.

Production-like ... but not production. That seems like a very special 
and narrow use case.

If it only is for testing and with no migration path to production, why 
should anybody than Mercurial developers want to use this?

> This patch introduces a Docker environment for running Mercurial
> under Apache + mod_wsgi. With just a few command executions, it is
> possible to spin up a Docker container running hgweb.

apache+mod_wsgi+multiple workers ... why not just run hg serve? What is 
it you want to test?

If you need this specific combo and can't use hg serve, how relevant 
will this be for people who use a different setup - such as nginx or 
uwsgi? Isn't this too specific to be of general use?

> The Docker environment is designed with customization in mind. With no
> options, we clone Mercurial from upstream and run @ with a multi-repo
> hgweb setup that allows pushes. An empty repository is created. You can
> push your favorite repository to it and test things.
>
> It is possible to customize the hgweb WSGI and config files if you wish
> to stray from the defaults.
>
> For Mercurial developers, it is possible to mount your local Mercurial
> checkout directory in the container. This means that you can make local
> changes and fire up an Apache WSGI environment within seconds to test
> those changes. (This is the primary use case I developed this patch
> for.)

Being a part of Mercurial source tree, but containing functionality for 
downloading source from elsewhere. That sounds very meta ... and not 
like something that belongs in Mercurial.

Clone from upstream sounds like an (odd) addition to a feature that 
would be more well-defined without it. I would suggest leaving it out in 
the first round, perhaps coming back and adding it later. Instead, it 
should use the source tree it is a part of.

For the topic of docker and debian and packaging, shouldn't we start by 
finishing the "packaging plan" for debian packages that bkero worked on 
in Munich? It seems like that would be first starting point and a 
possible building block for solving this use case.

> You can also employ data volume magic to have persistent repositories in
> the container.
>
> All of this is documented in the README.rst.
>
> Is the container and environment perfect? No. But you have to start
> somewhere. I'm already using this environment to examine memory and
> performance behavior of Mercurial when concurrently serving multiple
> clones. I find this environment extremely useful and I feel Mercurial
> developers will enjoy this new tool in their toolbelt.

"An easy way to test hgweb in the current checkout in apache" sounds 
like the primary and most relevant functionality this could give.

I suggest a first mile stone: make a simple command / script for 
launching a locally (system) installed apache+mod_wsgi as the current 
user with the right configuration.

Next milestone: run this with apache+mod_wsgi in docker, mounting the 
current checkout inside docker. Apache, mod_wsgi and python should live 
in docker, Mercurial and all config files, data files and log files 
should live in the real file system. (I would hate it when the input or 
output to my tests disappear.)


Final comment:

The content of this patch seems to implement a fine and quite 
customizable but also quite leaky abstraction layer on top of something 
complex. It is thus questionable how much it abstracts.

I think it would be more valuable to have a simple example for how to 
run hgweb in docker in production.

/Mads