- Я развертываю приложение
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;
}
}