Docker: удалить настройку при использовании нескольких файлов YAML - PullRequest
Новая
       6

Docker: удалить настройку при использовании нескольких файлов YAML

1 голос
/ 17 июня 2019

Используя Docker Swarm, я сохраняю все свои переопределения в одном yml файле, например: 

docker stack -c base.yml -c overrides.yml deploy myStack

Если мой base.yml файл определяет эти пределы развертывания для serviceA: 

serviceA:
  . . .
  deploy:
    resources:
      limits: {memory: 1024M}
      reservations: {memory: 1024M}

Я могу легко переопределить в overrides.yml: 

serviceA:
  deploy:
    resources:
      limits: {memory: 2048M}
      reservations: {memory: 2048M}

Таким образом, мой base.yml может меняться по мере выпуска новых версий продукта, но любые переопределения легко переносятся из старой в новую версию. Однако что, если я хочу УДАЛИТЬ или удалить что-то определенное в base.yml? Если я хочу сохранить reservation, но удалить определение limits, используя второй файл yml. Есть какой-либо способ сделать это? В настоящее время я использую yaml версии 3.6.

Эти два параметра не работают. Это (не разбирается): 

serviceA:
  deploy:
    resources:
      limits: {memory: }
      reservations: {memory: 2048M}

и это (используется значение по умолчанию, определенное в base.yml): 

serviceA:
  deploy:
    resources:
      reservations: {memory: 2048M}

Ответы [ 2 ]

2 голосов
/ 17 июня 2019

При использовании нескольких файлов docker-compose последние объединяются с первыми. Это означает, что вы не можете удалить определения, просто изменить существующие или добавить новые (см. https://github.com/docker/compose/issues/3729). A PR , чтобы разрешить создание и закрытие без слияния.

Итак, все, что у вас остается, это удалить определение limits из вашего base.yml и оставить его только в вашем overrides.yml.

0 голосов
/ 18 июня 2019

fjc предоставили актуальный ответ на мой вопрос. Для конкретного случая, который меня интересовал, я узнал, что если вы «переопределите» и установите предел памяти равным нулю (0), это эквивалентно тому, что он вообще не был установлен. Не общий обходной путь, но по крайней мере обходной путь для этого конкретного случая. Например: 

serviceA:
  deploy:
    resources:
      limits: { cpus: '0', memory: '0' }

фактически не будет ограничивать количество процессоров или памяти.

...