☰

Почему docker-compose создает исходный каталог в одном синтаксисе, а в другом — нет?

tag-icon • tag-icon docker docker-for-windows
Почему docker-compose создает исходный каталог в одном синтаксисе, а в другом — нет?

Рассмотрим следующий код YAML в моем docker-compose.ymlфайле, который настраивает монтирование тома (используя версию 3.7), используякраткий синтаксискак указано в документах:

volumes:
    - ./logging:/var/log/cron

Это сопоставляет относительный путь loggingна моей хост-машине с /var/log/cronпапкой внутри контейнера. Когда я запускаю docker-compose up, если loggingпапка не существует на моей хост-машине, Docker создает ее. Там все хорошо.

Теперь, если я изменю вышесказанное надлинный синтаксис:

volumes:
    - type: bind
      source: ./logging
      target: /var/log/cron

Теперь, когда я запускаю docker-compose up, он НЕ создает loggingпапку, если ее нет на моем хост-компьютере. Я получаю

Cannot create container for service app: b'Mount denied:\nThe source path "C:/Users/riptusk331/logging"\ndoesn\'t exist and is not known to Docker'

Кто-нибудь знает, почему краткая форма синтаксиса создает путь к хосту, если он не существует, а длинная форма — нет и выдает ошибку?

Использование Docker Desktop для Windows.

решение1

На самом деле это была «фича» (ошибка) старого -vсинтаксиса, которую они не хотели исправлять, поскольку это сломало бы все тысячи (миллионы?) реализаций, созданных людьми, которые полагались на это поведение.

Новый --mountсинтаксис томов, представленный для Docker Swarm, а затем расширенный для совместимости с исходными вызовами Docker CLI, явно не восстанавливал эту функциональность, поскольку это было «неожиданное волшебство», которое на самом деле не документировано и на которое не следовало полагаться.

Связанный контент