Первоначально это было внутреннее сообщение, и оно может относиться к некоторым из наших проектов, но справочная информация будет полезна, поэтому оставьте ссылки на них.
У нас есть проблема с Google App Engine, которая не позволяет намот новых развертываний.
Сообщение об ошибке:
ERROR: (gcloud.app.deploy) Error Response: [4] Your deployment has failed to become healthy in the allotted time and therefore was rolled back. If you believe this was an error, try adjusting the 'app_start_timeout_sec' setting in the 'readiness_check' section.
Это удивительная ошибка, тем более что у нас до этого не было проблем с этим до недавнего времени. Похоже, что наши изменения, сделанные ранее в этом году, по подготовке к новым проверкам работоспособности Google App Engine на самом деле не сработали, поэтому, когда система устарела 15 сентября (упомянуто здесь https://cloud.google.com/appengine/docs/flexible/custom-runtimes/migrating-to-split-health-checks),, с этого момента развертывания не работали). Спецификация проверки работоспособности приведена здесь: https://cloud.google.com/appengine/docs/flexible/python/reference/app-yaml#liveness_path.
Сообщение об ошибке ссылается на настройку app_start_timout_sec, более подробную информацию об этом можно найти здесь: https://cloud.google.com/endpoints/docs/openapi/troubleshoot-aeflex-deployment. Я не думал, что это была проблема с тайм-аутомТак как наша система загружается довольно быстро (менее 5 минут, по умолчанию), я исследовал журналы версии приложения (с этого момента я говорю о производственной системе codeWOF, если не указано). рабочие версии, но когда я посмотрел в Logs Viewer, были перечислены все разные версии, в том числе и те, которые вышли из строя.
Со следующими app.yaml в журналах отображалась эта ошибка:
liveness_check:
path: "/gae/liveness_check"
readiness_check:
path: "/gae/readiness_check"
Ready for new connections
Compiling message files
Starting gunicorn 19.9.0
Listening at: http://0.0.0.0:8080 (13)
Using worker: gevent
Booting worker with pid: 16
Booting worker with pid: 17
Booting worker with pid: 18
GET 301 0 B 2 ms GoogleHC/1.0 /readiness_check
GET 301 0 B 3 ms GoogleHC/1.0 /liveness_check
Это подтвердило, что система успешно загрузилась и чеки были получены. хотя и возвращает неправильный код, редирект 301 вместо 200. Но также, что проверки шли на неправильный URL, префикс не показывался.
Я полагал, что перенаправление было вызвано либо APPEND_SLASHили перенаправление HTTP на HTTPS. Я попробовал следующую конфигурацию и получил следующее:
liveness_check:
path: "/liveness_check/"
readiness_check:
path: "/readiness_check/"
GET 301 0 B 2 ms GoogleHC/1.0 /readiness_check
GET 301 0 B 3 ms GoogleHC/1.0 /liveness_check
Та же ошибка, что и выше, поэтому кажется, что установка пользовательского пути не влияет на то, куда отправляется проверка работоспособности. Поиск пользовательского пути во всех сообщениях журналирования возвращает ровно одно сообщение (сводная информация ниже):
2019-11-06 16:24:14.288 NZDT App Engine Create Version default:20191106t032141
livenessCheck: { path: "/liveness_check/" }
readinessCheck: { path: "/readiness_check/" }
Resources: { cpu: 1 memoryGb: 3.75 }
Итак, это первое, на что нужно обратить внимание, это правильная установка пользовательского пути, я не смог получить эточтобы изменить.
Я прочитал все сообщения StackOverflow, рассказывающие о App Engine и разделенных проверках работоспособности (было менее 10 записей), и попробовал все предложенные исправления. К ним относятся: Проверка правильности проверки разделения была установлена с помощью gcloud app describe --project codewof. Установка разделенных проверок работоспособности (снова) с помощью gcloud app update --split-health-checks --project codewof.
Последнее, что я попробовал, привело к чему-то довольно интересному. Я удалил все параметры проверки работоспособности в файлах app.yaml.
В документации (https://cloud.google.com/appengine/docs/flexible/custom-runtimes/configuring-your-app-with-app-yaml#updated_health_checks) указано следующее:
По умолчанию запросы HTTP от проверок работоспособностине пересылается в контейнер приложения. Если вы хотите расширить проверки работоспособности для своего приложения, укажите путь для проверок работоспособности или проверок готовности. Индивидуальная проверка работоспособности для вашего приложения считается успешной, если она возвращает код ответа 200 OK.
Это звучало так, как будто проверялась вся виртуальная машина, а не образ докера, работающий внутри нее, и развертывание работало!
GET 200 0 B 2 ms GoogleHC/1.0 /readiness_check
GET 200 0 B 3 ms GoogleHC/1.0 /liveness_check
Но если по какой-то причине отказал контейнер докераGoogle App Engine не знал бы, что есть проблема. Нам нужно посмотреть на этот сценарий и понять, что он на самом деле означает, я не смог найти ничего, что бы точно его указывало. Однако это позволяет нам выполнять срочные развертывания.
Я также протестировал следующее, чтобы пропустить перенаправления HTTPS.
settings/production.py
SECURE_REDIRECT_EXEMPT = [
r'^/?cron/.*',
r'^/?liveness_check/?$',
r'^/?readiness_check/?$',
]
liveness_check:
path: "/liveness_check/"
readiness_check:
path: "/readiness_check/"
GET 301 0 B 2 ms GoogleHC/1.0 /readiness_check
GET 301 0 B 3 ms GoogleHC/1.0 /liveness_check
Последнее, что я запутал, было связано с поведением сайта codewof-dev, противоречащим документации, которую я прочитал. Я не могу найти документацию снова, но я уверен, что там сказано, что экземпляр App Engine будет запускать либо устаревшие, либо новые проверки работоспособности. Но на codewof-dev веб-сайте работают оба!
GET 200 0 B 2 ms GoogleHC/1.0 /readiness_check
GET 200 2 B 2 ms GoogleHC/1.0 /_ah/health
GET 200 2 B 2 ms GoogleHC/1.0 /_ah/health
GET 200 2 B 2 ms GoogleHC/1.0 /_ah/health
GET 200 2 B 2 ms GoogleHC/1.0 /_ah/health
GET 200 2 B 2 ms GoogleHC/1.0 /_ah/health
GET 200 2 B 2 ms GoogleHC/1.0 /_ah/health
GET 200 0 B 2 ms GoogleHC/1.0 /readiness_check
GET 200 2 B 2 ms GoogleHC/1.0 /_ah/health
GET 200 0 B 2 ms GoogleHC/1.0 /readiness_check
GET 200 2 B 2 ms GoogleHC/1.0 /_ah/health
GET 200 0 B 2 ms GoogleHC/1.0 /readiness_check
GET 200 2 B 2 ms GoogleHC/1.0 /_ah/health
GET 200 0 B 2 ms GoogleHC/1.0 /readiness_check
GET 200 0 B 3 ms GoogleHC/1.0 /liveness_check
Последнее открытие: Сегодня утром я проверил, удалив все конфигурации проверки работоспособности в файлах app.yaml (как я это делал ранее), но также удалил все настраиваемые URL проверки работоспособности в нашем файле маршрутизации URL конфигурации. Система успешно развернута со следующими проверками работоспособности
GET 200 0 B 2 ms GoogleHC/1.0 /readiness_check
GET 200 0 B 3 ms GoogleHC/1.0 /liveness_check
Похоже, что экземпляр виртуальной машины App Engine имеет свою собственную проверку и не входит в наш контейнер Docker. Это подойдет для большинства гибких экземпляров GAE, но не для настраиваемой опции времени выполнения, которую мы используем.