☰

app.yaml wird beim Bereitstellen nicht aktualisiert (Google App Engine/Google Cloud Platform)

tag-icon • tag-icon java google-cloud-platform google-app-engine yaml
app.yaml wird beim Bereitstellen nicht aktualisiert (Google App Engine/Google Cloud Platform)

Dies ist meine standardmäßige app.yaml-Datei:

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

Wenn ich mit meiner aktualisierten app.yaml-Datei bereitstelle, wird die Datei einfach auf die vorherige Standarddatei zurückgesetzt. Folgendes versuche ich:

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

UNTEN AKTUALISIERT:

OK, also ich habe das hier oben jetzt zum Laufen gebracht. Es schien, dass der API-Dienst zwei app.yaml-Dateien hatte und ich musste beide ändern. Dies hat jetzt eine Konfiguration auf der GCP-Weboberfläche, die der von mir bereitgestellten ähnelt: min. 1 und max. 3.ABER trotzdem werden manchmal 4–5 Instanzen erstellt.:S

Und nun zu meiner anderen Anwendung, dem Scheduler. Folgendes habe ich in die Datei app.yaml eingefügt:

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

Und wenn es bereitgestellt ist, sieht seine Konfiguration auf GCP folgendermaßen aus:

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

Und hier ist ein Screenshot des Ergebnisses:

Bildbeschreibung hier eingeben

Sehr verwirrend.

Antwort1

Es gibt einige Optionen, die aus Konfigurationen für zwei verschiedene Laufzeiten gemischt sind.

Jede Option für runtime: customist beschrieben inHier. handlers:und runtime_config:werden für die benutzerdefinierte Laufzeit nicht erwähnt, da sie Teil der Java-Laufzeit sindHier.

core: 1existiert in keiner der zuvor erwähnten Konfigurationen und ich vermute, Sie wollten cpu: 1stattdessen verwenden, was in beiden Konfigurationen verwendet werden kann. Außerdem erhalte ich beim Versuch, das zweite bereitzustellen, app.yamleine Fehlermeldung, die besagt, dass core:es nicht existiert, sodass Ihre Konfiguration gar nicht erst bereitgestellt werden sollte.

Aktualisiert:

In dem Artikel, der beschreibtInstanzverwaltungund erwähnt, dass

Ihnen werden nur die inaktiven Instanzen bis zu der von Ihnen für jeden Dienst festgelegten maximalen Anzahl inaktiver Instanzen in Rechnung gestellt.

Das bedeutet, dass Sie irgendwann mehr inaktive Instanzen haben, als Sie als Maximum festgelegt haben, diese aber nicht in Rechnung gestellt werden. Und die Grafik auf diesem Bild unterstützt diese Behauptung.

verwandte Informationen