grahamdumpleton / mod_wsgi-docker Goto Github PK

Docker images for Apache/mod_wsgi.

License: Apache License 2.0

Shell 100.00%

mod_wsgi-docker's Introduction

MOD_WSGI (DOCKER)

The mod_wsgi-docker package is a companion package for Apache/mod_wsgi. It contains configurations for building docker images which bundle up Apache and mod_wsgi-express.

Available images

Prebuilt images available are:

grahamdumpleton/mod-wsgi-docker:python-2.7
grahamdumpleton/mod-wsgi-docker:python-2.7-onbuild
grahamdumpleton/mod-wsgi-docker:python-3.3
grahamdumpleton/mod-wsgi-docker:python-3.3-onbuild
grahamdumpleton/mod-wsgi-docker:python-3.4
grahamdumpleton/mod-wsgi-docker:python-3.4-onbuild
grahamdumpleton/mod-wsgi-docker:python-3.5
grahamdumpleton/mod-wsgi-docker:python-3.5-onbuild

See mod-wsgi-docker on Docker Hub for more information.

How to use these images

Create a Dockerfile in your Python web application project:

FROM grahamdumpleton/mod-wsgi-docker:python-2.7-onbuild
CMD [ "hello.wsgi" ]

The list of CMD arguments should consist of the path to the WSGI script file for the Python web application and any additional arguments you wish to have supplied to the mod_wsgi-express command.

These 'onbuild' images include multiple ONBUILD triggers, which should be all you need to bootstrap most applications. The build will COPY the current directory into /app and then RUN pip install on any requirements.txt file. It is possible to define pre and post hooks to enable additional system packages to be installed and for additional application setup to be performed.

You can then build and run the Docker image:

docker build -t my-python-app .
docker run -it --rm -p 8000:80 --name my-running-app my-python-app

The Python web application should then be accessible at port 8000 of the docker host.

Note that although your specific Python web application when run will run as the non root user whiskey, the Apache server itself will initially start up as the root user. Some Docker runtime environments however may be set up so as to prohibit you running your container as the root user and require a non root user from the outset.

If this is the case, you can use:

FROM grahamdumpleton/mod-wsgi-docker:python-2.7-onbuild
USER $MOD_WSGI_USER:$MOD_WSGI_GROUP
CMD [ "hello.wsgi" ]

For additional examples see the 'demos' sub directory.

mod_wsgi-docker's People

Contributors

Stargazers

Watchers

mod_wsgi-docker's Issues

Git not available

Trying to build python 2.7-onbuild causes this error:
Error [Errno 2] No such file or directory while executing command git clone -q git://github.com/mongodb/mongo-python-driver.git /app/.whiskey/tmp/pymongo
Cannot find command 'git'

How can I use other Apache modules?

So, Apache (or httpd) is very modular which I consider one of its biggest strength. But how can I use 3rd party modules like mod_xsendfile?

Support for Client Certificates

Can mod_wsgi-docker support client certificates? My wsgi app supports https successfully but indicates the SSL_CLIENT_CERT var isn't set when it tries to use it for client cert. I'm using curl outside the docker container to invoke https and also pass client.crt, client.key, similar to your gist Running HTTPS and client authentication with mod_wsgi-express. Is the gist newer than mod_wsgi-docker?
How can I fix this? A newer mod_wsgi in requirements.txt?

Failed to fetch jessie packages

while making docker build apt-get update failed with below error

Err http://deb.debian.org/ jessie/main amd64 Packages
404 Not Found
Err http://deb.debian.org/ jessie-updates/main amd64 Packages
404 Not Found
�[91mW: Failed to fetch http://security.debian.org/dists/jessie/updates/main/binary-amd64/Packages 404 Not Found [IP: 151.101.2.132 80]

W: Failed to fetch http://deb.debian.org/debian/dists/jessie/main/binary-amd64/Packages 404 Not Found

W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/main/binary-amd64/Packages 404 Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.
�[0mThe command '/bin/sh -c apt-get update && apt-get upgrade -y python-pip && pip install --upgrade pip && apt-get install -y cron bc' returned a non-zero code: 100

Update to latest mod_wsgi

Any chance we can get this updated to the latest mod_wsgi?

Enable compress-responses / mod_deflate

Hey,

I'm using grahamdumpleton/mod-wsgi-docker:python-2.7-onbuild for my Django app and I'm trying to compress my response (I could do it in application level but I read that it's a bad practice )
Maybe I'm missing something but I couldn't find any place that shows how to turn on the compress-responses or mod_deflate.

Thanks.

Could not bind to address using AUFS storage driver

Hi! After upgrading the image to last version (build bqv2jirxqyhwkruy9wwwdpf) of grahamdumpleton/mod-wsgi-docker:python-3.4, I'm getting:

[Fri Oct 23 12:44:06.150040 2015] [mpm_event:notice] [pid 1:tid 139766124951296] AH00489: Apache/2.4.17 (Unix) mod_wsgi/4.4.21 Python/3.4.3 configured -- resuming normal operations
[Fri Oct 23 12:44:06.150144 2015] [core:notice] [pid 1:tid 139766124951296] AH00094: Command line: 'httpd (mod_wsgi-express) -f /tmp/mod_wsgi-localhost:80:0/httpd.conf -E /dev/stderr -D MOD_WSGI_MPM_ENABLE_EVENT_MODULE -D MOD_WSGI_MPM_EXISTS_EVENT_MODULE -D MOD_WSGI_MPM_EXISTS_WORKER_MODULE -D MOD_WSGI_MPM_EXISTS_PREFORK_MODULE -D FOREGROUND'
[Fri Oct 23 12:44:06.150282 2015] [unixd:alert] [pid 18:tid 139766124951296] (2)No such file or directory: AH02157: initgroups: unable to set groups for User www-data and Group 33
[Fri Oct 23 12:44:06.150480 2015] [wsgi:alert] [pid 17:tid 139766124951296] (2)No such file or directory: mod_wsgi (pid=17): Unable to set groups for uname=www-data and gid=33.
[Fri Oct 23 12:44:06.150838 2015] [wsgi:alert] [pid 17:tid 139766124951296] mod_wsgi (pid=17): Failure to configure the daemon process correctly and process left in unspecified state. Restarting daemon process after delay.

My Dockerfile (widudev_devweb):

FROM grahamdumpleton/mod-wsgi-docker:python-3.4

WORKDIR /app

RUN pip install Flask
RUN pip install requests
RUN pip install pymongo
RUN pip install Flask-Babel

COPY . /app

RUN pybabel compile -d web_server/web_server/translations

RUN mod_wsgi-docker-build

EXPOSE 80
ENTRYPOINT [ "mod_wsgi-docker-start" ]

CMD [ "--working-directory", "web_server", \
      "--url-alias", "/web_server/static", "static", \
      "web_server.wsgi" ]

To upgrade I run:

docker build --no-cache --pull -t widudev_devweb:latest .

using -onbuild Dockerfiles with C library dependencies

for example, MySQL-python will not work without libmysqld-dev (or similar) installed on the OS.

is there a good/known workaround?

How do I modify the httpd.conf for apache?

Hi there, I am trying to figure out how to modify the httpd.conf used by the container, or override it with a custom config file.

static files

The static files of my Django application are not served.

Context path or SCRIPT_NAME when deployed in docker, and proxied throgh front-end apache

hello @GrahamDumpleton ,
when we server through mod_wsgi, apache inside docker, and setup a proxy throgh frontend Apache to this docker, every thing works as expected if it is mounted at root on front-end apache
in your article http://blog.dscpl.com.au/2015/06/proxying-to-python-web-application.html , there are ways specified for modifying forwarded headers like scheme, and port.

ProxyPass / http://docker.example.com:8002/

RequestHeader set X-Forwarded-Port 443
RequestHeader set X-Forwarded-Scheme https

but if proxied like below, with custom mount path

ProxyPass /my_api http://docker.example.com:8002/

then url reconstruction inside docker image not working, as SCRIPT_NAME for wsgi environ doesn't preserve frontend's mount path. what is recommonded way to do this?

: "httpd (pid 7) already running"

docker-compose sometimes has an abnormal shut down. I see something like httpd (pid 7) already running. (Full disclosure: I made a centos port of your mod_wsgi Docker, and the issue might not be in your code.)

A php Docker project fixes this by deleting the PID file before starting. Assuming Apache runs in the foreground, this should be all right.

See thes issue links:

(Container won't start twice...PHP)[https://github.com/docker-library/php/issues/187]
(apache2-foreground)[https://github.com/docker-library/php/blob/bdfd0fc1d19102cd6f951614072a51eabf7191bf/5.6/apache/apache2-foreground]

Documentation about process owner

Pulled from README:

Note that although your specific Python web application when run will run as the non root user www-data, the Apache server itself will initially start up as the root user. Some Docker runtime environments however may be set up so as to prohibit you running your container as the root user and require a non root user from the outset.

But in my container, I see the following processes running under root and whiskey:

root@8d5c6e93bd91:/app# ps aux 
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  2.0  0.0   4224   644 ?        Ss   18:09   0:00 tini -- mod_wsgi-express start-server --log-to-terminal --startup-log --port 80 app.wsgi
root        16  4.0  0.0  75044  5348 ?        S+   18:09   0:00 httpd (mod_wsgi-express) -f /tmp/mod_wsgi-localhost:80:0/httpd.conf -E /dev/stderr -DMOD_WSGI_MPM_ENABLE_EVENT_MODULE -DMOD_W
whiskey     18 15.2  0.3 317644 46596 ?        Sl+  18:09   0:00 (wsgi:localhost:80:0)    -f /tmp/mod_wsgi-localhost:80:0/httpd.conf -E /dev/stderr -DMOD_WSGI_MPM_ENABLE_EVENT_MODULE -DMOD_W
whiskey     19  0.0  0.0 145836  3904 ?        Sl+  18:09   0:00 httpd (mod_wsgi-express) -f /tmp/mod_wsgi-localhost:80:0/httpd.conf -E /dev/stderr -DMOD_WSGI_MPM_ENABLE_EVENT_MODULE -DMOD_W
root        33  2.0  0.0  21856  3656 ?        Ss   18:09   0:00 /bin/bash
root        48  0.0  0.0  19100  2620 ?        R+   18:09   0:00 ps aux

Did I misunderstand where the user www-data should be present?

Debian Package Issues

Hello Graham,

It seems like Debian Jessie is a bit outdated now and I can't apt-get any packages with your docker image because it requires me to do an apt-get update and they don't have some of the packages for Jessie hosted anymore. Is there a way I can work around that? I am needing to unzip client certificates to be used with apache and unzip is apparently not included in the debian version you used for these docker containers.

Resolving dependencies

Hi there,
I'm using Python-MySQL as connector to MySQL. So I've added it in requirements.txt file. But this module depends on MySQL-dev to be compiled and the build of docker image fail, because that package isn't present.
So, I do this workaround to fix the problem, I've added this code in the Dockerfile

RUN apt-get update && apt-get install -y \
                mysql-client libmysqlclient-dev \
        --no-install-recommends && rm -rf /var/lib/apt/lists/*
RUN pip install MySQL-python

But in some way, I think it should be another way to deal with dependencies in this Dockerfile.
What do you think?
Shall I look for another Dockerfile or use another SQL Connector?
Thank you very much.

Production

Hey

I'm currently getting my django app ready for production. I'm using docker, and i currently using the image grahamdumpleton/mod-wsgi-docker:python-2.7 from https://github.com/GrahamDumpleton/mod_wsgi-docker . I'm running it a bit customized as i am using the command ["python", "sonofatailorapp/manage_prod.py", "runmodwsgi", "config.wsgi", "--port=80", "--log-to-terminal", "--startup-log"] .

As far as i can understand, this method uses the mod_wsgi-express settings to run the server. And now is where it gets confusing to me. The docs says that mod_wsgi-express will automatically generate the settings as specified in the arguments, but i'm at a point where i would like to use other apache modules like mod_pagespeed and i can't seem to find a way doing this with mod_wsgi-express. I really like that i can startup the server through djangos manage.py as it set's up all the right paths for static files and so on. I also can't seem to find full documentation for mod_wsgi-express and maybe that's why i don't get it. At this point i'm not even sure if express is the right way to go in production. Any input would be greatly appreciated !

Cheers

Improve Docker Build Time

I know this image isn't exactly designed for development, but I find it a little cumbersome that the build process installs pip, wheel, mod_wsgi-express, and project dependencies every time there is a code change. Would it be possible to change the COPY . /app line to COPY ./requirements.txt ./app and then run COPY . /app after running mod_wsgi-docker-build? This would only invalidate the cache if the requirements list has changed. (See Dockerfile best practices here for an example)

Django Demo example.wsgi

Hi Mr. Graham,

I did not find example.wsgi in Django Demo where you call in your mod_wsgi args in Dockerfile, can you push it to the repo.

regards,
Ahmed

pip packages not getting cached

The way things are right now, the pip packages are not getting cached, which often adds unnecessary build time since the packages don't change often. It would be better to run it first thing from the Dockerfile instead of in a script to leverage Docker's caching mechanism, as explained here: https://www.aptible.com/documentation/enclave/tutorials/faq/dockerfile-caching/pip-dockerfile-caching.html

Error while building on Windows 10

I tried building a Django app but got an error, so I tried building the example Django app and got the same error. I'm running Docker for Windows 10.

C:\dev\wsgi-docker\demos\django-1.7>docker -v
Docker version 1.13.1, build 092cba3

C:\dev\wsgi-docker\demos\django-1.7>docker build -t my-python-app .
Sending build context to Docker daemon 579.1 kB
Step 1/2 : FROM grahamdumpleton/mod-wsgi-docker:python-2.7-onbuild
python-2.7-onbuild: Pulling from grahamdumpleton/mod-wsgi-docker
357ea8c3d80b: Pulling fs layer
d8e8125c3c45: Pulling fs layer
8ce0f800159c: Pull complete
51666a419414: Pull complete
045c2d41cdcf: Pull complete
da0c5bb9768e: Pull complete
7a683736e1c6: Pull complete
9021919b127d: Pull complete
2d0ee1f8e3b7: Pull complete
28e556b37a65: Pull complete
c52e0d09645b: Pull complete
799dabb4f6ba: Pull complete
Digest: sha256:9f47437c7ebfc7374e61bc7396bb6c56ed25187bd5560d35305bf568e222f995
Status: Downloaded newer image for grahamdumpleton/mod-wsgi-docker:python-2.7-onbuild
# Executing 2 build triggers...
Step 1/1 : COPY . /app
Step 1/1 : RUN mod_wsgi-docker-build
 ---> Running in 9566e093cbb9
 -----> Installing dependencies with pip
Collecting Django<1.8 (from -r requirements.txt (line 1))
  Downloading Django-1.7.11-py2.py3-none-any.whl (7.4MB)
Installing collected packages: Django
Successfully installed Django-1.7.11
You are using pip version 8.1.2, however version 9.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
 -----> Running .whiskey/action_hooks/build
: No such file or directory
The command '/bin/sh -c mod_wsgi-docker-build' returned a non-zero code: 127

Updating the App

I now have this container working nicely with my Flask application, so thanks for saving me a bunch of time!

I'm wondering if there is an easy recipe for updating the container w/ a new version of the app without having to recreate the image? Is it simply a matter of scp'ing the necessary bits up into the /app directory on the container? Any docs would be most appreciated.

How to update limit-request-body using this image?

Hello Graham,

I know this project has officially been abandoned but I hope you can point me in the right direction:
Following is my Dockerfile:

FROM grahamdumpleton/mod-wsgi-docker:python-3.5-onbuild

COPY . /usr/local/deploy/xyz/current/

CMD ["--processes", "3", "--threads", "1", "--limit-request-body", "104857600", "--request-timeout", "600", "--inactivity-timeout", "600", "/usr/local/deploy/xyz/current/xyz.wsgi" ]

Even though I'm setting limit-request-body to 104857600 bytes, in my application Im unable to send more than 1MB in the request object and I get the following error:
413 Request Entity Too Large

I've also tried setting an ENV variable but with no luck:

FROM grahamdumpleton/mod-wsgi-docker:python-3.5-onbuild

COPY . /usr/local/deploy/xyz/current/

ENV MOD_WSGI_LIMIT_REQUEST_BODY=20971520

CMD ["--processes", "3", "--threads", "1", "--request-timeout", "600", "--inactivity-timeout", "600", "/usr/local/deploy/xyz/current/xyz.wsgi" ]

debian mirrors used in mod-wsgi-docker:python-3.5-onbuild image failing

The prebuilt image grahamdumpleton/mod-wsgi-docker:python-3.5-onbuild fails during docker build with

Step 2/6 : RUN apt-get update
---> Running in e3b34d57e100
Err http://security.debian.org jessie/updates InRelease

Err http://deb.debian.org jessie InRelease

Err http://deb.debian.org jessie-updates InRelease

Err http://security.debian.org jessie/updates Release.gpg
Temporary failure resolving 'security.debian.org'

New Apache version

There's a new version at http://mirror.ventraip.net.au/apache/httpd/ and the old one is not present anymore.
New version: 2.4.23

I can make a pull request once it compiled successfully.

docker hub fails with non-onbuild versions

https://hub.docker.com/r/grahamdumpleton/mod-wsgi-docker/builds/

I'm trying to "inline" the onbuild version and use grahamdumpleton/mod-wsgi-docker:python-3.4 directly. The reason for doing this is so that COPY . /app is done as late as possible to make better use of the docker cache. But it's failing because libmysqlclient-dev isn't installed. I suspect it is using an old version of grahamdumpleton/mod-wsgi-docker:python-3.4 which is because docker hub can't build these non-onbuild versions.

pre-build hook being ignored?

This docker images seems awsome, thank you for sharing! I'm assuming I'm the one to fail here but I'm not sure where it's going wrong. I'm trying to dockerize an Django application which requires MySQL-python. This fails as libmysqlclient-dev is missing.

To set this straight I created an .docker/action_hooks/pre-build file which should be called before the pip install part in build.sh, it however doesn't as I don't see the expected echo " -----> Running .whiskey/action_hooks/pre-build output and the error remains the same.

What am I missing here.

$ docker build -t my-app .

Sending build context to Docker daemon 608.3 kB
Sending build context to Docker daemon 
Step 0 : FROM grahamdumpleton/mod-wsgi-docker:python-2.7-onbuild
# Executing 2 build triggers
Trigger 0, COPY . /app
Step 0 : COPY . /app
 ---> Using cache
Trigger 1, RUN mod_wsgi-docker-build
Step 0 : RUN mod_wsgi-docker-build
 ---> Running in 206694174a14
 -----> Installing dependencies with pip
...

$ cat Dockerfile:

FROM grahamdumpleton/mod-wsgi-docker:python-2.7-onbuild
CMD [ "webtool/wsgi.py" ]

$ cat requirements.txt:

Django<1.8
requests
MySQL-python

$ cat .docker/action_hooks/pre-build:

#!/usr/bin/env bash

set -eo pipefail

apt-get update
apt-get install -y libmysqlclient-dev

rm -r /var/lib/apt/lists/*

$ stat .docker/action_hooks/pre-build

Access: (0755/-rwxr-xr-x)  Uid: ( 1000/  user)   Gid: ( 1000/  user)

Documentation for mod_wsgi express command line flags

Is there any comprehensive documentation of mod_wsgi express command line flags?
I find myself needing to dig into code every time that I need to configure something.

403 error on root when using --mount-point

Hello!

I'm just starting to use mod_wsgi, so I'm probably wrong, but...
Shouldn't line 706 at server/init.py be

<Directory '%(document_root)s'>
instead of
<Directory '%(server_root)s'>
?

The issue is when i say --mount-point /api then I get config saying:
`
DocumentRoot '/tmp/mod_wsgi-localhost:8000:0/htdocs'

<Directory '/tmp/mod_wsgi-localhost:8000:0'>
Require all granted

<Directory '/tmp/mod_wsgi-localhost:8000:0/htdocs/api'>
Require all granted

`

So there is no access granted to /tmp/mod_wsgi-localhost:8000:0/htdocs and I get 403 at the root

Officially abandon mod_wsgi-docker project.

The mod_wsgi-docker project has effectively been dead for some time. There are various reasons this happened. These include:

Docker Inc changed how automated builds worked on Docker Hub such that it was impossible to build this specific image using it. This means there was no automated way to build images if changes were made. This happened years ago. Any updates since then were done manually by building on my laptop and pushing updates to Docker Hub. These manual updates could only be done when I was travelling at conferences and they had sufficient network bandwidth. I can't do it from home as Australia has such crappy internet. I never go into an office. I haven't done any such updates for a long time.
The way the image was constructed followed practices which Docker Inc sort of led us to believe were okay to do, such as running containers as root, using privileged ports etc. Turns out these were bad practices to adopt. It is always a bad idea to require an image be run as root. Once you set things up that way though, it is impossible to change because people depend on it. This is why official Docker Inc images still use such bad practices.
Maintaining custom steps to build Python from source code so that it was installed correctly was an extra maintenance burden. One couldn't use the official Python base images from Docker Inc at the time because they didn't install Python such that it could be used with embedded systems. This was because they didn't provide a version with Python shared libraries. This much at least has now been corrected in the official Python images.
The custom build/runtime scripts designed to make it easy to deploy were a good first pass, but based on what was learned, a second pass was really necessary. This is what the warpdrive project was about. Although I did a number of blog posts, and mentioned warpdrive in conference talks, as a generalised build/runtime system to deploying Python WSGI applications (especially in containers), feedback and interest was next to non existent. Reality is that in the Python web community, or at least in the container space, people don't like the idea of opinionated stacks. Tools like docker were such a shiny new thing, people saw it as an opportunity to learn something new and so did everything from scratch, even if they did a poor job of it. They didn't want a curated container image built to best practices and there still isn't really any out there that I know of.
There was never a community around mod_wsgi-docker either. Yes, a small number of people were probably using it, but the number who have ever communicated back to me about it is very few. Sure there are some bug reports or issues here, but very few, and no one willing to help.

So the mod_wsgi-docker project really needs to be officially abandoned. The issue is for the few using it what you do. Pre-built images based on warpdrive also died due to lack of interest from anyone.

The only real suggestion is that you use warpdrive if you like the idea of an opinionated build and runtime, but build the image yourself using your own Dockerfile from the official Python base images.

I outlined a Dockerfile to get things started in this direction in the talk:

https://www.slideshare.net/GrahamDumpleton/secrets-of-a-wsgi-master

See slides 23 and 24.

Do note though that that Dockerfile is incomplete, and is now known to have security issues related to some things it does if you are not running images in a container runtime which has been setup with security in mind. Additional steps would need to be added to it to fix those issues.

Anyway, this issue is here to solicit feedback for those few using the mod_wsgi-docker image, as to what you would like to see happen. I don't want to be maintaining this image, nor the alternate images which used warpdrive. I still might entertain expanding on and describing a recommended Dockerfile which uses warpdrive, but you build yourself to create an image. Right now I am not even using warpdrive though, so I don't have too much incentive to do that either if only going to be a handful of users.

Please provide any thoughts you may have as comments here.

---

Error while building python-2.7-onbuild

It appears the URL for jessie Release is no longer valid.

Get:3 http://deb.debian.org jessie Release [148 kB]
Ign http://deb.debian.org jessie-updates Release
Err http://deb.debian.org jessie-updates/main amd64 Packages
  
Err http://deb.debian.org jessie-updates/main amd64 Packages
  
Err http://deb.debian.org jessie-updates/main amd64 Packages
  
Err http://deb.debian.org jessie-updates/main amd64 Packages
  
Err http://deb.debian.org jessie-updates/main amd64 Packages
  404  Not Found