Шаринг локальных файлов хоста для контейнеров

Добавил(а) microsin

Каждый контейнер имеет все необходимое для своего функционирования, без зависимости от каких-либо предустановленных сущностей на машине хоста. Поскольку контейнеры работают изолированно, они оказывают минимальное влияние на хост и другие контейнеры. Эта изоляция дает нам большое преимущество, контейнеры минимизируют конфликты между системой хоста и другими контейнерами. Однако эта изоляция также означает, что контейнеры по умолчанию не могут напрямую получать доступ к данным на машине хоста.

Рассмотрим сценарий, когда у вас есть контейнер для web-приложения, который требует доступа к настройкам конфигурации, сохраненным в файле на вашей системе хоста. Этот файл может содержать такие важные данные, как база данных пользователей или ключи API. Хранение такой чувствительной информации в образе контейнера вводит риски безопасности, особенно если подразумевается обмен образами. Чтобы решить эту проблему, Docker предоставляет две опции хранилища, реализующие мост между границей изоляции данных контейнера и данных машимны хоста: тома (volumes) и привязки монтирования (bind mounts).

[Сравнение volume и и bind mount]

Если вам нужно обеспечить такое поведение, когда данные, сгенерированные или модифицированные внутри контейнера, должны сохраняться, когда контейнер останавливается (или даже когда он удаляется), то ваш вариант volume. См. [3], чтобы подробнее познакомиться с сохранением данных контейнера, использованием томов и случаями, когда это может понадобиться.

Если у вас есть определенные файлы или директориии на вашей системе хоста, которыми вы хотите напрямую поделиться с вашим контейнером, наподобие файлов конфигурации или разрабатываемого кода, то вы вероятно будете использовать bind mount. Это похоже на открытие прямого портала между хостом и контейнером, через который файлы становятся общими. Bind mounts идекально подходит для рабочих окружений разработки, где доступ к файлам в реальном времени и их совместное использование между хостом и контейнером играют решающее значение.

[Шаринг файлов между хостом и контейнером]

С командой docker run могут использоваться оба флага: -v (или --volume) и --mount, чтобы позволить реализовать общий доступ к файлам или директориям вашей локальной машины (хост) и контейнером Docker. Однако есть некоторые отличия в их поведении и использовании.

Флаг -v проще и удобнее для базовых операций volume или bind mount. Если место расположения на хосте отсутствует, когда используется -v или --volume, то будет автоматически создана соответствующая директория.

Представим себе, что вы разработчик, работающий над проектом. У вас есть директория проекта для исходного кода на вашем компьютере. Когда вы компилируете свой код, генерируемые артефакты (скомпилированный код, исполняемый код, образы, и т. п.) сохраняются в отдельный подкаталог вашей директории проекта. В следующих примерах эта директория обозначена как /HOST/PATH. Теперь вам нужно сделать так, чтобы артефакты сборки оказались доступны в контейнере Docker, где работает ваше приложение. Кроме того, вы хотите, чтобы контейнер автоматически получал доступ к последней версии артефактов сборки, когда вы пересобрали свой код.

Следующая команда docker run запустит контейнер, используя bind mount и отображение монтирования на место расположения файлов в контейнере.

$ docker run -v /HOST/PATH:/CONTAINER/PATH -it nginx

Флаг --mount предоставляет больше возможностей и более тонкое управление, что больше подходит для сложных сценариев монтирования или распространения конечного результата разработки. Если вы используете --mount, чтобы сделать привязку монтирования (bind-mount) файла или директории, которых нет на хосте Docker host, то команда docker run не создаст их автоматически, и сгенерирует ошибку.

$ docker run --mount type=bind,source=/HOST/PATH,target=/CONTAINER/PATH,readonly nginx

Замечание: Docker рекомендует использовать синтаксис --mount вместо -v. Это дает больше контроля надо процессом монтирования, и позволяет избежать потенциальных проблем из-за отсутствующих директорий.

[Разрешения для Docker при доступе к файлам хоста]

Когда используются bind mount, крайне важно, чтобы Docker имел необходимые разрешения для доступа к директории хоста. Для предоставления доступа на чтение/запись можно при создании контейнера использовать модификаторы :ro (read-only, только для чтения) или: rw (read-write, доступ на чтение и запись) с флагом -v или --mount. Например, следующая команда предоставляет разрешение доступа на чтение и запись.

$ docker run -v HOST-DIRECTORY:/CONTAINER-DIRECTORY:rw nginx

Применение read-only bind mount позволит контейнеру обращаться к смонтированным файлам на хосте для чтения, но контейнеру нельзя будет модифицировать или удалять файлы. Монтирования read-write bind mount позволят контейнеру изменять или удалять смонтированные файлы, что также отражается и на файловой системе хоста. Монтирования read-only bind mount гарантируют, что файлы хоста не могут быть случайно изменены или удалены контейнером.

Synchronized File Share. По мере роста объема вашего кода традиционные методы шаринга фйлов наподобие bind mount становятся медленными или не эффективными, особенно для окружений разработки, где необходим частый доступ к файлам. Синхронизируемые file share улучшают производительность bind mount за счет синхронизируемого кэша файловой системы. Эта оптимизация обеспечивает быстрый и эффективный доступ к файлам между хостом и виртуальной машиной (VM).

[Практический пример]

По следующему пошаговому руководству можно научиться создавать и использовать bind mount для создания общих файлов между хостом и контейнером.

Запуск контейнера

1. Загрузите и установите Docker Desktop [5].

2. Запустите контейнер, используя httpd-образ с помощью следующей команды:

$ docker run -d -p 8080:80 --name my_site httpd:2.4

Эта команда создаст и запустит контейнер, и в нем в фоне будет запущен сервис httpd, и его порт 80 будет опубликован на хосте как порт 8080.

3. Запустите на хосте браузер, и обратитесь в нем по ссылке http://localhost:8080, или используйте команду curl, чтобы проверить как работает сервис.

$ curl localhost:8080

Использование bind mount

С помощью bind mount вы можете отобразить файл конфигурации на вашем компьютере хоста на указанное место внутри контейнера. В этом примере вы увидите, как изменить внешний вид веб-страницы с помощью bind mount:

1. Удалите существующий контейнер, используя Docker Desktop Dashboard (альтернативно можно в командной строке воспользоваться командой docker rm httpd:2.4):

2. Создайте на системе хоста новую директорию с именем public_html.

$ mkdir public_html

3. Поменяйте текущую директорию на public_html, и создайте в ней файл index.html со следующим содержимым. Это обычный файл HTML, который содержит простую веб-страничку с дружелюбным приветствием в виде ASCII-картинки кита.

< !DOCTYPE html>

< html lang="en">

< head>

< meta charset="UTF-8">

< title> My Website with a Whale & Docker!< /title>

< /head>

< body>

< h1>Whalecome!!< /h1>

< p>Look! There's a friendly whale greeting you!< /p>

< pre id="docker-art">
   ##         .
  ## ## ##        ==
 ## ## ## ## ##    ===
 /"""""""""""""""""\___/ ===
{                       /  ===-
\______ O           __/
\    \         __/
 \____\_______/
Hello from Docker!

< /pre>

< /body>

< /html>

4. Теперь надо запустить контейнер. Примеры с опциями --mount и -v дадут одинаковый результат. Но одновременно их запускать нельзя. Чтобы запустить другую команду, надо сначала удалить ранее созданный контейнер my_site.

$ docker run -d --name my_site -p 8080:80 -v .:/usr/local/apache2/htdocs/ httpd:2.4

Совет: когда вы используете флаг -v или --mount в командной строке Windows PowerShell, необходимо давать полный путь к вашей директории вместо простого ./. Причина в том, что PowerShell обрабатывет относительные пути не так, как bash (обычно используемый в окружениях Mac и Linux).

Когда контейнер запущен, обращение в браузере по ссылке http://localhost:8080 покажет вам новую страничку с картинкой кита.

Доступ к файлу на Docker Desktop Dashboard

1. Вы можете просмотреть смонтироанные файлы внутри контейнера, если в разделе Containers кликните на закладку Files, и затем выберите файл внутри директории /usr/local/apache2/htdocs/. Затем выберите "Open file editor".

2. Файл на хосте, и проверьте, что этот файл также удалился на контейнере. В также увидите, что этот файл больше не существует в Docker Desktop Dashboard.

3. Заново создайте HTML-файл на системе хоста, и убедитесь, что этот файл появился на закладке Files в разделе Containers на Docker Desktop Dashboard. Теперь вы можете обратиться к этому файлу и на сайте http://localhost:8080.

Остановка контейнера

Контейнер продолжает работать, пока вы его не остановите.

1. Перейдите в раздел Containers в Docker Desktop Dashboard.

2. Найдите котейнер, который вы хотели бы остановить.

3. Выберите действие Delete в столбце Actions.