<p>gunicorn 20.0.0：--[server：main]の下の引数を検出しない貼り付け</p>

謝罪いたします。 変更ログのエントリには「SimplifyPasteDeploymentのドキュメント」としか書かれていないので、ここでより良いニュースエントリを準備するのを手伝うべきでした。

このためのPRはここにあります： https ：//github.com/benoitc/gunicorn/pull/1957

以前はuse = egg:gunicorn#mainを非推奨にしましたが、現在は非推奨ではありません。 この変更は、PasteDeploy互換環境でのGunicornの役割を明確にすることを目的としています。

このスタイルの.iniファイルでGunicornを使用するには2つのオプションがあります。

最初のオプションは、 gunicorn CLIを使用することです。 これを行うときは、Gunicorn独自のCLIフラグまたはGunicorn独自の構成モジュール（デフォルトgunicorn.conf.py ）を使用してサーバー引数を構成する必要があります。 Gunicorn bindはソケットをバインドし、リロードを管理し、PIDファイルを書き込みます。 Gunicornは、 .iniのappセクションを使用して、呼び出し可能なアプリケーションを構成できます。

2番目のオプションは、 pserveなどの貼り付けスクリプトランナーを使用することです。 この場合、このスクリプトランナーは、リロードの管理、PIDファイルの書き込みなどを行います。 他のほとんどのオプションは引き続き機能しますが、 .iniファイルのserverブロックを使用するには、貼り付けと互換性のあるスクリプトランナーを呼び出す必要があります。 Gunicornはもはやそのようなスクリプトランナーではありません。

もっと明確にすることができるかどうか教えてください。

あなたの場合、以前と同じように続行できるはずですが、 gunicornよりも$ pserveを使用してアプリケーションを開始します。 Gunicornのすべてのサーバー構成は、すでに行っているように、 serverブロックに含めることができます。

以前の動作では、ファイルと競合するオプションをコマンドラインで指定できるため、混乱を招く可能性がありました。 また、 .iniファイルで補間用の構成変数を指定する機能を追加し、（異なるappブロックに加えて）異なる$ serverブロックを指定する機能を追加するように要求されました。 その結果、これらすべての機能のサポートを追加しようとするのではなく、GunicornをPaste_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サーバー。

これで問題は解決しました。この問題を自由に閉じてください=）

ありがとう、
コリー

最後にもう1つ、思い出せる詳細をすべて追加したと思います。 serverブロックがegg:gunicorn#main以外のものを指定した場合でも、$ gunicorn --paste production.iniを呼び出すと、サーバーとしてGunicornが使用される可能性があります。

Gunicornは主にサーバーおよびプロセスマネージャーであるため、Gunicornが任意のPaste互換サーバーを呼び出すための一般的なCLIであることは意味がありません。 代わりに、GunicornはPaste Deployアプリケーションをサポートするサーバーであり、Paste互換のサーバーです。 ただし、これは貼り付けスクリプトランナーCLIではありません。

このために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

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

関連するかどうかはわかりませんが、 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変更ログで何を変更しますか？

@benoitcGunicornCLIでのPasteDeployサーバー定義のサポートの削除を呼びかけたいと思います。 私は今日これを行うことができます。

変更ログを遡及的に変更してより明確にする（20.0リリースの重大な変更セクションを作成する）場合でも問題ありませんか？

@CorreyLおもしろい！ そのようなコマンドラインで指定されたオプションを使用して、 gunicornを確実に実行できます。 gunicornを実行するには、これが最も安全で好ましい方法だと思います。 pserveとの統合は便利ですが、ここで問題が発生することを知っておくと便利です。 非推奨にするのを間違えなかったといいのですが。

変更ログを遡及的に変更してより明確にする（20.0リリースの重大な変更セクションを作成する）場合でも問題ありませんか？

@tilgoviはい間違いなく

@tilgovi今日、この変更を追加できますか？ 20.0.1のためにそれを持っているのはクールだろう:)

c25563fに1行のメモを追加しました。 変更が発生してから、ドキュメントはすでに更新されています。 うまくいけば、そのメモを見た人は誰でもドキュメントとこれらの問題を見つけることができます。 😅

@tilgoviありがとう

これによって驚くほど影響を受けるという別の確認を追加したかっただけです。 私の場合はそれほど重要ではありませんでしたが、アップグレード後にgunicornが開発で自動リロードを停止した理由やその他のマイナーな動作の変更について混乱しました。 私は今日それを理解しようとしばらく時間を費やし、 --paste INIファイルの設定が機能しなくなったことに気づきました。これは、この問題への道を見つけるのに役立ちました。

これが実行可能かどうかはわかりませんが、Pasterファイルを介してサーバー引数を設定しようとしていることを検出した場合にgunicornに警告を出力させることは可能でしょうか？

混乱をお詫びします、@Deimos。 PRを確認しますが、ここに追加する具体的な計画はありません。

実際に--pasteを--configと一緒に使用したい場合はどうでしょうか。 私たちの場合（RhodeCode）は、gunicorn構成にあるメモリ監視の特別なロジックの大きな要件です。

@marcinkuzminskiは理想的なユースケースです。 --pasteと--configの両方を指定するだけです。 ただし、gunicorn構成ファイルでサーバーを構成することが期待されるため、Gunicornは貼り付けiniファイルの「サーバー」セクションを読み取りません。

それは残念です。

gunicornをインストーラーでお客様に出荷しており、すべてのロジックと構成は.iniファイルに委任されています。 これは、インターネット上のほとんどの例がPyramidプロジェクトに指定する方法でもあります。

この変更はそれを壊し、gunicornをフォークして元に戻し、ロジックを変更して構成をgunicorn_conf.pyに委任する方がおそらく簡単です:(

--pasteオプションが特別なプレフィックスで読み取られる場合はどうでしょうか。 たとえば、-pasteを使用してgunicornを設定できますが、プレフィックスがgunicorn.の設定オプションのみが読み取られます。

例えば

gunicorn.workers = 2
gunicor.XXX = YYY

--configを使用する必要はありません。 ペーストINIを完全に使用できます。 そのためには、 gunicorn pserveを使用します。 ドキュメントを参照してください： https ：//docs.gunicorn.org/en/stable/run.html#paste -deployment

加えられた変更は、サーバーを実行できる一般的なPasteDeploymentCLIとしてGunicornを使用するためのサポートを削除することだけでした。 Gunicornは、互換性のあるサーバー自体を貼り付けます。

この変更は、 .iniファイルがserverブロックでウェイトレスまたはその他のサーバーを指定する潜在的な混乱を取り除くために行われましたが、 gunicorn --paste production.iniで実行すると実際には使用されませんまったくウェイトレス。 また、 server:main以外の代替serverブロックを指定する機能を要求することもよくあります。 pserveのような完全に優れたCLIが存在する場合にこれらの機能のサポートを維持することは、意味がないように思われました。

gunicorn CLIは、INIファイルからアプリケーション定義を読み取ることができますが、サーバーの構成には独自の構成ファイルを使用します。 INIファイルを使用してGunicornサーバーを構成する場合は、スクリプト/プロセスランナーとして別のツール（ pserveなど）を使用します。

しかし、私の最初のコメントのように、-configを--pasteと一緒に使用する必要があります。
私たちのプロジェクトでは、すべてが単一の構成ファイル（.ini）によって管理されています。.iniファイルを調整するだけのアップグレード/オートスケールロジックがたくさんあります。 次に、-configも使用して、設定するカスタムpython構成を指定します

• カスタムロガー形式（これは技術的には.iniファイルを使用して指定することはできません）
• ワーカーメモリ管理（Pythonコード）

GunicornはPasteと互換性がありますが、このように機能が制限されており、2つの構成ファイルを使用できないために回復できないという問題が発生しました。また、別のファイルの構成に移動することは、実際にフォークするよりも手間がかかります。 Gunicornとそのフォークを維持して、その動作を元に戻します。

このチケットの論理的根拠は知っていますが、以前はgunicornとウェイトレスを一緒に使用していました。gunicornbinaryを実行することは十分に明白だと思います、IMHO。 さらに、ユーザーが別の卵を使用しているかどうかを検出して、それをハードエラーにすることもできると思います。

私が覚えているなら、私たちはそのような使用法を考慮しませんでした。 おそらく持ち帰ることができます
ユースケースとしてのサポートは良さそうです。 持っていても大丈夫でしょうか
警告をログに記録しますか？

2020年10月16日金曜日08: 28MarcinKuźmiń[email protected]
書きました：

しかし、私の最初のように、-configを--pasteと一緒に使用する必要があります
コメント。
私たちのプロジェクトでは、すべてが単一の構成ファイル（.ini）によって管理されています
.iniファイルを調整するだけのアップグレード/オートスケールロジックがたくさんあります。
次に、-configも使用して、設定するカスタムpython構成を指定します

• カスタムロガー形式（これは技術的には不可能です
  .iniファイルを使用して指定）
• ワーカーメモリ管理

Gunicornは貼り付け互換ですが、このように機能が制限されています。
そしてそれは私たちが回復できない問題を引き起こしました。

理論的根拠は知っていますが、以前は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

したがって、-config = / path / to/gunicorn_conf.pyとまったく同じようにgunicorn_conf.pyが読み込まれます。

したがって、上記は私たちにとってうまくいくでしょう、そしてそれはこのチケットの問題も解決しています。 それを実装するのがどれほど簡単で実行可能かわからない。

そうでなければ、gunicornバイナリを実行しているときに.iniファイルから構成をロードする機能をもたらすことができれば、それは素晴らしいことであり、それは私たちに多くの手間を省くでしょう。 警告があっても問題ありません

可能であれば、実際に別の解決策を考えました。 ユニコーンエッグでpserveを使用する場合は、構成ファイルが.iniファイル内に設定されると便利です。

それは機能するはずであり、文書化されています。 そうでない場合は、バグを報告してください。

わかりました、これを確認します。 しかし、AFAIRでは、gunicornとpserveのバイナリの動作にわずかな変更がありました。 思い出してください。gunicorn--pasteは.iniファイルパスにアクセスできましたが、gunicorneggを使用したpserveはアクセスできませんでした。 これを確認し、必要に応じて関連するチケットを開きます。