Дипломная работа: Автоматизация доставки программного обеспечения при помощи DevOps практик и инструментов в облаке AWS в компании ООО "Команда Лабс"
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
76
Рисунок 31. Балансировка трафика при помощи AWS Network Load
Balancer
Далее воспользуемся сервисом AWS Auto Scaling Group. Для того, чтобы
сервис понимал, какие серверы он должен масштабировать, мы должны ему
предоставить заранее созданные образы. Так как выбор ПО для создания
подобных образов на рынке не особенно много, и при наличии в нашей команде
экспертизы в использовании, мы решили собирать образы при помощи Packer
1.5.4 [27] от компании HashiCorp. При запуске Packer 1.5.4 [27] мы должны
предоставить ему json файл с декларативным описанием того, что мы хотим
видеть внутри полученного образа. Внутри собираемого образа мы собираем
Nginx [13] из исходного кода, как описывалось ранее. А также запускаем
скрипты конфигурации сервера и проверка после перезагрузки сервера его
работоспособности. За основу мы берём последнюю сборку сервера Ubuntu
18.04, и в роли билдера мы должны указать amazon-ebs, это значит, что мы будем
разворачивать его внутри AWS.
77
После сборки образа Nginx [13] сервера мы можем добавить имя
полученного AMI [34] (Amazon Machine Images) в сервис, который будет
управлять количеством запущенных данных инстансов Auto Scaling Launch
Configurations. Каждый раз, когда мы будем обновлять сервер с Nginx, мы
должны новый AMI добавлять сюда в рамках PCI DSS [29].
Рисунок 32. Настройа Launch Configuration
После необходимо создать Auto Scaling группу, которая будет следить за
количество запущенных инстансов, в нашем случае нам необходимо по одному
серверу на каждую Availability Zone (дата-центр AWS внутри одного региона, в
нашем случае это eu-central-1 — Франкфурт). В роли балансировщика выбираем
созданный ранее NLB:
Рисунок 33. Создание Auto Scalling группы
78
Итак, у нас должно быть 2 созданных Nginx 1.17.7 [13]с ервера, при этом,
если любой из них перестаёт быть доступным, он удаляется из таргетной группы,
терминируется и создаётся новый инстанс, созданный на основе Packer 1.5.4
образа. В случае увеличения трафика мы можем задать большее количество
желаемых инстансов в 2 или 3 дата-центрах.
Разворачивание инфраструктуры в AWS при помощи Terraform
Одна из самых важных задач DevOps состоит в том, чтобы максимально
автоматизировать разворачивание инфраструктуры. А также в рамках PCI DSS
[29] необходимо регулярно проводить учения по Disaster Recovery, где все
участники команды должны знать, как в любой момент развернуть
инфраструктуру за кратчайшие сроки на случай падения всей системы или
разрушительной атаки извне с деградацией сервисов. Для подобной практики мы
будем использовать бесплатное решение от HashiCorp под названием Terraform
0.12.23 [22]. Оно поможет нам в декларативной форме описать желаемую
инфраструктуру, а также совместно всей командой управлять состоянием
системы с помощью сервиса Amazon S3.
Кодовая база инфраструктурного кода для удобства поддержки и
переиспользования кода должна быть разделена на модули. Целью
разворачивания инфраструктуры должна быть следующая схема:
79
Рисунок 34. Необходимая инфраструктура
Логирование, алертинг и мониторинг
Для полного понимания того, что происходит в нашей системе, в каждом
из окружений, нам необходимо собирать события со всех инстансов EC2 c
Ubuntu 18.04 [15] и из сервисов ECS [7], складывать их в централизованное
хранилище и затем нам нужен инструмент для аналитики записанных событий.
Для агрегации логов вполне подходит сервис, который из коробки предоставляет
AWS, CloudWatch [35]. Он предоставляет инструменты для интеграции, для
помещения событий в топики, настройки оповещений, аналитики. Но мы хотели
более удобного инструмента для работы с логами, такой, как стек ELK 7.1 [20]
(Elasticsearch, Logstash, Kibana), который де-факто считается промышленным
стандартом.
80
Рисунок 35. Информационная модель
2.2.2 Характеристика нормативно-справочной, входной и оперативной
информации
Для гибких подходов к разворачиванию инфраструктуры и доставки кода
мы решили применять подход Инфраструктура как код (Infrastructure as Code,
IaC) [3]. Исходным документом является код от программистов и
автоматизаторов тестирования, в котором они в декларативном виде описывают
желаемые характеристики системы, который затем попадает в Git репозиторий.
Оттуда код забирается по расписанию при помощи сервера интеграции TeamCity
с помощью скриптов выполняется и разворачивается в желаемом окружении.
Затем со всех серверов собирается информация в виде логов и состояниях
системы и складывается в ElasticSearch 7.1 и InfluxDB 2.0 соответственно. Таким
Источник: https://baza.diplomsite.ru/previewfile/1758