Лабораторная работ №2
по дисциплине: Основы DevOps
на тему: Автоматизация сборки и деплоя Python Docker-приложений через Jenkins с интеграцией GitHub
Группа: ПИ-431Б
Студент: Махмутов Чингиз Ильдарович
Принял: Аитбаев Вадим

---

1. Цели работы

Цель работы является освоение практических навыков автоматизации процесса непрерывной интеграции и развертывания (CI/CD) с использованием Jenkins, а также налаживание взаимодействия с удалённым репозиторием GitHub посредством Webhook.

В рамках работы создадим собственный Jenkins Job, используя готовый pipeline скрипт (Jenkinsfile), освоим управление параметрами сборки, настройку вебхуков для инициирования автоматических сборок, запустим тесты в изолированном Docker-контейнере и развернем приложение с учётом индивидуальных параметров (порт, имя студента).

---

2. Теоретическая часть

2.1. CI/CD

Непрерывная интеграция (CI, англ. Continuous Integration) – это практика разработки программного обеспечения (ПО), которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем.

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

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

Для организации процесса непрерывной интеграции необходимо развернуть на выделенном сервере службу, которая будет выполнять получение исходного кода из репозитория (CVS, subversion, github, bitbucket и т.п.), сборку проекта, выполнение тестов, развертывание готового проекта и отправку отчетов о работе. Существует большое количество веб-сервисов, которые предоставляют возможности непрерывной интеграции: Jenkins, Buddy, TeamCity, Comboo CI, Gitlab CI, Circle CI, Codeship, CruiseControl, Travis CI и т.д.

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

2.2. Что такое Jenkins и какие у него особенности

Jenkins — это система потоковой сборки для автоматизации всех видов задач, связанных с созданием, тестированием, доставкой или развёртыванием программного обеспечения.

При этом Jenkins — не просто сервер непрерывной интеграции, а полноценный фреймворк для создания CI/CD-систем и других автоматизированных процессов разработки. Всё благодаря гибкой настройке программы, которая включает:

• Модульность. Модульная архитектура позволяет расширять функциональность Jenkins с помощью плагинов и адаптировать работу программы под конкретные задачи и процессы разработки.
• Масштабируемость. Jenkins постоянно развивается благодаря открытой архитектуре и обширному сообществу. Разработчики могут создавать для него собственные плагины и интеграции, тем самым адаптируя программу к новым требованиям и технологиям. Также это позволяет добавлять слейв-узлы, тем самым увеличивая общую производительность ПО.
• Высокую совместимость. Благодаря большой библиотеке плагинов Jenkins легко интегрируется с различными инструментами разработки, системами управления версиями, облачными платформами и другими сервисами.

К примеру, с помощью плагинов Jenkins можно интегрировать с API-платформой МТС Exolve, через которую программисты получают автоматические SMS о статусе сборки ПО, данные об ошибках в коде, о завершении определённых этапов разработки и прочих событиях. Так специалисты смогут быстрее получать актуальную информацию о ходе своих проектов и экономить время для других задач.

2.3. Как работает Jenkins

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

Фреймворк Jenkins функционирует в распределённой архитектуре: мастер-сервер (контроллер) координирует процессы и делегирует задачи, а вспомогательные слейв-серверы — агенты разгружают контроллер и выполняют поставленные им команды.

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

В целом у фреймворка для непрерывной разработки Jenkins множество преимуществ:

• Простая настройка. Jenkins содержит исполняемые файлы, которые легко устанавливаются на различные операционные системы вроде Windows и Mac. Так как это автономное решение на базе Java, его настройка занимает всего пять минут.
• Открытый исходный код. Принцип Open Source позволяет работать в программе бесплатно. Кроме того, сообщество Jenkins предлагает огромную библиотеку учебных пособий, кейсов и другой информации для программирования.
• Большой выбор плагинов. В Jenkins насчитывается более 2000 дополнительных модулей для управления инфраструктурой, анализа, тестирования, интеграций и других задач разработки.

---

3. Практическая часть

3.1. Создание и конфигурирование Jenkins Job

Был разработан Jenkins Job с именем student-chingiz-mahkmutov со pipeline скриптом (Jenkinsfile), который указан ниже:

pipeline {
    agent any
    
    parameters {
        string(name: 'STUDENT_NAME', defaultValue: 'Chingiz Mahmutov', description: 'Имя студента')
        string(name: 'PORT', defaultValue: '8091', description: 'Порт')
    }
    
    stages {
        stage('Удаляем старые контейнеры и образы') {
            steps {
                script {
                    // Останавливаем и удаляем контейнер с нужным именем, если он есть
                    sh "docker ps -a -q --filter name=hello-mahmutov-container | xargs -r docker rm -f"
                    // Удаляем образ с нужным именем, если он есть
                    sh "docker images -q student-mahmutov-app | xargs -r docker rmi -f"
                }
            }
        }
        stage('Выгружаем код из репозитория') {
            steps {
                git 'https://github.com/ChinaGiza/DevOpsLaba2.git'
            }
        }
        stage('Собираем docker image') {
            steps {
                script {
                    dockerImage = docker.build("student-mahmutov-app")
                }
            }
        }
        stage('Запускаем тесты в докере') {
            steps {
                script {
                    dockerImage.inside {
                        sh 'python -m unittest test_app.py'
                    }
                }
            }
        }
        stage('Запускаем докер контейнер') {
            steps {
                script {
                    sh "docker run -d --name hello-mahmutov-container -p ${params.PORT}:${params.PORT} -e STUDENT_NAME='${params.STUDENT_NAME}' -e PORT=${params.PORT} student-mahmutov-app"
                }
            }
        }
    }
}

Данный Jenkinsfile имеет структуру, где:

• Параметры pipeline позволяют задавать индивидуальное имя студента (Chingiz Mahmutov) и порт развертывания (8091), делая pipeline максимальное гибким и повторно используемым
• Выгрузка кода из GitHub выполняется через шаг git, что позволяет Jenkins автоматически получать свежие изменения
• Сборка Docker-образа гарантирует, что приложение упаковано в изолированный контейнер, что упрощает переносимость и эксплуатацию
• Выполнение тестов внутри контейнера повышает надежность кода: сборка не пойдет дальше при наличии ошибок
• Запуск Docker-контейнера с параметрами окружения и пробросом порта реализует персонализированный деплой с учетом индивидуального порта и отображением имени студента (Махмутов Чингиз)

3.2. Настройка GitHub WebHook для автоматического запуска сборки

Был создан GitHub Webhook для автоматического запуска сборки, имеющие следующие параметры:

• Payload URL: http://158.160.194.244:8080/github-webhook/
• Content type: application/json
• Which events would you like to trigger this webhook?: Just the push event

3.3. Работа с Jenkins и проверка

Созданный Jenkins Job был успешно собран и запущен.
Результат запуск:

Далее была проведена проверка работы GitHub Webhook.
Созданный commit в GitHub:

Результат запуска после commit:

---

Вывод

В данной лабораторной работе были освоены практические навыки автоматизации процесса непрерывной интеграции и развертывания (CI/CD) с использованием Jenkins, а также налаживания взаимодействие с удалённым репозиторием GitHub посредством Webhook.