mod_wsgi

mod_wsgi
Name	mod_wsgi
Developer	Graham Dumpleton
Released	2007
Programming language	C, Python
Operating system	Unix-like, Windows
License	Apache License 2.0

mod_wsgi mod_wsgi is an Apache HTTP Server module that embeds the Python interpreter within the server process to host Python web applications. It provides a bridge between the Apache HTTP Server and Python web frameworks such as Django (web framework), Flask (web framework), Pylons (web framework), TurboGears, and web2py. Designed for production environments, mod_wsgi emphasizes process management, application isolation, and integration with Apache features like virtual hosts and SSL.

Overview

mod_wsgi implements the Web Server Gateway Interface (WSGI) specification to allow Python applications to run within the Apache HTTP Server process. It supports multiple operation modes, application daemon processes, and integration with Apache modules like mod_ssl, mod_rewrite, and mod_proxy. Commonly paired with projects such as Virtualenv, pip, setuptools, uWSGI, and Gunicorn, mod_wsgi competes with alternative deployment strategies employed for frameworks including Bottle (web framework), CherryPy, and Tornado (web server).

Architecture and Operation

mod_wsgi embeds a Python interpreter into the Apache process model, leveraging Apache features like worker MPM and event MPM from Apache HTTP Server releases. It can run in embedded mode or daemon mode, with daemon mode offering isolation similar to external servers like uWSGI and Gunicorn. In daemon mode, process groups can be configured with controlled privilege separation resembling techniques used by systemd, supervisord, and upstart. Application lifecycle hooks are compatible with WSGI middleware from ecosystems such as Paste (Python), Werkzeug, and Beaker (web framework). Interaction with asynchronous libraries like asyncio, Twisted, and gevent requires consideration of interpreter state and IO models historically influenced by PEP 3333 and Python runtime changes by the Python Software Foundation.

Installation and Configuration

mod_wsgi is typically compiled against the target Python interpreter and Apache development headers from distributions such as Debian, Ubuntu, Red Hat Enterprise Linux, CentOS, Fedora, SUSE, and FreeBSD. Package managers like APT (software), YUM, DNF, and Homebrew sometimes provide prebuilt packages. Configuration uses Apache directives such as WSGIScriptAlias, WSGIDaemonProcess, and WSGIProcessGroup within httpd.conf or virtual host files managed by control panels like cPanel, Plesk, and orchestration tools including Ansible, Puppet, Chef (software), and SaltStack. Environments often employ Virtualenv or pyenv to manage interpreter versions provided by vendors like Python Software Foundation and distributions including Arch Linux and OpenBSD.

Deployment and Integration

Deployments integrate mod_wsgi with frameworks like Django (web framework), Flask (web framework), and content systems such as Plone and Zope. Integration with front-end proxies like HAProxy, NGINX, and Varnish enables load balancing and caching; mod_wsgi can also cooperate with reverse proxy setups common in Amazon Web Services, Google Cloud Platform, Microsoft Azure, and Heroku deployments. Continuous integration pipelines using Jenkins, Travis CI, CircleCI, and GitLab CI/CD often build and test mod_wsgi-hosted apps, while containerization with Docker (software), Kubernetes, and orchestration by OpenShift alters the process management pattern and runtime expectations.

Performance and Scalability

mod_wsgi supports multi-process and multi-threaded configurations influenced by Apache MPM choices and process management strategies like those in uWSGI and Gunicorn. Tuning parameters include daemon process count, thread pools, and request handling policies paralleling recommendations from High Performance Browser Networking authors and performance tools such as ab (ApacheBench), wrk (HTTP benchmarking tool), Siege (software), and locust (software). Scaling horizontally behind load balancers from F5 Networks or software load balancers like HAProxy and NGINX is common; for stateful workloads teams may employ Redis, Memcached, and database clusters based on PostgreSQL, MySQL, MariaDB, or MongoDB to reduce application server load. Profiling with gprof, perf (Linux), valgrind, and Python profilers such as cProfile informs tuning when using extensions written in Cython or native C modules.

Security Considerations

Running Python inside the Apache process model exposes considerations analogous to running modules like mod_php and mod_perl. Privilege separation and chroot-like isolation are often implemented using techniques promoted by SELinux, AppArmor, and container namespaces from Linux kernel features. TLS termination is usually handled by mod_ssl or offloaded to proxies such as NGINX or HAProxy, with certificate management through Let's Encrypt and tools like Certbot. Mitigations against common web threats leverage patterns described by OWASP and tools such as ModSecurity; authentication integration is possible via mod_authnz_ldap, mod_auth_basic, or identity providers like OAuth 2.0, OpenID Connect, and SAML implementations from Shibboleth.

History and Development

mod_wsgi originated in the mid-2000s, created by Graham Dumpleton to provide a robust WSGI host for Apache HTTP Server deployments. Its development paralleled the standardization of WSGI in PEP 3333 and the growth of web frameworks such as Django (web framework), Pylons (web framework), and Flask (web framework). Over time, contributions and issues have been tracked alongside projects managed by communities linked to Python Package Index and discussions in mailing lists associated with Apache Software Foundation and the Python Software Foundation. Alternatives and contemporaries like uWSGI, Gunicorn, and serverless offerings from Amazon Lambda, Google Cloud Functions, and Azure Functions shifted deployment patterns while mod_wsgi remains relevant for Apache-centric infrastructures.

Category:Web server software