这最初是内部消息，可能涉及我们的某些项目，但是背景信息将非常有用，因此请留意这些内容。
我们在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拆分运行状况检查做准备而实际上不起作用，所以当9月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 }
这是要研究的第一件事，是正确设置自定义路径，我无法更改。
我阅读了所有有关App Engine和拆分运行状况检查（条目少于10个）的StackOverflow帖子，并尝试了所有建议的修复程序。这些包括：
已使用gcloud app describe --project codewof正确设置了对拆分运行状况检查的检查。
再次使用gcloud app update --split-health-checks --project codewof设置分割健康检查。
我尝试的最后一件事导致了一些非常有趣的事情。我删除了app.yaml文件中的所有运行状况检查设置。
默认情况下，来自运行状况检查的HTTP请求不会转发到您的应用程序容器。如果要将运行状况检查扩展到应用程序，请指定活动检查或准备情况检查的路径。如果您对应用程序进行的自定义运行状况检查返回200 OK响应代码，则认为已成功。
听起来好像正在检查整个VM，而不是在其中运行的docker映像正在检查，并且部署正常！
GET 200 0 B 2 ms GoogleHC/1.0 /readiness_check
GET 200 0 B 3 ms GoogleHC/1.0 /liveness_check
但是，如果Docker容器由于某种原因而失败，则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 VM实例具有自己的检查，并且没有进入我们的Docker容器。对于大多数GAE flexible实例来说，这很好，但对于我们正在使用的自定义运行时选项，则不是。