app.yaml no se actualiza cuando lo implemento (motor de aplicaciones de Google/Google Cloud Platform)

app.yaml no se actualiza cuando lo implemento (motor de aplicaciones de Google/Google Cloud Platform)

Este es mi archivo app.yaml predeterminado:

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

Cuando implemento con mi archivo app.yaml actualizado, el archivo simplemente se restablece al anterior predeterminado. Esto es lo que intento:

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

ACTUALIZADO A CONTINUACIÓN:

Bien, hice que este de arriba funcione ahora. Parecía que el servicio API tenía dos archivos app.yaml y tuve que cambiarlos en ambos. Esto ahora tiene una configuración en la interfaz web de GCP que se parece a la que implementé: mínimo 1 y máximo 3.PERO, aun así, a veces crea de 4 a 5 instancias.:S

AHORA, para mi otra aplicación, el programador, esto es lo que puse en el archivo 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

Y cuando se implementa, en GCP su configuración se ve así:

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

Y aquí hay una captura de pantalla del resultado:

ingrese la descripción de la imagen aquí

Muy confuso.

Respuesta1

Hay algunas opciones mezcladas de configuraciones para dos tiempos de ejecución diferentes.

Cada opción runtime: customse describe enaquí. handlers:y runtime_config:no se mencionan para el tiempo de ejecución personalizado porque son parte del tiempo de ejecución de Javaaquí.

core: 1no existe en ninguna de las configuraciones mencionadas anteriormente y sospecho que querías usar cpu: 1en su lugar, que se puede usar en ambas configuraciones. Además, cuando intento implementar en segundo lugar, app.yamlaparece un error que dice que core:no existe, por lo que su configuración no debería implementarse en primer lugar.

Actualizado:

En el artículo que describegestión de instanciasy menciona que

Se le facturará solo por las instancias inactivas hasta el número máximo de instancias inactivas que establezca para cada servicio.

Lo que implica que en algún momento puedes tener más instancias inactivas de las que has establecido como máximo pero no se te facturarán. Y el gráfico de esa imagen respalda esa afirmación.

información relacionada