由于未通过就绪检查，Google App Engine 部署失败答案

【问题标题】：Google App Engine deployment fails because of failing readiness check由于未通过就绪检查，Google App Engine 部署失败
【发布时间】：2020-07-05 00:19:29
【问题描述】：

自定义应用引擎环境无法启动，似乎是由于健康检查失败。该应用程序有一些自定义依赖项（例如 PostGIS、GDAL），因此在应用程序引擎映像之上有几层。它构建成功并在 Docker 容器中本地运行。

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.

Dockerfile 如下所示（注意：没有CMD 作为入口点在docker-compose.yml 和app.yaml 中定义）：

FROM gcr.io/google-appengine/python
ENV PYTHONUNBUFFERED 1
ENV DEBIAN_FRONTEND noninteractive

RUN apt -y update && apt -y upgrade\
    && apt-get install -y software-properties-common \
    && add-apt-repository -y ppa:ubuntugis/ppa \
    && apt -y update \
    && apt-get -y install gdal-bin libgdal-dev python3-gdal  \ 
    && apt-get autoremove -y \
    && apt-get autoclean -y \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

ADD requirements.txt /app/requirements.txt
RUN python3 -m pip install -r /app/requirements.txt 
ADD . /app/
WORKDIR /app

不幸的是，这会创建一个高达 1.58GB 的图像，但原始 gcr.io python 图像从 1.05GB 开始，所以我认为图像的大小不会或应该是一个问题。

使用以下 docker-compose.yml 配置在本地运行它可以立即漂亮地启动容器：

version: "3"
services:
  web:
    build: .
    command: gunicorn gisapplication.wsgi --bind 0.0.0.0:8080

所以，我原以为以下yaml.app 可以解决问题：

runtime: custom
env: flex
entrypoint: gunicorn -b :$PORT gisapplication.wsgi

beta_settings:
    cloud_sql_instances: <sql-db-connection>

runtime_config:
    python_version: 3

运气不好。因此，根据上面的错误，它似乎与准备检查有关。尝试增加应用程序启动的超时时间（15 分钟！）之前似乎有一些 issues with health checks 并且自 2019 年 9 月起回滚到旧版运行状况检查并不是解决方案。

readiness_check:
    path: "/readiness_check"
    check_interval_sec: 10
    timeout_sec: 10
    failure_threshold: 3
    success_threshold: 3
    app_start_timeout_sec: 900

liveness_check:
    path: "/liveness_check"
    check_interval_sec: 60
    timeout_sec: 4
    failure_threshold: 3
    success_threshold: 2
    initial_delay_sec: 30

拆分运行状况检查肯定已开启。 gcloud beta app describe 的输出是：

authDomain: gmail.com
codeBucket: staging.proj-id-000000.appspot.com
databaseType: CLOUD_DATASTORE_COMPATIBILITY
defaultBucket: proj-id-000000.appspot.com
defaultHostname: proj-id-000000.ts.r.appspot.com
featureSettings:
  splitHealthChecks: true
  useContainerOptimizedOs: true
gcrDomain: asia.gcr.io
id: proj-id-000000
locationId: australia-southeast1
name: apps/proj-id-000000
servingStatus: SERVING

那没用，因此也尝试增加实例可用的资源，并为 1 个 CPU (6.1GB) 分配最大内存量：

resources:
    cpu: 1
    memory_gb: 6.1
    disk_size_gb: 10

为了安全起见，我在应用程序中添加了运行状况检查端点（旧版运行状况检查和拆分运行状况检查）——它是一个 Django 应用程序，所以这进入了项目的urls.py：

path(r'_ah/health/', lambda r: HttpResponse("OK", status=200)),
path(r'readiness_check/', lambda r: HttpResponse("OK", status=200)),
path(r'liveness_check/', lambda r: HttpResponse("OK", status=200)),

因此，当我深入查看日志时，似乎有一个 curl 用户代理对 /liveness_check 的成功请求，但随后从 GoogleHC 代理对 /readiness_check 的请求返回了 503（服务不可用）

不久之后（在 8 个失败的请求之后 - 为什么是 8 个？）似乎发送了一个关闭触发器：

2020-07-05 09:00:02.603 AEST Triggering app shutdown handlers.

对这里发生的事情有任何想法吗？我想我已经用尽了解决这个问题的选项，并且想知道是否可以更好地投入时间在 Compute/EC2 中启动和运行。

附录：

除了链接的 SO 问题外，我还在 Google 上解决了问题（here 和 here）

【问题讨论】：

使用 Google Cloud 提出问题 - 让我们看看他们能否解决。

标签： python django docker google-app-engine google-cloud-platform

【解决方案1】：

您将准备检查发送到path: "/readiness_check"，但您的网址处理程序是path(r'readiness_check/'...)

注意处理程序中的尾部斜杠。删除它（或在readiness_check: 的路径中添加一个斜杠）并查看是否可以修复它。我认为这会给你一个404，但你得到一个503，它告诉我你可能有一个更严重的错误。单击控制台中503 左侧的箭头之一，查看错误消息是什么。您可能需要在控制台中搜索 traceback 才能看到它。

【讨论】：

不，不是这样。正如您自己提到的那样，这不会吐出 503。如果您省略尾部斜杠，Django 会重定向，因此可能会出现 301 Moved Permanently。
控制台只显示“调试：操作 [project-id-redacted] 未完成。等待重试。更新服务 [默认]（这可能需要几分钟）...⠏调试：操作 [ project-id-redacted] 未完成。等待重试。”如果标志 --verbosity=debug 它只是一遍又一遍地打印这个语句，所以那里没有细节。浏览日志但有 1e6，很难看出问题所在。 curl 代理 (200) 进行了成功的活动性检查，但紧随其后的是“已启动 VM 关闭”。

【解决方案2】：

好吧，谷歌的人也无法帮助解决它，但是在经历了太多日志的史诗般的旅程之后，我设法找出问题所在：Dockerfile 需要一个 CMD 声明。虽然我认为这就是 app.yaml 中的 entrypoint 的用途，但 App Engine 似乎使用 docker run 启动了容器。因此，只需将此行添加到 Dockerfile 即可修复它：

CMD gunicorn -b :$PORT gisapplication.wsgi

我还恢复了默认的健康检查设置，并且能够从我的应用程序中获取健康检查的 URL 路径，并让 Google 基础容器提供的默认 nginx 实例处理这些设置。

【讨论】：