Как обмениваться данными между контейнерами Docker – CloudSavvy IT

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

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

В этом руководстве мы рассмотрим несколько методов передачи данных между вашими контейнерами Docker. Предположим, вы уже настроили Docker и знакомы с фундаментальными концепциями, такими как контейнеры, образы, тома и сети.

Использование томов для совместного использования каталога

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

Объемы могут быть прикреплены к нескольким контейнерам одновременно. Это облегчает беспрепятственный обмен данными и постоянство, которым управляет Docker.

Для начала создайте том:

docker volume create –name общие данные

Затем создайте свои контейнеры, подключив том к пути файловой системы, ожидаемому каждым образом:

docker run -d -v shared-data: / data –name example example-image: latest docker run -d -v shared-data: / backup-source –name backup backup-image: latest

В этом примере контейнер резервного копирования получит эффективный доступ к каталогу контейнера / data этого примера. Он будет смонтирован как / backup-source; изменения, сделанные одним контейнером, будут отражены в другом.

Быстрый запуск контейнеров с подходящими объемами

Приведенный выше пример можно упростить, используя команду docker run –volumes-fromflag. Это обеспечивает механизм автоматического монтирования томов, которые уже используются существующим контейнером:

docker run -d –volumes-from example –name backup backup-image: latest

На этот раз резервный контейнер получит том с общими данными, смонтированный в его каталог / data. Флаг –volumes-from извлекает все определения томов, прикрепленные к примеру контейнера. Он особенно идеально подходит для заданий резервного копирования и других недолговечных контейнеров, которые действуют как вспомогательные компоненты для вашей основной службы.

Повышение безопасности с помощью креплений только для чтения

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

Если не предполагается, что контейнер вносит изменения, рекомендуется монтировать общие тома в режиме только для чтения. В приведенном выше примере контейнеру резервного копирования необходимо только прочитать содержимое тома с общими данными. Установка режима монтирования в режим только для чтения усиливает это ожидание, предотвращая ошибки или вредоносные двоичные файлы в образе от удаления данных, используемых в примере контейнера.

docker run -d -v shared-data: / backup-source: ro –name backup резервный образ: последний

Добавление ro в качестве третьего параметра, разделенного двоеточиями, к флагу -v указывает, что том должен быть смонтирован в режиме только для чтения. Вы также можете написать readonly вместо ro в качестве более явной альтернативы.

Обмен данными по сети

Вы можете использовать сетевые обмены как альтернативный подход к обмену данными через тома файловой системы. Присоединение двух контейнеров к одной сети Docker позволяет им беспрепятственно взаимодействовать с использованием автоматически назначаемых имен хостов:

docker network создать demo-network docker run -d –net demo-network –name first example-image: latest docker run -d –net demo-network –name second another-image: latest

Здесь первый сможет пинговать второй и наоборот. Ваши контейнеры могут запускать службу HTTP API, позволяющую им взаимодействовать с данными друг друга.

Продолжая пример резервного копирования, теперь ваш контейнер резервного копирования может сделать сетевой запрос на http: // example: 8080 / backup-data, чтобы получить данные для резервного копирования. Пример контейнера должен ответить архивом, содержащим все данные, которые необходимо сохранить. Затем контейнер резервного копирования отвечает за сохранение архива в подходящем месте для хранения.

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

При использовании этого подхода важно учитывать безопасность. Убедитесь, что любые HTTP API, предназначенные для внутреннего доступа других ваших контейнеров Docker, не имеют портов, открытых в мостовой сети вашего хоста Docker. Это поведение по умолчанию при использовании параметров сети, показанных выше; привязка порта с -p 8080: 8080 позволит получить доступ к API резервного копирования через сетевые интерфейсы вашего хоста. Это будет проблемой безопасности.

Резюме

Контейнеры Docker – это изолированные среды, которые не могут получить доступ к файловым системам друг друга. Тем не менее, вы можете обмениваться данными, создав том, подключенный ко всем участвующим контейнерам. Использование общей сети Docker – это альтернативный вариант, который обеспечивает более сильное разделение в сценариях, где прямое взаимодействие с файловой системой не требуется.

Рекомендуется максимально ограничивать межконтейнерные взаимодействия. Случаи, когда вам нужен совместный доступ к данным, должны быть четко определены, чтобы избежать тесной связи ваших сервисов друг с другом. Контейнеры, которые жестко зависят от данных из Другая Контейнер может быть сложнее развертывать и поддерживать с течением времени, что сводит на нет более широкие преимущества контейнеризации и изоляции.