Дипломная работа: Автоматизация доставки программного обеспечения при помощи DevOps практик и инструментов в облаке AWS в компании ООО "Команда Лабс"
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
51
Рисунок 28. Настройка балансировщика нагрузки и горизонтальное
масштабирование
Вывод к главе 1
На основания рассмотренного материала выяснили, что для
сопровождения разработки и выкатывания программного обеспечения,
необходимо внедрять лучшие DevOps практики и инструменты для
эксплуатации и разворачивании системы. Самыми главными особенностями
этих процессов является то, что они встраиваются в структуру процесса
разработки продукта. Также для того, чтобы обеспечить упрощение подходов к
безопасности и соответствия требованим гос стандартов, необходимо применять
практики DevSecOps и также встраивать их в процесс разработки.
52
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Для начала определимся с намеченной схемой построения
инфраструктуры, чтобы понять, какие подходы и инструменты будут
использоваться при разработке автоматизации развёртывания окружения.
Разработка в компании происходит по гибкой методологии Agile [1], это
значит, что процесс происходит итерационно, по спиральной модели. Поэтому
важно тестировать и непрерывно улучшать продукт с каждой итерацией.
Рисунок 29. Ожидаемая схема проекта
53
Для начала необходимо организовать виртуальное частное облако (Virtual
Private Cloud, VPC [6]), где будут располагаться внутренние сервисы.
Необходимо организовать разные подсети для различных задач: публичные и
приватные. В публичных сетях будут располагаться ресурсы, к которым
необходим доступ из интернета, такие, как бастион сервер и web-server Nginx. В
приватных сетях будут располагаться сервисы решения HAPICloud и те сервисы,
которые могут иметь связь с внешним миром через NAT и прокси-серверы.
Как видно, мы хотим использовать балансировщик в роли единой точки
входа, который будет распределять трафик HTTPS между NGINX серверами,
которые будут обеспечивать связь с сервисами HAPI, которые развёрнуты в ECS
[7] кластере. Главное требование к этому узлу состоит в устойчивости к
нагрузкам и отказам и в простоте горизонтального масштабирования, поэтому
будут использованы Auto Scaling группы, которые увеличивают количество
инстансов при повышении нагрузки, а также поднимают новые инстансы, если
старые отказали по тем или иным причинам. Для хранения данных, которые
используют сервисы, HAPICloud используется Amazon Relational Database
Service (RDS) PostgreSQL версии 10.6 [26].
Автоматизацией этого этапа развёртывания будут проходить в 2 этапа:
вначале с помощью Packer [27] подготовим запускаемые образы для web-
сервера Nginx, где будем собирать приложение Nginx из исходного кода при
помощи bash скриптов вместе с кастомными модулями, которые необходимо
использовать во время эксплуатации. Также будет использоваться Ansible [18]
для конфигурации и настройки Nginx [13]сервера.
Затем разворачивание инфраструктуры будет происходить c помощью
Terraform [22]. С его помощью в декларативной форме будут созданы
• VPC
• Указаны дата-центры, где будет разворачиваться окружение
• Network Load Balancer для распределения нагрузки
• Подсети
• Шлюз во внешнюю сеть
54
• Определение правил для входящего и исходящего трафика с
помощью Security Groups
• EC2 серверы
• RDS
В роли базы данных для хранения состояния Terraform [22], с которым
могут работать все участники процесса, будет использоваться Amazon S3 [23]
хранилище.
Автоматизация развёртывания приложений HAPICloud будет
происходить при помощи сервера интеграции TeamCity [17]. С его помощью
будет автоматически запускаться сборка и тестирование кода, подтягиваться
зависимости. Созданные в результате артефакты будут заворачиваться в Docker
[8] образы и отправляться в хранилище репозиторий Amazon Container Registry
[10], а затем запускать в Amazon Container Services [7].
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Методология процесса оценки риска для перемещения данных
разработана в соответствии с требованиями 6.1.2, 6.1.3, 8.2 и 8.3 стандарта ISO /
IEC 27001: 2013 [28] «Информационные технологии. Методы защиты. Системы
управления информационной безопасностью. Требования» и Политикой
информационной безопасности внутри компании Data Travel.
При оценке рисков компания придерживается следующих правил:
• Все сотрудники, подрядчики, консультанты, временные и другие
работники Data Travel и его дочерних компаний участвуют в процессах оценки
рисков.
• Данные политики рименимы ко всем активам персональных данных
(personally identifiable information, PII) и среде данных держателей карт.
• Для активов, которые не влияют на безопасность персональных
данных или данных о держателях карт, использование этой формальной
процедуры контроля изменений осуществляется по усмотрению руководства
Data Travel.
55
Определения и термины
ISM - Менеджер информационной безопасности
СУИБ - система управления информационной безопасностью, набор
политик, связанных с управлением информационной безопасностью или
рисками, связанными с ИТ, который обозначает проектирование, реализацию и
обслуживание согласованного набора политик, процессов и систем для
управления рисками для своих информационных активов.
Первый этап - это идентификация всех активов в области действия
СМИБ. Все активы, которые могут повлиять на конфиденциальность,
целостность и доступность данных держателя карты, должны быть
идентифицированы. Активы могут быть бумажными или электронными
документами, приложениями, базами данных, персоналом, компьютерным
оборудованием, комнатами или внешними службами. Для каждого актива Data
Travel должны быть определены владельцы активов - сотрудник или отдел,
ответственный за актив. Следующим шагом является выявление угроз и
уязвимостей, связанных с каждым активом Data Travel. Базовые угрозы и
уязвимости могут быть определены путем выбора из списка, включенного в
Таблицу оценки рисков. Владельцы активов могут определять дополнительные
угрозы и уязвимости в зависимости от контекста применения данного актива
(требования безопасности, бизнес-требования, правовые акты и т. д.)
Для каждого актива Data Travel должны быть определены владельцы
активов - сотрудник или отдел, ответственный за акт.
Последствия и вероятность
Следующим шагом является определение уровня Последствия (влияние
на Data Travel) в случае нанесения урона. Уровень последствий определяется
отдельно для каждой комбинации угрозы/уязвимости в соответствии со
следующей таблицей:
Источник: https://baza.diplomsite.ru/previewfile/1758