<p>gunicorn 20.0.0: --paste não detectando argumentos em [server:main]</p>

Me desculpe. A entrada do changelog diz apenas "Simplify Paste Deployment documentation", e eu deveria ter ajudado a preparar uma entrada de notícias melhor aqui.

O PR para isso está aqui: https://github.com/benoitc/gunicorn/pull/1957

Anteriormente, tínhamos obsoleto use = egg:gunicorn#main mas isso não está mais obsoleto. A mudança visa esclarecer o papel do Gunicorn em um ambiente compatível com o Paste Deploy.

Existem duas opções para usar o Gunicorn com este estilo de arquivo .ini .

A primeira opção é usar a CLI gunicorn . Ao fazer isso, você deve usar os próprios sinalizadores CLI do Gunicorn ou o próprio módulo de configuração do Gunicorn (padrão gunicorn.conf.py ) para configurar os argumentos do servidor. Gunicorn bind é o soquete, gerencia o recarregamento, grava arquivos PID e assim por diante. Gunicorn pode usar uma seção app em seu .ini para configurar o aplicativo que pode ser chamado.

A segunda opção é usar um executor Paste Script como pserve . Nesse caso, esse executor de script gerencia o recarregamento, grava arquivos PID e assim por diante. A maioria das outras opções ainda deve funcionar, mas para usar o bloco server do seu arquivo .ini você precisa invocar um executor de script compatível com Paste. Gunicorn não é mais um executor de scripts.

Deixe-me saber se eu posso adicionar mais clareza.

No seu caso, você poderá continuar como antes, mas use pserve em vez de gunicorn para iniciar sua inscrição. Toda a configuração do servidor para Gunicorn pode estar no seu bloco server , como você já deve ter feito.

O comportamento anterior era potencialmente confuso porque permitia especificar opções na linha de comando que entrariam em conflito com o arquivo. Também tivemos solicitações para adicionar a capacidade de especificar vars de configuração para interpolação no arquivo .ini e especificar diferentes blocos server (além de diferentes blocos app ). Como resultado, foi tomada a decisão de descontinuar o uso do Gunicorn como um executor Paste _server_ em vez de tentar adicionar suporte para todos esses recursos. A CLI do Gunicorn agora suporta a leitura de um arquivo Paste Deploy .ini para construir um aplicativo, mas o uso de blocos server é deixado para ferramentas dedicadas nesse ecossistema.

No seu caso, você poderá continuar como antes, mas use pserve em vez de gunicorn para iniciar sua inscrição.

Obrigado pela resposta rápida @tilgovi!

Seguindo sua recomendação:

$ 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

O que é ótimo, já que parte do PR interno que abri envolvia ter que mudar o comando pserve para gunicorn , que eu estava um pouco cauteloso, pois não sou o desenvolvedor original do nosso servidor de API interno.

Isso resolve meus problemas, sinta-se à vontade para fechar este problema =)

Obrigado,
Correy

Uma nota final, e então acho que acrescentei todos os detalhes de que me lembro. Era potencialmente confuso que invocar gunicorn --paste production.ini usaria Gunicorn como servidor _mesmo que o bloco server especificasse algo diferente de egg:gunicorn#main _!

Como o Gunicorn é principalmente um servidor e gerenciador de processos, não faz sentido que o Gunicorn seja uma CLI geral para invocar servidores compatíveis com Paste arbitrários. Em vez disso, Gunicorn é um servidor que suporta aplicativos Paste Deploy e é um servidor compatível com Paste. No entanto, _não_ é uma CLI do Paste Script Runner!

Eu abri um problema no livro de receitas da Pyramid para isso: https://github.com/Pylons/pyramid_cookbook/issues/222

Eu pensei que tinha documentado isso completamente no próprio Gunicorn, mas não consegui encontrar a referência no início. Está aqui: http://docs.gunicorn.org/en/stable/run.html#paste -deployment

@tilgovi apenas um aviso, esta foi uma mudança decisiva para minha equipe também. Talvez valha a pena passar para a parte de mudança de quebra do changelog?

Vou reabrir o problema e auto-atribuir. Vou fechá-lo quando atualizar o changelog para ficar mais legível aqui.

Mais uma vez, minhas desculpas por não falar mais claramente no changelog inicialmente.

@tilgovi colisão

Por favor, deixe-me saber se isso deve ser aberto como um problema separado.

Isso pode ser um problema isolado com nossa base de código, mas depois de um pouco mais de testes, minha equipe notou que, para nosso servidor de API, gunicorn 20.0.0 quebra a função pyramid_ldap3.get_ldap_connector .

gunicorn 20.0.0 :

No arranque:

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

Após tentar autenticar:

[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

No arranque:

$ 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

Após tentar autenticar:

[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

Nenhuma alteração foi feita em development.ini entre gunicorn 20.0.0 e gunicorn 19.9.0 .

Curiosamente, podemos parar o erro com gunicorn 20.0.0 se iniciarmos o servidor com o seguinte comando:

$ 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

Não tenho certeza se está relacionado, mas iniciar o servidor usando gunicorn 20.0.0 com pserve é a única vez que vemos este aviso:

/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 o que você mudaria no changelog?

@benoitc Gostaria de chamar a atenção para a remoção do suporte para definições de servidor Paste Deploy na CLI do Gunicorn. Eu posso fazer isso hoje.

Tudo bem se eu modificar o log de alterações retroativamente para torná-lo mais claro (faça a seção de alterações na versão 20.0)?

@CorreyL interessante! Você pode definitivamente executar gunicorn com as opções especificadas na linha de comando assim. Eu acho que essa é a maneira preferida e mais segura de executar gunicorn . A integração com pserve é uma conveniência, mas é bom saber que causa problemas aqui. Espero não ter cometido um erro ao desconsiderar.

Tudo bem se eu modificar o log de alterações retroativamente para torná-lo mais claro (faça a seção de alterações na versão 20.0)?

@tilgovi sim com certeza

@tilgovi você pode adicionar essa mudança hoje? Seria legal tê-lo para 20.0.1 :)

Adicionada uma nota de uma linha a c25563f. A documentação já foi atualizada desde que a mudança aconteceu. Espero que qualquer pessoa que veja essa nota possa encontrar a documentação e esses problemas. 😅

@tilgovi obrigado

Só queria adicionar outra confirmação de ser surpreendentemente impactado por isso. Não foi muito significativo no meu caso, mas fiquei confuso sobre por que o gunicorn parou de recarregar automaticamente no dev desde a atualização, bem como algumas outras pequenas mudanças de comportamento. Passei algum tempo tentando descobrir isso hoje e percebi que as configurações em meus arquivos INI --paste não estavam mais funcionando, o que me ajudou a encontrar o caminho para esse problema.

Não tenho ideia se isso é viável, mas seria possível fazer com que o gunicorn produzisse um aviso se detectar que você ainda está tentando definir argumentos do servidor por meio do arquivo Paster?

Minhas desculpas pela interrupção, @Deimos. Gostaria de rever PRs, mas não tenho planos específicos para adicionar mais aqui.

Que tal um caso em que você realmente queira usar --paste junto com --config? O que no nosso caso (RhodeCode) é um grande requisito para a lógica especial de monitoramento de memória que temos na configuração do gunicorn.

@marcinkuzminski esse é o caso de uso ideal. Basta especificar --paste e --config . No entanto, o Gunicorn não lerá a seção "servidor" do arquivo paste ini porque a expectativa é que você configure o servidor no arquivo de configuração do gunicorn.

Isso é lamentável.

Estamos enviando gunicorn para os clientes no instalador, e toda a lógica e configuração foram delegadas aos arquivos .ini. É assim que a maioria dos exemplos na internet especifica para projetos de pirâmide.

Essa mudança quebra isso, e provavelmente é mais fácil para nós fazer um fork do gunicorn para trazê-lo de volta, depois alterar a lógica e delegar a configuração para gunicorn_conf.py :(

E se as opções --paste fossem lidas, com um prefixo especial. por exemplo, você pode configurar o gunicorn com --paste, mas leria apenas as opções de configuração que seriam prefixadas com gunicorn.

por exemplo

gunicorn.workers = 2
gunicor.XXX = YYY

Você não precisa usar --config . Você pode usar a pasta INI inteiramente. Para isso, use pserve em vez de gunicorn . Consulte a documentação: https://docs.gunicorn.org/en/stable/run.html#paste -deployment

A mudança que foi feita foi apenas para remover o suporte ao uso do Gunicorn como uma CLI de implantação de colagem geral que pode executar servidores. Gunicorn ainda _é um_ próprio servidor compatível com Paste.

Essa alteração foi feita para remover possíveis confusões em que um arquivo .ini especificaria garçonete, ou qualquer outro servidor, em seu bloco server , mas executá-lo com gunicorn --paste production.ini não usaria garçonete em tudo. As pessoas também frequentemente solicitavam a capacidade de especificar um bloco alternativo server diferente de server:main . Manter o suporte para esses recursos quando existem CLIs perfeitamente bons como pserve para isso não parecia fazer sentido.

A CLI gunicorn pode ler uma definição de aplicativo de um arquivo INI, mas usa seu próprio arquivo de configuração para configurar um servidor. Use outra ferramenta (como pserve ) como o script / process runner se você quiser usar o arquivo INI para configurar um servidor Gunicorn.

mas temos que usar --config junto com --paste, conforme meu primeiro comentário.
Em nosso projeto tudo é gerenciado por um único arquivo de configuração (.ini) Há muita lógica de upgrade/autoscale que apenas ajusta o arquivo .ini. Em seguida, usamos também --config para especificar uma configuração python personalizada que define

• formato de logger personalizado (isso tecnicamente não é possível de ser especificado usando o arquivo .ini)
• gerenciamento de memória do trabalhador (código Python)

Gunicorn é compatível com Paste, mas a funcionalidade é limitada dessa maneira, e criou um problema para nós do qual não conseguimos recuperar porque não podemos ter 2 arquivos de configuração, e também mover para a configuração em outro arquivo é mais trabalhoso do que bifurcar Gunicorn e manter esse garfo apenas para trazer esse comportamento de volta.

Eu sei a razão para este bilhete, mas costumávamos usar gunicorn e garçonete juntos, e eu acho que executar o binário gunicorn é explícito o suficiente, IMHO. Além disso, acho que você pode até detectar se os usuários usam um ovo diferente e torná-lo um erro difícil.

Não consideramos esse uso, se bem me lembro. Provavelmente podemos trazer de volta
o suporte dele como o caso de uso parece bom. Seria bom ter um
aviso de log para isso?

Em sex 16 out 2020 às 08:28 Marcin Kuźmiński [email protected]
escrevi:

mas temos que usar --config junto com --paste, conforme meu primeiro
Comente.
Em nosso projeto tudo é gerenciado por um único arquivo de configuração (.ini)
Há muita lógica de atualização/autoescala que apenas ajusta o arquivo .ini.
Em seguida, usamos também --config para especificar uma configuração python personalizada que define

• formato de registrador personalizado (isso tecnicamente não é possível ser
  especificado usando o arquivo .ini)
• gerenciamento de memória do trabalhador

Gunicorn é compatível com pasta, mas a funcionalidade é limitada dessa maneira,
e isso criou um problema para nós do qual não conseguimos nos recuperar.

Eu sei o motivo, mas costumávamos usar gunicorn e garçonete juntos,
e eu pensando em executar o binário gunicorn é explícito o suficiente, IMHO.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/benoitc/gunicorn/issues/2169#issuecomment-709838842 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAADRIQR2CLVUOYK6FDY2ZDSK7RZFANCNFSM4JMI65YA
.

>

Enviado do meu celular

Na verdade, pensei em outra solução, se possível. Ao usar pserve com ovo de unicórnio, também seria bom que o arquivo de configuração fosse definido dentro do arquivo .ini.

por exemplo

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

Então ele carregaria o gunicorn_conf.py exatamente como --config=/path/to/gunicorn_conf.py faz

Portanto, o acima funcionaria para nós e também está resolvendo o problema deste ticket. Não tenho certeza de quão fácil e viável isso é implementar.

Caso contrário, se você pudesse trazer a funcionalidade de carregar a configuração do arquivo .ini ao executar o binário gunicorn, seria incrível, isso nos pouparia muito aborrecimento. Ter um aviso sobre isso não é problema

Na verdade, pensei em outra solução, se possível. Ao usar pserve com ovo de unicórnio, também seria bom que o arquivo de configuração fosse definido dentro do arquivo .ini.

Isso deve funcionar e está documentado. Se isso não acontecer, por favor registre um bug!

Ok, vamos verificar isso. Mas AFAIR houve pequenas mudanças na forma como os binários gunicorn vs pserve funcionam. Se bem me lembro, gunicorn --paste teve acesso ao caminho do arquivo .ini, enquanto o pserve usando gunicorn egg não. Verificaremos isso e abriremos um ticket relevante, se necessário.