Программы обучения AWS

Break the Monolith

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

блоки контейнеров
введение

Введение

модуль 1

Контейнеризация монолитного приложения

модуль 2

Развертывание монолитного приложения

модуль 3

Break the Monolith

шаг 4

Развертывание микросервисов

модуль 5

Очистка

Модуль 4. Развертывание микросервисов

В этом модуле вы развернете свое приложение node.js как набор взаимосвязанных сервисов за балансировщиком Application Load Balancer (ALB). Затем с помощью ALB вы легко переключите трафик с монолита на микросервисы. Приступить

Обзор архитектуры

Следуя этому процессу, вы запустите микросервисы и безопасно переведете трафик из монолитного приложения.

обзор архитектуры
  1. Развернутый монолит
    Это начальная конфигурация. Монолитное приложение node.js выполняется в контейнере в Amazon ECS.
  2. Запуск микросервисов
    С помощью трех образов контейнера, которые вы создали и переместили в Amazon ECR в предыдущем модуле, вы запустите три микросервиса в существующем кластере Amazon ECS.
  3. Настройка целевых групп
    Как и в модуле 2, вы добавите целевую группу для каждого сервиса и обновите правила ALB для подключения новых микросервисов.
  4. Переключение трафика и завершение работы монолитного приложения
    Изменив одно правило в ALB, вы начнете перенаправление трафика к работающим микросервисам. Когда все будет в порядке, завершите работу монолитного приложения.

Время выполнения: 30 минут

Используемые сервисы:

Инструкции по внедрению

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

  • Шаг 1. Запись определений задач для сервисов

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

    ⚐ ПРИМЕЧАНИЕ. К определению задачи можно добавлять множественные контейнеры. Таким образом, все три микросервиса можно выполнять в виде разных контейнеров на одном сервисе. Тем не менее это будет монолитное решение, поскольку каждый контейнер нужно линейно масштабировать вместе с сервисом. Ваша цель – получить три независимых сервиса. При этом для каждого сервиса нужно, чтобы его собственное определение задачи выполнялось в контейнере с образом для этого сервиса.

    Можно либо записывать определения задач в пользовательском интерфейсе консоли, либо ускорить процесс, записав их в виде JSON. Чтобы записать определение задачи в виде файла JSON, выберите «Configure via JSON» (Настроить через JSON) внизу нового экрана «Task Definition» (Определение задачи).

    Параметры определения задачи:

    • Имя = [service-name] 
    • Образ = [service ECR repo URL]:latest 
    • ЦП = 256 
    • Память = 256 
    • Порт контейнера = 3000 
    • Порт хоста = 0



    Или с помощью JSON:

    {
    "containerDefinitions": [
        {
            "name": "[service-name]",
            "image": "[account-id].dkr.ecr.us-west-2.amazonaws.com/[service-name]:[tag]",
            "memoryReservation": "256",
            "cpu": "256",
            "essential": true,
            "portMappings": [
                {
                    "hostPort": "0",
                    "containerPort": "3000",
                    "protocol": "tcp"
                }
            ]
        }
    ],
    "volumes": [],
    "networkMode": "bridge",
    "placementConstraints": [],
    "family": "[service-name]"
}

    ♻ Повторяйте этот процесс, чтобы создать определение задачи для каждого сервиса:

    • posts
    • threads
    • users

  • Шаг 2. Настройка Application Load Balancer: целевые группы

    Как и в модуле 2, вы настроите целевые группы для каждого сервиса. Благодаря целевым группам трафик правильно достигает каждого сервиса.

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

    • Перейдите в раздел «Load Balancer» (Балансировщик нагрузки) в консоли EC2.
    • Должен отобразиться уже существующий балансировщик нагрузки с именем demo.
    • Установите флажок, чтобы увидеть сведения об этом балансировщике.
    • На странице сведений обратите внимание на значение атрибута VPC.

     

    Настройка целевых групп

    • Перейдите к разделу «Target Group» (Целевая группа) консоли EC2.
    • Выберите «Create target group» (Создать целевую группу).
    • Настройте целевую группу (не меняйте значения по умолчанию, если они здесь не указаны): имя = [имя сервиса]; протокол = HTTP; порт = 80; VPC = выберите облако VPC, соответствующее балансировщику нагрузки из предыдущего шага.
      • Настройки для расширенной проверки работоспособности: «Healthy threshold» (Порог работоспособности) = 2; «Unhealthy threshold» (Порог неработоспособности) = 2; «Timeout» (Время ожидания) = 5; «Interval» (Интервал) = 6
    • Выберите «Create» (Создать).

     

    ♻ Повторяйте этот процесс, чтобы создать целевую группу для каждого сервиса:

    • posts
    • threads
    • users

     

    Наконец, создайте четвертую целевую группу

    • drop-traffic

    Это фиктивная целевая группа. Ее роль – не допускать поступления трафика к монолитному приложению после начала полнофункциональной работы микросервисов. В таблице должно быть в общей сложности 5 целевых групп.

    целевые группы

  • Шаг 3. Настройка правил для прослушивателя

    Прослушиватель проверяет входящие запросы на подключение, поступающие к ALB, для соответствующей маршрутизации трафика.

    В настоящий момент все четыре ваших сервиса (монолитное приложение и три микросервиса) работают за одним и тем же балансировщиком нагрузки. Для перехода от монолитного приложения к микросервисам вы запустите маршрутизацию трафика к микросервисам и остановите маршрутизацию трафика к монолитному приложению.

    Открытие прослушивателя

     

    Обновление правил для прослушивателя

    • Выберите «View/edit rules >» (Просмотр / редактирование правил >) для прослушивателя.
    • Нажмите «+» и вставьте правило.
    • Критерии правила следующие:
      • IF Path = /api/[service-name]* THEN Forward to [service-name]
      • Например: Path = /api/posts* forward to posts
    • Создайте четыре новых правила: одно для поддержания трафика к монолиту и по одному для каждого сервиса. В общей сложности у вас будет пять правил, в том числе одно по умолчанию. Обязательно добавляйте свои правила в следующем порядке:
      • api: /api* forwards to api
      • users: /api/users* forwards to users
      • threads: /api/threads* forwards to threads
      • posts: /api/posts* forwards to posts
    • Нажмите на стрелку назад слева вверху страницы, чтобы вернуться в консоль балансировщика нагрузки.
    настройка правил для прослушивателя

  • Шаг 4. Развертывание микросервисов

    Теперь вы развернете три сервиса в кластере. Повторите эти шаги для каждого из трех сервисов:

    • Перейдите в меню «Clusters» (Кластеры) в левой части консоли Amazon ECS.
    • Выберите свой кластер: BreakTheMonolith-Demo-ECSCluster.
    • На вкладке сервисов выберите «Create» (Создать).
    • Настройте сервис (не меняйте значения по умолчанию): «Task definition» (Определение задачи) = выберите наибольшее значение для X: [имя-сервиса]:X (X должно быть = 1 в большинстве случаев), «Service name» (Имя сервиса) = [имя-сервиса], «Number of tasks» (Количество задач) = 1
    • Выберите «Configure ELB» (Настроить ELB)
      • Тип ELB = Application Load Balancer
      • Для роли IAM выберите BreakTheMonolith-Demo-ECSServiceRole
      • Выберите свой балансировщик нагрузки demo
      • Выберите «Add to ELB» (Добавить к ELB)
    • Добавьте сервис в целевую группу:
      • «Listener port» (Порт прослушивателя) = «80:HTTP»;
      • Имя целевой группы = выберите свою группу: [имя-сервиса]
    • Выберите «Save» (Сохранить).
    • Выберите «Create Service» (Создать сервис).
    • Выберите «View Service» (Просмотреть сервис).


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

    развертывание микросервисов

  • Шаг 5. Переключение трафика на микросервисы

    В настоящий момент микросервисы работают, но весь трафик по-прежнему поступает на монолитный сервис.

    Обновление правил для прослушивателя для перенаправления трафика на микросервисы

    • Перейдите к разделу «Load Balancer» (Балансировщик нагрузки) в консоли EC2.
    • Выберите «View/edit rules >» (Просмотр / редактирование правил >) для прослушивателя в балансировщике нагрузки demo.
    • Удалите первое правило (/api* forwards to api).
    • Обновите правило по умолчанию для перенаправления на drop-traffic.

    Ваши правила должны выглядеть приблизительно так:

    переключение трафика на микросервисы

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

    • Вернитесь к кластеру Amazon ECS BreakTheMonolith-Demo-ECSCluster.
    • Выберите сервис api, а затем «Update» (Обновить).
    • Измените количество задач на 0.
    • Выберите «Update Service» (Обновить сервис).

     

    После этого Amazon ECS удалит все подключения из контейнеров, которые сервис развернул в кластере, а затем остановит контейнеры. Если обновить списки «Deployments» (Развертывания) или «Tasks» (Задачи) через 30 секунд, можно будет увидеть, что количество задач стало равно 0. Сервис по-прежнему активен, и если его нужно по той или иной причине откатить, просто обновите его для развертывания дополнительных задач.

    • Выберите сервис api, затем «Delete» (Удалить) и подтвердите удаление.


    Теперь вы полностью разделили монолитное приложение node.js на микросервисы без прерывания работы!

  • Шаг 6. Проверка развертывания

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

    • Перейдите к разделу «Load Balancers» (Балансировщики нагрузки) в консоли EC2.
    • Выберите свой балансировщик нагрузки demo-microservices.
    • Скопируйте и вставьте значение имени DNS в браузер.
    • Отобразится сообщение «Ready to receive requests» (Готов к приему запросов).

     

    Просмотрите значения для каждого микросервиса: ALB направляет трафик на основе URL-адреса запроса. Для просмотра каждого сервиса просто добавьте его имя в конце имени DNS следующим образом:

    • http://[имя DNS]/api/users
    • http://[имя DNS]/api/threads
    • http://[имя DNS]/api/posts
    см. значения для каждого микросервиса

    ⚐ ПРИМЕЧАНИЕ. Эти URL-адреса выполняют в точности те же функции, которые они выполняли при развернутом монолитном приложении. Это очень важно, поскольку любые API или клиенты, ожидающие подключения к данному приложению, не будут затронуты произошедшими изменениями. Для перехода от монолитного приложения к микросервисам не требуется вносить какие-либо изменения в другие части вашей инфраструктуры.

    Протестировать API можно и с помощью таких инструментов, как Postman.

Далее: очистка