app.yaml não é atualizado quando eu implemento (Google App Engine / Google Cloud Platform)

Question

Este é o meu arquivo padrão 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

Quando implanto com meu arquivo atualizado app.yaml, o arquivo é redefinido para o arquivo padrão anterior. É isso que eu tento:

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

ATUALIZADO ABAIXO:

OK, então eu peguei este aqui para trabalhar agora. Parecia que o serviço de api tinha dois arquivos app.yaml e eu tive que mudar em ambos. Isso agora tem uma configuração na interface da web do GCP que se parece com a que implementei: min 1 e max 3. MAS, mesmo assim, às vezes cria 4-5 instâncias. : S

AGORA, para meu outro aplicativo, o agendador, é isso que eu coloco no arquivo 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__
  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

E quando é implantado, no GCP, sua configuração é assim:

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

E aqui está uma captura de tela do resultado:

Muito confuso.

    

Answer 1

Existem algumas opções misturadas de configurações para dois tempos de execução diferentes.

Todas as opções para runtime: custom estão descritas em aqui . handlers: e runtime_config: não são mencionados para o tempo de execução personalizado porque fazem parte do tempo de execução Java aqui .

core: 1 não existe em nenhuma das configurações mencionadas anteriormente Eu suspeito que você queria usar cpu: 1 , que pode ser usado em ambas as configurações. Além disso, ao tentar implantar o segundo app.yaml , recebo um erro dizendo que core: não existe, portanto, sua configuração não deve ser implantada em primeiro lugar.

Atualizado:

No artigo que descreve a gestão de ocorrências e as menções que

You will be billed only for idle instances up to the number of maximum idle instances that you set for each service.

Isso implica que, em algum momento, você pode ter mais instâncias ociosas do que aquelas definidas como máximo, mas elas não serão cobradas. E o gráfico nessa imagem suporta essa afirmação.