app.yaml не обновляется при развертывании (механизм Google App /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
ОБНОВЛЕНО НИЖЕ:
Хорошо, так что я получил этот выше, чтобы работать сейчас. Казалось, у api-сервиса было два файла app.yaml, и мне пришлось изменить оба. Теперь в веб-интерфейсе GCP есть конфигурация, похожая на ту, которую я развернул: минимум 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 ответ
Есть несколько опций, смешанных из конфигураций для двух разных сред выполнения.
Каждый вариант для runtime: custom
описано здесь. handlers:
а также runtime_config:
не упоминаются для пользовательской среды выполнения, потому что они являются частью среды выполнения Java здесь.
core: 1
не существует ни в одной из ранее упомянутых конфигураций, и я подозреваю, что вы хотели использовать cpu: 1
вместо этого, который может использоваться в обеих конфигурациях. Плюс при попытке развернуть вторую app.yaml
Я получаю сообщение об ошибке, что core:
не существует, поэтому ваша конфигурация не должна быть развернута в первую очередь.
Обновлено:
В статье, которая описывает управление экземпляром и упоминает, что
Вам будет выставлен счет только за незанятые экземпляры, количество которых не превышает максимально допустимого числа экземпляров, установленного для каждой службы.
Это означает, что в какой-то момент у вас может быть больше бездействующих экземпляров, чем то, которое вы установили в качестве максимума, но они не будут оплачиваться. И рисунок на этом изображении подтверждает это утверждение.