☰

デプロイ時に app.yaml が更新されない (Google App engine/Google Cloud Platform)

tag-icon • tag-icon java google-cloud-platform google-app-engine yaml
デプロイ時に app.yaml が更新されない (Google App engine/Google Cloud Platform)

これは私のデフォルトの app.yaml ファイルです:

runtime: custom
env: flex
service: api

runtime_config:
   jdk: openjdk8

handlers:
- url: /.*
  script: this field is required, but ignored

automatic_scaling:
  min_num_instances: 1
  max_num_instances: 10

更新した app.yaml ファイルを使用してデプロイすると、ファイルは以前のデフォルトのファイルにリセットされます。私が試したのは次のとおりです。

runtime: custom
env: flex
service: api

runtime_config:
   jdk: openjdk8

handlers:
- url: /.*
  script: this field is required, but ignored

automatic_scaling:
  max_num_instances: 1

resources:
  core: 1

以下更新:

OK、これで上記のものが動作するようになりました。api-service には 2 つの app.yaml ファイルがあったようで、両方を変更する必要がありました。これで、GCP Web インターフェースに、私がデプロイしたものと似た構成 (最小 1、最大 3) ができました。しかし、それでも 4 ～ 5 個のインスタンスが作成されることがあります。:S

さて、私の他のアプリケーションであるスケジューラについては、app.yaml ファイルに次の内容を入力します。

runtime: java8
service: 'scheduler'
inbound_services:
- warmup
derived_file_type:
- java_precompiled
threadsafe: True
auto_id_policy: default
api_version: '1.0'
handlers:
- url: (/.*)
  static_files: __static__\1
  upload: __NOT_USED__
  require_matching_file: True
  login: optional
  secure: optional
- url: /
  script: unused
  login: optional
  secure: optional
- url: /.*/
  script: unused
  login: optional
  secure: optional
- url: /_ah/.*
  script: unused
  login: optional
  secure: optional
- url: /cron/v1/simulations
  script: unused
  login: optional
  secure: optional
resources:
  cpu: 1
  memory_gb: 1
  disk_size_gb: 1
  volumes:
  - name: ramdisk1
    volume_type: tmpfs
    size_gb: 0.5
automatic_scaling:
  min_num_instances: 1
  max_num_instances: 2
  cool_down_period_sec: 180
  cpu_utilization:
    target_utilization: 0.6

デプロイされると、GCP 上の構成は次のようになります。

runtime: java8
api_version: '1.0'
env: standard
threadsafe: true
instance_class: F1
inbound_services:
  - warmup
handlers:
  - url: '(/.*)'
    application_readable: false
    static_files: "__static__\\1"
    require_matching_file: true
    upload: __NOT_USED__
  - url: /
    script: unused
  - url: '/.*/'
    script: unused
  - url: '/_ah/.*'
    script: unused
  - url: /cron/v1/simulations
    script: unused
automatic_scaling:
  min_idle_instances: automatic
  max_idle_instances: automatic
  min_pending_latency: automatic
  max_pending_latency: automatic

結果のスクリーンショットは次のとおりです。

ここに画像の説明を入力してください

とても混乱するような。

答え1

2 つの異なるランタイムの構成から混在したオプションがいくつかあります。

のすべてのオプションruntime: customは、ここ.これらはJavaランタイムの一部であるため、カスタムランタイムでは言及されていませhandlers:ん。runtime_config:ここ。

core: 1は、前述のいずれの構成にも存在しないため、cpu: 1代わりに両方の構成で使用できる を使用したいと思われます。さらに、2 番目にデプロイしようとすると、存在しないapp.yamlというエラーが表示されるcore:ため、そもそも構成をデプロイすべきではありません。

更新しました：

記事ではインスタンス管理そして、

各サービスに設定した最大アイドル インスタンス数までのアイドル インスタンスに対してのみ課金されます。

つまり、ある時点では、最大として設定した数よりも多くのアイドル インスタンスが存在する可能性がありますが、課金は行われません。この画像のグラフィックは、その主張を裏付けています。

関連情報