<p>gunicorn 20.0.0: --paste не обнаруживает аргументы в разделе [server:main]</p>

Мои извенения. В записи журнала изменений говорится только «Упростить вставку документации по развертыванию», и я должен был помочь подготовить здесь лучшую запись новостей.

PR для этого находится здесь: https://github.com/benoitc/gunicorn/pull/1957 .

Ранее мы считали устаревшим use = egg:gunicorn#main , но это больше не рекомендуется. Это изменение призвано прояснить роль Gunicorn в среде, совместимой с Paste Deploy.

Есть два варианта использования Gunicorn с этим стилем файла .ini .

Первый вариант — использовать интерфейс командной строки gunicorn . Когда вы делаете это, вы должны использовать собственные флаги CLI Gunicorn или собственный модуль конфигурации Gunicorn (по умолчанию gunicorn.conf.py ) для настройки аргументов сервера. Gunicorn связывает сокет, управляет перезагрузкой, записывает файлы PID и так далее. Gunicorn может использовать раздел app в вашем .ini для настройки вызываемого приложения.

Второй вариант — использовать средство запуска Paste Script, такое как pserve . В этом случае этот скрипт-раннер управляет перезагрузкой, записывает PID-файлы и так далее. Большинство других параметров должны по-прежнему работать, но для использования блока server вашего файла .ini вам необходимо вызвать программу запуска сценариев, совместимую с вставкой. Gunicorn больше не является таким исполнителем сценариев.

Дайте мне знать, если я могу добавить больше ясности.

В вашем случае вы сможете продолжить, как и раньше, но используйте pserve вместо gunicorn для запуска приложения. Вся конфигурация сервера для Gunicorn может быть в вашем блоке server , как вы уже сделали.

Предыдущее поведение могло сбивать с толку, поскольку позволяло указывать параметры в командной строке, которые конфликтовали с файлом. У нас также были запросы на добавление возможности указывать переменные конфигурации для интерполяции в файле .ini и указывать различные блоки server (в дополнение к различным блокам app ). В результате было принято решение отказаться от использования Gunicorn в качестве средства запуска Paste_server_, а не пытаться добавить поддержку всех этих функций. Интерфейс командной строки Gunicorn теперь поддерживает чтение файла Paste Deploy .ini для создания приложения, но использование блоков server остается на усмотрение специальных инструментов в этой экосистеме.

В вашем случае вы сможете продолжить, как и раньше, но используйте pserve вместо gunicorn для запуска приложения.

Спасибо за быстрый ответ @tilgovi!

По вашей рекомендации:

$ 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

Это здорово, так как часть внутреннего PR, который я открыл, заключалась в том, чтобы изменить команду pserve на gunicorn , чего я немного опасался, поскольку я не являюсь первоначальным разработчиком нашего внутренний сервер API.

Это решает мои проблемы, не стесняйтесь закрывать эту тему =)

Спасибо,
Корри

Последнее замечание, а затем, кажется, я добавил все детали, которые смог вспомнить. Потенциально сбивало с толку то, что вызов gunicorn --paste production.ini будет использовать Gunicorn в качестве сервера _даже если в блоке server указано что-то отличное от egg:gunicorn#main _!

Поскольку Gunicorn в первую очередь является менеджером серверов и процессов, Gunicorn не имеет смысла быть общим интерфейсом командной строки для вызова произвольных серверов, совместимых с Paste. Вместо этого Gunicorn — это сервер, поддерживающий приложения Paste Deploy, и он _является_ сервером, совместимым с Paste. Однако это _не_ интерфейс командной строки для запуска скриптов вставки!

Для этого я открыл вопрос в кулинарной книге Pyramid: https://github.com/Pylons/pyramid_cookbook/issues/222 .

Я думал, что полностью задокументировал это в самом Gunicorn, но сначала не мог найти ссылку. Это здесь: http://docs.gunicorn.org/en/stable/run.html#paste-deployment

@tilgovi просто предупреждаю, что это тоже было серьезным изменением для моей команды. Возможно, стоит перейти к части журнала изменений, посвященной критическим изменениям?

Я снова открою тему и назначу себя. Я закрою его, когда обновлю журнал изменений, чтобы он был более разборчивым.

Опять же, мои извинения за то, что я не назвал это более четко в журнале изменений изначально.

@tilgovi шишка

Пожалуйста, дайте мне знать, если это должно быть открыто как отдельная проблема.

Это может быть изолированная проблема с нашей кодовой базой, но после небольшого дополнительного тестирования моя команда заметила, что для нашего сервера API gunicorn 20.0.0 нарушает функцию pyramid_ldap3.get_ldap_connector .

gunicorn 20.0.0 :

На старте:

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

После попытки аутентификации:

[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

На старте:

$ 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

После попытки аутентификации:

[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

Не было внесено никаких изменений в development.ini между gunicorn 20.0.0 и gunicorn 19.9.0 .

Интересно, что мы можем остановить ошибку с помощью gunicorn 20.0.0 , если запустим сервер с помощью следующей команды:

$ 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

Я не уверен, связано ли это вообще, но запуск сервера с помощью gunicorn 20.0.0 с pserve — это единственный раз, когда мы видим это предупреждение:

/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 , что бы вы изменили в журнале изменений?

@benoitc Я хотел бы призвать к удалению поддержки определений сервера Paste Deploy в интерфейсе командной строки Gunicorn. Я могу сделать это сегодня.

Ничего, если я изменю журнал изменений задним числом, чтобы сделать его более понятным (сделать раздел критических изменений в выпуске 20.0)?

@CorreyL интересно! Вы определенно можете запустить gunicorn с параметрами, указанными в командной строке. Я думаю, что это предпочтительный и самый безопасный способ запустить gunicorn . Интеграция с pserve удобна, но приятно осознавать, что здесь возникают проблемы. Надеюсь, я не ошибся, отказавшись от этого.

Ничего, если я изменю журнал изменений задним числом, чтобы сделать его более понятным (сделать раздел критических изменений в выпуске 20.0)?

@tilgovi да, определенно

@tilgovi , можете ли вы добавить это изменение сегодня? Было бы здорово иметь его для 20.0.1 :)

Добавлено однострочное примечание к c25563f. Документация уже была обновлена ​​с момента внесения изменений. Надеюсь, любой, кто увидит эту заметку, сможет найти документацию и эти проблемы. 😅

@tilgovi спасибо

Просто хотел добавить еще одно подтверждение того, что это неожиданно повлияло на это. В моем случае это не имело большого значения, но я был сбит с толку тем, почему gunicorn перестал автоматически перезагружаться в dev после обновления, а также несколькими другими незначительными изменениями в поведении. Сегодня я потратил некоторое время, пытаясь понять это, и понял, что настройки в моих INI-файлах --paste больше не работают, что помогло мне найти путь к этой проблеме.

Я понятия не имею, возможно ли это, но возможно ли, чтобы gunicorn выводил предупреждение, если обнаружит, что вы все еще пытаетесь установить аргументы сервера через файл Paster?

Приношу свои извинения за перерыв, @Deimos. Я бы просмотрел PR, но у меня нет конкретных планов добавлять сюда больше.

Как насчет случая, когда вы действительно хотите использовать --paste вместе с --config? Что в нашем случае (RhodeCode) является большим требованием для специальной логики мониторинга памяти, которую мы получили в конфигурации пушки.

@marcinkuzminski , это идеальный вариант использования. Просто укажите --paste и --config . Однако Gunicorn не будет читать раздел «сервер» файла вставки ini, поскольку ожидается, что вы настроите сервер в файле конфигурации gunicorn.

Это неудачно.

Мы отправляем gunicorn клиентам в установщике, а вся логика и конфигурация делегированы файлам .ini. Это то же самое, что и большинство примеров в Интернете для проектов Pyramid.

Это изменение ломает это, и нам, вероятно, будет проще разветвить gunicorn, чтобы вернуть его, а затем изменить логику и делегировать конфигурацию в gunicorn_conf.py :(

А если бы опции --paste читались со специальным префиксом. например, вы можете настроить gunicorn с помощью --paste, но он будет читать только параметры конфигурации, которые будут иметь префикс gunicorn.

например

пушка.рабочие = 2
Gunicor.XXX = ГГГ

Вам не нужно использовать --config . Вы можете использовать пасту INI полностью. Для этого используйте pserve вместо gunicorn . См. документацию: https://docs.gunicorn.org/en/stable/run.html#paste -deployment

Внесенное изменение заключалось только в удалении поддержки использования Gunicorn в качестве общего интерфейса командной строки Paste Deployment, который может запускать серверы. Gunicorn по-прежнему _является_ сервером, совместимым с Paste.

Это изменение было внесено, чтобы устранить возможную путаницу, когда файл .ini будет указывать официантку или любой другой сервер в своем блоке server , но запуск его с gunicorn --paste production.ini на самом деле не будет использовать вообще официантка. Люди также часто просили указать альтернативный блок server , отличный от server:main . Сохранение поддержки этих функций, когда для этого существуют совершенно хорошие интерфейсы командной строки, такие как pserve , казалось, не имело смысла.

Интерфейс командной строки gunicorn может считывать определение приложения из файла INI, но для настройки сервера он использует собственный файл конфигурации. Используйте другой инструмент (например, pserve ) в качестве исполнителя сценария/процесса, если вы хотите использовать INI-файл для настройки сервера Gunicorn.

но мы должны использовать --config вместе с --paste, согласно моему 1-му комментарию.
В нашем проекте все управляется одним файлом конфигурации (.ini). Существует много логики обновления/автомасштабирования, которая просто настраивает файл .ini. Затем мы также используем --config, чтобы указать пользовательскую конфигурацию Python, которая устанавливает

• пользовательский формат регистратора (технически это невозможно указать с помощью файла .ini)
• управление рабочей памятью (код Python)

Gunicorn совместим с Paste, но таким образом функциональность ограничена, и это создало для нас проблему, от которой мы не можем избавиться, потому что у нас не может быть 2 файлов конфигурации, а также переход к конфигурации в другом файле требует больше работы, чем на самом деле разветвление Gunicorn и поддержание этого форка только для того, чтобы вернуть это поведение.

Я знаю причину этого билета, но раньше мы использовали gunicorn и официантку вместе, и я думаю, что запуск бинарного файла gunicorn достаточно явный, ИМХО. Кроме того, я думаю, вы даже можете определить, используют ли пользователи другое яйцо, и сделать это серьезной ошибкой.

Насколько я помню, мы не рассматривали такое использование. Мы, вероятно, можем вернуть
поддержка этого варианта использования звучит хорошо. Было бы нормально иметь
предупреждение журнала об этом?

Пт, 16 октября 2020 г., 08:28, Марчин Кузьмински, уведомления на адрес github.com
написал:

но мы должны использовать --config вместе с --paste, согласно моему 1-му
комментарий.
В нашем проекте все управляется одним конфигурационным файлом (.ini)
Существует много логики обновления/автомасштабирования, которая просто настраивает файл .ini.
Затем мы также используем --config, чтобы указать пользовательскую конфигурацию Python, которая устанавливает

• пользовательский формат регистратора (это технически невозможно
  указывается с помощью файла .ini)
• управление рабочей памятью

Gunicorn совместим с пастой, но в этом отношении его функциональность ограничена.
и это создало для нас проблему, от которой мы не можем избавиться.

Я знаю причину, но раньше мы использовали ганикорн и официантку вместе,
и я думаю, что запуск бинарного файла gunicorn достаточно явный, ИМХО.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/benoitc/gunicorn/issues/2169#issuecomment-709838842 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/AAADRIQR2CLVUOYK6FDY2ZDSK7RZFANCNFSM4JMI65YA
.

>

Отправлено с моего мобильного

Я действительно думал о другом решении, если это возможно. При использовании pserve с яйцом единорога также было бы неплохо, чтобы файл конфигурации был установлен внутри файла .ini.

например

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

Таким образом, он будет загружать gunicorn_conf.py точно так же, как это делает --config=/path/to/gunicorn_conf.py.

Таким образом, вышеизложенное будет работать для нас, и это также решает проблему этого билета. Не уверен, насколько легко и осуществимо это реализовать.

В противном случае, если бы вы могли добавить функциональность загрузки конфигурации из файла .ini при запуске бинарного файла gunicorn, это было бы здорово, это избавило бы нас от многих хлопот. Предупредить об этом не проблема

Я действительно думал о другом решении, если это возможно. При использовании pserve с яйцом единорога также было бы неплохо, чтобы файл конфигурации был установлен внутри файла .ini.

Это должно работать и задокументировано. Если это не так, пожалуйста, сообщите об ошибке!

Хорошо, мы это проверим. Но AFAIR были небольшие изменения в том, как работают бинарные файлы gunicorn vs pserve. Насколько я помню, gunicorn --paste имел доступ к пути к файлу .ini, а pserve с помощью gunicorn egg - нет. Мы проверим это и при необходимости создадим соответствующий тикет.