File: deployment.rst

package info (click to toggle)
python-aiohttp 1.2.0-1
  • links: PTS, VCS
  • area: main
  • in suites: stretch
  • size: 2,288 kB
  • ctags: 4,380
  • sloc: python: 27,221; makefile: 236
file content (312 lines) | stat: -rw-r--r-- 8,733 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
=========================
aiohttp server deployment
=========================

There are several options for aiohttp server deployment:

* Standalone server

* Running a pool of backend servers behind of :term:`nginx`, HAProxy
  or other *reverse proxy server*

* Using :term:`gunicorn` behind of *reverse proxy*

Every method has own benefits and disadvantages.


.. _aiohttp-deployment-standalone:

Standalone
==========

Just call :func:`aiohttp.web.run_app` function passing
:class:`aiohttp.web.Application` instance.


The method is very simple and could be the best solution in some
trivial cases. But it doesn't utilize all CPU cores.

For running multiple aiohttp server instances use *reverse proxies*.

.. _aiohttp-deployment-nginx-supervisord:

Nginx+supervisord
=================

Running aiohttp servers behind :term:`nginx` makes several advantages.

At first, nginx is the perfect frontend server. It may prevent many
attacks based on malformed http protocol etc.

Second, running several aiohttp instances behind nginx allows to
utilize all CPU cores.

Third, nginx serves static files much faster than built-in aiohttp
static file support.

But this way requires more complex configuration.

Nginx configuration
--------------------

Here is short extraction about writing Nginx configuration file.
It doesn't cover all available Nginx options.

For full reference read `Nginx tutorial
<https://www.nginx.com/resources/admin-guide/>`_ and `official Nginx
documentation
<http://nginx.org/en/docs/http/ngx_http_proxy_module.html>`_.

First configure HTTP server itself:

.. code-block:: nginx

   http {
     server {
       listen 80;
       client_max_body_size 4G;

       server example.com;

       location / {
         proxy_set_header Host $http_host;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_redirect off;
         proxy_buffering off;
         proxy_pass http://aiohttp;
       }

       location /static {
         # path for static files
         root /path/to/app/static;
       }

     }
   }

This config listens on port ``80`` for server named ``example.com``
and redirects everything to ``aiohttp`` backend group.

Also it serves static files from ``/path/to/app/static`` path as
``example.com/static``.

Next we need to configure *aiohttp upstream group*:

.. code-block:: nginx

   http {
     upstream aiohttp {
       fail_timeout=0 means we always retry an upstream even if it failed
       # to return a good HTTP response

       # TCP servers
       server 127.0.0.1:8081 fail_timeout=0;
       server 127.0.0.1:8082 fail_timeout=0;
       server 127.0.0.1:8083 fail_timeout=0;
       server 127.0.0.1:8084 fail_timeout=0;
     }
   }

All HTTP requests for ``http://example.com`` except ones for
``http://example.com/static`` will be redirected to
``127.0.0.1:8081``, ``127.0.0.1:8082``, ``127.0.0.1:8083`` or
``127.0.0.1:8084`` *backend proxies*.

By default Nginx uses round-robin algorithm for backend selection.

.. note::

   Nginx is not the only existing *reverse proxy server* but the most
   popular one.  Alternatives like HAProxy may be used as well.

Supervisord
-----------

After configuring Nginx we need to start our aiohttp backends. Better
to use some tool for starting them automatically after system reboot
or backend crash.

There are very many ways to do it: Supervisord, Upstart, Systemd,
Gaffer, Circus, Runit etc.

Here we'll use `Supervisord <http://supervisord.org/>`_ for example::

   [program:aiohttp_1]
   cmd=/path/to/aiohttp_example.py 8081
   user=nobody
   autostart=true
   autorestart=true

   [program:aiohttp_2]
   cmd=/path/to/aiohttp_example.py 8082
   user=nobody
   autostart=true
   autorestart=true

   [program:aiohttp_3]
   cmd=/path/to/aiohttp_example.py 8083
   user=nobody
   autostart=true
   autorestart=true

   [program:aiohttp_4]
   cmd=/path/to/aiohttp_example.py 8084
   user=nobody
   autostart=true
   autorestart=true

The config will run four aiohttp server instances, ports are specified
by command line.

aiohttp server
--------------

The last step is preparing aiohttp server for working with supervisord.

Assuming we have properly configured :class:`aiohttp.web.Application`
and port is specified by command line the task is trivial::

   # aiohttp_example.py
   import argparse
   from aiohttp import web

   parser = argparse.ArgumentParser(description="aiohttp server example")
   parser.add_argument('port', type=int)


   if __name__ == '__main__':
       app = web.Application()
       # configure app

       args = parser.parse_args()
       web.run_app(app, port=args.port)

For real use cases we perhaps need to configure other things like
logging etc. but it's out of scope of the topic.


.. _aiohttp-deployment-gunicorn:

Nginx+Gunicorn
==============

aiohttp can be deployed using `Gunicorn
<http://docs.gunicorn.org/en/latest/index.html>`_, which is based on a
pre-fork worker model.  Gunicorn launches your app as worker processes
for handling incoming requests.

In opposite to deployment with :ref:`bare Nginx
<aiohttp-deployment-nginx-supervisord>` the solution doesn't need to
manually run several aiohttp processes and use tool like supervisord
for monitoring it. But nothing is for free: running aiohttp
application under gunicorn is slightly slower.


Prepare environment
-------------------

You firstly need to setup your deployment environment. This example is
based on `Ubuntu` 14.04.

Create a directory for your application::

  >> mkdir myapp
  >> cd myapp

`Ubuntu` has a bug in pyenv, so to create virtualenv you need to do some
extra manipulation::

  >> pyvenv-3.4 --without-pip venv
  >> source venv/bin/activate
  >> curl https://bootstrap.pypa.io/get-pip.py | python
  >> deactivate
  >> source venv/bin/activate

Now that the virtual environment is ready, we'll proceed to install
aiohttp and gunicorn::

  >> pip install gunicorn
  >> pip install -e git+https://github.com/KeepSafe/aiohttp.git#egg=aiohttp


Application
-----------

Lets write a simple application, which we will save to file. We'll
name this file *my_app_module.py*::

   from aiohttp import web

   def index(request):
       return web.Response(text="Welcome home!")


   my_web_app = web.Application()
   my_web_app.router.add_get('/', index)


Start Gunicorn
--------------

When `Running Gunicorn
<http://docs.gunicorn.org/en/latest/run.html>`_, you provide the name
of the module, i.e. *my_app_module*, and the name of the app,
i.e. *my_web_app*, along with other `Gunicorn Settings
<http://docs.gunicorn.org/en/latest/settings.html>`_ provided as
command line flags or in your config file.

In this case, we will use:

* the *'--bind'* flag to set the server's socket address;
* the *'--worker-class'* flag to tell Gunicorn that we want to use a
  custom worker subclass instead of one of the Gunicorn default worker
  types;
* you may also want to use the *'--workers'* flag to tell Gunicorn how
  many worker processes to use for handling requests. (See the
  documentation for recommendations on `How Many Workers?
  <http://docs.gunicorn.org/en/latest/design.html#how-many-workers>`_)

The custom worker subclass is defined in
*aiohttp.worker.GunicornWebWorker* and should be used instead of the
*gaiohttp* worker provided by Gunicorn, which supports only
aiohttp.wsgi applications::

  >> gunicorn my_app_module:my_web_app --bind localhost:8080 --worker-class aiohttp.worker.GunicornWebWorker
  [2015-03-11 18:27:21 +0000] [1249] [INFO] Starting gunicorn 19.3.0
  [2015-03-11 18:27:21 +0000] [1249] [INFO] Listening at: http://127.0.0.1:8080 (1249)
  [2015-03-11 18:27:21 +0000] [1249] [INFO] Using worker: aiohttp.worker.GunicornWebWorker
  [2015-03-11 18:27:21 +0000] [1253] [INFO] Booting worker with pid: 1253

Gunicorn is now running and ready to serve requests to your app's
worker processes.

.. note::

   If you want to use an alternative asyncio event loop
   `uvloop <https://github.com/MagicStack/uvloop>`_, you can use the
   ``aiohttp.worker.GunicornUVLoopWebWorker`` worker class.


More information
----------------

The Gunicorn documentation recommends deploying Gunicorn behind an
Nginx proxy server. See the `official documentation
<http://docs.gunicorn.org/en/latest/deploy.html>`_ for more
information about suggested nginx configuration.


Logging configuration
---------------------

``aiohttp`` and ``gunicorn`` use different format for specifying access log.

By default aiohttp uses own defaults::

   '%a %l %u %t "%r" %s %b "%{Referrer}i" "%{User-Agent}i"'

For more information please read :ref:`Format Specification for Accees
Log <aiohttp-logging-access-log-format-spec>`.

.. disqus::
  :title: aiohttp deployment with gunicorn