Настройка Docker Swarm: оркестрация контейнеров без Kubernetes

Docker Swarm: что ломается при ручном управлении контейнерами

Когда сервисы поднимают вручную, каждый запуск — это docker run по SSH или docker compose up на конкретной машине. Рестарт-политика задана не везде, поэтому упавший процесс просто остаётся лежать: контейнер есть в списке, порт слушается кем-то другим или никем, а узнаёте об этом из обращений пользователей, а не из мониторинга. Заодно теряется инвентарь — на каком узле что живёт и какая ревизия образа крутится, помнит только тот инженер, который это запускал.

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

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

Docker Swarm даёт ровно те примитивы, которых не хватает при ручном управлении контейнерами — декларативное описание сервиса, заданное число реплик, перезапуск упавших задач и перенос их с выбывшего узла. Дальше разбираем, как это закрывается на практике: что настраивается до первого docker stack deploy, где узкие места и как проходит обновление без окна недоступности.

Что даёт оркестрация контейнеров: эффект в эксплуатации

Служба описывается декларативно: сколько реплик держать, какие лимиты по процессору и памяти, чем проверять живость. Дальше оркестратор сам поддерживает это состояние — упавший контейнер перезапускается, а задача с выпавшей ноды переезжает на свободную. Класс отказов «сервис лежит, пока дежурный не заметит» исчезает из эксплуатации целиком.

Время восстановления сокращается с десятков минут до секунд. Раньше оповещение будило инженера, тот заходил на сервер и поднимал процесс руками; теперь перезапуск и переразмещение идут автоматически, а проверка живости не пускает трафик в ещё не готовый контейнер. Простой на плановых работах тоже уходит: обновление катится по одной реплике, остальные продолжают обслуживать запросы.

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

Нагрузка на серверы становится предсказуемой: лимиты и резервирования не дают одному сервису выесть ресурсы соседей, а размещение по меткам разводит тяжёлые задачи по разным машинам. Мы собираем это на Docker Swarm — оркестрация не тянет за собой отдельный слой абстракций и обслуживается той же командой, что и сами сервисы.

Варианты развёртывания кластера: сравнение подходов

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

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

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

Порядок внедрения: от аудита до передачи в эксплуатацию

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

1. Аудит инфраструктуры — инвентаризируем сервисы, зависимости, точки хранения данных и секретов, доступные узлы и каналы связи. Фиксируем узкие места: единственный узел под пиком, ручные правки конфигураций, отсутствие копий состояния кластера.
2. Проектирование схемы кластера — определяем число управляющих и рабочих узлов, кворум, разнесение по зонам, внутренние сети и правила доступа между сервисами. Согласуем, что именно должно пережить отказ узла, а что — отказ зоны.
3. Настройка сервисов — описываем службы: число реплик, ограничения по ресурсам, проверки состояния, порядок поочерёдного обновления и возврата на прошлую версию. Конфигурации и секреты держим вне образов, чтобы среда поднималась одинаково на любом узле.
4. Проверка отказоустойчивости — намеренно выводим узлы из обслуживания, гасим управляющий узел, рвём связь между зонами, даём пиковую нагрузку. Смотрим, восстанавливаются ли реплики сами и сколько занимает возврат в норму.
5. Обучение команды — показываем вашим инженерам штатные операции: выкат версии, откат, масштабирование, чтение состояния кластера, разбор инцидента. Отдаём регламенты, чтобы типовые задачи решались без нас.
6. Передача в эксплуатацию — отдаём конфигурации, схему, политики резервного копирования и мониторинга, инструкции по восстановлению. Первый плановый выкат проходим вместе с вашей командой и закрываем работы по чек-листу.

Что остаётся у вашей команды: конфигурации и регламенты

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

• Файлы конфигурации: манифесты стека со всеми сервисами, сетями, томами и метками размещения — развёртывание одной командой.
• Схемы: топология кластера, роли менеджеров и воркеров, точки входа трафика и связи с внешним хранилищем состояния.
• Политики доступа к реестру образов: кто публикует теги, какие образы считаются проверенными, как ограничено чтение с рабочих узлов.
• Регламент обновления и отката: порядок выката сервиса, проверка готовности, условия остановки и возврат на прошлую версию без простоя.
• Инструкции для дежурной смены: что смотреть при недоступности сервиса, как вывести узел из ротации и как передать смену.
• Документация по резервному копированию: что именно сохраняется и как проверяется восстановление кластера на чистой площадке.
• Карта мониторинга: какие метрики и оповещения заведены на сервисы, кому они приходят и на что реагировать в первую очередь.
• Чек-листы приёмки: набор проверок после правки конфигурации, чтобы изменение не ушло в рабочую среду непроверенным.

Кейс: как сократили простой службы доставки после сбоя узла

Заказчик — региональная служба доставки с собственной диспетчерской системой: приём заказов, распределение курьеров и трекинг. Приложение жило на двух серверах, развёртывание шло вручную по инструкции: остановить службу, обновить файлы, поднять заново, проверить логи. Пока инженер не завершал проверки, часть заказов не принималась.

Что показывали замеры до перехода

Падение одного узла останавливало приём заказов на 40-50 минут: дежурный поднимал службу руками, сверяя конфигурацию по заметкам в репозитории. Выпуск обновления занимал около получаса рутинных шагов, а мелкие расхождения между серверами приводили к 8-10 ручным вмешательствам в неделю — от правки переменных окружения до перезапуска зависших процессов.

Что изменили

Собрали кластер на Docker Swarm из трёх узлов и перевели приложение в контейнеры с одинаковым описанием окружения. Роли распределили так, чтобы управляющие узлы оставались в кворуме при потере одного из них, а рабочие несли нагрузку. Сервисы получили health-check и правило перезапуска: упавшая задача перепланируется на живой узел без участия человека. Обновления выпускаем через rolling update — по несколько реплик за раз, с ожиданием готовности и автооткатом на предыдущий образ, если проверки не прошли. Реестр образов чистим по правилу хранения последних сборок.

После перехода простой при отказе узла сократился до 20-40 секунд — трафик перехватывают реплики на живых узлах. Выпуск обновления занимает 3-4 минуты и не требует остановки приёма заказов, а число ручных вмешательств снизилось до одного-двух в неделю: в основном плановые работы. Время от коммита до работающей версии в кластере сократилось с нескольких часов ожидания окна до одного прохода выпуска.

Чем Docker Swarm отличается от Kubernetes и когда он уместен

Разница не в том, какой оркестратор «мощнее», а в цене сопровождения. Docker Swarm — часть движка контейнеризации: кластер собирается из нескольких узлов одной командой, сервисы описываются декларативно (образ, число реплик, правила размещения), а состояние управляющих узлов реплицируется между ними. Kubernetes — отдельная платформа с расширяемой моделью API, своим планировщиком и большим набором расширений; её нужно ставить, обновлять и обслуживать как самостоятельную систему.

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

Отсюда критерий выбора. При 3-10 узлах, однородных сервисах без локального состояния и отсутствии отдельной команды на платформу Swarm даёт оркестрацию встроенными средствами. Если сервис один, оркестратор не нужен вовсе — достаточно файла Compose и системного юнита автозапуска. Kubernetes оправдан там, где кластер делят несколько продуктовых команд, нужны операторы баз данных и автомасштабирование под пиковую нагрузку.

Мы начинаем с карты сервисов и профиля нагрузки: где живёт состояние, как часто релизы, какой простой допустим. По этим данным видно, где оркестратор избыточен, а где экономия на нём обернётся ручным дежурством.

Технические сомнения: отказоустойчивость, обновления, откат

Отказоустойчивость в Docker Swarm держится на кворуме управляющих узлов: пока их большинство, кластер сохраняет состояние и продолжает планировать задачи. Ниже — ответы на сомнения, которые чаще всего звучат перед запуском.

Как обновление проходит без простоя?

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

Как откатить неудачный релиз?

Образы версионируются, поэтому возврат — это запуск предыдущей версии сервиса, а не пересборка из исходников. Настраиваем автоматический откат при провале проверок и репетируем сценарий на стенде, чтобы возврат занимал минуты.

Что входит в поддержку кластера после запуска?

Наблюдение за узлами и сервисами, обновление самого движка, ротация доступов, резервные копии состояния кластера и разбор инцидентов. Плюс плановые проверки: гасим узел и смотрим, как кластер отрабатывает потерю.

Обсудим задачу: что уточним до начала работ

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

• Где размещаются сервисы: собственные серверы, частное облако или несколько площадок, насколько устойчива связь между ними.
• Какие требования к простою: допустимо ли короткое прерывание при обновлении или нагрузку нужно переносить без остановки.
• Как устроено хранение данных: где лежат базы и состояния, нужна ли репликация и резервные копии между узлами.
• Как выпускаются обновления: сколько окружений, кто запускает раскатку, нужна ли автоматизация сборки образов и отката на прошлую версию.
• Как распределены доступы: кто управляет кластером, нужны ли журнал действий и разделение ролей.
• Кто сопровождает систему дальше: своя команда или подрядчик, какой объём документации нужен для передачи.
• Что уже работает: действующая конфигурация, прошлые попытки, окна, в которые можно вносить изменения.

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