由于准备就绪检查失败，Google应用程序引擎部署失败

Question

自定义应用程序引擎环境无法启动，这似乎是由于运行状况检查失败所致。该应用程序有几个自定义依赖项（例如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如下所示（注意：docker-compose.yml和app.yaml中定义了noCMD作为入口点）：

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分钟！）之前似乎有一些问题，而从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启动和运行上

附录：

除了相关的问题外，我还浏览了谷歌的问题（here和here）

Answer 1

您正在向path: "/readiness_check"发送准备就绪检查，但该检查的url处理程序是path(r'readiness_check/'...)

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

Answer 2

好吧，谷歌的家伙们也帮不上忙，但在经历了一段史诗般的旅程之后，我终于找到了问题所在：Dockerfile需要一个CMD语句。虽然我假设这就是app.yaml中的entrypoint的用途，但似乎appengine使用docker run启动了容器。因此，只需将这一行添加到Dockerfile即可修复：

CMD gunicorn -b :$PORT gisapplication.wsgi

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