Управление кластером Docker Swarm с помощью Swarmpit

    image

    Доброго времени суток, %username%. Пора расчехлить блог после 6 лет простоя и попробовать опять что-то полезное принести сообществу.

    Я крайне удивлен, что на хабре до сих пор нет ни одной статьи про Swarmpit. Я конечно понимаю, что наверняка большинство изучая Docker останавливаются собственно на нем и потом пытаются забраться на Эверест под названием Kubernetes. Не знаю точных чисел, но думаю тут большинство теряются и либо вообще забивают на Docker либо только его и используют. А зря!

    Docker Swarm это почти идеальная система для почти всех. Я очень сомневаюсь, что действительно большому количеству людей нужен Kubernetes. Я убил на него почти сутки и понял, что убью еще штук 30, чтобы потом его спокойно использовать, НО я простой программист и вся эта крутая DevOps движуха вообще не о программировании. И тут я услышал про Docker Swarm и за 1 сутки абсолютно легко в него вник.

    Для кого нужен Docker Swarm? Вы уже прониклись отличными возможностями Docker экосистемы. Ваши приложения состоят из микросервисов. При этом у Вас несколько серверов и хотелось бы и отказоустойчивость иметь и нагрузку как-то регулировать.

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

    docker swarm init
    docker swarm join
    

    В целом я бы мог просто оставить ссылку на сайт Swarmpit и закончить, Вы все умеете читать, а устанавливается он вообще 1 командой и там даже думать не нужно, Вы просто расслабляетесь и запускаете свои контейнеры.

    Ссылка вот:

    Но я все-таки немного опишу и покажу скриншоты из этой чудесной админки.

    1. Главный экран


    Здесь собрана вся информация о кластере. Также сюда можно закрепить избранные сервисы и следить за их статусом:

    image

    2. Подключение сторонних реестров


    По умолчанию Swarmpit будет искать образы в hub.docker.com

    image

    3. Добавление нового сервиса


    Тут все предельно просто и понятно. Сначала находим образ в открытом или закрытых реестрах.

    image

    Выбираем версию, название и само собой режим: глобальный или реплицированный. Также можно задать команду на выполнение:

    image

    Затем настраиваем его сеть. Может добавить из общих, настроить порты и дать hostname alias для сервиса.

    image

    Устанавливаем переменные среды, подключаем хранилища, добавляем конфиги и секретные конфиги.

    image

    Устанавливаем лимиты для приложения:

    image

    Можем выдать сервису теги, включить автообновление образа, выдать ноды для деплоя и вообще настроить политику редеплоя, чтобы избежать простоя приложения:

    image

    Настройка логов:

    image

    4. Само собой можно добавлять сети и изменять их


    image

    5. Просматривать подключенные к кластеру ноды


    На одной машине у Вас может быть несколько нод (почитайте про docker-machine), но инстанс Swarmpit может быть подключен только к одному кластеру и только за ним будет следить.

    image

    6. Добавлять хранилища, контролируемые docker


    image

    7. Ну и само собой добавлять конфиги


    image

    8. Также можно добавлять пользователей с 2-мя типами доступа


    image

    Т.к. это docker swarm само собой можно создавать стеки и их запуск возможен только с помощью docker-compose формата:

    image

    Плюсы:

    +Я не кунг-фу мастер консоли, хоть и разворачивал в ней часть своих сервисов и убивал на это очень много времени. Swarmpit это время здорово экономит, особенно когда начинаешь играться с конфигами для того же nginx например. И вскоре обещают сделать версионирование конфигов с авторедеплоем связанных сервисов. Т.е. изменили строчку, сохранили и конфиг автоматом полетел во все сервисы, где он до этого был указан.

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

    Минусы:

    -Мастер пароль никак нельзя сбросить и нужно переустанавливать кластер, если Вы его потеряли

    -Разработчиков вроде 1-2, поэтому фичи добавляют долго, но на текущий момент критических багов я не обнаружил

    -Всякие мелкие недоработки, но большая часть из них висит в issue и разработчики обещают к 2.0 все выполнить

    -Контроль только над подключенным кластером, никакой поддержки сторонних кластеров или подключения к ним нет и видимо не будет

    Собственно еще раз дам ссылку на сайт Swarmpit тыц
    Github страница Swarmpit тыц.

    На данный момент я сделал еще 2 open source проекта на NodeJS, если интересно могу рассказать про них тоже. 1-й это редирект для телеграма без рекламы и ультрамелкий (Docker Image весит 27МБ и тоже написан на NodeJS без единого пакета), 2-й посложнее это cdn сервер для изображений, который налету может модифицировать изображения (ресайз, смена формата, качество итд) и может сэкономить 200$ (может и меньше, такова цена Business CloudFlare который позволяет делать так же).

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

    Что Вы используете в production

    • 25,9%Docker (деплой ручками, редеплой понятно может быть например Wachtower)28
    • 25,0%Docker swarm27
    • 36,1%Kubernetes (и его соседи mesos, rancher итд)39
    • 22,2%Git24
    • 24,1%Другой способ запуска26
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 75

      +2

      А у меня с docker swarm наоборот не сложилось. Очень многое приходилось делать руками, писать скрипты, допиливать напильником. k8s же хоть и требовал начального погружения, но зато очень многие проблемы решаются с пол пинка. Я уже не говорю про комьюнити которое просто огромное. В то время когда я взялся за k8s я был просто разработчиком, после чего так затянуло, что перешли переквалифицироваться в sre

        +2
        Безусловно k8s крайне мощный и всеобъемлющий. Но тут все-таки проблема времени, кому-то он быстрее дается, а кто-то я =)
        Ну и для средней коммерции swarm хватает, главное очень упрощает деплой и разработку, особенно со Swarmpit. И я могу делать то, что умею, а именно программировать.
          +5
          Я тоже смотрел в сторону k8s, немного охренел от количества информации, в которой нужно разобраться, и решил что Swarm пока что для моего мелкого кластера хватит с головой :)
        +2
        Интересная штука очень похожа на Portainer, есть ли какие-то различия?
          0
          Portainer мощнее, например можно объединять разные кластеры и даже одиночные машины. Ему вроде не обязательно, чтобы нода работала в режиме сварма. Но админка мне показалась в разы менее удобной, чем у Swarmpit и поэтому я пока использую именно второй.
            0
            админка да, покрасивше, хотя вопрос вкуса. На тему удобства очень не понравилось, что нет возможности обновить список, только релоад страницы. И на списке стеков у портейнера можно развернуть каждый стек в таски и наблюдать их состояние. В Swarmpit как я понял только руками ходить. Но самое главное у Swarmpit я не нашел ключевой фичи для UI для сварма — консоль в контейнер. Без неё вот прям печально в проде
              0
              А для чего обновлять список? Или у Вас несколько человек управляет через админку?
              Стеки вообще почти бессмысленны в swarmpit =(
              Про консоль согласен, совсем забыл написать в посте
                0
                ну например дебаг процесса деплоя. В какой последовательности таски стартуются\стопаются
            0
            У него еще и апи есть как свой а также он прокидывает апи докера, писал тулзу с помощью которой из ci/cd делал деплой
            0

            Нет, уж лучше K8s


            Если слишком сложно, то используйте Rancher (который раньше был на Swarm).


            Хотя документация и комьюнити такие обширные, что всё-таки рекомендую GKE + Gitlab.

              +4
              Вы не поверите, но не всем и не для всего нужен k8s. Даже более чем уверен, что для большинства людей хватит и обычного docker с watchtower.
              Вхождение в k8s непростое и тут все-таки нужно соблюдать баланс между деятельностью. Сидеть сутками поднимать кластер вместо того, чтобы писать код все-таки не очень хорошо. Для каждой задачи свои инструменты и я думаю, что swarm с приличным ui вроде swarmpit или portainer экономит огромное количество времени для разработчиков и позволяет добиться цели малой кровью.
                0

                Вы преувеличиваете сложность K8s.
                Точнее так: если вам нужно делать простые вещи, то K8s это может лучше и не усложняйте, оставьте всё на дефолтах :)
                К тому же по любому чиху есть доки, форумы и чаты, где можно проконсультироваться.

                  +2
                  Как недавно познавший кубер, выскажу свое мнение:
                  1) У Кубера сложные для понимания базовые сущности
                  2) поднятие простейшего сервиса превращается в написание длиннющего ямла, тот же docker-compose и swarm сильно лаконичнее

                  В то же время соглашусь, swarm мертв.
                    –1
                    Да, увы, последний апдейт 2017 год
                    Но пока для базовых кластеров вроде функционала хватает, другое дело, что однажды его могут выкинуть, не захотев поддерживать
                      +2
                      Все-таки про standalone Swarm пишут так:

                      docs.docker.com/swarm/get-swarm

                      You are viewing docs for legacy standalone Swarm. These topics describe standalone Docker Swarm. In Docker 1.12 and higher, Swarm mode is integrated with Docker Engine.
                        0
                        И правда. В таком случае в прошлом году выходили только фиксы.
                          +1

                          И снова Вы ошибаетесь и совершенно зря хороните swarm. При выходе последней на данный момент версии докера 19.03 в swarm была добавлена кучка фич, включая очень полезную поддержку sysctl. И вышла эта версия примерно пол года назад.

                +4
                Нет, уж лучше K8s

                Чем конкретно лучше, если брать относительно небольшие проекты с парой десятков микросервисов? Безусловно, фич у k8s намного больше, но какие из них реально необходимы этим небольшим проектам, и при этом отсутствуют в swarm?

                  0

                  Банально всем.
                  Вас никто не обязывает использовать все фичи K8s, но если вы захотите их использовать, то вы сможете это сделать. И что Gitlab что GKE дают возможность сделать это какое-то достаточно продолжительное время бесплатно, хотя при этом это инструменты Enterprise Production уровня.
                  А ещё есть Minicube и K3s, но по мне так Rancher наиболее прост для освоения.

                    +3
                    Банально всем.

                    Это максимально далеко от адекватного ответа на вопрос "чем конкретно".


                    Тратить кучу времени на изучение k8s ради потенциальной возможности воспользоваться в будущем фичами, необходимости в которых прямо сейчас нет, и может никогда не возникнуть — ну, такое. Есть много более полезных способов потратить время.

                      0

                      В своё время Rancher ушёл от Swarm под капотом на K8s и я был очень этому рад, т.к. мой проект примерно в то же время достиг определённых ограничений в Swarm.


                      Если вы столкнетесь с проблемой или нестабильностью, то в Swarm вы можете её просто не решить или решать очень долго из-за отсутствия информации или ограниченности Swarm. С K8s вероятность такого близка к 0.
                      Один из ваших небольших проектов когда-то созреет для чего-то бОльшего, вы созреете, ведь раньше вам и compose хватало, а сейчас вам уже нужен оркестратор. K8s это логичное продолжение цепочки.


                      На мой взгляд, для разработчика инфраструктура должна быть как код — это естественно. K8s этой парадигме максимально соответствует, а Swarm в этом плане… кривоват.
                      В K8s есть реализация практически всего, что вам может прийти в голову, не понятно зачем ограничивать себя Swarm, который занимает на рынке всё меньше и меньше и скоро просто вымрет.


                      https://medium.com/@fairwinds/docker-swarm-is-dead-long-live-kubernetes-2d0db0609e09

                        +3

                        Вы сами ответили на свой вопрос: "когда-то созреет для чего-то бОльшего". Вот когда (и если) созреет — тогда и будет пора переходить на что-то бо́льшее.


                        Частично потому, что есть шанс, что к тому моменту может и swarm станет чем-то бо́льшим, и его всё ещё будет достаточно. Но суть данного обсуждения вовсе не в том, всегда ли будет хватать swarm, и не в том, что уже сейчас есть достаточно большие проекты, которым swarm уже не хватает. А в том, что k8s сейчас просто модная тема, и его тащат во все проекты подряд, вне зависимости от того, насколько он реально им необходим. И у этого есть своя цена: увеличение сложности, которая пока что не окупается ничем, кроме абстрактных обещаний "может быть, когда-нибудь, этому проекту реально понадобятся все эти фичи и сложности". И это очень плохо, потому что абсолютному большинству проектов они не понадобятся никогда, а платить сложностью требуется уже сейчас!


                        В программировании уже все осознали, что если фича не нужна прямо сейчас, то её не нужно ни проектировать ни кодить. Потому что когда это делается преждевременно, в надежде что "в будущем она нам обязательно пригодится", то это практически всегда очень плохо заканчивается. Осталось подождать, пока эта же концепция дойдёт до девопсов…

                          +1

                          Swarm умирает, K8s это мейнстрим, стандарт в индустрии оркестраторов, а не какой-то новомодный хайповый проект и работает уже надёжнее и предсказуемее Swarm на дефолтах.
                          Вам сложно разобраться со всеми настройками K8s, оставьте же дефолт, не нужно все трогать, там действительно есть где заблудиться :)


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


                          Самая большая сложность, скорее психологическая — это первоначально окружение себе настроить.
                          Вот это вот сложно?!
                          https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app

                            +1
                            Swarm умирает

                            Откуда такая информация?


                            K8s это мейнстрим

                            XML тоже был мейнстримом… а потом пришёл JSON. Некоторые технологии таки успевают проплыть мимо, пока ты сидел на берегу, и это к лучшему.


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

                            Простите, но это либо тупой FUD, либо та самая конкретика, которую я от Вас пытаюсь услышать с самого начала: что конкретно в swarm может "постоянно идти не так", и какие конкретно реально нужные небольшим проектам вещи мы "не сможем сделать"?

                              0
                              > Откуда такая информация?

                              Анализ market shares разных оркестраторов, вероятно.
                              Я, правда, не смог быстро найти отчеты, в которых упомянут Swarm.
                                0
                                Нашел аналитику 17-го года: platform9.com/blog/kubernetes-docker-swarm-compared (секция «Takeaways»).
                                Уже тогда все было очень грустно, с тех пор лучше не стало.
                                  +1

                                  Да, по уровню популярности у swarm около 10%. НО.


                                  Во-первых, это довольно далеко от "swarm умирает" (у firefox примерно столько же, но он на умирающего тоже не сильно похож).
                                  Во-вторых, аналитика по google trends и SO показывает про что чаще задают вопросы, и нет ничего удивительного в том, что про намного более сложный k8s вопросов задаётся намного больше (только вот что в этом хорошего).
                                  В-третьих, оценка популярности — это далеко не единственно важный критерий при выборе используемой технологии.
                                  В-четвёртых мы уже не раз видели дико популярные технологии, в т.ч. захватывавшие 90+% рынка, и некоторые из них уже не с нами.


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

                                    0
                                    про намного более сложный k8s

                                    Я, все еще, не могу понять, чем именно он намного более сложный, точнее, что такое «намного». Объективно — более сложный, да, больше кодовая база, например. Субъективно — что то оркестратор, что это. Цели и задачи одни и те же, сказать, что в Kubernetes есть какие-то лишние сущности, я не могу. У системы контроля версий Mercurial тоже есть какая-то пользовательская база, но я не вижу никаких преимуществ перед Git (который, кажется, тоже «намного более сложный»), между Swarm и K8s разница того же порядка.
                                      +5

                                      Есть очень простое, измеримое определение сложности: время (в контексте этой дискуссии — кривая обучаемости). Сколько времени необходимо потратить на изучение новой технологии, чтобы просто начать ей пользоваться на среднем (достаточным для большинства в первые пару лет использования) уровне, и сколько времени необходимо для того, чтобы освоить систему на достаточно высоком (достаточном для того, чтобы можно было самостоятельно выявить и починить любую проблему в течении часа) уровне.


                                      Выход на средний уровень для mercurial занимал около часа, для git около пары дней. Выход на высокий уровень для mercurial — без понятия (у меня не возникало с ним проблем которые бы этого уровня требовали), для git — неделя. Абсолютное большинство разработчиков эту неделю "на git" не выделили, поэтому раз в несколько месяцев умудряются довести локальное репо до состояния, когда им проще его убить и склонировать начисто с нуля, чем понять в чём проблема и починить. Это вполне себе показатель излишней сложности инструмента.


                                      Если отойти от измеримых характеристик, то основное преимущество mercurial перед git в том, что UI mercurial оперирует сущностями/понятиями с точки зрения пользователя (что намного удобнее и всё упрощает), а UI git оперирует внутренними понятиями и подробностями реализации самого git (именно по этой причине всем кажется, что git checkout делает совершенно разные и не связанные между собой вещи — потому что они не связанные с точки зрения пользователя, а с точки зрения внутреннего устройства git эта команда делает только одну вещь).


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

                                        +2
                                        Подписываюсь под каждым словом. И при этом я бы не против иметь такой проверенный, надежный и мощный инструмент в своей копилке, как k8s. Но мне жалко своего времени пока что и может если я наткнусь на крутой интерфейс, где все будет понятно и просто, может тогда я тоже перескочу на k8s, но пока благодаря swarmpit я вообще не парусь и продолжаю набирать код, вместо возни с серверами и тупой их настройкой.
                                          +1

                                          Ну вот и я бы не против иметь в копилке k8s. По сути, я в данной дискуссии не столько защищаю swarm, как может показаться, сколько надеюсь, что оппоненты мне покажут, зачем реально лично мне необходим куб, чтобы я оправдал выделение значительного времени на его изучение. Но, увы, пока никто ничего конкретного мне так и не ответил.

                                          –3

                                          Не соглашусь:


                                          1) swarm high level за 4 часа? Вы просто не сталкивались с действительно серьёзными проблемами.


                                          2) "Сколько времени требует куб — я лично пока не выяснял, но судя по тому, что пишут абсолютно все — там другой порядок цифр"


                                          Не читал, но осуждаю!


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

                                            +4

                                            Я потратил около трёх месяцев чистого рабочего времени на перевод проекта с docker-compose в пару сотен строк на k8s с основной задачей упростить деплой и локальную разработку. Сейчас это несколько тысяч сырых строк. Я не уверен, что что-то реально полезное сделал для проекта. Вернее, что не мог бы достигнуть лучшего результата с swarm, потратив в разы меньше времени и сэкономив порядка 10000 usd только на своей зп.

                                              +1

                                              Страшные вы истории рассказываете.


                                              Более 500 часов уже зная Swarm потратили на изучение и переезд на K8s?
                                              Без обид, но судя по всему действительно не стоило этим заниматься с такой эффективностью.


                                              Или вы свой проект параллельно переписывали, а не "просто переводили его со Swarm на K8s".


                                              Было/стало, если можно, в студию.

                                                0

                                                Перечитал ваше сообщение и увидел, что проект был на docker-compose, а это не Swarm. Compose не оркестратор, со всеми вытекающими из этого выводами, поэтому вполне допускаю, что в принципе осваивая концепцию оркестра, который занимается в том числе автоматическим поднятием нод по необходимости ресурсов сервисам и т.д. и т.п. вы потратили действительно очень много времени.


                                                Но речь тут именно о Swarm > K8s, а не Compose > K8s.


                                                Хотя я присутствовал в команде, где разработчики вообще не разрабатывали в docker и за примерно ваше время (3 месяца) успешно перешли на разработку и выкатку именно в кубер, с добавлением куда нужно переменных и необходимых сервису ресурсов.

                                                  +2

                                                  Я, зная Swarm, пришёл на проект, где был docker-compose в продакшене, но уже было принято решение о переезде на k8s, которым я и занялся, как единственный человек, хоть с чем-то сложнее docker-compose работавший.


                                                  Итоговое решение функционально оказалось проще, чем я реализовывал на swarm (в частности тут фиксированное число сред, без динамического создания на каждую ветку для демо и тестов), но вот "кода" оказалось заметно больше на примерно то же количество сервисов (считая поды с, например, nginx+php-fpm за два сервиса в docker-compose/swarm). В том числе пришлось выбирать между написанием своего шаблонизатора и добавлением в проект Helm и helmfile из-за того, что k8s не поддерживает интерполяцию переменных окружения. kustomize не осилил, да. Выбрал Helm+helmfile, что внесло ещё заметную долю сложности. Minikube для локальной разработки сложнее, чем docker swarm оказался. Документация k8s хуже организована с точки зрения версионирования.


                                                  Плюс, не совсем в сторону k8s минус, а в сторону managed кластеров — кластеры docker swarm у меня были под прямым управлением, или сам что-то менял, или админов просил. С managed это сложнее, в некоторых настройках или просьбах что-то обновить просто отказали или запросили адский ценник, пришлось искать костыли для обхода типа демонсетов пишуших в sysctl. Ну и по мелочи типа требования какое-то время поддерживать старый прод на docker-compose как fallback с синхронизацией файлов онлайн.


                                                  Ну и активная разработка самого продукта не останавливалась.


                                                  P.S. видимо разное имеем в виду под оркестраторами, я про оркестратор контейнеров. docker-compose оркестрирует контейнеры в пределах одного хоста, docker swarm и k8s позволяют делать это в пределах кластера из нескольких нод.

                                          +3

                                          У k8s более 50 типов сущностей из коробки, просто разобраться какие тебе нужны, а какие нет на конкретном проекте, может занять неделю и более

                                  +1

                                  Ладно разработчики или девопсы стараются проташить ради "строчки в резюме", так вот недавно релизнули ь первый раз в к8с и это было бизнес-требование, типа не солидно предлагать SaaS без k8s

                                  +1

                                  Про Swarm вы говорите про Docker Swarm или Docker in swarm mode?

                                    0
                                    А какая кстати разница?
                                      +1

                                      Docker Swarm, ещё называемый Docker Swarm standalone — первая реализация кластера для докера от команды докера. Сейчас вроде уже не поддерживается. Работает независимо от докер-демона, просто оркестриует в нём контейнеры, для демона просто клиент.


                                      Docker swarm mode — с какой-то достаточно древней по нынешним временам версии, режим работы обычного докер-демона в режиме кластера. Актуально и потихоньку развивается.

                                        0
                                        Понял, ну видел, что первый вроде уже года 3 висит без обновлений, поэтому думаю его вообще можно не учитывать
                                          +1

                                          Я так, уточнил на всякий случай, чтобы не получилось как c PHP, когда люди, работавшие с ним в последний раз в 4 версии, рассуждают о его недостатках в контексте восьмой :)

                              0
                              Я как-то перезапустил сервис Docker на доставшемся мне в наследство Swarm-кластере.
                              Моментально попадали все сервисы, которые были в Swarm.
                              Не знаю, ожидаемое это поведение или нет. В Kubernetes надо долго трудиться, чтобы получить похожий результат. При настройках по умолчанию подобное там невозможно.
                                0

                                Нет, не ожидаемое. Но если после перезапуска запустилась более новая версия докера — тогда всё может быть, надо сначала читать доки как корректно обновлять узлы кластера (и это касается абсолютно любого кластерного сервиса, у всех свои заморочки, и swarm тут ничем не выделяется). Ещё, наверное, возможны проблемы если узлов было два, и один перезапустился — но это тоже штатная беда всех кластерных сервисов, поэтому и рекомендуется запускать нечётное количество узлов.

                                  0
                                  Узлов было три, иначе кворума не будет.
                                  Версия докера не менялась.
                                  В Kubernetes, кстати, можно выключить вообще все мастеры, и поды останутся работать.
                                  +1

                                  У меня как-то рухнул локальный minikube кластер, где-то прав не хватило. Я полдня вычищал систему от его остатков, чтобы запустить с нуля.

                                    +1
                                    с кубером проще, как-то сдохла нода, обнаружили через полгода только.
                                    Берешь чистый хост и деплоишь новую.
                                  +1

                                  Мне понравилось две фичи k8s: поды и ингрессы "из коробки". Но не уверен, что их удобство компенсирует сложность. Тем более, что из-за нужд проекта, ингресс сводится к прописыванию доменов для неймспейса, а дальше рулит обычный nginx, типа api gateway.

                                  +1

                                  Какая разница под ранчером k8s или нет? Если всё равно надо писать километровые yaml.

                                  0
                                  Сам раньше пользовался Swarm, правда с Portainer. Но k8s все же лучше.
                                  Как минимум, сварм не учитывает доступные ресурсы при запуске сервисов.

                                  Плюс, если заходите переехать в облако, то Swarm-а в облаках нет вообще. А k8s практически везде, хоть и с небольшими изменениями.

                                  Поднять k8s можно на обычных vds-ках тем же rancher с пол пинка. Если что-то отвалилось, удаляете и ставите заново, никаких проблем, специально ломал и тестировал.
                                    0
                                    Плюс, если заходите переехать в облако, то Swarm-а в облаках нет вообще.


                                    Можно подробнее?

                                    заходите переехать в облако


                                    Что вы имеете в виду? Нет кнопки «развернуть swarm»?
                                      0
                                      Готового swarm кластера нигде не видел. Но его поднять дело 2х команд
                                        0
                                        Ну по хорошему суть сварма, как и k8s в использовании нескольких машин одновременно. Облака GKE, AWS, Azure предлагают готовые кластеры k8s с поддержкой автоматического выделения мощностей, своих стораджей и пр.

                                        Для Сварма такого нет. Само-собой, вы можете купить десяток серверов и самостоятельно там все поднять. Я так на k8s работаю, т.к. это сильно дешевле.
                                        Но с k8s при возникновении необходимости, я могу довольно быстро переехать в любое облако, а во из Сварма вы будете переезжать несколько больнее.
                                          +1
                                          Интересно, в чем конкретно будет боль переезда (если исключить вопросы автомасштабируемости)?
                                            +1
                                            У меня со свармом не сложилось на нескольких машинах.

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

                                            Потом перешел на сварм, попробовал добавить еще нод, но оно как-то странно себя вело при сбоях. А при добавлении ноды из другого датацентра — вообще хаос, пару часов не мог поднять. Вроде должна быть отказоустойчивость, в итоге получаешь только кучу проблем. Остался на одном большом сервере со свармом (ибо уже перешел, ну и сервисы лучше компоса восстанавливаются после сбоев).

                                            Еще в сварме не работали readness/liveness пробы. Они вроде есть, вроде все создается, но не работает. Разбираться сложно, т.к. свармом фиг кто пользуется.

                                            Потом еще понадобилось взаимодействие с АПИ сварма из приложения для запуска задач. И решил до кучи перейти на k8s, т.к. работает куда стабильнее (специально около месяца пробовал как что, пробовал все ломать, крушить, смотреть как поднимется) и есть возможность стучаться в АПИ из любого языка.

                                            Автомасштабированием я не пользуюсь, т.к. все крутится на обычных серверах, оно там по сути и не будет работать, т.к. новые машины из воздуха не появятся. А просто накидывать число реплик я и так могу.
                                              0
                                              А у кого запускали сервера, если не секрет?

                                              Я пока тестировал на небольших приложениях со скейлингом и лоад балансингом между нодами на разных дроплетах в DO. Там они общаются по приватной сети и вроде все очень шустро работает. Хочу попробовать перевезти более нагруженные системы, т.к. скорость и удобство пока радуют. Если не выйдет, то видимо пора будет серьезно осваивать k8s
                                                0
                                                Именно тестировал k8s: GKE, AWS, Azure. Из наших Selectel, Mail.ru
                                                Отдельные сервера: FirstVDS, Vscale, тот же Селектел, RuWeb

                                                Из облаков GKE круче всех. Банально потому что там можно удобно создавать машины разных конфигураций в одном кластере. В других либо я не нашел как, либо вовсе нельзя. А, ну еще там нет платы за мастера. Мастеров там по сути как бы нет, вы их не видите, что очень удобно. В том же AWS мастера обходятся как неплохой сервер, хотя 90% проектам оно нафиг не сдалось.

                                                Селектел на тот момент ломал кластер при масштабировании и где-то за неделю проблему они не решили, а я на них забил. Но у них очень классные технические параметры машин, все очень шустро.

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

                                                Яндекс ничем не выделяется, а на тот момент и вовсе был в закрытой бете, кажется.

                                                В целом это все довольно дорого. Если у вас реально нет потребности в авто-выделении новых нод, то в 99% случаях облака не пригодятся и проще сделать парк VDS.
                                                В зарубежных облаках еще есть плата за трафик, что иногда очень и очень критично.

                                                Якобы проблема со стораджами на bare-metal, как по мне, больше надумана адептами «А вдруг нода сломается». Если у вас не реальное облако, то забейте на это все.

                                                Сейчас остановился на Ruweb, порядка 10 машин в кластере. И VDS и железо. Пробовал подключать к этому парку ноды из VScale (это другой ДЦ) — все круто.

                                                Очень много могу рассказывать про k8s, докер и разработку вот-этого-всего, т.к. свой проект уже 2.5 года на нем веду, как работа 24/7.
                                                  0
                                                  Было бы круто, если бы Вы написали статью на эту тему, хотя бы в общих чертах.
                                                  Я честно пока не могу выделить столько времени и терпения на k8s. Docker и Swarm очень легко дались и пока с ними вроде все ок, но дальше уж очень больно нырять пока что
                                                    0
                                                    Не, спасибо, я не особо писатель :) Да и загрызут меня представители наших хостеров, т.к. ничего хорошего я про них не скажу, увы.
                                                  0
                                                  В целом я тестировал именно «А что будет если я что-то прибью».
                                                  Что-то это либо система, либо какая-то нода, причем иногда нормальным ребутом, иногда прям в жесткую.

                                                  С GKE/AWS/Azure проблем в этом плане нет. Там вот очень классно. С российскими облаками постоянно какой-то треш, да простят меня сотрудники Яндекса/Маила/Селектела.
                                                0
                                                А при добавлении ноды из другого датацентра — вообще хаос, пару часов не мог поднять.


                                                Не ubuntu 18, часом, пользовали? У нас была проблема со схожим описанием, выяснилось, что шифрованные сети работают только с версией 16.04.x (kernel > 4.4).

                                                Правда, не совсем непонятно, как это все относится к переезду между облаками… :)
                                                  0
                                                  Давно это было, уже не помню. Но обычно использую Debian/Ubuntu, да. Может быть и так. Помню что там все адски зависло и я долго не мог просто достучаться хоть куда-то. не срослось у меня со свармом.

                                                  К переезду именно это не относится.

                                                  Ну, вы попробуйте, а там расскажете. И параллельно попробуйте k8s.
                                                  Я тоже долго не мог понять в чем же разница. А разница в меньшем числе проблем, все просто :)
                                                    0
                                                    Swarm мы уже год как используем, правда, пока для разработки только. Особенных проблем не замечали, тестовые кластеры многократно «поднимали» с нуля за десяток минут (считая со времени старта всех чистых VDS).
                                                      0
                                                      Я с ним работал последний раз почти год назад, наверное. Так что могло что-то и улучшиться.

                                                      Попробуйте поронять ноды, уронить мастер, заблокировать сеть у ноды, разделить кластер на две группы. У меня он такие тесты не проходил, увы.
                                                        0
                                                        Вспомнил. Еще интересный глюк был, когда какой-нибудь сервис внезапно выпадал из сети и становился недоступен для всех остальных.

                                                        До сих пор не знаю почему так получалось, но это было больно, потому как Сварм считает, что все ок и не стремится его перезапустить. Хотя иногда надо было именно удалить и создать заново.

                                                        Еще сварм не умел не-обновлять не-изменившиеся сервисы. YML файл один, внутри изменился только один сервис. А перезапускается вообще все.
                                                        Потом он вроде как научился, но как-то через раз. И опять же — гадай почему.
                                                          0

                                                          Первое возможно было вызвано https://success.docker.com/article/ipvs-connection-timeout-issue

                                                            0
                                                            Нет, это были сервисы на одной ноде.
                                                              0

                                                              Так это касается сервисов и на одной ноде, насколько я понимаю — если они работают через ту же оверлейную сеть, что и между нодами (а обычно это именно так).

                                                                0
                                                                Ну, ладно, может быть. Суть в том, что оно создавало проблемы из коробки. С k8s мне лично повезло больше.
                                          0

                                          Сворм практически мертв. Это видно по количеству багов/фичец в каждом рилизе.


                                          Попробуйте поднимать кубер через терраформ — синтаксически это не так вырвиглазно чем бесконечные ямлы, да и проверка синтаксиса будет, и не понадобится изучать вмякие кощенитские приблуды типа Helm (хотя в третьей версии они уже приблизились к тому что делает терраформ)

                                            +1

                                            Новичкам проще с Rancher или GKE начинать, там вообще в gui можно всё поднять за пару минут без кода.


                                            Дальше берёте связку gitlab + gke, по мануалам Gitlab делаете базовую настройку и спокойно ведёте разработку.
                                            В такой связке Gitlab позволяет получить дополнительные 200$ к 300$ дающимся новым аккаунтам самим Google, а 500$ это вполне себе ощутимая цифра.
                                            И не как на AWS счёта выставляются, а по-моему гораздо более предсказуемо и внезапно большие цифры как на AWS не прилетают, да и выше $500 просто так с меня не начали снимать, что особо порадовало.


                                            Если ещё и preemptible нодами научитесь пользоваться, то этих 500 на небольших проектах может ооочень надолго хватить.

                                              0
                                              Третий день жду эти +200
                                              Их вообще хоть кто-то глазами видел вживую? Или может их не дают левым людям с улицы?
                                                0

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

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

                                          Самое читаемое