自定义应用程序引擎环境无法启动，这似乎是由于运行状况检查失败。该应用程序有一些自定义依赖项（例如 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.
The Dockerfile看起来如下（注：没有CMD因为入口点定义在docker-compose.yml and 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.ymlconfig 可以立即完美地启动容器：
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 is:
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)),
因此，当我深入查看日志时，似乎有一个成功的请求/liveness_check来自curl用户代理，但后续请求/readiness_check来自 GoogleHC 代理返回 503（服务不可用）
不久之后（在 8 个失败的请求之后 - 为什么是 8 个？）似乎发送了一个关闭触发器：
2020-07-05 09:00:02.603 AEST Triggering app shutdown handlers.
对这里发生的事情有什么想法吗？我想我已经用尽了解决这个问题的选项，并且想知道是否可以更好地投入时间来在 Compute/EC2 中启动和运行。
ADDENDUM:
除了链接的 SO 问题之外，我还遇到了 Google 上的问题（here and here)
您正在将准备情况检查发送至path: "/readiness_check"，但是你的 url 处理程序是path(r'readiness_check/'...)
请注意处理程序中的尾部斜杠。删除它（或在路径中添加一个尾部斜杠readiness_check:）并看看是否可以解决问题。我认为这会给你一个404，但你得到的是503这告诉我你可能有一个更严重的错误。单击左侧的箭头之一503在控制台中，查看错误消息是什么。您可能需要在控制台中搜索traceback看见了。