swarm кластер что это такое
Кластер Docker Swarm за 30 секунд
В этом июне, в качестве лейтмотива конференции DockerCon мы видели демо, в котором 3-узловой Swarm-кластер был создан за 30 секунд используя набор инструментов для кластеризации Swarm, интегрированную в Docker Engine 1.12.
Впечатляет, но естественно, мне нужно было попробовать сделать это самому, чтобы увидеть своими глазами.
Создание узлов в вашем Swarm
Я нашел самый простой путь. Для начала работы со Swarm (Роем) использовать docker-machine. Для создания хостов с установленным на них Docker Engine я использовал драйвер virtualbox’а, но вы можете использовать любой драйвер который вы хотите, например amazonec2.
Инициализация вашего менеджера
Присоединение воркеров (workers)
Скопируйте команду, отображенную ниже для первого узла из ваших воркеров, чтобы присоединить его к кластеру.
Теперь у вас есть Swarm-кластер!
Давайте что-нибудь развернем (deploy)
Первоначально мы хотим создать сеть верхнего уровня (оверлейную сеть), чтобы развернуть наше приложение.
До Docker Engine 1.12 оверлейные сети требовали внешнего хранилища ключ/значение, но с созданием распределенного хранилища в Docker 1.12 это больше не требуется.
Давайте развернем простое приложение Apache на публичном порту 5001. Я использую специальный образ Apache, найденный мной на DockerHub, который выводит ID контейнера, обслуживающего запрос. Позже это будет использовано для демонстрации балансировки нагрузки.
Вы можете использовать следующие команды, чтобы проверить ваш новый сервис:
Сетка маршрутизации
Добавления сетки маршрутизации и децентрализованной архитектуры в Docker 1.12 позволяет любым узлам-воркерам в кластере маршрутизировать (направлять) трафик к другим узлам.
В нашем веб-сервисе, (описанном выше) мы открыли кластерный (cluster-wide) порт 5001. Вы можете послать запрос на любой узел на порт 5001, и сеть маршрутизации направит запрос на тот узел, который запустил контейнер.
Балансирование нагрузки
Всегда когда создается новая служба, виртуальный IP создается вместе с этой службой. IPVS владеет (осуществляет) балансировкой нагрузки, высокопроизводительным уровнем 4 балансирования нагрузки, который встроен в ядро Linux.
Чтобы показать это, запустим curl несколько раз, для демонстрации изменение ID контейнера.
Балансировка нагрузки при помощи Docker 1.12 является контейнер-осведомленной (container-aware). Хост-осведомленная (host-aware) балансировочная система, такая как nginx или haproxy, удаляет или добавляет контейнеры требуемой конфигурации обновления балансирования нагрузки и перезапуска этих сервисов. Существует полезная библиотека, называемая Interlock, которая прослушивает Docker Events API и обновляет конфигурацию/осуществляет перезапуск сервиса “на лету”. Но этот инструмент больше требуется после нового добавления балансирования нагрузки в Docker 1.12.
Это не может быть так просто…
Эта картинка из Nigel Poulton очень хорошо обобщает различия между старым Swarm и новым Swarm.
Перевод картинки:
Старый путь (много шагов и команд не показано)
Новый путь
С Docker 1.12 вы также как и раньше можете инсталлировать внешние распределенные службы (consul, etcd, zookeeper), или отдельную службу планирования. Настройка TLS сквозная из коробки, нет “незащищенного режима”. У меня не существует никаких сомнений, что новый Docker Swarm является самым быстрым путем для получения запущенного и работающего docker-native кластера, готового быть развернутым в продакшн.
А что насчет большого масштабирования? Спасибо усилиям “капитана” Docker’a Chanwit Kaewkasi и DockerSwarm2000, они показали нам, что вы можете создать кластер из 2384 узлов и 96287 контейнеров.
Режим Swarm является самым оптимальным
Включать режим Swarm совершенно необязательно. Вы можете думать о режиме Swarm, как о наборе скрытых процедур, которые запускаются всего лишь командой
Swarm в Docker’е 1.12 также поддерживает согласования, плавающие обновления (rolling updates) образа, глобальные сервисы и сервисы по расписанию, базирующиеся на ограничениях.
Отказ узла в Docker Swarm
Также хочу затронуть тему отказа узлов в Docker Swarm. Команды, относящиеся к сервисам Docker Engine 1.12, являются декларативными. Например, если вы задаете команду «Я хочу 3 реплики данного сервиса», то кластер будет поддерживать это состояние.
В случае отказа узла контейнеры которого были задействованы, swarm обнаружит, что желаемое состояние не совпадает с действительным и автоматически исправит ситуацию путем перераспределения контейнеров на другие доступные узлы.
Чтобы это продемонстрировать, давайте зададим новый сервис с тремя репликами.
Запустите, чтобы проверить работу сервиса
Сейчас у нас есть по одному контейнеру на каждом из узлов. Давайте выведем из строя узел 3, чтобы посмотреть на регулирование swarm в действии.
Теперь желаемое состояние не совпадает с действительным. У нас есть только 2 действующих контейнера, тогда как мы обозначили 3 контейнера, когда запускали сервис.
Использование докер сервиса дает вам возможность увидеть, что количество реплик уменьшилось до двух, а затем снова вернулось к трем
docker service tasks web покажет вам новый контейнер, назначенный на другом узле вашего кластера.
Этот пример показывает только регулирование контейнеров на рабочих узлах. Совершенно другой процесс происходит, когда из строя выходит менеджер, особенно, если это лидер raft группы для решения задач консенсуса.
Глобальные сервисы
Глобальные сервисы полезны, когда вы хотите создать контейнер на каждом узле вашего кластера. Подумайте о ведении протокола или мониторинге.
Помните, я говорил, что сервисы являются декларативными? Когда вы добавляете новый узел к вашему кластеру, swarm определяет, что желаемое состояние не совпадает с действительным, и запускает экземпляр глобального контейнера на этом узле.
Ограничения
Для демонстрации ограничений я использовал докер машину, чтобы ускорить новую машину с помощью engine label.
Затем я добавил ее в swarm.
Далее я создал сервис, ссылающийся на это ограничение.
Помните, я говорил, что сервисы являются декларативными? 😉 Это означает, что, когда мы масштабируем этот сервис, он запоминает наши ограничения и масштабирует только отвечающие условиям узлы.
John Zaccone
Docker Captain и Software Engineer в Ippon Technologies, который любит вбрасывать вещи на рынок побыстрее. Специализируется на agile, микросервисах, контейнерах, автоматизации, REST, devops.
Чем полезен Docker Swarm и в каких случаях лучше использовать Kubernetes
Технология контейнеризации позволяет запускать приложения в отдельных независимых средах — контейнерах. Они упрощают развертывание приложений, изолируют их друг от друга и ускоряют разработку. Но когда контейнеров становится слишком много, ими трудно управлять. Тут на помощь приходят системы оркестровки.
В статье разберем, чем может быть полезен Docker Swarm и в каких случаях стоит присмотреться к более продвинутым решениям.
Что такое Docker Swarm и чем он может быть полезен
При построении крупной продакшн-системы в нее обязательно закладывают требования по отказоустойчивости, производительности и масштабируемости. То есть система должна быть защищена от сбоев, не тормозить и иметь возможность для увеличения мощности.
Обычно для этого создают кластер — отдельностоящие хосты (серверы) объединяют под общим управлением, со стороны это выглядит как единая система. При этом она намного устойчивее к сбоям и производительнее:
При работе с контейнерами эти задачи решают системы оркестровки. Оркестровка — это управление и координация взаимодействия между контейнерами. Контейнеры запускаются на хостах, а хосты объединяют в кластер.
У Docker есть стандартный инструмент оркестровки — Docker Swarm Mode, или просто Docker Swarm. Он поставляется «из коробки», довольно прост в настройке и позволяет создать простой кластер буквально за минуту.
Кластер Swarm (Docker Swarm Cluster) состоит из нод, которые делят на два типа:
Схематичное устройство кластера Docker Swarm: три управляющих ноды и семь рабочих. Источник
В Docker Swarm вместо прямого использования контейнеров используются сервисы (Docker Swarm Service). Они похожи на контейнеры, но всё же это немного другое понятие.
Сервис — это что-то вроде уровня абстракции над контейнерами. В Swarm мы не запускаем контейнеры явно — этим занимаются сервисы. Для достижения отказоустойчивости мы лишь указываем сервису количество реплик — нод, на которых он должен запустить контейнеры. А Swarm уже сам проследит за тем, чтобы это требование выполнялось: найдет подходящие хосты, запустит контейнеры и будет следить за ними. Если один из хостов отвалится — создаст новую реплику на другом хосте.
Что такое Kubernetes и в чем его преимущества перед Swarm
Кроме стандартного Docker Swarm есть и другие инструменты оркестровки, например Kubernetes. Это сложная система, которая позволяет построить отказоустойчивую и масштабируемую платформу для управления контейнерами. Он умеет работать не только с контейнерами Docker, но и с другими контейнерами: rkt, CRI-O.
У Kubernetes довольно много возможностей, которые позволяют строить масштабные распределенные системы. Из-за этого порог вхождения в технологию гораздо выше, чем в Swarm. Нужно обладать определенным уровнем знаний, а на первоначальную установку и настройку может уйти несколько дней.
Если смотреть глобально, то устройство Kubernetes похоже на Swarm. Кластер состоит из двух типов нод: главной (Master) и рабочих (Worker):
Но если смотреть глубже, то устройство Kubernetes гораздо сложнее. В нем отдельные модули, например: proxy-балансировщик, etcd для хранения состояния кластера и другие компоненты. Не будем подробно всё это описывать. Достаточно понять, что Kubernetes устроен гораздо сложнее, чем Docker Swarm.
Глобально Kubernetes похож на Swarm. Но внутри все гораздо сложнее. Источник
Так зачем нужен Kubernetes со своими сложностями, когда уже есть «родной» и простой Docker Swarm?
Дело в том, что Kubernetes позволяет решать задачи, которые не под силу Docker Swarm. Для примера возьмем автомасштабирование: это когда система сама подстраивает свою мощность под нагрузку. Для этого в кластер автоматически добавляются/удаляются ноды, либо в существующих нодах для «тяжелых» задач будет выделяться больше/меньше ресурсов.
Но если система умеет масштабироваться, она отреагирует на возросшую нагрузку и увеличит ресурсы для этих задач. А когда нагрузка спадет, снова освободит эти мощности. Если кластер размещен в облаке, автомасштабирование сильно экономит деньги. В моменты простоя неиспользуемые ресурсы освобождаются, и за них не нужно переплачивать.
Так вот, в Kubernetes можно настроить автомасштабирование. Да, придется написать конфигурационный файл и выполнить другие настройки, но в результате вы получите рабочую и стабильную систему. А если развернуть кластер в облаке, которое поддерживает автомасштабирование, то на настройку уйдет всего несколько минут.
Docker Swarm не умеет делать этого «из коробки». Можно построить автомасштабируемую систему с использованием Swarm. Но для этого придется вручную писать скрипты или программы, которые будут следить за нагрузкой, принимать решения и посылать команды в Docker Swarm. Либо можно использовать сторонние разработки, вроде Orbiter, но его возможности тоже ограничены, и в любом случае это еще одна дополнительная надстройка над Swarm.
Теперь представьте, что кроме автомасштабирования у вас есть другие задачи, для которых приходится городить кучу инструментов над Swarm. Всё это нужно поддерживать, понимать как оно работает и тщательно тестировать при обновлениях. В Kubernetes такие сложности спрятаны внутри, и они стабильно работают.
Краткое введение в Docker Swarm mode
Docker — прекрасен. С ним можно упаковать приложение по контейнерам, забросить их на случайный хост, и всё будет просто работать. Но на одном хосте особо не отмасштабируешься. Да и если хост прикажет долго жить, всё приложение отправится на тот свет вместе с ним. Конечно, для масштабирования можно завести сразу несколько хостов, объединить их при помощи overlay сети, так что и места больше будет, и возможность для контейнеров общаться останется.
Но опять же, как всем этим управлять? Хосты всё ещё могут отмирать. Как быстро определить, какой именно? Какие контейнеры на нём были? Куда теперь их переносить?
Начиная с версии 1.12.0 Docker может работать в режиме Swarm («Рой». В старых версиях был просто Docker Swarm, но тот работал по-другому), и потому способен решать все эти проблемы самостоятельно.
Что такое режим Swarm
Docker в Swarm режиме это просто Docker Engine, работающий в кластере. Кроме того, что он считает все кластерные хосты единым контейнерным пространством, он получает в нагрузку несколько новых команд (вроде docker node и docker service ) и концепцию сервисов.
Сервисы — это ещё один уровень абстракции над контейнерами. Как и у контейнера, у сервиса будет имя, базовый образ, опубликованные порты и тома (volumes). В отличие от контейнера, сервису можно задать требования к хосту (constraints), на которых его можно запускать. Да и вообще, сервис можно масштабировать прямо в момент создания, указав, сколько именно контейнеров для него нужно запустить.
Но важно понимать одну большую разницу. Сама по себе команда docker service create не создаёт никаких контейнеров. Она описывает желаемое состояние сервиса, а дальше уже Swarm менеджер будет искать способы это состояние достигнуть. Найдёт подходящие хосты, запустит контейнеры, будет следить, чтобы с ними (и хостами под ними) всё было хорошо, и перезапустит контейнер, если «хорошо» закончится. Иногда желаемое состояние сервиса так и не будет достигнуто. Например, если в кластере закончились доступные хосты. В таком случае сервис будет висеть в режиме ожидания до тех пор, пока что-нибудь не изменится.
План на сегодня
Будем играться. Пользы от абстрактной и непонятной теории — ноль, так что создадим-ка свой собственный уютный Docker кластер на три виртуальные машины. Запустим в нём один сервис для визуализации кластера, и ещё один, например web, чтобы масштабировался и заодно демонстрировал, как он успешно восстанавливается от внезапно упавшего хоста.
Что понадобится
Нам понадобится установленный Docker версии 1.12.0 и новее, docker-machine и VirtualBox. Первые два обычно устанавливаются вместе c Docker Toolbox на Маке и Windows. На Linux, ЕМНИП, docker-machine устанавливается отдельно, но всё ещё достаточно понятно. С установкой же VirtualBox проблем вообще не бывает. Обычно.
Я буду использовать Docker 17.03.1-ce для Mac и VirtualBox 5.1.20
Шаг 0. Создаём три виртуальные машины
Создавать машины при помощи именно docker-machine имеет смысл хотя бы потому, что они сразу будут идти с предустановленным Docker. Из трёх хостов на одном мы поселим менеджера Swarm, а на двух других — обычных рабочих. Собственно, создание виртуальных машин — удивительно безболезненное занятие:
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Установка и настройка Docker Swarm
кластеризация, такая кластеризация
В этой статье мы рассмотрим процесс установки и настройки режима Docker Swarm на сервере Ubuntu 16.04.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Docker Swarm является стандартным инструментом кластеризации для Docker, преобразующий набор хостов Docker в один последовательный кластер, называемый Swarm. Docker Swarm обеспечивает доступность и высокую производительность работы, равномерно распределяя ее по хостингам Docker внутри кластера.
Установка Docker Swarm:
Перед началом обновите Ваш системный репозиторий до последней версии с помощью следующей команды:
После обновления следует выполнить перезагрузку системы. Необходимо еще установить среду Docker. По умолчанию Docker не доступен в репозитории Ubuntu 16.04, поэтому сначала необходимо создать хранилище Docker и начать установку с помощью следующей команды:
Добавляем GPG ключ для Docker:
Добавляем репозиторий Docker и обновляем с помощью команды:
Установка среды Docker с помощью следующей команды:
После установки запустите службу Docker во время загрузки с помощью следующей команды:
Для запуска Docker необходимы root права, а для других юзеров доступ получается только с помощью sudo. При необходимости запустить docker без использования sudo, есть возможность создать Unix и включить в него необходимых пользователей за счет выполнения следующих строк кода:
Затем выйдя из системы, делаем вход через dockeruser.
Затем перезагрузите брандмауэр, включив его при загрузке
Выполните перезагрузку “Докера”:
Создавая Docker Swarm кластер, необходимо определиться с IP-адресом, за счет которого ваш узел будет действовать в качестве диспетчера:
Вы должны увидеть следующий вывод:
Проверяем его состояние:
Если все работает правильно, вы должны увидеть следующий вывод:
Проверка статуса Docker Swarm Cluster осуществляется следующим образом:
Вывод должен быть следующим:
Узел теперь настроен правильно, пришло время добавить его в Swarm Cluster. Сначала скопируйте вывод команды «swarm init» из вывода результата выше, а затем вставьте этот вывод в рабочий узел для присоединения к Swarm Cluster:
Вы должны увидеть следующий вывод:
Теперь выполните следующую команду для вывода списка рабочего узла:
Вы должны увидеть информацию следующего вида:
Docker Swarm Cluster запущен и работает, теперь можно запустить веб-сервис в Docker Swarm Mode. За счет следующей строки кода выполнится развертывание службы веб-сервера:
Приведенная выше строка создаст контейнер веб-сервера Apache и сопоставит его с 80 портом, позволив иметь полный доступ к необходимому веб-серверу Apache из удаленной системы. Теперь запускаем проверку работающего сервиса с помощью команды:
Вы должны увидеть следующий вывод:
Запустите службу масштабирования веб-сервера с помощью строки:
А также проверьте состояние с помощью команды:
Вы должны увидеть следующий вывод:
Веб-сервер Apache работает. Теперь вы можете получить доступ к веб-серверу:
Служба веб-сервера Apache теперь распределена по двум узлам. Docker Swarm обеспечивает доступность вашего сервиса. Если веб-сервер отключается на рабочем узле, то новый контейнер будет запущен на узле менеджера. Для проверки доступности следует остановить службу Docker на рабочем узле:
Запустите службу веб-сервера с помощью команды:
Вы должны увидеть следующую информацию:
С помощью данной статьи, вы смогли установить и настроить кластер Docker Swarm для ОС Ubuntu 16.04. Теперь вы можете легко масштабировать свое приложение в кластере до тысячи узлов и пятидесяти тысяч контейнеров без существенной потери производительности.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
🇲🇺 Docker Swarm для оркестрации контейнеров
1 Что такое Docker Swarm?
Docker Swarm – это режим работы с кластером Docker движков, отсюда и название Swarm.
Кластер хостов Docker работает в режиме Swarm.
Экземпляры Docker engine, которые участвуют в swarm, называются нодами.
Развертывание Swarm производственного уровня состоит из Docker нодов ( узлов ), распределенных по нескольким серверам.
2 Зачем это использовать? – Контейнерная оркестрация
Когда вы работаете в производственной среде, на сотнях докер-контейнеров будет работать несколько приложений.
Управление всеми этими контейнерами может быть большой головной болью для всех инженеров DevOps;
Вот где Docker Swarm поможет вам.
Он легко управляет и управляет кластером, в котором работают несколько докер-контейнеров.
3 Оркестрация Docker контейнеров
Теперь, когда вы знакомы с основами Docker Swarm, давайте рассмотрим пример его реализации.
В этом примере у меня есть три машины, работающие в кластере со следующими деталями:
Запуск токена на узле worker2.
В этом режиме выполняется одна задача службы swarm на всех узлах кластера.
Прежде чем запускать службу в global режиме, позвольте мне удалить существующий работающий контейнер.
CURRENT STATE узла worker1 – это завершение работы (так как мы остановили контейнер, на котором запущен сервис). Но так как для этой службы должны работать две реплики, на worker 2 была запущена другая служба.
Вот как вы достигаете высокой доступности с помощью Docker Swarm.
Проверьте, где эти 5 реплик работают в кластере.
1 реплика работает на узле manager1 и 2 реплики на обоих нодах worker.
Добавить комментарий Отменить ответ
• Свежие записи
• Категории
• itsecforu.ru
IT is good