postgresql - uWSGI, Flask, sqlalchemy y postgres: error de SSL: descifrado fallido o mal mac de registro

nginx (2)

Estoy intentando configurar un servidor web de aplicación usando uWSGI + Nginx, que ejecuta una aplicación Flask con SQLAlchemy para comunicarse con una base de datos de Postgres.

Cuando realizo solicitudes al servidor web, cualquier otra respuesta tendrá un error de 500.

El error es:

Traceback (most recent call last): File "/var/env/argos/lib/python3.3/site-packages/sqlalchemy/engine/base.py", line 867, in _execute_context context) File "/var/env/argos/lib/python3.3/site-packages/sqlalchemy/engine/default.py", line 388, in do_execute cursor.execute(statement, parameters) psycopg2.OperationalError: SSL error: decryption failed or bad record mac The above exception was the direct cause of the following exception: sqlalchemy.exc.OperationalError: (OperationalError) SSL error: decryption failed or bad record mac

El error se desencadena por un simple método Flask-SQLAlchemy :

result = models.Event.query.get(id)

uwsgi está siendo administrado por un supervisor , que tiene una configuración:

[program:my_app] command=/usr/bin/uwsgi --ini /etc/uwsgi/apps-enabled/myapp.ini --catch-exceptions directory=/path/to/my/app stopsignal=QUIT autostart=true autorestart=true

y la configuración de uwsgi ve así:

[uwsgi] socket = /tmp/my_app.sock logto = /var/log/my_app.log plugins = python3 virtualenv = /path/to/my/venv pythonpath = /path/to/my/app wsgi-file = /path/to/my/app/application.py callable = app max-requests = 1000 chmod-socket = 666 chown-socket = www-data:www-data master = true processes = 2 no-orphans = true log-date = true uid = www-data gid = www-data

Lo más lejos que puedo llegar es que tiene algo que ver con la bifurcación de uwsgi. Pero más allá de eso, no tengo claro qué se debe hacer.

Como alternativa, puede tirar el motor. Así es como resolví el problema.

Tales problemas pueden suceder si hay una consulta durante la creación de la aplicación, es decir, en el módulo que crea la aplicación. Si eso indica, el motor asigna un grupo de conexiones y luego uwsgi tenedores.

Al invocar ''engine.dispose ()'', el grupo de conexiones en sí mismo se cierra y aparecerán nuevas conexiones tan pronto como alguien comience a hacer consultas nuevamente. Entonces, si lo hace al final del módulo donde crea su aplicación, se crearán nuevas conexiones después del fork UWSGI.

El problema terminó siendo la bifurcación de uwsgi.

Al trabajar con procesos múltiples con un proceso maestro, uwsgi inicializa la aplicación en el proceso maestro y luego copia la aplicación en cada proceso de trabajo. El problema es que si abre una conexión de base de datos al inicializar su aplicación, entonces tiene múltiples procesos que comparten la misma conexión, lo que causa el error anterior.

La solución es establecer la opción de configuración lazy para uwsgi , lo que obliga a una carga completa de la aplicación en cada proceso:

lazy

Establecer el modo perezoso (cargar aplicaciones en trabajadores en lugar de maestro).
Esta opción puede tener implicaciones en el uso de la memoria ya que no se puede usar la semántica de Copiar en la escritura. Cuando lazy está habilitada, solo los trabajadores serán recargados por las señales de recarga de uWSGI; el maestro permanecerá vivo. Como tal, los cambios de configuración de uWSGI no se recogen al volver a cargar por el maestro.

También hay una opción de lazy-apps :

lazy-apps

Cargue aplicaciones en cada trabajador en lugar de en el maestro.
Esta opción puede tener implicaciones en el uso de la memoria ya que no se puede usar la semántica de Copiar en la escritura. A diferencia de lazy, esto solo afecta la forma en que se cargan las aplicaciones, no el comportamiento del maestro al volver a cargar.

Esta configuración de uwsgi terminó trabajando para mí: