Почему gunicorn не отвечает на проверки работоспособности CloudFoundry при запуске приложения cherrypy за NGINX? - PullRequest
Новая
       17

Почему gunicorn не отвечает на проверки работоспособности CloudFoundry при запуске приложения cherrypy за NGINX?

0 голосов
/ 28 ноября 2018
  • Я развертываю приложение cherrypy на CloudFoundry.
  • Я установил health-check-type: http в моем манифесте приложения.
  • У меня есть NGINX настройка в качестве обратного прокси-сервера(см. конфигурацию ниже).
  • Я использовал для запуска веб-сервера cherrypy примерно так: python3 -u app.py, и он работал нормально, но, очевидно, это не рекомендуется по разным причинам.
  • Сейчас я пытаюсь запустить gunicorn вокруг вишневого кода следующим образом: gunicorn -w 1 -t 300 -b :8080 app:app - это когда я больше не могу заставить приложение стать здоровым при запуске.

В CloudFoundry выМожно выбирать между проверками работоспособности со значением по умолчанию port.Установка health-check-type в port фактически позволяет gunicorn запускать и правильно обслуживать запросы.Однако, когда я установил health-check-type: http, запуск не удался.

Я могу видеть это в журналах: 

   2018-11-28T21:10:39.12+0100 [CELL/0] OUT Starting health monitoring of container
   2018-11-28T21:10:39.30+0100 [APP/PROC/WEB/0] OUT Start nginx ...
   2018-11-28T21:10:39.34+0100 [APP/PROC/WEB/0] OUT Starting nginx: nginx.
   2018-11-28T21:10:39.34+0100 [APP/PROC/WEB/0] OUT Start app ...
   2018-11-28T21:10:39.64+0100 [APP/PROC/WEB/0] ERR [2018-11-28 20:10:39 +0000] [94] [INFO] Starting gunicorn 19.9.0
   2018-11-28T21:10:39.64+0100 [APP/PROC/WEB/0] ERR [2018-11-28 20:10:39 +0000] [94] [INFO] Listening at: http://0.0.0.0:8080 (94)
   2018-11-28T21:10:39.64+0100 [APP/PROC/WEB/0] ERR [2018-11-28 20:10:39 +0000] [94] [INFO] Using worker: sync
   2018-11-28T21:10:39.64+0100 [APP/PROC/WEB/0] ERR [2018-11-28 20:10:39 +0000] [134] [INFO] Booting worker with pid: 134
   2018-11-28T21:10:43.67+0100 [APP/PROC/WEB/0] ERR [28/Nov/2018:20:10:43] ENGINE Bus STARTING
   2018-11-28T21:10:43.67+0100 [APP/PROC/WEB/0] ERR [28/Nov/2018:20:10:43] ENGINE Starting up DB access
   2018-11-28T21:10:43.67+0100 [APP/PROC/WEB/0] ERR [28/Nov/2018:20:10:43] ENGINE Bus STARTED

, который выглядит для меня, как будто все идет хорошо до этоготочка.Однако после завершения некоторых задач запуска мониторинг работоспособности снова и снова выдает выходные данные, пока время запуска окончательно не истечет: 

   2018-11-28T21:11:17.97+0100 [APP/PROC/WEB/0] OUT 127.0.0.1 - - [28/Nov/2018:20:11:17] "GET / HTTP/1.0" 302 100 "" "Go-http-client/1.1"
   2018-11-28T21:11:17.98+0100 [APP/PROC/WEB/0] ERR [28/Nov/2018:20:11:17]  [METRICS] [/] took 0.0024
   2018-11-28T21:11:17.98+0100 [APP/PROC/WEB/0] OUT 127.0.0.1 - - [28/Nov/2018:20:11:17] "GET / HTTP/1.0" 302 100 "" "Go-http-client/1.1"
   2018-11-28T21:11:17.99+0100 [APP/PROC/WEB/0] ERR [28/Nov/2018:20:11:17]  [METRICS] [/] took 0.0030
   2018-11-28T21:11:17.99+0100 [APP/PROC/WEB/0] OUT 127.0.0.1 - - [28/Nov/2018:20:11:17] "GET / HTTP/1.0" 302 100 "" "Go-http-client/1.1"
   2018-11-28T21:11:18.00+0100 [APP/PROC/WEB/0] ERR [28/Nov/2018:20:11:18]  [METRICS] [/] took 0.0028
   2018-11-28T21:11:18.00+0100 [APP/PROC/WEB/0] OUT 127.0.0.1 - - [28/Nov/2018:20:11:18] "GET / HTTP/1.0" 302 100 "" "Go-http-client/1.1"
   2018-11-28T21:11:18.01+0100 [APP/PROC/WEB/0] ERR [28/Nov/2018:20:11:18]  [METRICS] [/] took 0.0028
   2018-11-28T21:11:18.02+0100 [APP/PROC/WEB/0] OUT 127.0.0.1 - - [28/Nov/2018:20:11:18] "GET / HTTP/1.0" 302 100 "" "Go-http-client/1.1"
   2018-11-28T21:11:18.02+0100 [APP/PROC/WEB/0] ERR [28/Nov/2018:20:11:18]  [METRICS] [/] took 0.0027
   2018-11-28T21:11:18.03+0100 [APP/PROC/WEB/0] OUT 127.0.0.1 - - [28/Nov/2018:20:11:18] "GET / HTTP/1.0" 302 100 "" "Go-http-client/1.1"
   2018-11-28T21:11:18.04+0100 [APP/PROC/WEB/0] ERR [28/Nov/2018:20:11:18]  [METRICS] [/] took 0.0027

Похоже на gunicorn или NGINXответы с кодом состояния: 302 вместо 200, чего и ожидает проверка работоспособности.

Если я верну health-check-type обратно на port, все снова будет работать, и приложение запуститсяи волшебно работает.К сожалению, я действительно хочу использовать другие health-check-type: http (чтобы иметь возможность использовать health-check-http-endpoint).

Есть идеи, чего мне здесь не хватает в моей настройке?

  • Я попытался запустить gunicorn локально, что отлично работает.
  • Я также развертываю 4 других приложения с gunicorn в очень похожей конфигурации (включая NGINX и * 1056).* или flask) и хотя бы у одного из них опция health-check-type: http работает без описанных проблем.

Конфигурация обратного прокси-сервера NGINX для справки: 

server {

    # Running port
    listen 80;
    server_name  localhost;

    # Form submission size
    client_max_body_size 100m;

    location / {

        proxy_pass         http://127.0.0.1:8080;
        proxy_redirect     off;
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Host $server_name;
        proxy_connect_timeout       300;
        proxy_send_timeout          300;
        proxy_read_timeout          300;
        send_timeout                300;

    }
}

1 Ответ

0 голосов
/ 30 ноября 2018

Хорошо, поэтому я нашел проблему здесь.cherrypy по-разному обрабатывает «завершающий слеш» в URL-адресе при запуске самостоятельно или при работе под gunicorn.

Здесь имеются cherrypy сообщения об ошибках: https://github.com/cherrypy/cherrypy/issues/1624 https://github.com/cherrypy/cherrypy/issues/1185

Что произошло, когда моя проверка работоспособности запрашивала: /health было то, что gunicorn выдал 302 permanent redirect на /health/, что означало, что проверка работоспособности не удалась (так как она не вернула 200).

Изменение URL проверки работоспособности на /health/ работало в этой ситуации.

...