由于无法进行就绪检查，因此Google App Engine部署失败

自定义应用引擎环境无法启动，这似乎是由于运行状况检查失败所致。该应用程序具有一些自定义的依赖项（例如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分钟！）以前似乎有一些健康检查问题，并且自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)),

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

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

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

对这里发生的事情有任何想法吗？我想我已经穷尽了解决该问题的所有选项，并且想知道是否应该花费更多的时间在Compute / EC2中启动和运行这些时间。

附录：

除了链接的SO问题外，我还在Google上（这里和这里）进行了一些问题