Как обмениваться томами между несколькими хостами в режиме роевого режима докеров?

Можем ли мы совместно использовать общий/один именованный том для нескольких хостов в режиме swarm-режима докеры, что это самый простой способ сделать это?

Ответ 1

Если у вас есть настройка сервера NFS, вы можете использовать некоторую папку nfs в качестве тома из докера, например:

volumes:
    grafana:
      driver: local
      driver_opts:
        type: nfs
        o: addr=192.168.xxx.xx,rw
        device: ":/PathOnServer"

Ответ 2

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

С моей точки зрения, самым простым решением является rsync или, более точно, lsyncd n демоническая версия rsync. Но я никогда не пробовал это для докеров, поэтому я не могу сказать, справляется ли это с этим. Другие решения предлагаются с использованием Infinit.sh. В основном это делает то же самое, что и lsyncd. Это односторонняя синхронизация. Поэтому, если ваш контейнер-докер будет RW в своих томах, он не будет соответствовать вашим ожиданиям. Я пробовал это решение, и он работает очень хорошо для операций RO. И не в производстве. Это еще альфа-версия. Infinit также находится на пути предоставления драйвера докеров. Еще не выпущен. Поэтому я даже не пробовал. Слишком рискованно.

Другие решения, которые я нашел, но не смогли установить (и поэтому попробовать), - это flocker и glusterFS. Оба предназначены для создания FS Volume на основе нескольких жестких дисков с нескольких компьютеров. Но ни один из их хранилищ не работал в последние недели.

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

Cheers, Оливье

Ответ 3

В великой схеме вещей

Другие ответы определенно верны. Если вы чувствуете, что у вас все еще что-то не хватает или вы пришли к выводу, что в этом месте вещи никогда не будут действительно улучшаться, тогда вам, возможно, захочется пересмотреть использование типичной абстракции иерархической файловой системы, подобной POSIX. Не все приложения действительно нуждаются в этом (я мог бы сказать, что мало кто это делает). Возможно, у вас тоже нет.

В защите файловых систем

Он по-прежнему очень распространен во многих кругах, но обычно эти люди очень хорошо знают свои удаленные/распределенные файловые системы и знают, как их правильно настроить и эффективно использовать (и они могут быть очень хорошими системами, хотя часто не с существующими Драйверы уровня докеров). Иногда это также отчасти потому, что они просто вынуждены (кодовые базы, которые не могут или не должны быть перезаписаны для поддержки других хранилищ). Использование, настройка или даже запись произвольных драйверов тонера Docker будет второстепенной проблемой.

Альтернативы

Если у вас есть опция, тогда оцените другие решения для сохранения в ваших приложениях. Многие реализации не будут использовать интерфейсы файловой системы POSIX, а вместо этого - сетевые интерфейсы, которые не создают особых проблем на уровне инфраструктуры в кластерах, таких как Docker Swarm.

Решения, управляемые третьими лицами (например, облачные провайдеры)

Если вам удастся удалить все зависимости от файловых систем для постоянных и общих данных (это все еще нормально для локального состояния переходного), вы можете заявить, что имеете полностью "безгражданные" приложения. Конечно, часто всегда сохраняется состояние где-то еще, но идея в том, что вы не справляетесь с этим сами. Многие поставщики облачных вычислений (если там, где вы размещаете вещи), будут предлагать полностью управляемые решения для работы с постоянным состоянием, так что вам вообще не нужно об этом заботиться. Если вы идете по этому маршруту, рассмотрите управляемые службы, которые используют API-интерфейсы, совместимые с реализациями, которые можно использовать локально для тестирования (например, запустив контейнер Docker на основе образа для этой реализации, предоставленного сторонней организацией или вы можете поддерживать себя).

DIY-решения

Если вы хотите управлять постоянным состоянием себя в кластере Docker Swarm, тогда абстракция файловой системы часто неизбежна (и у вас, вероятно, будет больше проблем с таргетингом на блокирующие устройства, так или иначе). Вы хотите играть с node и ограничениями службы, чтобы гарантировать, что требования того, что вы используете для сохранения данных, выполняются. Для некоторых вещей, таких как центральный сервер СУБД, это может быть легко ( "всегда запускать задачу только для этого конкретного node" ), для других это может быть более активно.

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

Заключение

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