Это третий пост в моей серии под названием «Демистификация докера». Вам понадобится понимание изображений и контейнеров Docker, которые я объяснил во втором посте, чтобы понять это. Так что, если вы новичок, я рекомендую вам сначала пойти, проверьте их, а затем начните с этого.
Итак, с этим с дороги, давайте начнем. В этом посте я собираюсь поговорить о том, как справиться с данными в Docker. Это включает в себя обеспечение того, чтобы данные вашего приложения сохранялись даже после удаления контейнера и установления двухстороннего соединения между локальной машиной и контейнером Docker. Преимущество для последнего может заключаться в том, что вам не нужно перестроить изображения Docker каждый раз, когда вы вносите изменения в свой код.
Так как именно мы можем решить эти две очень важные проблемы? Объемы докера.
А какие объемы Docker? Объем Docker — это просто папки на вашей локальной машине, которые могут взаимодействовать с контейнером.
Это означает, что вы можете делать такие вещи, как хранилище файлы из вашего контейнера в локальной машине, и наоборот.
Теперь я буду освещать эти две концепции Docker: названные тома связывают крепления (+ анонимные объемы)
Концепция
Давайте предположим, что вы запускаете приложение в контейнере, которое преобразует и хранит статьи, которые пользователи вводят как .txt файл. Если вы не используете объемы Docker, то при удалении этого контейнера и создаете другой с того же изображения, у вас не будет доступа к сохраненным вами статьям, используя предыдущий контейнер. Это просто потому, что при удалении контейнера все данные, которые он имел, тоже удаляются.
Но что, если вы не сохранили данные внутри контейнера? Что, если вы сохранили его «где -то» на своей локальной машине, и каждый раз, когда вы запускаете контейнер, вы инструктируете Docker, чтобы искать эту папку, и используйте представленные там статьи.
Это именно то, где Названные тома вступают в игру.
Применение
Позвольте мне теперь показать вам, как вы на самом деле пойдете вперед, и использовать эти названные объемы и угадать, что их использование довольно просто:)
Это связано с тем, что при использовании объемов (не связывающих монтировки), независимо от того, являются ли они анонимными или названы, вам не нужно указывать путь на вашей локальной машине, где Docker должен хранить эти статьи (со ссылкой на наш пример). Это будет решено и управляется Docker автоматически. Вам просто нужно указать две вещи при запуске контейнера:
Название названного тома. Docker выберет файлы, хранящиеся ранее при автоматическом использовании этого названного тома. Если вы впервые используете этот названный громкость, то Docker создаст его для вас.
Путь внутри контейнера, который вы хотите связать. Например, если статьи получали магазин в
./data/articlesПапка в вашем контейнере, тогда это будет путь, который вам необходимо указать.
И с этими двумя вещами вы готовы идти! Так что ваша последняя команда будет выглядеть примерно так:
docker run -v volume-name:/path/in/container IMAGE_ID
Где том-имени это имя нашего названного тома и /path/in/container это путь внутри контейнера, который мы хотим связать.
Вышеупомянутая команда будет использовать названный том, который называется том-имени (или создайте его, если его не существует), и ваш контейнер теперь будет иметь доступ ко всем файлам, уже присутствующим в этом томе (который был бы создан каким -либо другим контейнером), а также сможет сохранять файлы в этом контейнере.
Таким образом, даже если вы удалите контейнер и, следовательно, его файловую систему, файлы, которые вы хотели сохранить, останутся сохранившимися. И это было для концепции названных томов.
Концепция
Что, если названные объемы, о которых я говорил выше, могут быть нанесены на карту в определенном месте на вашей машине. То есть, вместо того, чтобы управлять Docker, где на вашем компьютере именованная тома хранит эти файлы, вы можете указать их местоположение. Таким образом, вы также сможете редактировать эти файлы вручную из -за пределов контейнера.
Расширение этой цепочки мышления дальше, что если вы добавите свой код, и подключите его к контейнеру. Разве это не даст вам возможность напрямую видеть изменения, которые вы вносите в коде, отражающемуся в экземпляре вашего приложения? Да, это было бы. Удивительно, верно?
Если все еще не ясно, о чем я говорю, помните, как я сказал в последнем посте, что у Dockerfile есть инструкции по скопированию вашего кода в контейнер. После копирования вы не сможете изменить этот код. Но если вы настроите двустороннее соединение (как мы собираемся сделать только сейчас), тогда ваш контейнер сможет подобрать последний код.
Это то, что мы собираемся сделать с привязками. И мы собираемся столкнуться с небольшим сбором в этом, который мы решим, используя анонимные объемы.
Применение
Как и в случае с названными томами, привязки также настроены при запуске контейнера. Единственное отличие состоит в том, что когда вы указали имя в случае с именованными томами, вы указываете точный путь на локальной машине папки, с которой вы хотите установить ссылку, в вашем контейнере.
docker run -v /path/on/our/machine:path/in/container IMAGE_ID
Если мы установим путь на нашу хост -машину в папку, содержащую исходный код нашего приложения, и путь в контейнере, где мы скопировали код в DockerFile, то мы установили бы ссылку.
Любые изменения, которые мы сейчас вносите в нашу локальную копию кода, будут отражены в экземпляре приложения, работающего в контейнере.
Да, это все. Это так просто!
Незначительная проблема
Вы можете столкнуться с небольшим икотом, который я попытаюсь объяснить с примером.
Допустим, в вашем Dockerfile вы скопировали код для своего приложения Node.js и запустили NPM Установка Чтобы получить все зависимости в node_modules папка. Теперь, если вы используете крепления привязки а также Если Папка, которую вы подключаетесь к контейнеру, имеет код, но не node_modules Папка (потому что вы, возможно, не запустили npm Install локально), тогда ваша контейнерная версия приложения не будет работать, поскольку вся папка в контейнере переопределяется вашей локальной папкой и Отсюда node_modules Папка тоже потеряна.
Простое решение — запустить NPM Установка локально тоже, чтобы зависимости для копирования. Но что, если мы этого не хотим.
Для этого мы собираемся использовать анонимные объемы вместе со специальным свойством томов Docker.
Свойство состоит в том, что если указаны два тома (включенные монтировки связывания), то рассматривается более конкретный путь. Это будет более ясно, когда я покажу вам команду.
Поступая в анонимные объемы, они похожи на названные объемы и привязки, за исключением того, что вы не указываете имя или путь в вашей файловой системе. Они также различаются в отношении того, что они удаляются автоматически, когда контейнер удаляется в отличие от названных объемов и креплений. Анонимный том выглядел примерно так:
docker run -v /path/in/container IMAGE_ID
Теперь давайте использовать анонимные объемы и вышеупомянутое свойство для решения нашей первоначальной проблемы. Давайте сначала посмотрим на команду, а потом объясню, что она делает:
docker run -v /path/on/our/machine:path/in/container -v /path/in/container/node_modules IMAGE_ID
Здесь мы использовали крепление связывания, чтобы установить соединение между папкой, имеющей код на нашей машине, и местоположением в контейнере, где мы копируем код (указанный в Dockerfile). В идеале это должно перезаписать материал, присутствующий в контейнере с помощью нашего кода, следовательно, удаление node_modules Папка, которая была создана при создании изображения.
Но так как мы добавили анонимный том с более конкретным путем, то есть к node_modules Папка, которая создается во время построения изображения, Docker сохранит эту папку и заменит остальное на код на нашей локальной машине.
И это охватывает все, что вам нужно знать о объемах Docker (названных и анонимных) и привязки, чтобы начать. Лучший способ получить более глубокое понимание их — это начать использовать все, что вы узнали в своих реальных проектах. Я также умоляю вас пойти дальше и прочитать Официальная документация Для гораздо более подробного и технического объяснения, которое вышло за пределы этой статьи. С этим я надеюсь, что вы научились достаточно, чтобы получить довольно приличное представление о томах Docker!
Спасибо за чтение:)
Если у вас есть какие -либо отзывы для меня или просто хотите поговорить, не стесняйтесь общаться со мной на Twitter Анкет Я буду более чем рад вам помочь!: D.
Оригинал: «https://dev.to/rinkiyakedad/diving-deeper-into-docker-volumes-and-bind-mounts-4fp0»