Дипломная работа: Автоматизация доставки программного обеспечения при помощи DevOps практик и инструментов в облаке AWS в компании ООО "Команда Лабс"
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
41
https://www.cloudflare.com/ . Такое решение позволяет быстро изменять размеры
инфраструктуры, разворачивать при необходимости новые сервисы, быстро
масштабироваться и избежать дополнительных затрат на поддержку и
эксплуатацию.
Сервисы разворачиваются в сервисе Elastic Container Service Fargate, что
позволяет использовать одни и те же образы, которые используют программисты
для тестирования и разработки, QA для интеграционного и юнит тестирования,
Demo стенд для проведения демонстрации клиенту и бенефициарам.
1.3.2 Выбор и обоснование стратегии автоматизации задачи
В нашем случае наиболее подходящими стратегиями автоматизации
являются синергия хаотичной автоматизации в местах так называемого
бутылочного горлышка, узкого места, которое мешает продвижению по
конвейеру производства программного обеспечения, и автоматизация по
направлениям:
• Тестирование
• Сборка программного обеспечения
• Непрерывная доставка программного обеспечения в инфраструктуру
• Управление конфигурациями
• Автоматизация разворачивания инфраструктуры
• Непрерывная безопасность
• Непрерывная интеграция
• Мониторинг, телеметрия, метрики
• Логирование
В первую очередь необходимо настроить автоматизацию сборки
программ, и запуск тестов по расписанию при помощи сервера непрерывной
поставки [16] TeamCity CI/CD [17] сервера:
• Модульное тестирование (Unit Testing)
• Интеграционное тестирование (Integration Testing)
• Системное тестирование (System Testing)
42
• Операционное тестирование (Release Testing)
• Приемочное тестирование (Acceptance Testing)
• Тестирование пользовательских интерфейсов (UI Testing)
Поставку программного обеспечения будем также осуществлять с
помощью сервера интеграции TeamCity, используя bash скрипты, AWS CLI [6],
Docker [8], Amazon Container Services [7] и подход практики инфраструктура как
код [3].
Управление конфигурациями частично решается с помощью Docker, а
также Ansible [18].
К развёртыванию инфраструктуры с помощью кода в AWS решено
использовать Terraform, это позволит иметь аналогичную конфигурацию
заказанных серверов в тестовом, демо и производственных окружениях, что
исключит возможность человеческой ошибки и неоднородности сред.
Статическую проверку кода и модулей на уязвимости решено проверять
при помощи SonarQube, это исключит возможность попадания в сборку
небезопасных модулей и позволит раньше проводить проверку кода на
безопасность, что поможет ускорить доставку ПО без необходимости проверять
и исправлять код, который находится на этапе перед доставкой кода в
производственную среду.
Статический анализатор образов докер производится во время сборки на
TeamCity при помощи сканера уязвимостей внутри образов Trivy [19]
Мониторинг разворачивается при помощи запуска Docker [8] стека,
данные из серверов отправляются при помощи экспортеров, которые
настраиваются на EC2 [15] серверах при помощи Ansible.
Для автоматизации логирования используется ELK (ElasticSearch,
Logstash, Kibana) [20] стек, который предоставляет анализатор логов Kibana, а
также отправку сообщений об ошибках при помощи Logstash в средство
управления оповещениями и инцидентами OpsGenie [21] и дальнейшую
эскалацию инцидентов в команду поддержки.
43
1.3.3 Выбор и обоснование способа приобретения ИС для автоматизации
задачи
Платформой для разворачивания инфраструктуры исторически выбран
Amazon Web Services для возможности работать с несколькими регионами и
использования готовых решений для различных задач автоматизации.
Используются следующие платные ресурсы, предлагаемые платформой:
• EC2 инстансы с установленной Ubunt в роли пограничных серверов
• ElasticSearch Service [20] для логирования и аналитики
• Куплена поддержка со стороны платформы
• RedShift — база данных для аналитической обработки
• LoadBalancer в роли балансировщика нагрузки для входящего и
исходящего трафика на web-сервер Nginx
• Elastic Container Service для запуска задеплоенных сервисов
• RDS PostrgreSQL сервер в роли реляционной базы данных
• CloudWatch как средство сбора и аналитики логов со всех внутренних
сервисов и пограничных серверов
Aiven Kafka предоставляет сервис стриминговой передачи данных для
хранения оперативной информации. Сервис выбран для снижения сложности
обслуживания со стороны эксплуатации и дороговизны покупки
соответствующей инфраструктуры.
Документ-ориентированная база данных MongoDB также используется
как платформа, также снижается стоимость и сложность обслуживания со
стороны эксплуатации.
1.4 Обоснование проектных решений
1.4.1 Обоснование проектных решений по информационному обеспечению
Итак, определим последовательность, которая определяет схему
движения процесса. От разработчиков код подтверждается для сохранения
изменений и затем попадает в хранилище (репозиторий). Затем сервер
интеграции CI определяет, что в репозитории произошли изменения и запускает
44
сборку кода вместе с необходимыми зависимостями. После сборки необходимо
запустить тесты, озвученные в главе 1.3.2. Затем, если тесты проходят проверку,
собранный код разворачивается в окружении, предназначенном для разработки
и тестирования, где снова проходит тестирование, например, миграций и
интеграционные тесты. Затем, если все задачи, которые необходимо было
выполнить, закрыты разработчиками, то коду присваивается версия и
отправляется в производственное окружение. И уже оттуда мы можем снимать
телеметрию, и таким образом иметь представление о том, как работает наш код.
Рисунок 22. Схема процесса доставки программного обеспечения
1.4.2 Обоснование проектных решений по программному обеспечению
Так как разработка осуществляется на языке Java версии 12.0.1, сборщик
для зависимостей выбрали Maven [9].
Для автоматизации сборки и деплоймента в роли CI сервера используется
TeamCity [17] сервер и агенты сборки в связи с тем, что порог вхождения для
использования гораздо ниже других решений, таких, как GitlabCI или
BitbucketCI.
Собранные артефакты необходимо заворачивать в универсальные образы
с определённым окружением, для этого решено использовать образы Docker [8],
с установленной системой Alpine 3.11 последней версии и установленной Java
12.0.1, это единственные образы, которые проходят все тесты на уязвимости в
Trivy.
45
Готовые образы с собранным кодом внутри разворачиваются в Amazon
Container Services, который помогает оркестрировать и настраивать
взаимодействие между микросервисами.
Когда код необходимо разворачивать на девелоперском или
производственном окружении, мы хотим это описать кодом [3], чтобы избежать
рутинной операции и минимизировать количество ошибок, которое возникает
из-за разницы окружений. Поэтому для разворачивания инфраструктуры выбран
Terraform [22], для хранения состояния изменений, сделанных в Terraform,
используется Amazon Simple Storage Service [23] хранилище. Для управления
конфигурациями выбран Ansible [18] из-за поддержки изнутри системы
автоматизации Amazon Systems Manager [24], который также позволяет
автоматизировать рутинные операции конфигурирования окружения.
Выбор базы данных
Мы выбирали базы данных для агрегации логов и их последующей
обработки. Платформа AWS предоставляет CloudWatch Logs для хранения логов
и метрик. Но мы хотели каким-то образом иметь доступ через пользовательский
интерфейс и аналитику. Для этого мы решили отправлять данные в документ-
ориентированную базу данных и затем установить инструмент для аналитики.
Мы выбирали между ClickHouse и ElasticSearch.
Таблица 3
Сравнение СУБД ClickHouse и ElasticSearch
№ п/п
ClickHouse
ElasticSearch
1.
Быстрая
Мощный API с возможностью обрабатывать
входящие данные, поддержка CRUD
2.
Хорошо сжимает
данные
Поисковая система, обратный индекс
3.
RESTful
Поиск по базе близок к реальному времени
4.
Удобный CLI
Предлагает решение с пользовательским
интерфейсом для аналитики Kibana
Источник: https://baza.diplomsite.ru/previewfile/1758