Исследование и применение инструментов автоматизации разработки и непрерывной интеграции программного кода микросервисных приложений

Актуальность темы выпускной квалификационной работы (ВКР). Современные компании имеют сложившеюся бизнес-модель, которая в условиях кризиса и развития современных технологий может стать неэффективной в виду быстрых изменений во внешней среде. Многие компании могут вести деятельность по уже имеющимся моделям, но в таком случае вероятна потеря рынка, а также снижение показателей рентабельности. Скорость принятия решения по адаптации к новым условиям рынка и грамотном управлении предприятием влияет не только на конкурентоспособность, но и на сохранении бизнеса в целом.

В условиях информатизации и. автоматизации, конкурентоспособность компании на рынке достигается путем внедрения передовых решений автоматизации и отладкой бизнес-процесса.

Современные программные продукты представлены в виде облачных сервисов, что в свою очередь повышает доступность и снижает стоимость использования. На рынке ПО произошла революция облачных технологий, теперь имея доступ к интернету можно получить необходимые услуги по обработке данных. Такой подход потребовал создание теоретической и методологической базы для интеграции и эксплуатации облачных решений на предприятии.

Степень разработанности проблемы. Степень изученности отдельно рассматриваемых инструментов в мире достаточно высока, однако в России практика комплексного использования облачно-ориентированных инфраструктур и прикладных облачных решений пока что мала. Главными интересантами в разработке облачных сервисов, свободных технологий, методологий разработки являются такие корпорации как: Google, Amazon, Microsoft, VMWare, RedHat.

Объектом исследования в данной выпускной квалификационной работе является сервис трансляций автоспортивных событий.

Предметом исследования ВКР является облачно-ориентированная архитектура и микросервисная разработка приложений.

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

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

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

Для достижения данной цели решена оснавная задача исследования – разработка метода применения системы оркестрации Kubernetes и пакетного менеджера Helm для автоматизации развертывания приложения на базе облачного провайдера Amazon AWS.

Решение поставленной задачи было достигнуто путем выполнения следующих этапов:

• Анализ существующей инфраструктуры;
• Анализ инструментов оркестрации и автоматизции развертывания;
• Подготовка инфраструктуры как код для развертывания системы оркестрации и инфраструктуры;
• Подготовка СУБД для переноса на облачный сервис Amazon RDS Aurora;
• Рефакторинг деплоев контейнеризированного приложения;
• Внедрение разработанного решения.

Объектом исследования является платформа motorsport.tv.

Предметом исследования является облачно-ориентированная модель инфраструктуры и непрерывная разработка микросервисного приложения

Информационную базу составляют референтные модели, существующие ИТ-решения.

Методической основой исследования является метод реинжиниринга бизнес-процессов.

Теоретической основой решения является архиектурный подход к управлению предприятием

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

Теоретическая значимость ВКР состоит в развитии концепций архитектурного подхода для компаний, нацеленных на внедрение облачно ориентированных инфраструктур.

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

Использование облачной архитектуры и автоматизация бизнес-процессов в свою очередь приводит к следующим положительным эффектам:

• Возможность масштабирования и тиражирования;
• Снижение человеческого фактора как следствие снижение ошибок в виду полной автоматизации с использованием принципов и практик разработки программного обеспечения называемой «Инфраструктура как код» (IaC);
• Предсказуемость результатов, возможность прогнозирования и планирования;
• Снижение себестоимость продукта в виду исключения избыточных бизнес-процессов;
• Повышения отказоустойчивости в виду автоматического управления контейнеризированным приложением системой оркестрации;
• Использование системы контроля версий как истинный источник данных;
• Окружение для локальной разработки максимально приближено к продуктивной среде, и в идеальных условиях разрабатываемы код локально у разработчика должен так же работать и в облаке.

1.1.1 Терминология

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

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

«Темный запуск», или dark launch – это практика развертывания кода в рабочей среде, которая получает производственный трафик, но не влияет на взаимодействие с пользователем. Новые изменения развертываются вместе с существующими реализациями, и один и тот же трафик часто направляется для тестирования в оба места. Старая реализация все еще будет подключена к пользовательскому интерфейсу, а новый код можно оценить на правильность «за кулисами», используя реальные пользовательские запросы в производственной среде.

...

1.1.2 Что было до DevOps

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

...

1.1.6 Жизненный цикл DevOps

Непрерывное развитие

На первом этапе происходит планирование и кодирование программного обеспечения, а также формируется видение проекта.

Код может быть написан на любом языке, но поддерживается с помощью средств контроля версий. Процесс поддержки называется управлением исходным кодом (SCM). В нем используются следующие инструменты: Git, SVN, Mercurial, CVS и JIRA.

...

1.2.1 Непрерывная интеграция и ее преимущества

Непрерывная доставка (НД) является продолжением непрерывной интеграции. Этот подход нацелен на автоматизацию процесса доставки программного обеспечения, что позволяет группам в любое время легко и уверенно развернуть свой код в производство. Поскольку кодовая база всегда находится в состоянии развертывания, релиз программного обеспечения становится непримечательным событием без сложного ритуала. Команды могут быть уверены, что они могут выпускать ПО в любое время без сложной координации или тестирования на поздней стадии. Как и НИ, непрерывная доставка – это практика, для эффективности которой требуется сочетание технических и организационных улучшений.

...

1.2.4 Типы тестирования

Модульное тестирование

Модульные тесты отвечают за тестирование отдельных элементов кода изолированным и целенаправленным способом. Так проверяется работа отдельных функций и классов. Любые внешние зависимости заменяются реализациями-заглушками или макетами, чтобы полностью сфокусировать тест на рассматриваемом коде.

...

2.1 Системы контроля версий кода

Под системой контроля версий понимается механизм сохранения промежуточных состояний кода разрабатываемого программного обеспечения. То есть с помощью этой системы программист может управлять своими файлами во времени: смотреть историю изменений файлов и каталогов, возвращаться к более ранним версиям кода, объединять несколько версий файла

Для удобства разработки в 2005 году Линус Торвальдс разработал распределенную систему контроля версий для собственного ядра Linux. Git система представляет собой каталог на файловой системе, в котором хранятся исходные тексты программ, файлы конфигурации репозитория, файлы журналов в которых хранятся операции выполняемые с репозиторием, а так же индекс файлов репозитория. Предшественниками git были системы контроля версий такие как:

...

2.1.1 Инструменты жизненного цикла DevOps

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

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

...

2.2 Контейнеризация и оркестрация

В мире операционной системы Linux уже довольно долго существовала технология контейнеризации — первые идеи о раздельных пространствах имён для файловых систем и процессов появились уже более десятилетия назад. А в относительно недавнем прошлом появился LXC и стал стандартным для пользователей Linux способом взаимодействовать с мощной технологией изоляции, спрятанной в ядре Linux.

...

2.2.1 Docker

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

...

2.2.3 OpenShift

Конкуренцию Kubernetes составляет продукт компании RadHat – openshift. По своей сути это тот же Kubernetes (сертифицированный) но только готовый из коробки для Enterprise потребителя. Описывать внутреннее устройство OpenShift не имеет смысла так как, по сути, это и есть Kubernetes только с рядом дополнений от RedHat, поэтому ниже будут рассмотрены отличия от Kubernetes.

...

Таблица 1 – Примеры команд утилит kubectl и ОС

...

Таблица 2 – Развертывание кода на OpenShift и K8s

...

2.3 Инфраструктура как код

Инфраструктура как код (IaC; Infrastructure-as-Code) является подходом к управлению и описанию инфраструктуры с помощью конфигурационных файлов, исключая необходимость ручного конфигурирования и интерактивного взаимодействия с серверами. IaC может включаться в себя как скрипты так и декларативное управление инфраструктурой. Чаще всего используется декларативный метод взаимодействия.

...

Таблица 3 – Инструменты управления инфраструктурой

...

3 Внедрение и перенос контейнерезированного приложения в Kubernetes

Практической частью ВКР является перенос контейнеризированного облачно-ориентированного приложения предоставляющий сервис трансляций мотоспортивных мероприятий в систему оркестрации Kubernetes. Проект доступен по адресу https://motorsport.tv. Входные данные при реализации поставленной задачи были следующие.

Стек технологий:

...

3.1.1 Подготовка аккаунта AWS

Перенося приложение на новую архитектуру, от бизнеса стояла задача не просто перенести контейнеризированное приложение в Kubernetes, а развернуть его на новом AWS аккаунте. Для того что бы начать перенос приложения сначала необходимо подготовить аккаунт, другими словами, инфраструктуру. Как упоминалось в работе для управления инфраструктурой компания уже использовала инструмент управления инфраструктурой Terraform.

Под настройкой инфраструктуры понимается следующе:

...

3.1.5 Подготовка окружений в Kubernetes

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

...

3.1.7 Мониторинг системы

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

...

ЗАКЛЮЧЕНИЕ

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

Таким образом первым этапом выполнялись задачи по анализу инструментов и описанию логики взаимодействия непрерывной интеграции в проекции новой архитектуры. На данном этапе были выбраны инструменты для развертывания инфраструктуры, инструменты для шаблонизации приложения, сопутствующие инструменты для мониторинга системы, СУБД для переноса приложения, и описаны процессы непрерывной интеграции в новой инфраструктуре.

...

ПРИЛОЖЕНИЕ А

Листинг А.1 – шаблон для создания пользователей, политик и групп автогенерируемого файла *.tf для Terraform генерируемый Ansible

...

ПРИЛОЖЕНИЕ Б

Листинг Б.1 – Код для исполнения kubectl

...