В этом июне, в качестве лейтмотива конференции DockerCon мы видели демо, в котором 3-узловой Swarm-кластер был создан за 30 секунд используя набор инструментов для кластеризации Swarm, интегрированную в Docker Engine 1.12. Впечатляет, но естественно, мне нужно было попробовать сделать это самому, чтобы увидеть своими глазами. Я нашел самый простой путь. Для начала работы со Swarm (Роем) использовать docker-machine. Для создания хостов с установленным на них Docker Engine я использовал драйвер virtualbox’а, но вы можете использовать любой драйвер который вы хотите, например amazonec2.  Скопируйте команду, отображенную ниже для первого узла из ваших воркеров, чтобы присоединить его к кластеру.  Теперь у вас есть Swarm-кластер! Чтобы запустить приложение, мы используем служебную команду Docker’а create. С помощью флага --replicas, вы можете очень просто масштабировать сервис. Первоначально мы хотим создать сеть верхнего уровня (оверлейную сеть), чтобы развернуть наше приложение. До 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 в Docker’е 1.12 также поддерживает согласования, плавающие обновления (rolling updates) образа, глобальные сервисы и сервисы по расписанию, базирующиеся на ограничениях. Также хочу затронуть тему отказа узлов в Docker Swarm. Команды, относящиеся к сервисам Docker Engine 1.12, являются декларативными. Например, если вы задаете команду «Я хочу 3 реплики данного сервиса», то кластер будет поддерживать это состояние. В случае отказа узла контейнеры которого были задействованы, swarm обнаружит, что желаемое состояние не совпадает с действительным и автоматически исправит ситуацию путем перераспределения контейнеров на другие доступные узлы. Чтобы это продемонстрировать, давайте зададим новый сервис с тремя репликами. Запустите, чтобы проверить работу сервиса  Сейчас у нас есть по одному контейнеру на каждом из узлов. Давайте выведем из строя узел 3, чтобы посмотреть на регулирование swarm в действии. Теперь желаемое состояние не совпадает с действительным. У нас есть только 2 действующих контейнера, тогда как мы обозначили 3 контейнера, когда запускали сервис. Использование докер сервиса дает вам возможность увидеть, что количество реплик уменьшилось до двух, а затем снова вернулось к трем   docker service tasks web покажет вам новый контейнер, назначенный на другом узле вашего кластера.  Этот пример показывает только регулирование контейнеров на рабочих узлах. Совершенно другой процесс происходит, когда из строя выходит менеджер, особенно, если это лидер raft группы для решения задач консенсуса.  Глобальные сервисы полезны, когда вы хотите создать контейнер на каждом узле вашего кластера. Подумайте о ведении протокола или мониторинге.   Помните, я говорил, что сервисы являются декларативными? Когда вы добавляете новый узел к вашему кластеру, swarm определяет, что желаемое состояние не совпадает с действительным, и запускает экземпляр глобального контейнера на этом узле. Для демонстрации ограничений я использовал докер машину, чтобы ускорить новую машину с помощью engine label. Затем я добавил ее в swarm. Далее я создал сервис, ссылающийся на это ограничение.  Помните, я говорил, что сервисы являются декларативными? ;) Это означает, что, когда мы масштабируем этот сервис, он запоминает наши ограничения и масштабирует только отвечающие условиям узлы.  Docker Captain и Software Engineer в Ippon Technologies, который любит вбрасывать вещи на рынок побыстрее. Специализируется на agile, микросервисах, контейнерах, автоматизации, REST, devops. CEO в Southbridge