<p>gunicorn 20.0.0 : --paste ne détecte pas les arguments sous [server:main]</p>

Mes excuses. L'entrée du journal des modifications indique uniquement "Simplifier la documentation du déploiement par collage", et j'aurais dû aider à préparer une meilleure entrée de nouvelles ici.

Le PR pour cela est ici : https://github.com/benoitc/gunicorn/pull/1957

Auparavant, nous avions obsolète use = egg:gunicorn#main mais ce n'est plus obsolète. Le changement vise à clarifier le rôle de Gunicorn dans un environnement compatible Paste Deploy.

Il existe deux options pour utiliser Gunicorn avec ce style de fichier .ini .

La première option consiste à utiliser la CLI gunicorn . Lorsque vous faites cela, vous devez utiliser les propres drapeaux CLI de Gunicorn ou le propre module de configuration de Gunicorn (par défaut gunicorn.conf.py ) pour configurer les arguments du serveur. Gunicorn bind est le socket, gère le rechargement, écrit les fichiers PID, etc. Gunicorn peut utiliser une section app dans votre .ini pour configurer l'application appelable.

La deuxième option consiste à utiliser un exécuteur de collage de script tel que pserve . Dans ce cas, ce script runner gère le rechargement, écrit les fichiers PID etc. La plupart des autres options devraient toujours fonctionner, mais pour utiliser le bloc server de votre fichier .ini , vous devez invoquer un exécuteur de script compatible avec le collage. Gunicorn n'est plus un tel script runner.

Faites-moi savoir si je peux ajouter plus de clarté.

Dans votre cas, vous devriez pouvoir continuer comme avant, mais utilisez pserve plutôt que gunicorn pour démarrer votre application. Toute la configuration du serveur pour Gunicorn peut alors être dans votre bloc server , comme vous semblez l'avoir déjà fait.

Le comportement précédent était potentiellement déroutant car il permettait de spécifier des options sur la ligne de commande qui entreraient en conflit avec le fichier. Nous avons également reçu des demandes pour ajouter la possibilité de spécifier des variables de configuration pour l'interpolation dans le fichier .ini et de spécifier différents blocs server (en plus de différents blocs app ). En conséquence, la décision a été prise de déconseiller l'utilisation de Gunicorn en tant que coureur Paste _server_ plutôt que d'essayer d'ajouter la prise en charge de toutes ces fonctionnalités. La CLI Gunicorn prend désormais en charge la lecture d'un fichier Paste Deploy .ini pour construire une application, mais l'utilisation de blocs server est laissée à des outils dédiés dans cet écosystème.

Dans votre cas, vous devriez pouvoir continuer comme avant, mais utilisez pserve plutôt que gunicorn pour démarrer votre application.

Merci pour la réponse rapide @tilgovi !

Suite à votre recommandation :

$ 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

Ce qui est génial, car une partie du PR interne que j'ai ouvert impliquait de changer la commande pserve en gunicorn , ce dont je me méfiais un peu car je ne suis pas le développeur original de notre serveur API interne.

Cela résout mes problèmes, n'hésitez pas à fermer ce problème =)

Merci,
Corréy

Une dernière note, et puis je pense avoir ajouté tous les détails dont je me souviens. Il était potentiellement déroutant que l'invocation gunicorn --paste production.ini utilise Gunicorn comme serveur _même si le bloc server spécifiait autre chose que egg:gunicorn#main _ !

Étant donné que Gunicorn est principalement un serveur et un gestionnaire de processus, il n'est pas logique que Gunicorn soit une CLI générale pour invoquer des serveurs arbitraires compatibles avec Paste. Au lieu de cela, Gunicorn est un serveur qui prend en charge les applications Paste Deploy et c'est un serveur compatible avec Paste. Cependant, ce n'est _pas_ une CLI d'exécution de Paste Script !

J'ai ouvert un numéro sur le livre de recettes Pyramid pour cela : https://github.com/Pylons/pyramid_cookbook/issues/222

Je pensais avoir documenté cela de manière approfondie dans Gunicorn lui-même, mais je n'ai pas pu trouver la référence au début. C'est ici : http://docs.gunicorn.org/en/stable/run.html#paste -deployment

@tilgovi juste un avertissement, c'était aussi un changement radical pour mon équipe. Cela vaut peut-être la peine de passer à la partie changement de rupture du journal des modifications ?

Je vais rouvrir le problème et m'auto-assigner. Je le fermerai lorsque je mettrai à jour le changelog pour être plus lisible ici.

Encore une fois, mes excuses pour ne pas l'avoir dit plus clairement dans le journal des modifications au départ.

@tilgovi bosse

Veuillez me faire savoir si cela doit être ouvert en tant que problème distinct.

Il peut s'agir d'un problème isolé avec notre base de code, mais après quelques tests supplémentaires, mon équipe a remarqué que pour notre serveur d'API, gunicorn 20.0.0 casse la fonction pyramid_ldap3.get_ldap_connector .

gunicorn 20.0.0 :

Au démarrage:

$ 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()

Après avoir tenté de s'authentifier :

[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

Au démarrage:

$ 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

Après avoir tenté de s'authentifier :

[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

Aucune modification n'a été apportée à development.ini entre gunicorn 20.0.0 et gunicorn 19.9.0 .

Fait intéressant, nous pouvons arrêter l'erreur avec gunicorn 20.0.0 si nous démarrons le serveur avec la commande suivante :

$ 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

Je ne sais pas si c'est lié du tout, mais démarrer le serveur en utilisant gunicorn 20.0.0 avec pserve est la seule fois où nous voyons cet avertissement :

/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 que changeriez-vous dans le journal des modifications ?

@benoitc Je voudrais appeler la suppression de la prise en charge des définitions de serveur Paste Deploy dans la CLI Gunicorn. Je peux le faire aujourd'hui.

Est-ce que ça va si je modifie rétroactivement le journal des modifications pour le rendre plus clair (faire la section des modifications avec rupture dans la version 20.0) ?

@CorreyL intéressant ! Vous pouvez certainement exécuter gunicorn avec les options spécifiées sur la ligne de commande comme ça. Je pense que c'est le moyen préféré et le plus sûr d'exécuter gunicorn . L'intégration avec pserve est pratique, mais il est bon de savoir que cela cause des problèmes ici. J'espère que je n'ai pas fait d'erreur en le dépréciant.

Est-ce que ça va si je modifie rétroactivement le journal des modifications pour le rendre plus clair (faire la section des modifications avec rupture dans la version 20.0) ?

@tilgovi oui définitivement

@tilgovi pouvez-vous ajouter ce changement aujourd'hui ? Ce serait cool de l'avoir pour 20.0.1 :)

Ajout d'une note d'une ligne à c25563f. La documentation a déjà été mise à jour depuis le changement. Espérons que quiconque verra cette note pourra trouver la documentation et ces problèmes. 😅

@tilgovi merci

Je voulais juste ajouter une autre confirmation d'être étonnamment impacté par cela. Ce n'était pas très important dans mon cas, mais j'étais confus quant à la raison pour laquelle gunicorn avait arrêté le rechargement automatique dans le développement depuis la mise à niveau ainsi que quelques autres changements de comportement mineurs. J'ai passé du temps à essayer de le comprendre aujourd'hui et j'ai réalisé que les paramètres de mes fichiers INI --paste ne fonctionnaient plus, ce qui m'a aidé à trouver mon chemin vers ce problème.

Je ne sais pas si cela est faisable, mais serait-il possible que gunicorn génère un avertissement s'il détecte que vous essayez toujours de définir des arguments de serveur via le fichier Paster?

Mes excuses pour la perturbation, @Deimos. Je passerais en revue les PR, mais je n'ai pas de plans spécifiques pour en ajouter plus ici.

Que diriez-vous d'un cas où vous voudriez réellement utiliser --paste avec --config ? Ce qui dans notre cas (RhodeCode) est une grande exigence pour la logique spéciale de surveillance de la mémoire que nous avons dans la configuration gunicorn.

@marcinkuzminski c'est le cas d'utilisation idéal. Spécifiez simplement --paste et --config . Cependant, Gunicorn ne lira pas la section "server" du fichier paste ini car on s'attend à ce que vous configuriez le serveur dans le fichier de configuration de gunicorn.

C'est malheureux.

Nous expédions gunicorn aux clients dans le programme d'installation, et toute la logique et la configuration ont été déléguées aux fichiers .ini. C'est ainsi que la plupart des exemples sur Internet spécifient également les projets Pyramid.

Ce changement casse cela, et il est probablement plus facile pour nous de bifurquer gunicorn pour le ramener, puis de changer la logique et de déléguer la configuration à gunicorn_conf.py :(

Et si les options --paste étaient lues, avec un préfixe spécial. par exemple, vous pouvez configurer gunicorn avec --paste mais il ne lira que les options de configuration qui seraient préfixées par gunicorn.

par exemple

gunicorn.workers = 2
gunicor.XXX = AAAA

Vous n'avez pas besoin d'utiliser --config . Vous pouvez utiliser la pâte INI entièrement. Pour cela, utilisez pserve au lieu de gunicorn . Voir la documentation : https://docs.gunicorn.org/en/stable/run.html#paste -deployment

La modification apportée visait uniquement à supprimer la prise en charge de l'utilisation de Gunicorn en tant que CLI générale de déploiement de collage pouvant exécuter des serveurs. Gunicorn est toujours lui-même un serveur compatible avec Paste.

Cette modification a été apportée pour supprimer la confusion potentielle où un fichier .ini spécifierait une serveuse, ou tout autre serveur, dans son bloc server , mais l'exécuter avec gunicorn --paste production.ini n'utiliserait pas réellement serveuse du tout. Les gens ont également souvent demandé la possibilité de spécifier un autre bloc server autre que server:main . Maintenir la prise en charge de ces fonctionnalités alors que des CLI parfaitement bonnes comme pserve existent pour cela ne semblait pas logique.

La CLI gunicorn peut lire une définition d'application à partir d'un fichier INI, mais elle utilise son propre fichier de configuration pour configurer un serveur. Utilisez un autre outil (comme pserve ) comme exécuteur de script/processus si vous souhaitez utiliser le fichier INI pour configurer un serveur Gunicorn.

mais nous devons utiliser --config avec --paste, selon mon 1 er commentaire.
Dans notre projet, tout est géré par un seul fichier de configuration (.ini). Il y a beaucoup de logique de mise à niveau/mise à l'échelle automatique qui ajuste simplement le fichier .ini. Ensuite, nous utilisons également --config pour spécifier une configuration python personnalisée qui définit

• format d'enregistreur personnalisé (techniquement, il n'est pas possible de le spécifier à l'aide du fichier .ini)
• gestion de la mémoire des travailleurs (code Python)

Gunicorn est compatible avec Paste, mais la fonctionnalité est limitée de cette manière, et cela nous a créé un problème dont nous ne pouvons pas nous remettre parce que nous ne pouvons pas avoir 2 fichiers de configuration, et aussi passer à la configuration sur un autre fichier est plus de travail que de bifurquer Gunicorn et maintenir cette fourche juste pour ramener ce comportement.

Je connais la raison d'être de ce ticket, mais nous avions l'habitude d'utiliser le gunicorn et la serveuse ensemble, et je pense que l'exécution du binaire gunicorn est assez explicite, à mon humble avis. De plus, je pense que vous pouvez même détecter si les utilisateurs utilisent un œuf différent et en faire une erreur difficile.

Nous n'avons pas considéré une telle utilisation si je me souviens bien. Nous pouvons probablement ramener
le support de celui-ci car le cas d'utilisation sonne bien. Serait-il acceptable d'avoir un
avertissement de journal pour cela?

Le ven 16 oct. 2020 à 08:28 Marcin Kuźmiński [email protected]
a écrit:

mais nous devons utiliser --config avec --paste, selon mon 1 er
commenter.
Dans notre projet, tout est géré par un seul fichier de configuration (.ini)
Il y a beaucoup de logique de mise à niveau/mise à l'échelle automatique qui ajuste simplement le fichier .ini.
Ensuite, nous utilisons également --config pour spécifier une configuration python personnalisée qui définit

• format d'enregistrement personnalisé (cela n'est techniquement pas possible d'être
  spécifié à l'aide du fichier .ini)
• gestion de la mémoire des travailleurs

Gunicorn est compatible avec la pâte, mais la fonctionnalité est limitée de cette façon,
et cela nous a créé un problème dont nous sommes incapables de nous remettre.

Je connais la raison, mais nous avions l'habitude d'utiliser le gunicorn et la serveuse ensemble,
et je pense que l'exécution du binaire gunicorn est assez explicite, à mon humble avis.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/benoitc/gunicorn/issues/2169#issuecomment-709838842 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/AAADRIQR2CLVUOYK6FDY2ZDSK7RZFANCNFSM4JMI65YA
.

>

Envoyé depuis mon portable

En fait, j'ai pensé à une autre solution si possible. Lors de l'utilisation de pserve avec un œuf de licorne, il serait également agréable que le fichier de configuration soit défini dans le fichier .ini.

par exemple

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

Donc, il chargerait le gunicorn_conf.py exactement comme --config=/path/to/gunicorn_conf.py le fait

Donc, ce qui précède fonctionnerait pour nous, et cela résoudrait également le problème de ce ticket. Je ne sais pas à quel point cela est facile et faisable à mettre en œuvre.

Sinon, si vous pouviez apporter la fonctionnalité de chargement de la configuration à partir du fichier .ini lors de l'exécution du binaire gunicorn, ce serait génial, cela nous éviterait beaucoup de tracas. Avoir un avertissement à ce sujet n'est pas un problème

En fait, j'ai pensé à une autre solution si possible. Lors de l'utilisation de pserve avec un œuf de licorne, il serait également agréable que le fichier de configuration soit défini dans le fichier .ini.

Cela devrait fonctionner et est documenté. Si ce n'est pas le cas, veuillez signaler un bogue !

Ok, nous allons vérifier cela. Mais AFAIR, il y a eu de légers changements dans le fonctionnement des binaires gunicorn vs pserve. Si je me souviens bien, gunicorn --paste avait accès au chemin du fichier .ini, contrairement à pserve using gunicorn egg. Nous vérifierons cela et ouvrirons un ticket correspondant si nécessaire.