Comments 26
Использовали. Приколы иногда ловили, но удобная штука, когда надо докер размазать на несколько хостов.
Большинству проектов, которые я встречал, достаточно было бы swarm'а, вместо того, чтоб следовать моде и лезть в k8s.
Учавствовал в микро истории: Одна микро компания имела докеризированный сервис в k8s от DigitalOcean. Платила около 100$ в месяц. Развернули на паре локальных виртуалок в swarm, сходу все задплоилось как надо. Прошел год, полет нормальный. 100$ в месяц экономия.
Однако часто слышу мнение, что swarm не торт, что swarm мертв и т.д.
Команды docker init нет в официальной документации, может вы имели ввиду docker swarm init?
Отличная обзорная статья, спасибо автору.
Используем в нескольких проектах на проде, в т.ч. в CI/CD, управлять очень просто, отлично работает автопубликация через traefik.
Есть известные неисправляющиеся баги на смешанных кластерах на Windows нодах с ingress и публикацией порта, открывал issue безрезультатно больше года назад - раз и два.
Хотя в итоге это не стало большой проблемой, если публиковать ресурсы с Windows нод через traefik, крутящийся на линуксовой ноде, ну и планомерно отказываться вообще от контейнеров на Windows.
Спасибо огромное за статью! Подскажите, пожалуйста, как расшарить volumes между нодами в swarm? Насколько помню ранее это было недоступно в swarm в отличие от k8s, или уже есть решение? Хотелось бы узнать оптимальный вариант из опыта.
Насколько я знаю, нативной поддержки нет. Но для решения данной проблемы подойдет любая реализация NFS: от провайдера или вручную установить. Я пользовался GlusterFS:
https://thenewstack.io/tutorial-create-a-docker-swarm-with-persistent-storage-using-glusterfs/
Спасибо за обзор, жаль, что поздно на него наткнулся.
Могу добавить, что для пользователей Ansible будет удобно использовать готовые модули по swarm и docker в целом https://docs.ansible.com/ansible/latest/collections/community/docker/docker_swarm_module.html
Вопросец возник: Портейнер показывает запущенные контейнеры только на той машине, где сам портейнер: если сервис решит запустить свой контейнер на другой ноде сварма - фиг, а не доступ к консоли, обзору нагрузки и т.д.
Как с этим бороться??? Или тот порт, который рекомендуете открыть при установке Портейнера, именно для этого?
Данная команда, запускает контейнер с агентом portainer на всех нодах в кластере:
docker stack deploy -c portainer-agent-stack.yml portainerПри появлении новой ноды в кластере, manager нода автоматически запустит агента portainer на новой ноде. И весь функционал portainer будет доступен для контейнеров на этой ноде. Если логику запуска portainer надо поменять, то правим файл portainer-agent-stack.yml.
Нет, порт 9443 нужен только для веб морды portainer.
А что произойдет если Leader нода ляжет? Другая нода примет роль leader? на остальных нодах останутся работать контейнеры? Контейнеры с Leader ноды запустятся на других нодах?
И еще вопрос, подскажите, а есть ли способ обеспечить доступность без участия внешнего балансировщика?
Мне приходит в голову dns round robin, но если одна из нод пропадает, то всё начнет тупить.
Если есть еще ноды с ролью manager и кворум может быть разрешен, то новая нода станет ведущей. Swarm использует алгоритм Raft поэтому следует использовать нечетное кол-во managerнод чтобы кворум работал. Да, контейнеры работать останутся, но добавлять и обновлять сервисы в кластере будет нельзя. Да, контейнеры с manager нод так же мигрируют, как и с обычных нод.
Ну, в swarm есть встроенный балансировщик, который прослушивает порты (указанные в сompose файле) на все нодах и пробрасывает трафик, либо в контейнер, который есть на этой ноде, либо на другую доступную в кластере.
В примерах везде так описано, будто у нод нет статичных данных. Но по крайней мере в веб-приложениях почти всегда наоборот. Как с ними быть? Почти ни в одной статье про это не пишут.
Как писали выше, htdocs можно положить на NFS, а что делать с файлами СУБД?
И где брать сам NFS? Как безопасно подключать его к виртуалкам, учитывая, что он не поддерживает авторзацию? Пока, единственная идея, которая пришла в голову - это объявить ноду для хранилища специальным тегом и в каждом стеке объявлять контейнер с nfs-сервером на этой ноде, а в контейнер веб-приложении при сборке сразу прописать монтирование этой NFS (монтировать из драйвера волайма не получится, т.к. внутренняя сеть кластера доступна только контейнерам, и даже если ее вытащить на ноду, это и безопасность ухудшит и проблемы с порядком старта сети и контейнеров возникнут). Внешнее хранилище NFS не поднять без провайдера, или же надо будет решать, как соединить виртулки нод второй сетью)
Очень бы хотелось обо всем этом почитать. Какие есть хорошие практики отработанные. Но пока не нашел ни одного текста, где это бы подробно разбиралась :(
а что делать с файлами СУБД?
а запускать СУБД в swarm на нескольких нодах, это искать геморрой на одно место
СУБД всетаки должна быть выделена отдельно и заниматься ей должны dba
==
там где я видел что БД работает в кластере — она была привязана к одной конкретной ноде и у нее было расшарена внутрь контейнера хранилка
Можно запускать и на одной. Вопрос был в другом: во всех мануалах по swarm превозносится идея, что он автоматически запустит, перезапустит контейнер на произвольной ноде. Когда это вообще может быть полезно без данных? Я кроме майнинга и тому подобного не могу придумать полезных задач, где надо размножать контейнеры, не хранящие состояние и не имеющие доступа к общим данным. А если состояние и данные хранить, то где статьи про хорошие практики в этом?
Что касается СУБД: в Docker базу предполагается запускать в том же стеке, в отдельном контейнере. Если запускать ее снаружи, от кластера нет никакого толка, так как надо будет решать вручную и проблему связи по сети, и совместного запуска/остановки, и передачу паролей и вообще все. Единственный выход, который вижу я, это в условиях деплоя жёстко прописывать один хост для базы, жёстко прописывать один хост для nfs-сервера, а "плавающими" оставлять только веб-сервер. При этом запеч прямо в образ монтирование nfs. Но ни в одной инструкции, ни в одном видеоролике об этом не говорят. Это и есть лучшая/единственная практика или есть способы лучше?
Такое ощущение, что по всех статьях даётся вольный пересказ примера из официального руководства и никто не описывает свой реальный опыт практического применения.
Во всех инструкциях только показывают, как весело можно играться с этими чистыми контейнерами и нигде не рассматривается вопрос данных.
Когда это вообще может быть полезно без данных?
ну база находится в отдельном кластере и ноды туда по сети ходят
вообще БД это отдельный стек и у нее должен быть отдельный кластер чисто с БД, вплоть до того что у него отдельная SAN от кластера с приложениями
и нигде не рассматривается вопрос данных.
«тыжпрограммист» (с)
ну вообще архитектор системы должен знать как строятся такие системы когда ее проектирует, инструкция она универсальная и не учитывает что некоторые сервисы не могут параллелится 'в лоб'
вообще масштабирование и параллелизм в СУБД это тема отдельного разговора и docker — это не инструмент для решения этих вопросов
> ну база находится в отдельном кластере и ноды туда по сети ходят
Даже если БД на отдельном кластере, где статьи про то, как построить кластер для СУБД на Swarm или заметка, что он для этого совершенно непригоден?
Во-вторых, не все приложения одинаковые. Некоторые не требуют большой базы. Бывает, что у вас сотни приложений и маленькая база у каждого. И этим всем надо управлять. Можно, конечно, колхозить все скриптами, но тогда какой только вообще от инфраструктуры кластера? Можно и деплоит скриптами наколхозить тем же ансиблом.
ну вообще архитектор системы должен знать как строятся такие системы
Зачем тогда вообще статьи писать? Все это есть в официальном руководстве к докеру. Интересна практика, кто как у себя сделал.
вообще масштабирование и параллелизм в СУБД это тема отдельного разговора и docker — это не инструмент для решения этих вопросов
Тогда к чему имеет отношение Docker Swarm кроме поднятия пустых контейнеров без состояния и данных?
У Вас, к примеру, есть полезные кейсы на Docker Swarm, которыми Вы могли бы поделиться? Как у Вас это организовано?
Например, если у вас база на отдельном кластере, на чем он? Как вы обеспечиваете связь контейнеров Swarm с этой базой? Внутренняя сеть Swarm автоматически связывает только контейнеры, получается, вы подключали базу снаружи к каждой ноде?
У Вас, к примеру, есть полезные кейсы на Docker Swarm, которыми Вы могли бы поделиться? Как у Вас это организовано?
да почти на всех местах где я работал, использовался или swarm или кубер
на самом нагруженном проекте, было две базы, кликхаус и постгри, с объемом под 30 терабайт каждый
в swarm кластере было по 20-30 нод каждого сервиса которые лопатили данные на выход-выход и внутри этих БД
ноды без состояний и без данных внутри, они получают данные из шины (kafka, rabbit) или из REST API, идут в БД (отдельный кластер на 3-5 инстансов) и рабоают там с данными
вы подключали базу снаружи к каждой ноде?
… дда? а что в этом такого? ноды же могут по сети хоть друг к другу в гости ходить, могут и в БД ходить
Расскажите, пожалуйста, об этом подробнее
На чем строился отдельный кластер с СУБД? В частности, какую ФС вы использовали (ведь они либо быстрые, либо поддерживают больше одного монтирования не чтение/запись)? Или держали данные в памяти, как это делает MySQL в режиме кластера?
Про сеть, получается, вы не использовали встроенную функцию Swarm для автоматического создания внутренней сети между нодами одного стека? Это строилось на своей инфраструктуре или на арендованных виртуалках в публичной сети?
очень хорошие вопросы, тоже всегда задаюсь такими, когда читаю статьи. хотелось бы реально больше практических статей из реальной жизни
Если вдруг у вас docker swarm живет в esxi, то overlay работать не будет, тк будет конфликт на порту 4789. Этот порт используется vmware для VXLAN
Причем кластер развернется, overlay сети будут созданы, будут разворачиваться реплики контейнеров и реплики будут пинговаться, но доступа к контейнерам по сети не будет
Лечится командой на инициализацию кластера со сменой порта
docker swarm init --data-path-port 7789
А еще надо иметь ввиду, что если в момент выполнения команды "docker stack deploy" у вас в контейнерах выполняются задачи, то они будут прерваны
Мы делали скрипт для "zero time deploy" но столкнулись с тем, что невозможно с master ноды контролировать health status контейнеров, развернутых на worker нодах.
Я вообще не понимаю, почему в swarm через cli невозможно получить информацию о контейнерах, которые запустились на worker нодах. Только какие-то костыли через удаленное выполнение команд через ssh
Возможно в k8s это из коробки есть
Я как правило для этого использую API Prometheus/API Portainer или что-то аналогичное для получения статуса контейнеров
Docker Swarm для самых маленьких