<p>gunicorn 20.0.0: --pegar sin detectar argumentos en [servidor:principal]</p>

Mis disculpas. La entrada del registro de cambios solo dice "Simplificar la documentación de implementación de pegado", y debería haber ayudado a preparar una mejor entrada de noticias aquí.

El PR para esto está aquí: https://github.com/benoitc/gunicorn/pull/1957

Anteriormente, habíamos obsoleto use = egg:gunicorn#main pero ya no está obsoleto. El cambio pretende aclarar el papel de Gunicorn en un entorno compatible con Paste Deploy.

Hay dos opciones para usar Gunicorn con este estilo de archivo .ini .

La primera opción es usar la CLI gunicorn . Cuando haga esto, debe usar las banderas CLI propias de Gunicorn o el módulo de configuración propio de Gunicorn (predeterminado gunicorn.conf.py ) para configurar los argumentos del servidor. Gunicorn enlaza el zócalo, gestiona la recarga, escribe archivos PID, etc. Gunicorn puede usar una sección app en su .ini para configurar la aplicación invocable.

La segunda opción es usar un ejecutor de Paste Script como pserve . En este caso, este ejecutor de secuencias de comandos administra la recarga, escribe archivos PID, etc. La mayoría de las otras opciones aún deberían funcionar, pero para usar el bloque server de su archivo .ini necesita invocar un ejecutor de secuencias de comandos que sea compatible con Pegar. Gunicorn ya no es un corredor de guiones.

Avíseme si puedo agregar más claridad.

En su caso, debería poder continuar como antes, pero use pserve en lugar de gunicorn para iniciar su aplicación. Toda la configuración del servidor para Gunicorn puede estar en su bloque server , como parece que ya lo ha hecho.

El comportamiento anterior era potencialmente confuso porque permitía especificar opciones en la línea de comandos que entrarían en conflicto con el archivo. También recibimos solicitudes para agregar la capacidad de especificar variables de configuración para la interpolación en el archivo .ini y especificar diferentes bloques server (además de diferentes bloques app ). Como resultado, se tomó la decisión de desaprobar el uso de Gunicorn como un ejecutor de Paste _server_ en lugar de intentar agregar soporte para todas estas características. Gunicorn CLI ahora admite la lectura de un archivo Paste Deploy .ini para construir una aplicación, pero el uso de bloques server se deja a las herramientas dedicadas en ese ecosistema.

En su caso, debería poder continuar como antes, pero use pserve en lugar de gunicorn para iniciar su aplicación.

Gracias por la rápida respuesta @tilgovi!

Siguiendo tu recomendación:

$ pserve development.ini
# ...
Starting server in PID 40148.
[2019-11-12 14:26:30 -0800] [40148] [INFO] Starting gunicorn 20.0.0
[2019-11-12 14:26:30 -0800] [40148] [INFO] Listening at: https://0.0.0.0:9090 (40148)
[2019-11-12 14:26:30 -0800] [40148] [INFO] Using worker: gevent
[2019-11-12 14:26:30 -0800] [40263] [INFO] Booting worker with pid: 40263

Lo cual es genial, ya que parte de las relaciones públicas internas que abrí involucraban tener que cambiar el comando pserve a gunicorn , lo cual desconfiaba un poco ya que no soy el desarrollador original de nuestro servidor API interno.

Eso resuelve mis problemas, siéntete libre de cerrar este problema =)

Gracias,
Correy

Una nota final, y luego creo que he agregado todos los detalles que puedo recordar. ¡Era potencialmente confuso que invocar gunicorn --paste production.ini usaría Gunicorn como servidor _incluso si el bloque server especificaba algo diferente a egg:gunicorn#main _!

Dado que Gunicorn es principalmente un servidor y administrador de procesos, no tiene sentido que Gunicorn sea una CLI general para invocar servidores arbitrarios compatibles con Paste. En cambio, Gunicorn es un servidor que admite aplicaciones Paste Deploy y es un servidor compatible con Paste. ¡Sin embargo, _no_ es una CLI del ejecutor de Pegar Script!

Abrí un número en el libro de cocina Pyramid para esto: https://github.com/Pylons/pyramid_cookbook/issues/222

Pensé que había documentado esto a fondo en Gunicorn, pero al principio no pude encontrar la referencia. Está aquí: http://docs.gunicorn.org/en/stable/run.html#paste -deployment

@tilgovi solo un aviso, esto también fue un cambio importante para mi equipo. ¿Quizás valga la pena pasar a la parte de cambio de última hora del registro de cambios?

Volveré a abrir el problema y me autoasignaré. Lo cerraré cuando actualice el registro de cambios para que sea más legible aquí.

Nuevamente, mis disculpas por no mencionarlo más claramente en el registro de cambios inicialmente.

@tilgovi golpe

Por favor, avíseme si esto debería abrirse como un problema separado.

Este puede ser un problema aislado con nuestro código base, pero después de un poco más de prueba, mi equipo notó que para nuestro servidor API, gunicorn 20.0.0 rompe la función pyramid_ldap3.get_ldap_connector .

gunicorn 20.0.0 :

En el arranque:

$ pip list | grep gunicorn
gunicorn             20.0.0
$ pserve bioapps/development.ini
[2019-11-20 15:55:30 -0800] [9902] [INFO] Starting gunicorn 20.0.0
[2019-11-20 15:55:30 -0800] [9902] [INFO] Listening at: https://0.0.0.0:10999 (9902)
[2019-11-20 15:55:30 -0800] [9902] [INFO] Using worker: gevent
[2019-11-20 15:55:30 -0800] [10034] [INFO] Booting worker with pid: 10034
/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:53: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. It may also silently lead to incorrect behaviour on Python 3.7. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016. Modules that had direct imports (NOT patched): ['urllib3.util.ssl_ (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/ssl_.py)', 'urllib3.util (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/__init__.py)'].
  monkey.patch_all()

Después de intentar autenticar:

[2019-11-20 15:57:54,189] INFO  [access:342][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" {'username': 'colim', 'password': ''}
[2019-11-20 15:57:57,276] ERROR [exc_logger:114][DummyThread-1] 'https://bioappsdev02.bcgsc.ca:10999/session'
Traceback (most recent call last):
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/tweens.py", line 39, in excview_tween
    response = handler(request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/router.py", line 156, in handle_request
    view_name
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/view.py", line 642, in _call_view
    response = view_callable(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/config/views.py", line 181, in __call__
    return view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 390, in attr_view
    return view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 368, in predicate_wrapper
    return view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 439, in rendered_view
    result = view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 148, in _requestonly_view
    response = view(request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/cornice/service.py", line 493, in wrapper
    response = view_(request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/bioapps/api/endpoints/session.py", line 139, in session_post
    username, request.validated['password'], request,
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/bioapps/api/endpoints/session.py", line 27, in get_ldap_groups
    auth = connector.authenticate(username, password)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid_ldap3/__init__.py", line 208, in authenticate
    password=escape_for_search(password))
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid_ldap3/__init__.py", line 82, in execute
    with manager.connection() as conn:
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid_ldap3/__init__.py", line 165, in connection
    auto_bind=True, lazy=False, read_only=True)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/core/connection.py", line 326, in __init__
    self.do_auto_bind()
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/core/connection.py", line 343, in do_auto_bind
    self.bind(read_server_info=True)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/core/connection.py", line 585, in bind
    _, result = self.get_response(response)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/strategy/base.py", line 370, in get_response
    raise LDAPResponseTimeoutError('no response from server')
ldap3.core.exceptions.LDAPResponseTimeoutError: no response from server
[2019-11-20 15:57:57,298] INFO  [access:362][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" 500 206

gunicorn 19.9.0

En el arranque:

$ pip install gunicorn==19.9.0
Collecting gunicorn==19.9.0
  Using cached https://files.pythonhosted.org/packages/8c/da/b8dd8deb741bff556db53902d4706774c8e1e67265f69528c14c003644e6/gunicorn-19.9.0-py2.py3-none-any.whl
Installing collected packages: gunicorn
  Found existing installation: gunicorn 20.0.0
    Uninstalling gunicorn-20.0.0:
      Successfully uninstalled gunicorn-20.0.0
Successfully installed gunicorn-19.9.0
$ pip list | grep unicorn
gunicorn             19.9.0
$ gunicorn --paste bioapps/development.ini
[2019-11-20 16:03:45 -0800] [12015] [INFO] Starting gunicorn 19.9.0
[2019-11-20 16:03:45 -0800] [12015] [INFO] Listening at: https://0.0.0.0:10999 (12015)
[2019-11-20 16:03:45 -0800] [12015] [INFO] Using worker: gevent
[2019-11-20 16:03:45 -0800] [12018] [INFO] Booting worker with pid: 12018

Después de intentar autenticar:

[2019-11-20 16:04:39,292] INFO  [access:342][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" {'username': 'colim', 'password': ''}
[2019-11-20 16:04:39,527] INFO  [access:362][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" 200 639

No se realizaron cambios en development.ini entre gunicorn 20.0.0 y gunicorn 19.9.0 .

Curiosamente, podemos detener el error con gunicorn 20.0.0 si iniciamos el servidor con el siguiente comando:

$ pip list | grep unicorn
gunicorn             20.0.0
$ gunicorn --paste bioapps/development.ini -b 0.0.0.0:8999 --workers 1 --certfile /etc/ssl/certs/current/webserver.cer  --keyfile /etc/ssl/certs/current/private.key.u
[2019-11-20 16:14:27 -0800] [14783] [INFO] Starting gunicorn 20.0.0
[2019-11-20 16:14:27 -0800] [14783] [INFO] Listening at: https://0.0.0.0:8999 (14783)
[2019-11-20 16:14:27 -0800] [14783] [INFO] Using worker: sync
[2019-11-20 16:14:27 -0800] [14798] [INFO] Booting worker with pid: 14798

[2019-11-20 16:16:39,550] INFO  [access:342][MainThread] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:8999/session HTTP/1.1" {'username': 'colim', 'password': ''}
[2019-11-20 16:16:39,768] INFO  [access:362][MainThread] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:8999/session HTTP/1.1" 200 639

No estoy seguro de si está relacionado en absoluto, pero iniciar el servidor usando gunicorn 20.0.0 con pserve es la única vez que vemos esta advertencia:

/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:53: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. It may also silently lead to incorrect behaviour on Python 3.7. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016. Modules that had direct imports (NOT patched): ['urllib3.util.ssl_ (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/ssl_.py)', 'urllib3.util (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/__init__.py)'].
  monkey.patch_all()

@tilgovi , ¿qué cambiarías en el registro de cambios?

@benoitc Me gustaría llamar la atención sobre la eliminación de la compatibilidad con las definiciones de servidor Paste Deploy en la CLI de Gunicorn. Puedo hacer esto hoy.

¿Está bien si modifico el registro de cambios de forma retroactiva para que quede más claro (haga la sección de cambios importantes en la versión 20.0)?

@CorreyL interesante! Definitivamente puede ejecutar gunicorn con las opciones especificadas en la línea de comando de esa manera. Creo que es la forma preferida y más segura de ejecutar gunicorn . La integración con pserve es una conveniencia, pero es bueno saber que causa problemas aquí. Espero no haber cometido un error al eliminarlo.

¿Está bien si modifico el registro de cambios de forma retroactiva para que quede más claro (haga la sección de cambios importantes en la versión 20.0)?

@tilgovi sí definitivamente

@tilgovi , ¿puedes agregar este cambio hoy? Sería genial tenerlo para 20.0.1 :)

Se agregó una nota de una línea a c25563f. La documentación ya ha sido actualizada desde que ocurrió el cambio. Con suerte, cualquiera que vea esa nota pueda encontrar la documentación y estos problemas. 😅

@tilgovi gracias

Solo quería agregar otra confirmación de haber sido sorprendentemente impactado por esto. No fue muy significativo en mi caso, pero estaba confundido acerca de por qué gunicorn dejó de recargar automáticamente en el desarrollo desde la actualización, así como algunos otros cambios de comportamiento menores. Pasé un tiempo tratando de resolverlo hoy y me di cuenta de que la configuración en mis archivos INI --paste ya no funcionaba, lo que me ayudó a encontrar el camino a este problema.

No tengo idea de si esto es factible, pero ¿sería posible que gunicorn emita una advertencia si detecta que todavía está intentando configurar los argumentos del servidor a través del archivo Paster?

Mis disculpas por la interrupción, @Deimos. Revisaría las relaciones públicas, pero no tengo planes específicos para agregar más aquí.

¿Qué tal un caso en el que realmente desea usar --pegar junto con --config? Que en nuestro caso (RhodeCode) es un gran requisito para la lógica especial de monitoreo de memoria que tenemos en la configuración de gunicorn.

@marcinkuzminski ese es el caso de uso ideal. Simplemente especifique tanto --paste como --config . Sin embargo, Gunicorn no leerá la sección "servidor" del archivo pegar ini porque se espera que configure el servidor en el archivo de configuración de gunicorn.

Eso es lamentable.

Estamos enviando gunicorn a los clientes en el instalador, y toda la lógica y la configuración se han delegado a los archivos .ini. Así es como la mayoría de los ejemplos en Internet especifican para proyectos Pyramid.

Este cambio rompe eso, y probablemente sea más fácil para nosotros bifurcar gunicorn para recuperar eso, luego cambiar la lógica y delegar la configuración a gunicorn_conf.py :(

¿Qué pasa si se leen las opciones --pegar, con un prefijo especial? por ejemplo, podría configurar gunicorn con --paste pero solo leería las opciones de configuración que tendrían el prefijo gunicorn.

p.ej

gunicorn.trabajadores = 2
gunicor.XXX = YYY

No necesita usar --config . Puede usar la pasta INI por completo. Para eso, use pserve en lugar de gunicorn . Consulte la documentación: https://docs.gunicorn.org/en/stable/run.html#paste -deployment

El cambio que se realizó fue solo para eliminar la compatibilidad con el uso de Gunicorn como una CLI de implementación de pegado general que puede ejecutar servidores. Gunicorn sigue siendo un servidor compatible con Paste.

Este cambio se realizó para eliminar posibles confusiones en las que un archivo .ini especificaría mesera, o cualquier otro servidor, en su bloque server , pero ejecutarlo con gunicorn --paste production.ini en realidad no usaría camarera en absoluto. La gente también solicitaba a menudo la posibilidad de especificar un bloque server alternativo que no sea server:main . Mantener el soporte para estas funciones cuando existen CLI perfectamente buenas como pserve para esto no parecía tener sentido.

La CLI gunicorn puede leer una definición de aplicación desde un archivo INI, pero usa su propio archivo de configuración para configurar un servidor. Utilice otra herramienta (como pserve ) como script/ejecutor de procesos si desea utilizar el archivo INI para configurar un servidor Gunicorn.

pero tenemos que usar --config junto con --paste, según mi primer comentario.
En nuestro proyecto, todo se administra mediante un único archivo de configuración (.ini). Hay mucha lógica de actualización/escala automática que solo ajusta el archivo .ini. Luego usamos también --config para especificar una configuración personalizada de python que establece

• formato de registrador personalizado (esto técnicamente no es posible especificarlo usando el archivo .ini)
• gestión de la memoria del trabajador (código Python)

Gunicorn es compatible con Paste, pero la funcionalidad está limitada de esta manera, y creó un problema para nosotros del que no podemos recuperarnos porque no podemos tener 2 archivos de configuración, y también mover a la configuración en otro archivo es más trabajo que bifurcar Gunicorn y mantener esa bifurcación solo para recuperar ese comportamiento.

Conozco el motivo de este boleto, pero solíamos usar gunicorn y waitress juntos, y creo que ejecutar el binario gunicorn es lo suficientemente explícito, en mi humilde opinión. Además, creo que incluso puede detectar si los usuarios usan un huevo diferente y convertirlo en un error grave.

Si no recuerdo mal, no consideramos tal uso. Probablemente podamos traer de vuelta
el soporte de él como el caso de uso suena bien. ¿Estaría bien tener un
registro de advertencia para ello?

El vie 16 oct 2020 a las 08:28 Marcin Kuźmiński [email protected]
escribió:

pero tenemos que usar --config junto con --paste, según mi primera
comentario.
En nuestro proyecto, todo se gestiona mediante un único archivo de configuración (.ini)
Hay mucha lógica de actualización/escala automática que solo ajusta el archivo .ini.
Luego usamos también --config para especificar una configuración personalizada de python que establece

• formato de registrador personalizado (esto técnicamente no es posible
  especificado usando el archivo .ini)
• gestión de la memoria del trabajador

Gunicorn es compatible con pasta, pero la funcionalidad está limitada de esta manera,
y nos creó un problema del que no podemos recuperarnos.

Conozco la razón, pero solíamos usar gunicornio y camarera juntos,
y creo que ejecutar el binario gunicorn es lo suficientemente explícito, en mi humilde opinión.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/benoitc/gunicorn/issues/2169#issuecomment-709838842 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAADRIQR2CLVUOYK6FDY2ZDSK7RZFANCNFSM4JMI65YA
.

>

Enviado desde mi móvil

De hecho, pensé en otra solución si es posible. Al usar pserve con un huevo de unicornio, también sería bueno que el archivo de configuración se estableciera dentro del archivo .ini.

p.ej

use = egg:gunicorn#main
workers = 2
config = /path/to/gunicorn_conf.py

Entonces cargaría gunicorn_conf.py exactamente como lo hace --config=/path/to/gunicorn_conf.py

Entonces, lo anterior funcionaría para nosotros, y también está resolviendo el problema de este boleto. No estoy seguro de cuán fácil y factible es implementarlo.

De lo contrario, si pudiera traer la funcionalidad de cargar la configuración desde el archivo .ini al ejecutar el binario gunicorn, sería increíble, eso nos ahorraría muchas molestias. Tener una advertencia al respecto no es problema.

De hecho, pensé en otra solución si es posible. Al usar pserve con un huevo de unicornio, también sería bueno que el archivo de configuración se estableciera dentro del archivo .ini.

Eso debería funcionar y está documentado. Si no es así, ¡presente un error!

Bien, revisaremos esto. Pero AFAIR hubo ligeros cambios en el funcionamiento de los binarios gunicorn vs pserve. Si no recuerdo mal, gunicorn --paste tenía acceso a la ruta del archivo .ini, mientras que pserve usando gunicorn egg no. Verificaremos esto y abriremos un ticket relevante si es necesario.