<p>gunicorn 20.0.0: --paste tidak mendeteksi argumen di bawah [server:main]</p>

Permintaan maaf saya. Entri changelog hanya mengatakan "Sederhanakan dokumentasi Penerapan Tempel", dan saya seharusnya membantu menyiapkan entri berita yang lebih baik di sini.

PR untuk ini ada di sini: https://github.com/benoitc/gunicorn/pull/1957

Sebelumnya, kami telah menghentikan use = egg:gunicorn#main tetapi itu tidak lagi digunakan. Perubahan ini dimaksudkan untuk memperjelas peran Gunicorn dalam lingkungan yang kompatibel dengan Tempel Deploy.

Ada dua opsi untuk menggunakan Gunicorn dengan gaya file .ini ini.

Opsi pertama adalah menggunakan gunicorn CLI. Ketika Anda melakukan ini, Anda harus menggunakan flag CLI Gunicorn sendiri atau modul konfigurasi Gunicorn sendiri (default gunicorn.conf.py ) untuk mengonfigurasi argumen server. Gunicorn mengikat soket, mengelola pemuatan ulang, menulis file PID, dan sebagainya. Gunicorn dapat menggunakan bagian app di .ini Anda untuk mengonfigurasi aplikasi yang dapat dipanggil.

Opsi kedua adalah menggunakan runner Tempel Skrip seperti pserve . Dalam hal ini, pelari skrip ini mengelola pemuatan ulang, menulis file PID, dan sebagainya. Sebagian besar opsi lain seharusnya masih berfungsi, tetapi untuk menggunakan blok server .ini file .ini Anda, Anda perlu menjalankan skrip runner yang kompatibel dengan Tempel. Gunicorn tidak lagi menjadi script runner.

Beri tahu saya jika saya dapat menambahkan lebih banyak kejelasan.

Dalam kasus Anda, Anda seharusnya dapat melanjutkan seperti sebelumnya, tetapi gunakan pserve daripada gunicorn untuk memulai aplikasi Anda. Semua konfigurasi server untuk Gunicorn kemudian dapat berada di blok server Anda, seperti yang tampaknya sudah Anda lakukan.

Perilaku sebelumnya berpotensi membingungkan karena memungkinkan menentukan opsi pada baris perintah yang akan bertentangan dengan file. Kami juga memiliki permintaan untuk menambahkan kemampuan untuk menentukan vars konfigurasi untuk interpolasi dalam file .ini dan menentukan blok server yang berbeda (selain blok app yang berbeda). Akibatnya, keputusan dibuat untuk menghentikan penggunaan Gunicorn sebagai _server_ runner Tempel daripada mencoba menambahkan dukungan untuk semua fitur ini. Gunicorn CLI sekarang mendukung membaca file .ini Tempel Deploy untuk membuat aplikasi, tetapi menggunakan blok server diserahkan kepada perkakas khusus di ekosistem itu.

Dalam kasus Anda, Anda seharusnya dapat melanjutkan seperti sebelumnya, tetapi gunakan pserve daripada gunicorn untuk memulai aplikasi Anda.

Terima kasih atas respon cepatnya @tilgovi!

Mengikuti rekomendasi Anda:

$ 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

Yang bagus, karena bagian dari PR internal yang saya buka melibatkan harus mengubah perintah pserve menjadi gunicorn , yang saya agak waspadai karena saya bukan pengembang asli kami server API internal.

Itu menyelesaikan masalah saya, jangan ragu untuk menutup masalah ini =)

Terima kasih,
Correy

Satu catatan terakhir, dan kemudian saya pikir saya telah menambahkan semua detail yang dapat saya ingat. Itu berpotensi membingungkan bahwa memanggil gunicorn --paste production.ini akan menggunakan Gunicorn sebagai server _bahkan jika blok server menentukan sesuatu selain egg:gunicorn#main _!

Karena Gunicorn pada dasarnya adalah server dan manajer proses, tidak masuk akal bagi Gunicorn untuk menjadi CLI umum untuk menjalankan server yang kompatibel dengan Tempel sewenang-wenang. Sebaliknya, Gunicorn adalah server yang mendukung aplikasi Tempel Deploy dan merupakan server yang kompatibel dengan Tempel. Ini adalah _not_ CLI pelari Skrip Tempel!

Saya membuka masalah pada buku masak Piramida untuk ini: https://github.com/Pylons/pyramid_cookbook/issues/222

Saya pikir saya telah mendokumentasikan ini secara menyeluruh di Gunicorn sendiri, tetapi saya tidak dapat menemukan referensi pada awalnya. Ada di sini: http://docs.gunicorn.org/en/stable/run.html#paste -deployment

@tilgovi hanya sebagai peringatan, ini juga merupakan perubahan besar bagi tim saya. Mungkin layak untuk pindah ke bagian perubahan yang melanggar dari changelog?

Saya akan membuka kembali masalah dan menetapkan sendiri. Saya akan menutupnya ketika saya memperbarui changelog agar lebih mudah dibaca di sini.

Sekali lagi, saya minta maaf karena tidak menyebutkannya lebih jelas di changelog awalnya.

@tilgovi benjolan

Tolong beri tahu saya jika ini harus dibuka sebagai masalah terpisah.

Ini mungkin masalah yang terisolasi dengan basis kode kami, tetapi setelah sedikit pengujian lebih lanjut, tim saya telah memperhatikan bahwa untuk server API kami, gunicorn 20.0.0 merusak fungsi pyramid_ldap3.get_ldap_connector .

gunicorn 20.0.0 :

Pada mulanya:

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

Setelah Mencoba Mengautentikasi:

[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

Pada mulanya:

$ 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

Setelah Mencoba Mengautentikasi:

[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

Tidak ada perubahan yang dilakukan pada development.ini antara gunicorn 20.0.0 dan gunicorn 19.9.0 .

Menariknya, kita dapat menghentikan kesalahan dengan gunicorn 20.0.0 jika kita memulai server dengan perintah berikut:

$ 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

Saya tidak yakin apakah ini terkait sama sekali, tetapi memulai server menggunakan gunicorn 20.0.0 dengan pserve adalah satu-satunya saat kami melihat peringatan ini:

/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 apa yang akan Anda ubah di changelog?

@benoitc Saya ingin meminta penghapusan dukungan untuk definisi server Tempel Deploy di Gunicorn CLI. Saya bisa melakukan ini hari ini.

Apakah boleh jika saya memodifikasi changelog secara retroaktif untuk membuatnya lebih jelas (buat bagian pemutusan perubahan di rilis 20.0)?

@CorreyL menarik! Anda pasti dapat menjalankan gunicorn dengan opsi yang ditentukan pada baris perintah seperti itu. Saya pikir itu adalah cara yang disukai dan paling aman untuk menjalankan gunicorn . Integrasi dengan pserve adalah kemudahan, tetapi senang mengetahui hal itu menyebabkan masalah di sini. Saya harap saya tidak membuat kesalahan untuk membatalkannya.

Apakah boleh jika saya memodifikasi changelog secara retroaktif untuk membuatnya lebih jelas (buat bagian pemutusan perubahan di rilis 20.0)?

@tilgovi ya pasti

@tilgovi dapatkah Anda menambahkan perubahan ini hari ini? Akan keren untuk memilikinya untuk 20.0.1 :)

Menambahkan catatan satu baris ke c25563f. Dokumentasi telah diperbarui sejak perubahan terjadi. Mudah-mudahan, siapa pun yang melihat catatan itu dapat menemukan dokumentasi dan masalah ini. 😅.

@tilgovi terima kasih

Hanya ingin menambahkan konfirmasi lain karena terpengaruh secara mengejutkan oleh ini. Itu tidak terlalu signifikan dalam kasus saya, tetapi saya bingung mengapa gunicorn berhenti memuat ulang secara otomatis di dev sejak memutakhirkan serta beberapa perubahan perilaku kecil lainnya. Saya menghabiskan beberapa waktu untuk mencoba mencari tahu hari ini dan menyadari bahwa pengaturan di file --paste INI saya tidak lagi berfungsi, yang membantu saya menemukan cara untuk mengatasi masalah ini.

Saya tidak tahu apakah ini layak, tetapi apakah mungkin untuk membuat gunicorn mengeluarkan peringatan jika mendeteksi bahwa Anda masih mencoba mengatur argumen server melalui file Paster?

Mohon maaf atas gangguannya, @Deimos. Saya akan meninjau PR, tetapi saya tidak punya rencana khusus untuk menambahkan lebih banyak di sini.

Bagaimana dengan kasus ketika Anda benar-benar ingin menggunakan --paste bersama dengan --config? Yang dalam kasus kami (RhodeCode) merupakan persyaratan besar untuk logika khusus pemantauan memori yang kami dapatkan di konfigurasi gunicorn.

@marcinkuzminski itulah kasus penggunaan yang ideal. Cukup tentukan --paste dan --config . Namun, Gunicorn tidak akan membaca bagian "server" dari file paste ini karena harapannya adalah Anda akan mengkonfigurasi server di file konfigurasi gunicorn.

Itu sangat disayangkan.

Kami mengirimkan gunicorn ke pelanggan dalam penginstal, dan semua logika dan konfigurasi telah didelegasikan ke file .ini. Ini adalah bagaimana sebagian besar contoh melalui internet menentukan untuk proyek Piramida.

Perubahan ini mematahkan itu, dan mungkin lebih mudah bagi kita untuk memotong gunicorn untuk mengembalikannya, lalu mengubah logika dan mendelegasikan konfigurasi ke gunicorn_conf.py :(

Bagaimana jika opsi --paste akan dibaca, dengan awalan khusus. misalnya Anda dapat mengonfigurasi gunicorn dengan --paste tetapi hanya akan membaca opsi konfigurasi yang akan diawali dengan gunicorn.

misalnya

gunicorn.workers = 2
gunicor.XXX = YYY

Anda tidak perlu menggunakan --config . Anda dapat menggunakan tempel INI seluruhnya. Untuk itu gunakan pserve alih-alih gunicorn . Lihat dokumentasi: https://docs.gunicorn.org/en/stable/run.html#paste -deployment

Perubahan yang dilakukan hanya untuk menghapus dukungan penggunaan Gunicorn sebagai CLI Penempatan Tempel umum yang dapat menjalankan server. Gunicorn masih _adalah a_ Tempel server yang kompatibel itu sendiri.

Perubahan ini dibuat untuk menghilangkan potensi kebingungan di mana file .ini akan menentukan pelayan, atau server lain, di blok server , tetapi menjalankannya dengan gunicorn --paste production.ini tidak akan benar-benar menggunakan pelayan sama sekali. Orang juga sering meminta kemampuan untuk menentukan blok server alternatif selain server:main . Mempertahankan dukungan untuk fitur-fitur ini ketika CLI yang sangat bagus seperti pserve ada untuk ini tampaknya tidak masuk akal.

CLI gunicorn dapat membaca definisi aplikasi dari file INI, tetapi menggunakan file konfigurasinya sendiri untuk mengonfigurasi server. Gunakan alat lain (seperti pserve ) sebagai skrip / runner proses jika Anda ingin menggunakan file INI untuk mengkonfigurasi server Gunicorn.

tetapi kita harus menggunakan --config bersama dengan --paste, sesuai komentar pertama saya.
Dalam proyek kami semuanya dikelola oleh file konfigurasi tunggal (.ini) Ada banyak logika upgrade/autoscale yang hanya menyesuaikan file .ini. Kemudian kami juga menggunakan --config untuk menentukan konfigurasi python khusus yang disetel

• format logger kustom (secara teknis ini tidak mungkin ditentukan menggunakan file .ini)
• manajemen memori pekerja (kode Python)

Gunicorn kompatibel dengan Tempel, tetapi fungsinya terbatas dengan cara ini, dan itu menciptakan masalah bagi kami yang tidak dapat kami pulihkan karena kami tidak dapat memiliki 2 file konfigurasi, dan juga pindah ke konfigurasi pada file lain lebih berfungsi daripada sebenarnya forking Gunicorn dan mempertahankan garpu itu hanya untuk mengembalikan perilaku itu.

Saya tahu alasan untuk tiket ini, tetapi kami dulu menggunakan gunicorn dan pelayan bersama, dan saya pikir menjalankan biner gunicorn cukup eksplisit, IMHO. Selain itu, saya pikir Anda bahkan dapat mendeteksi jika pengguna menggunakan telur yang berbeda dan membuatnya menjadi kesalahan yang sulit.

Kami tidak mempertimbangkan penggunaan seperti itu jika saya ingat. Kita mungkin bisa membawa kembali
dukungannya karena usecase terdengar bagus. Apakah boleh memiliki
log peringatan untuk itu?

Pada Jum 16 Okt 2020 pukul 08:28 Marcin Kuźmiński [email protected]
menulis:

tapi kita harus menggunakan --config bersama dengan --paste, sesuai langkah pertama saya
komentar.
Dalam proyek kami semuanya dikelola oleh file konfigurasi tunggal (.ini)
Ada banyak logika pemutakhiran/penskalaan otomatis yang hanya menyesuaikan file .ini.
Kemudian kami juga menggunakan --config untuk menentukan konfigurasi python khusus yang disetel

• format logger khusus (secara teknis ini tidak mungkin
  ditentukan menggunakan file .ini)
• manajemen memori pekerja

Gunicorn kompatibel dengan pasta, tetapi fungsinya terbatas dengan cara ini,
dan itu menciptakan masalah bagi kami yang tidak dapat kami pulihkan.

Aku tahu alasannya, tapi kami dulu menggunakan gunicorn dan pelayan bersama,
dan saya pikir menjalankan biner gunicorn cukup eksplisit, IMHO.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/benoitc/gunicorn/issues/2169#issuecomment-709838842 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAADRIQR2CLVUOYK6FDY2ZDSK7RZFANCNFSM4JMI65YA
.

>

Dikirim dari Ponsel saya

Saya sebenarnya memikirkan solusi lain jika memungkinkan. Saat menggunakan pserve dengan telur unicorn, akan lebih baik jika file konfigurasi diatur di dalam file .ini.

misalnya

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

Jadi itu akan memuat gunicorn_conf.py persis seperti yang dilakukan --config=/path/to/gunicorn_conf.py

Jadi hal di atas akan berhasil untuk kita, dan itu juga memecahkan masalah tiket ini. Tidak yakin seberapa mudah dan layak untuk diterapkan.

Jika tidak, Jika Anda dapat membawa fungsionalitas memuat konfigurasi dari file .ini saat menjalankan biner gunicorn, itu akan luar biasa, itu akan menghemat banyak kerumitan. Memiliki peringatan tentang itu tidak masalah

Saya sebenarnya memikirkan solusi lain jika memungkinkan. Saat menggunakan pserve dengan telur unicorn, akan lebih baik jika file konfigurasi diatur di dalam file .ini.

Itu harus bekerja dan didokumentasikan. Jika tidak, silakan ajukan bug!

Oke, kami akan memeriksa ini. Tetapi AFAIR ada sedikit perubahan dalam cara kerja binari gunicorn vs pserve. Jika saya ingat, gunicorn --paste memiliki akses ke jalur file .ini, sedangkan pserve menggunakan telur gunicorn tidak. Kami akan memeriksa ini dan membuka tiket yang relevan jika diperlukan.