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

Augie Fackler raf at durin42.com
Thu Nov 13 07:24:42 CST 2014


On Thu, Nov 13, 2014 at 04:43:29AM +0100, Mads Kiilerich wrote:
> 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?

It might also serve as a useful starting point for someone that wants
to automate their hg serving setup with docker, but isn't sure where
to start.

>
> >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?

I'm assuming he wants to test under a realistic multi-threaded
environment, rather than the phoney no-concurrency variant that hg
serve gives you.

>
> 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.

+1, that seems reasonable.

>
> 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
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list