<p>gunicorn 20.0.0: --paste가 [server:main]에서 인수를 감지하지 못함</p>

죄송합니다. 변경 로그 항목에는 "Simplify Paste Deployment documentation"만 표시되며 여기에서 더 나은 뉴스 항목을 준비하는 데 도움이 되었을 것입니다.

이에 대한 PR은 다음과 같습니다. https://github.com/benoitc/gunicorn/pull/1957

이전에는 use = egg:gunicorn#main 가 더 이상 사용되지 않지만 더 이상 사용되지 않습니다. 변경 사항은 Paste Deploy 호환 환경에서 Gunicorn의 역할을 명확히 하기 위한 것입니다.

이 스타일의 .ini 파일과 함께 Gunicorn을 사용하는 두 가지 옵션이 있습니다.

첫 번째 옵션은 gunicorn CLI를 사용하는 것입니다. 이 작업을 수행할 때 Gunicorn의 자체 CLI 플래그 또는 Gunicorn의 자체 구성 모듈(기본값 gunicorn.conf.py )을 사용하여 서버 인수를 구성해야 합니다. Gunicorn 바인드의 소켓은 재로딩을 관리하고 PID 파일을 작성하는 등의 작업을 수행합니다. Gunicorn은 $ .ini 의 app 섹션을 사용하여 애플리케이션 호출 가능을 구성할 수 있습니다.

두 번째 옵션은 pserve 와 같은 스크립트 붙여넣기 실행기를 사용하는 것입니다. 이 경우 이 스크립트 러너는 다시 로드를 관리하고 PID 파일을 작성하는 등의 작업을 수행합니다. 대부분의 다른 옵션은 여전히 ​​작동하지만 .ini 파일의 server 블록을 사용하려면 붙여넣기와 호환되는 스크립트 실행기를 호출해야 합니다. Gunicorn은 더 이상 그런 스크립트 실행자가 아닙니다.

더 명확성을 추가할 수 있는지 알려주십시오.

귀하의 경우 이전과 같이 계속할 수 있어야 하지만 $ gunicorn #$ 대신 pserve 를 사용하여 애플리케이션을 시작하십시오. Gunicorn의 모든 서버 구성은 이미 완료한 것처럼 server 블록에 있을 수 있습니다.

이전 동작은 파일과 충돌할 수 있는 명령줄에 옵션을 지정할 수 있기 때문에 잠재적으로 혼란스러웠습니다. 또한 .ini 파일에 보간을 위한 구성 변수를 지정하는 기능을 추가하고 다른 server 블록(다른 app 블록 외에)을 지정하는 기능을 추가해 달라는 요청도 있었습니다. 결과적으로 이러한 모든 기능에 대한 지원을 추가하기보다 Gunicorn을 붙여넣기 _server_ 실행기로 사용하지 않기로 결정했습니다. 이제 Gunicorn CLI는 애플리케이션을 구성하기 위해 Paste Deploy .ini 파일 읽기를 지원하지만 server 블록을 사용하는 것은 해당 생태계의 전용 도구에 맡겨집니다.

귀하의 경우 이전과 같이 계속할 수 있어야 하지만 $ gunicorn #$ 대신 pserve 를 사용하여 애플리케이션을 시작하십시오.

@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 서버.

그러면 내 문제가 해결됩니다. 이 문제를 자유롭게 종료하세요 =)

감사 해요,
코리

마지막으로 메모를 한 다음 기억할 수 있는 모든 세부 사항을 추가한 것 같습니다. server 블록이 egg:gunicorn#main 이외의 것을 지정하더라도 gunicorn --paste production.ini 를 호출하면 Gunicorn을 서버로 사용한다는 것이 잠재적으로 혼란스러웠습니다 _!

Gunicorn은 주로 서버 및 프로세스 관리자이기 때문에 Gunicorn이 임의의 Paste 호환 서버를 호출하기 위한 일반 CLI가 되는 것은 이치에 맞지 않습니다. 대신 Gunicorn은 붙여넣기 배포 응용 프로그램을 지원하는 서버이며 붙여넣기 호환 서버입니다. 하지만 스크립트 붙여넣기 실행기 CLI는 _아닙니다_!

나는 이것을 위해 피라미드 요리책에 대한 문제를 열었습니다: https://github.com/Pylons/pyramid_cookbook/issues/222

나는 이것을 Gunicorn 자체에서 철저히 문서화했다고 생각했지만 처음에는 참조를 찾을 수 없었습니다. 여기에 있습니다: http://docs.gunicorn.org/en/stable/run.html#paste -deployment

@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

gunicorn 20.0.0 와 gunicorn 19.9.0 development.ini 가 변경되지 않았습니다.

흥미롭게도 다음 명령으로 서버를 시작하면 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

관련이 있는지 확실하지 않지만 pserve gunicorn 20.0.0 를 사용하여 서버를 시작할 때만 이 경고가 표시됩니다.

/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 Gunicorn CLI에서 Paste Deploy 서버 정의에 대한 지원 제거를 요청하고 싶습니다. 오늘 할 수 있습니다.

변경 로그를 소급하여 수정하여 더 명확하게 해도 괜찮습니까(20.0 릴리스의 주요 변경 섹션 작성)?

@CorreyL 재미있다! 이와 같이 명령줄에 지정된 옵션으로 gunicorn 를 확실히 실행할 수 있습니다. 나는 그것이 gunicorn 를 실행하는 가장 안전하고 선호되는 방법이라고 생각합니다. pserve 와의 통합은 편리하지만 여기서 문제가 발생한다는 사실을 알게 되어 기쁩니다. 나는 그것을 비추천하는 실수를 하지 않기를 바랍니다.

변경 로그를 소급하여 수정하여 더 명확하게 해도 괜찮습니까(20.0 릴리스의 주요 변경 섹션 작성)?

@tilgovi 네 확실히

@tilgovi 오늘 이 변경 사항을 추가할 수 있습니까? 20.0.1을 위해 그것을 가지고 있으면 좋을 것입니다 :)

c25563f에 한 줄 메모를 추가했습니다. 변경 사항이 발생한 이후 문서가 이미 업데이트되었습니다. 이 메모를 보는 모든 사람이 문서와 이러한 문제를 찾을 수 있기를 바랍니다. 😂

@tilgovi 감사합니다

이것에 의해 놀라울 정도로 영향을 받는 것에 대한 또 다른 확인을 추가하고 싶었습니다. 제 경우에는 그다지 중요하지 않았지만 업그레이드 이후에 gunicorn이 dev에서 자동 다시 로드를 중지한 이유와 기타 몇 가지 사소한 동작 변경 사항에 대해 혼란스러웠습니다. 나는 오늘 그것을 알아내려고 시간을 보냈고 내 --paste INI 파일의 설정이 더 이상 작동하지 않는다는 것을 깨달았습니다. 이 문제를 해결하는 데 도움이 되었습니다.

이것이 가능한지 모르겠지만, Paster 파일을 통해 여전히 서버 인수를 설정하려고 한다는 것을 감지하면 gunicorn이 경고를 출력하도록 할 수 있습니까?

혼란에 대해 사과드립니다, @Deimos. PR을 검토하겠지만 여기에 더 추가할 구체적인 계획은 없습니다.

실제로 --paste를 --config와 함께 사용하려는 경우는 어떻습니까? 우리의 경우(RhodeCode)는 gunicorn 구성에 있는 메모리 모니터링의 특수 논리에 대한 큰 요구 사항입니다.

@marcinkuzminski 이상적인 사용 사례입니다. --paste 와 --config 를 모두 지정하면 됩니다. 그러나 Gunicorn은 사용자가 gunicorn 구성 파일에서 서버를 구성할 것으로 예상하기 때문에 붙여넣기 ini 파일의 "서버" 섹션을 읽지 않습니다.

운이 없었어.

우리는 설치 프로그램에서 고객에게 gunicorn을 배송하고 있으며 모든 논리와 구성은 .ini 파일에 위임되었습니다. 이것은 인터넷을 통한 대부분의 예제가 피라미드 프로젝트를 지정하는 방법이기도 합니다.

이 변경은 이를 깨고, gunicorn이 이를 다시 가져오도록 포크한 다음, 논리를 변경하고 구성을 gunicorn_conf.py로 위임하는 것이 더 쉬울 것입니다.

--paste 옵션이 특수 접두어와 함께 읽혀지면 어떻습니까? 예를 들어 --paste로 gunicorn을 구성할 수 있지만 gunicorn. 접두사가 붙은 구성 옵션만 읽습니다.

예

gunicorn.workers = 2
gunicor.XXX = YYY

--config 를 사용할 필요가 없습니다. 붙여넣기 INI를 완전히 사용할 수 있습니다. 이를 위해 $#$ gunicorn pserve 대신 pserve 를 사용하십시오. 문서 참조: https://docs.gunicorn.org/en/stable/run.html#paste -deployment

변경된 사항은 서버를 실행할 수 있는 일반 붙여넣기 배포 CLI로 Gunicorn을 사용하는 것에 대한 지원을 제거하는 것뿐이었습니다. Gunicorn은 여전히 ​​_a_ 붙여넣기 호환 서버 자체입니다.

이 변경은 .ini 파일이 server 블록에서 웨이트리스 또는 다른 서버를 지정하지만 gunicorn --paste production.ini 와 함께 실행하면 실제로 사용하지 않는 잠재적인 혼란을 제거하기 위해 만들어졌습니다. 전혀 웨이트리스. 사람들은 또한 server:main 이외의 대체 server 블록을 지정하는 기능을 요청하기도 했습니다. pserve 와 같은 완벽하게 좋은 CLI가 있을 때 이러한 기능에 대한 지원을 유지하는 것은 이치에 맞지 않는 것 같았습니다.

gunicorn CLI는 INI 파일에서 애플리케이션 정의를 읽을 수 있지만 서버를 구성하기 위해 자체 구성 파일을 사용합니다. INI 파일을 사용하여 Gunicorn 서버를 구성하려면 다른 도구(예 pserve )를 스크립트/프로세스 실행기로 사용하십시오.

그러나 첫 번째 주석에 따라 --paste와 함께 --config를 사용해야 합니다.
우리 프로젝트에서 모든 것은 단일 구성 파일(.ini)에 의해 관리됩니다. .ini 파일을 조정하는 많은 업그레이드/자동 크기 조정 논리가 있습니다. 그런 다음 --config를 사용하여 다음을 설정하는 사용자 지정 Python 구성을 지정합니다.

• 사용자 지정 로거 형식(기술적으로 .ini 파일을 사용하여 지정할 수 없음)
• 작업자 메모리 관리(Python 코드)

Gunicorn은 붙여넣기와 호환되지만 이러한 방식으로 기능이 제한되고 2개의 구성 파일을 가질 수 없기 때문에 복구할 수 없는 문제가 발생했습니다. 또한 다른 파일의 구성으로 이동하는 것은 실제로 포크하는 것보다 더 많은 작업이 필요합니다. Gunicorn과 그 행동을 되돌리기 위해 포크를 유지하는 것입니다.

나는 이 티켓에 대한 근거를 알고 있지만 우리는 gunicorn과 웨이트리스를 함께 사용했고 gunicorn 바이너리를 실행하는 것이 충분히 명시적이라고 생각합니다. IMHO. 또한 사용자가 다른 계란을 사용하여 하드 오류로 만드는지 감지할 수도 있다고 생각합니다.

내 기억에 우리는 그런 사용법을 고려하지 않았습니다. 우리는 아마 다시 가져올 수 있습니다
유스케이스에 대한 지원은 좋은 것 같습니다. 가지고 있어도 괜찮을까요
그것에 대한 경고를 기록합니까?

2020년 10월 16일 금요일 08:28 Marcin Kuźmiński [email protected]
썼다:

그러나 우리 는 내 첫 번째에 따라 --paste와 함께 --config를 사용해야합니다.
논평.
우리 프로젝트에서 모든 것은 단일 구성 파일(.ini)로 관리됩니다.
.ini 파일을 조정하는 많은 업그레이드/자동 크기 조정 논리가 있습니다.
그런 다음 --config를 사용하여 다음을 설정하는 사용자 지정 Python 구성을 지정합니다.

• 사용자 정의 로거 형식(기술적으로
  .ini 파일을 사용하여 지정됨)
• 작업자 메모리 관리

Gunicorn은 붙여넣기 호환이 가능하지만 이러한 방식으로 기능이 제한되고,
그리고 그것은 우리가 복구할 수 없는 문제를 야기했습니다.

이유는 알지만 우리는 총구와 웨이트리스를 함께 사용하곤 했습니다.
그리고 나는 gunicorn 바이너리를 실행하는 것이 충분히 명시적이라고 생각합니다. IMHO.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 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

따라서 --config=/path/to/gunicorn_conf.py가 수행하는 것처럼 gunicorn_conf.py를 로드합니다.

따라서 위의 방법은 우리에게 효과적이며 이 티켓의 문제도 해결하고 있습니다. 구현하는 것이 얼마나 쉽고 실현 가능한지 확실하지 않습니다.

그렇지 않으면 gunicorn 바이너리를 실행할 때 .ini 파일에서 구성을 로드하는 기능을 가져올 수 있다면 굉장할 것입니다. 그러면 많은 번거로움이 줄어들 것입니다. 그것에 대해 경고를 받는 것은 문제가 되지 않습니다

실제로 가능하면 다른 솔루션을 생각했습니다. 유니콘 에그와 함께 pserve를 사용할 때 구성 파일이 .ini 파일 안에 설정되는 것도 좋을 것입니다.

작동해야 하며 문서화되어 있습니다. 그렇지 않은 경우 버그를 신고하십시오!

알겠습니다. 확인해 보겠습니다. 그러나 AFAIR에서는 gunicorn과 pserve 바이너리가 작동하는 방식에 약간의 변경이 있었습니다. 내가 기억한다면 gunicorn --paste는 .ini 파일 경로에 액세스할 수 있지만 gunicorn egg를 사용하는 pserve는 액세스할 수 없습니다. 이를 확인하고 필요한 경우 관련 티켓을 열겠습니다.