Docker меняет расположение именованных томов

У меня проблема, которую я просто не могу понять. Я использую докер для запуска определенных контейнеров, но у меня есть проблемы по крайней мере с одним томом, где я не люблю спрашивать, может ли кто-нибудь подсказать, что я делаю неправильно. В качестве примера я использую Nifi-Ingestion, но он затрагивает еще больше объемов контейнеров.

Во-первых, давайте поговорим о версиях, которые я использую:

  • Докер версии 19.03.8, сборка afacb8b7f0
  • docker-compose версии 1.27.4, сборка 40524192
  • Убунту 20.04.1 ЛТС

Теперь давайте покажем объем в моем рабочем файле docker-compose:

В моем контейнере он настроен следующим образом:

volumes:
    - nifi-ingestion-conf:/opt/nifi/nifi-current/conf

Ниже моего файла docker-compose он определяется как обычный именованный том:

volumes:
    nifi-ingestion-conf:

Это фрагмент из docker-compose, который я хотел бы заставить работать

В моем контейнере он настроен в этом случае следующим образом (мой STORAGE_VOLUME_PATH определен как /mnt/storage/docker_data):

volumes:
    - ${STORAGE_VOLUME_PATH}/nifi-ingestion-conf:/opt/nifi/nifi-current/conf

Внизу, я думаю, есть что делать, но я не знаю, что мне нужно делать здесь. В данном случае так же, как и в рабочем docker-compose:

volumes:
    nifi-ingestion-conf:

Итак, в чем моя проблема?

У меня есть два файла docker-compose. Один использует обычные именованные тома, а другой использует тома в моем дополнительном пути монтирования. Когда я запускаю контейнеры, кажется, что тома работают по-разному, так как файлы пишутся в первом стиле, а не во втором. Мои пути монтирования генерируются во второй версии, поэтому с моими переменными среды в .env-файле все в порядке.

Подсказка: /mnt/storage/docker_data — это монтирование NFS, но моя машина имеет полные права на этот общий ресурс.

Вот моя запись fstab для монтирования этого тома (возможно, мне нужно установить другие параметры):

10.1.0.2:/docker/data               /mnt/storage/docker_data        nfs     auto,rw

Большие фрагменты

Вот более крупный фрагмент, если docker-compose (мне нужно вырезать и удалить достоверные данные, моя проблема не в том, что он не работает, а только в том, что том действует по-другому. Все для этого одного тома есть в коде.) :

version: "3"
services:
    nifi-ingestion:
        image: my image on my personal repo
        container_name: nifi-ingestion
        ports:
            - 0000
        labels:
            - app-specivic
        volumes:
            - ${STORAGE_VOLUME_PATH}/nifi-ingestion-conf:/opt/nifi/nifi-current/conf
            #working: - nifi-ingestion-conf:/opt/nifi/nifi-current/conf
        environment:
            - app-specivic
        networks:
            - cnetwork

volumes:
    nifi-ingestion-conf:

networks:
    cnetwork:
        external: false
        ipam:
            driver: default
            config:
                - subnet: 192.168.1.0/24

А вот env (только значение, которое мы используем)

STORAGE_VOLUME_PATH=/mnt/storage/docker_data
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
Как создать PHP Image с нуля
Как создать PHP Image с нуля
Сегодня мы создадим PHP Image from Scratch для того, чтобы легко развернуть базовые PHP-приложения. Пожалуйста, имейте в виду, что это разработка для...
2
0
2 343
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

если я правильно понял ваш вопрос, вам интересно, почему следующий фрагмент кода docker-compose работает для вас

version: "3"
services:
  nifi-ingestion:
    volumes:
       - nifi-ingestion-conf:/opt/nifi/nifi-current/conf
volumes:
  nifi-ingestion-conf:

и следующий фрагмент docker-compose не работает для вас

version: "3"
services:
  nifi-ingestion:
    volumes:
      - ${STORAGE_VOLUME_PATH}/nifi-ingestion-conf:/opt/nifi/nifi-current/conf

что отличает их, так это то, как вы используете тома. вам нужно различать пути монтирования хоста и монтирование именованных томов

Вы можете смонтировать путь хоста как часть определения для одной службы, и нет необходимости определять его в ключе volumes верхнего уровня.

Но если вы хотите повторно использовать том в нескольких службах, определите именованный том в ключе volumes верхнего уровня.

именованные тома управляются докером

Если вы запускаете контейнер с томом, которого еще не существует, Docker создает том за вас.

также, посоветовал бы вам прочитать этот ответ

обновлять: вы также можете прочитать о томах docker nfs

привет, извините, это был сбой копирования-вставки. Я исправил, как есть на самом деле. Это все строки, которые используются для томов. Моя проблема не в том, что файл содержит синтаксические ошибки, а в том, что именованный том без определенного пути монтирования (с использованием /var/lib/docker) действует иначе, чем когда я использую абсолютный путь

25x14 18.12.2020 10:52

Я просто не хочу, чтобы тома из контейнеров в этом docker-compose находились в /var/lib/docker, так как в случае сбоя жесткого диска данные теряются. И я хотел бы иметь возможность настроить новый сервер, просто смонтировать этот каталог и запустить контейнеры, и они просто используют эти тома. Я уже написал сценарий очистки, который проверяет правильность данных. При ручном копировании данных это даже работало.

25x14 18.12.2020 11:57

@ 25x14: ваш вопрос не ясен. вы хотите смонтировать том nfs на хосте в контейнер или создать именованный том поверх nfs?

Mr. 18.12.2020 12:28

Том nfs смонтирован на хосте. Я хотел бы иметь именованные тома внутри того каталога, который смонтирован.

25x14 18.12.2020 13:02

@ 25x14: я надеюсь, что последнее обновление моего ответа достаточно для вас

Mr. 20.12.2020 08:56

Здравствуйте, извините за поздний ответ. Я просто хотел бы иметь именованный том, но определить его физическое расположение (у меня есть docker-host с небольшим жестким диском и смонтированным общим ресурсом с нужным мне хранилищем). Причина в том, что данные не теряются, когда мой docker-host выходит из строя, и их можно легко использовать повторно, когда я заменяю docker-host. У самих контейнеров с этим проблем нет.

25x14 12.01.2021 08:34

Теперь я решил. Все, что я сделал, было правильно - проблема была в самом хранилище.

25x14 21.01.2021 09:06

Другие вопросы по теме