Web-разработка

Автоматизация и масштабирование инфраструктуры приложений с Docker Swarm и AWS

13.06.2023

Вступление

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

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

Продемонстрируем это.

Что будем создавать?

Среду Docker Swarm с одним управляющим узлом и тремя рабочими узлами.
Стек Docker для развертывания 3-уровневой архитектуры приложений с тремя службами Docker: Web/Apache, Node.js и Postgres.

Понадобятся:

Учетная запись AWS с доступом пользователя IAM.
Учетная запись Docker Hub.
Базовые знания о Docker, Docker Compose и командах CLI.
Знание экземпляров EC2 Amazon и консоли управления AWS.
Знание файловых систем и команд Linux.
Доступ к инструменту командной строки.
IDE, например VS Code.

Ключевые понятия

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

Задача — это просто контейнер Docker и набор выполняемых в нем инструкций или команд.

Этап 1. Подготовка

Прежде чем переходить к Docker Swarm, настроим серверы/машины для узлов Swarm. Воспользуемся экземплярами EC2 Amazon, виртуальные и локальные машины тоже сгодятся.

Понадобится:

Один экземпляр EC2 с управляющим узлом.
Три экземпляра EC2 с рабочим узлом.

Группы безопасности

Для взаимодействия всех узлов в Docker Swarm нужен доступ к определенным портам:

Подробнее — здесь.

Создадим две группы безопасности: swarm_app_mgr_sg для управляющего узла, swarm_app_wkr_sg для рабочих узлов.

Сначала создаем группы, затем добавляем для них правила входящих подключений. Для каждого правила задаем источник групп безопасности mgr/wkr, добавить его к sg потом в AWS не получится.

Правила входящих подключений для групп безопасности управляющего узла:

SSH | TCP | Порт: 22 | Источник: мой IP
HTTP | TCP | Порт: 80 | Источник: IPv4 везде
HTTPS | TCP | Порт: 443 | Источник: IPv4 везде
Пользовательский TCP | TCP | Порт: 8080 | Источник: IPv4 везде
Пользовательский TCP | TCP | Порт: 2377 | Источник: swarm_app_wkr_sg
Пользовательский TCP | TCP | Порт: 7946 | Источник: swarm_app_wkr_sg
Пользовательский UDP | UDP | Порт: 7946 | Источник: swarm_app_wkr_sg
Пользовательский UDP | UDP | Порт: 4789 | Источник: swarm_app_wkr_sg

Правила входящих подключений для групп безопасности рабочего узла:

SSH | TCP | Порт: 22 | Источник: мой IP
HTTP | TCP | Порт: 80 | Источник: IPv4 везде
HTTPS | TCP | Порт: 443 | Источник: IPv4 везде
Пользовательский TCP | TCP | Порт: 7946 | Источник: swarm_app_mgr_sg
Пользовательский UDP | UDP | Порт: 7946 | Источник: swarm_app_mgr_sg
Пользовательский UDP | UDP | Порт: 4789 | Источник: swarm_app_mgr_sg

Создаем сервер управляющего узла

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

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

Создадим шаблон запуска EC2 swarm_node_template и к каждому поднимаемому серверу/узлу применим одинаковые настройки.

Настройки шаблона запуска:

AMI: Amazon Linux 2.
Type: бесплатный уровень t2.micro, но выбирайте в соответствии с требованиями приложения.
Key pair: выбирается/создается пара ключей.
Network: сети, задаются при запуске экземпляров.
Advanced Details User data: здесь добавляется скрипт bash, по которому при запуске экземпляров устанавливаются, включаются и запускаются Docker и Docker Compose. Скопируйте и вставьте в раздел User details этот скрипт:

sudo yum update -y
sudo yum install -y docker

#устанавливаем docker compose
sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

sudo systemctl enable docker
sudo systemctl start docker

На этом шаблоне запустим экземпляр swarm_app_mgr и подключим группу безопасности swarm_app_mgr_sg. Воспользуемся виртуальным частным облаком по умолчанию и подсетью.

Создаем серверы рабочего узла

Тем же шаблоном запустим на рабочих машинах три экземпляра swarm_app_wkr1, swarm_app_wkr2 и swarm_app_wkr3 с группой безопасности swarm_app_wkr_sg:

Этап 2. Создание Swarm

Создадим среду Swarm и присвоим каждому экземпляру EC2 его роль узла.

Присваиваем роль управляющего узла

Сначала подключимся по SSH к экземпляру управляющего узла и, запустив docker --version и docker-compose --version, проверим установленные версии Docker и Docker Compose:

Авторизуемся со своим именем пользователя в Docker Hub и паролем sudo docker login.

Создадим Swarm и присвоим этому серверу роль управляющего узла:

sudo docker swarm init

Мы получили управляющий узел и направления для создания новых управляющих/рабочих узлов.

IP-адрес — это частный IP-адрес экземпляра. Это важно, потому что управляющему узлу для подключения рабочих узлов нужен статический IP-адрес. Скопируйте ту первую команду.

В этом случае в Swarm правильный IP-адрес определился автоматически, но иногда вы направляетесь на «рекламу» IP-адреса. И тогда придется снова запустить команду init с дополнительным параметром --advertise-addr <YOUR_IP_ADDRESS>.

Присваиваем роли рабочих узлов

Скопировав команду, откроем еще три окна терминала и подключимся по SSH к каждому экземпляру рабочих узлов. Вставляем команду, данную от управляющего узла, и получаем подтверждение добавления каждого узла в Swarm:

sudo docker swarm join --token <TOKEN> <MANAGER_IP_ADDRESS>

Чтобы просмотреть все узлы с их статусами, в терминале управляющего узла запускаем sudo docker node ls. Звездочкой * обозначается узел, в котором мы сейчас находимся:

Если запустим эту же команду в терминале рабочего узла, получим сообщение об ошибке:
Error response from daemon: This node is not a swarm manager. Worker nodes can’t be used to view or modify cluster state. Please run this command on a manager node or promote the current node to a manager. (Реакция на ошибку от демона: «Это не управляющий узел Swarm. Рабочие узлы не используются для просмотра или изменения состояния кластера. Запустите эту команду в управляющем узле или повысьте роль текущего узла до управляющего).

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

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

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

Теперь узлы Swarm готовы к работе.

Этап 3. Создание стека Swarm

Базовая среда настроена, определим и развернем архитектуру приложения. Приложение настраивается на трех уровнях.

Уровень фронтенда/веба: на веб-серверах Apache, 10 реплик.
Уровень бэкенда/приложения: на Node.js, 4 реплики.
Уровень бэкенда / базы данных: на Postgres, 1 реплика.

У нас нет фактического исходного кода приложения для развертывания, но процесс тот же.

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

Мы определяем все узлы, службы, образы, тома и параметры развертывания, на Swarm — балансировка нагрузки и распределение служб/контейнеров между доступными узлами.

При сбое задачи, например экземпляра службы/контейнера, в Swarm она автоматически завершается и ей на замену создается новая для восполнения общего количества объявленных реплик.

Если случается сбой узла или он становится недоступен, необходимые службы и контейнеры перераспределяются между доступными узлами. Этим объясняется такая высокая доступность и отказоустойчивость Swarm.

Docker Compose

Конечно, службы и задачи создаются отдельно с помощью команд Docker CLI, но это муторно и времязатратно. Лучше создадим с Docker Compose Swarm-стек и оркестрируем всю архитектуру одним файлом и одной командой.

Стек создается из файла docker-compose.yml. Все то же самое, что и в Docker Compose, но в дополнение к службам, портам, томам и сетям с помощью стека определяются параметры развертывания. Мы указываем число реплик для каждой службы, ограничения на размещение, политики перезапуска, политики отката и многое другое. Полный список параметров — в официальной документации.

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

Так же подключаясь по SSH к управляющему узлу, создадим новый файл docker-compose.yml или клонируем репозиторий Github с файлом compose внутри.

Напомним: это базовая структура файла compose. У нас имеется четыре службы* и две мостовые сети для фронтенда и бэкенда:

version: "3.8"

services:
  web:
  
  node:

  db:
  
  visualizer:

networks:
  frontend:
    driver: bridge
  backend: 
    driver: bridge 

volumes:

version: "3.8"

services:
  web:
    image: httpd:2.4.55
    ports: 
      - 80:80
    networks:
      - frontend
    deploy:
      replicas: 10
      placement:
        constraints: [node.role == worker]
      restart_policy:
        condition: on-failure
  
  node:
    image: node:19-alpine3.16
    networks:
      - frontend
      - backend
    command: ["sleep", "10000"] # это только для принудительного сохранения контейнера запущенным, ведь фактического кода приложения нет
    deploy:
      replicas: 4
      placement:
        constraints: [node.role == worker]
      restart_policy:
        condition: on-failure
  
  db:
    image: postgres:15.2
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=mypass
    networks:
      - backend
    deploy:
      replicas: 1
      placement:
        constraints: [node.role == worker]
      restart_policy:
        condition: on-failure
  
  visualizer:
    image: bretfisher/visualizer
    ports:
      - 8080:8080
    stop_grace_period: 1m30s
    networks:
      - frontend
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    deploy:
      placement:
        constraints: [node.role == manager]

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge

volumes:
  db-data:

*Я включил четвертую службу visualizer — отличный инструмент разработки, которым визуализируется ландшафт и работоспособность служб всех узлов.

Сосредоточившись только на архитектуре, а не на фактическом коде приложения, я сделал файл Compose довольно простым. Дополняйте его и делайте надежнее для задач своего приложения.

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

Файл Compose готов.

Этап 4. Развертывание стека

Развернуть Swarm-стек очень просто.

Это делается в командной оболочке управляющего узла командой docker stack delpoy с указанием с помощью -c файла Compose. Затем добавляется файл Compose и имя стека swarm_app:

sudo docker stack deploy -c docker-compose.yml stack_name

Вот приложение и развернуто… по крайней мере, для разработки.

Службы в стеке просматриваем этой командой:

sudo docker stack services stack_name

Подробнее все задачи/контейнеры просматриваем этой командой:

sudo docker stack ps stack_name

В выделенной области показана работа Swarm в реальном времени. Похоже, некоторые задачи службы node.js завершились, вероятно, из-за команды sleep, но немедленно заменились запущенной задачей.

Если перейти на любой из общедоступных IP-адресов узла Swarm, мы должны увидеть сайт Apache в реальном времени:

Visualizer

Теперь самое интересное. Перейдем в ту неожиданно появившуюся четвертую службу visualizer, развернутую в управляющем узле с портом 8080 manager_node_public_IP:8080:

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

Смоделируем сбой узла. В консоли управления AWS останавливаем один из серверов рабочего узла и возвращаемся в visualizer:

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

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

Автоматизация и масштабирование инфраструктуры приложений с Docker Swarm и AWS

Вступление

Что будем создавать?

Ключевые понятия

Этап 1. Подготовка

Группы безопасности

Создаем сервер управляющего узла

Создаем серверы рабочего узла

Этап 2. Создание Swarm

Присваиваем роль управляющего узла

Присваиваем роли рабочих узлов

Этап 3. Создание стека Swarm

Docker Compose

Этап 4. Развертывание стека

Visualizer

Читайте также

Репозитории GitHub в помощь каждому веб-разработчику

Service Workers и стратегии кэширования

Топ — 9 фреймворков в мире искусственного интеллекта

Тесты

Насколько хорошо вы разбираетесь в алгоритмах и структурах данных

Насколько хорошо вы разбираетесь в Python?

Насколько хорошо вы разбираетесь в концепциях баз данных?