Есть docker-swarm в который входит несколько серверов. На каждом из них может крутиться само web приложение. Надо расшарить данные на диске так, что бы его могли видеть все запущенные ноды. В данный момент настроен lsync на мастере, откуда обновление растекаются по всем серверам на которых соответсвенно запущен rsync. Nfs тут не катит, так как он и подвисает бывает и скорость доступа к файлам заметно ниже чем они были бы локально. Да и важна отказоустойчивость, при падении одной из нод, даже мастера, что бы все продолжало работать. lsync например перестает корректно работать при пропадании одного из серверов. Насчет кластерных фс тут тоже не знаю как они себя поведут, насколько высока скорость доступа к данным, сайтик там все-таки не маленький. С этим делом опыта мало имел, а поднять бы надо уже вчера :)...
syncthing (бесплатный опенсорс) и resilio sync (в девичестве bittorrent sync, комерция, есть бесплатная обрезанная версия) - р2р синхронизация файлов.
оба умеют inotify, оба демоны, маленькие нативные ресурсонетребовательные, компилированы практически под каждую ось.
есть авторские репозитории.
для дуальности выбора :)
у синха пока еще хреновый враппер под андроид, поэтому использую ресилио для синхронизации/бекапа карты памяти с телефона на домашнюю файлопомойку.
я так понял ты пытаешься синхронизировать файлы между несколькими носителями, к которым контейнеры с сервисом стучатся напрямую "внутри одной железки".
нет, железок несколько, там рой докеровский. Надо что бы все контейнеры с php имели доступ к файлам. Двухсторонний не надо. То есть разрабочики задеплоили код и он сразу попал на все докеры с пап
Вообще как файловая системе - Ceph
Но если "сайтик маленький", то ваши требования к надежности как то слишком трудоемко звучат.
Возможно имеет смысл просто использовать ПО, которое умеет репликацию - это уже в зависимости от задач. PostgreSQL, Tarantool, syncthing, Elliptics
Как раз так НЕ маленький :). Сейчас посещаемость под 100к. Но планируется за год поднять в 10 раз...
Насколько быстро в Ceph будет доступ к данным? Ведь это куча php файлов которые надо еще скомпилировать...
Ведь это куча php файлов которые надо еще скомпилировать...
Для исходного кода не нужна ни общая файловая система, ни репликация.
Если уж критично синхронный исходный код - то использовать специальное ПО, которое умеет параллельно обновлять и запускать на нескольких нодах в кластере.
Например, Nomad.
Ну там какая тема, идет обновление кода, а оно часто происходит, нужно его на все ноды раскидать. И хорошо бы это происходило в автоматическом режиме. Так как пока есть там одна задачка не решенная с созданием определенных кэшей...
stratosmi, со Swarm все хорошо, но я как понял он не умеет синкать volume. То есть если на одной ноде то проблем нет, а если под больше то как он себя поведет кто его знает. Предлагают там nfs юзать, но это не дело для сайта, любые проблемы с сетью и каюк :)
То есть если на одной ноде то проблем нет, а если под больше то как он себя поведет кто его знает. Предлагают там nfs юзать, но это не дело для сайта, любые проблемы с сетью и каюк :)
volume для кода PHP????
Это нарушение концепции Docker и принципов Swarm соответственно.
Если у вам нужно так нестандартно работать с кодом, то законченные решения такие как Docker Swarm и Flynn.io плохо подходят.
Имеет смысл рассмотреть Nomad, он как позволяет делать весьма нестандратные выкрутасы с запуском приложений на нескольких нодах одновременно.
Может я что то не то понимаю? у меня есть контейнеры с http+php. Нужно что бы в них выполнялся код который я каким то образом подключу туда... И при изменении кода разработчиками прозрачно растекался по всем контейнерам.
Сейчас вот lsync на все железные машинки раскидывает и от туда уже можно моунтить... Ну это в перспективе.
Может я что то не то понимаю? у меня есть контейнеры с http+php. Нужно что бы в них выполнялся код который я каким то образом подключу туда... И при изменении кода разработчиками прозрачно растекался по всем контейнерам.
Концепция Docker подразумевает, что всё ПО находится внутри контейнера.
А снаружи, через volume подключены только данные.
Да, на каждую новую версию ПО - контейнер обновляется.
Для поддержи этого имеется и Docker Registry и куча механизмов внутри того же Swarm.
Код автоматически разъезжается по нодам штатным образом.
А вот если вы размещаете код PHP вне контейнера, на volume, - разумеется, вы можете настроить, чтобы все это работало.
Но вот обновления придется делать какими-то внешними средствами, вместо того, чтобы положиться на возможности Swarm как это было вы в стандартной схеме работы, когда код внутри контейнеров.
Собственно, вы с этим и столкнулись, насколько я понял?
Может я что то не то понимаю? у меня есть контейнеры с http+php. Нужно что бы в них выполнялся код который я каким то образом подключу туда... И при изменении кода разработчиками прозрачно растекался по всем контейнерам.
Сейчас вот lsync на все железные машинки раскидывает и от туда уже можно моунтить... Ну это в перспективе.
Обычная схема:
1) Пересоздается новая версия контейнера. Это будет небольшой объем, так Docker накатывает только изменения поверх "эталонной" версии.
2) Полученный образ называется образом с "артефактом".
3) Этот образ отправляется в Docker Registry
4) Оттуда его забирают ноды Swarm'а.
stratosmi, Ага именно с этим. Тогда хорошо, к примеру при деплое можно набрать команду которая пересоберет контейнер с новым кодом и выложит его в локальный репозиторий. Далее мне надо будет стопнуть старые сервисы, на которых могут висеть довольно приличное количество подключений. Которые все вообщем то и отвалятся, что будет совсем не хорошо, или докер аккуратно дождется пока они сами не отпадут? Грубо у меня 2 ноды сейчас, соответсвенно я стартую 2 копии контейнера. На каждом может висеть по 100 а то и больше подключений....
Ну и другой момент, что код весит гиг, а может и больше, но там выборочно я думаю можно его закинуть...
Конечно хотелось бы сделать все правильно. И я что то упустил из виду это концепцию...
stratosmi, Спасибо большое буду читать доки по этому, что то как то вскользь проскочил :).
в данный момент по graceful restart ничего толкового не нашел но буду продолжать смотреть. Ну я так понял что логика может быть такая, что просто подминится содержимое контейнера без перезапуска сервиса.
Если я например обновил конфиги еще, тогда надо будет выполнить команду для того что бы их перечитать?
Конфиги ведь тоже внутри контейнера надо хранить?
есть конечно такие штуки docker config create myconfig ./config.cnf . Но когда конфигов много, не удобно мне кажется с этим работать...
stratosmi, ага, понял принцип, где то даже для ключики видел подобные, как руки дойдут буду пробовать.
Сейчас пока для тестов развернул на серверах разработки, а вот скоро начну кластер крутить...
