自定义应用程序引擎环境无法启动，似乎是由于健康检查失败。该应用程序有一些自定义依赖项（例如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中没有定义CMD作为入口点）：

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.iopython映像从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）