Changeset - 87de82eb7cb0
[Not reviewed]
default
0 1 0
Mads Kiilerich (mads) - 6 years ago 2020-06-08 14:10:13
mads@kiilerich.com
Grafted from: e534f564afa5
docs: update docs changes from stable 75b1994e4959 with kallithea.config.application refactoring in default 3a02b678b5e7
1 file changed with 1 insertions and 1 deletions:
0 comments (0 inline, 0 general)
docs/overview.rst
Show inline comments
 
@@ -156,49 +156,49 @@ server that serves WSGI applications ove
 

	
 
Kallithea itself is not serving HTTP (or HTTPS); that is the web server's
 
responsibility. Kallithea does however need to know its own user facing URL
 
(protocol, address, port and path) for each HTTP request. Kallithea will
 
usually use its own HTML/cookie based authentication but can also be configured
 
to use web server authentication.
 

	
 
There are several web server options:
 

	
 
- Kallithea uses the Gearbox_ tool as command line interface. Gearbox provides
 
  ``gearbox serve`` as a convenient way to launch a Python WSGI / web server
 
  from the command line. That is perfect for development and evaluation.
 
  Actual use in production might have different requirements and need extra
 
  work to make it manageable as a scalable system service.
 

	
 
  Gearbox comes with its own built-in web server for development but Kallithea
 
  defaults to using Waitress_. Gunicorn_ and Gevent_ are also options. These
 
  web servers have different limited feature sets.
 

	
 
  The web server used by ``gearbox serve`` is configured in the ``.ini`` file.
 
  Create it with ``config-create`` using for example ``http_server=waitress``
 
  to get a configuration starting point for your choice of web server.
 

	
 
  (Gearbox will do like ``paste`` and use the WSGI application entry point
 
  ``kallithea.config.middleware:make_app`` as specified in ``setup.py``.)
 
  ``kallithea.config.application:make_app`` as specified in ``setup.py``.)
 

	
 
- `Apache httpd`_ can serve WSGI applications directly using mod_wsgi_ and a
 
  simple Python file with the necessary configuration. This is a good option if
 
  Apache is an option.
 

	
 
- uWSGI_ is also a full web server with built-in WSGI module. Use
 
  ``config-create`` with ``http_server=uwsgi`` to get a ``.ini`` file with
 
  uWSGI configuration.
 

	
 
- IIS_ can also server WSGI applications directly using isapi-wsgi_.
 

	
 
- A `reverse HTTP proxy <https://en.wikipedia.org/wiki/Reverse_proxy>`_
 
  can be put in front of another web server which has WSGI support.
 
  Such a layered setup can be complex but might in some cases be the right
 
  option, for example to standardize on one internet-facing web server, to add
 
  encryption or special authentication or for other security reasons, to
 
  provide caching of static files, or to provide load balancing or fail-over.
 
  Nginx_, Varnish_ and HAProxy_ are often used for this purpose, often in front
 
  of a ``gearbox serve`` that somehow is wrapped as a service.
 

	
 
The best option depends on what you are familiar with and the requirements for
 
performance and stability. Also, keep in mind that Kallithea mainly is serving
 
dynamically generated pages from a relatively slow Python process. Kallithea is
 
also often used inside organizations with a limited amount of users and thus no
0 comments (0 inline, 0 general)