Повседневная работа с Jenkins

1. Повседневная работа с Jenkins

Основы сборки и развертывания сервисов

2. Continuous Integration (CI)

Непрерывная интеграция
Практика включает в себя:
Хранение кода в системе контроля
версий (VCS)
Code Review
Частые автоматизированные сборки
Модульное тестирование
Статистическая проверка качества
кода
Автоматизированное развертывание
на среды разработки
Проверка работоспособности системы
после развертывания
Основные инструменты CI:
Git, Git-LFS, BitBucket
JUnit, Jest
Maven, Npm (yarn)
SonarQube
Sonatype Nexus OSS, Harbor
Jenkins

3. Continuous delivery (CD)

Непрерывная поставка
Практика включает в себя:
Хранение инсталляционного
пакета(дистрибутива) в централизованном
хранилище.
Гарантирование того, что единый
дистрибутив пройдет все циклы
тестирования.
Хранение конфигураций тестовых сред в
централизованном версионном хранилище.
Автоматизацию развертывания приложения
на среды тестирования.
Автоматические проверки успешности
процесса развертывания.
Интеграция с инструментами тестирования–
функционального, нагрузочного и
динамического тестирования на безопасность.
Основные инструменты CD:
Sonatype Nexus OSS, Harbor
Jenkins
BitBucket
Разворачиваются сервисы в кластере
Kubernetes
Проверка успешности развертывания
осуществляется несколькими способами:
Jenkins как основной оркестратор, средства
мониторинга и работы с кластером Kibana,
Rancher, Grafana

4. Part I build

5. Build with Jenkins: pipeline script

Pipeline plugin — решение, реализованное в виде
плагина к Jenkins, позволяющее воплотить принцип
«процесс развертывания как код»
Представляет собой Groovy-скрипт
Обычное расположение в GIT-репозитории:
distribution/Jenkins-ci/build.groovy
Структура pipeline-скрипта:
Параметры
Агент
Этапы и шаги выполнения
Post-секция
Основным параметром для сборки является ветка
репозитория, изменения по которой необходимо
будет протестировать в дальнейшем на стенде

6. Build with Jenkins: main stages

SCM – Source Control
Management
Проверка наличия GIT-репозитория
Проверка наличия указанной ветки из
параметров в GIT-репозитории
Копирование репозитория в рабочее
пространство Jenkins
Set Env(ironments)
Проверка ввода всех необходимых
параметров
Определение характеристик сборки
Инициализация необходимых
переменных для сборки
Формирование dockerTag
Build <project_name>
Сборка проекта с Maven или Npm
(yarn)
Unit Tests/Tests
Тестирование проекта
Create images
Сборка докер-образов
Push images
Отправка докер-образов в хранилище

7. Build with Jenkins: docker

Docker – платформа, позволяющая упаковывать приложение вместе со всей его
средой.
Три главных понятия в Docker:
Образы (Images). Образ содержит файловую систему, которая будет доступна приложению, и
другие метаданные (такие как путь к исполняемому файлу, который должен быть исполнен
при запуске образа; данные приложения)
Хранилища (Registry). Хранилище Docker – это репозиторий , в котором хранятся образы
Docker и который упрощает обмен этими образами между различными людьми и
компьютерами.
Контейнеры (Containers). Контейнер на основе Docker – это обычный контейнер Linux,
созданный из образа на основе Docker. Выполняемый̆ контейнер – это процесс, запущенный
на хосте, на котором работает Docker, но он полностью изолирован как от хоста, так и от всех
других процессов, запущенных на нем.
Docker поддерживает под одним именем несколько версий или вариантов одного и
того же образа.
Каждый вариант образа должен иметь уникальный тег

8. Build with Jenkins: docker-tag

Пример для разбора (все совпадения случайны):
Ветка d/SM-98339-demo-branch
Хэш коммита 71173edd7df0127465dcec352cf…
В pipeline dockerTag формируется на этапе «Set Env»
Имя ветки и коммит являются составляющими тега образа контейнера
Тег состоит из трех частей:
Наименования рабочей ветки, с преобразованием в допустимый формат: d__SM-98339-demo-
branch
Вторая часть содержит в себе часть хэша коммита длиной 11 символов: 71173edd7df
Третья часть представляет из себя постфикс. Постфикс бывает трех видов:
DEV - используется для dev-контура.
SNAPSHOT или SNAPSHOT_LT могут использоваться в stage-контуре.
STABLE используется в тегах образов для развертывания приложений в prod-зоне.
Все три части тега конкатенируются между собой двумя нижними подчеркиваниями.
Итоговый тег по нашему примеру будет выглядеть следующим образом:
d__SM-98339-demo-branch__71173edd7df__DEV

9. Build with Jenkins: create images

Образы, которые должны быть собраны в рамках текущей задачи в Jenkins, могут быть
сформированы двумя способами:
На основе файла *.yml, в котором перечислены наименование будущего образа и рабочие директории,
которые должны оказаться в образе (файл содержит в названии «docker-list»)
На основе Dockerfile
На этапе «Set Env» формируется список образов (dockerList) на основе выбранного файла
Этап «Create Images» создает по сформированным ранее dockerTag и dockerList образы
контейнеров (команда docker build)
Полное наименование образа будет выглядеть примерно так:
edupower-flyway-data:d__SM-98339-demo-branch__71173edd7df__DEV

10. Build with Jenkins: push images

На этапе «Push images» образы отправляются в централизованное хранилище
Harbor
В зависимости от проекта, образ может лежат в различных каталогах хранилища.
Например, образы edu-back отправляются в каталог education:
Если требуется проверить образ, его можно «забрать» из хранилища и запустить
на основе него контейнер
В дальнейшем, образ из Harbor будет использоваться при развертывании
приложения на стенде

11. Error analysis using Jenkins

Характерным признаком того, что сборка закончилась неудачно, является
покраснение любого из этапов сборки и статус FAILURE её завершения
Сборка может быть в статусе UNSTABLE, тогда цвет этапа, который не смог
завершиться успешно, будет окрашен в желтый цвет

12. Error analysis using Jenkins

Для анализа ошибок можно использовать два
инструмента:
1.
Console Output: выводит логи сборки в текстовом
формате, с простым форматированием
Чтобы воспользоваться этим инструментом, необходимо
перейти в провалившеюся сборку и в контекстном меню
слева выбрать «Console Output».
2.
Blue Ocean: позволяет визуализировать этапы сборки
и прочитать логи конкретного шага
Чтобы воспользоваться этим инструментом, необходимо
перейти в провалившеюся сборку и в контекстном меню
слева выбрать «Open Blue Ocean».

13. Part II DEPLOY

14. Kubernetes Cluster Architecture

Kubernetes – это программная система, которая позволяет легко развертывать
контейнеризированные приложения и управлять ими.
На аппаратном уровне кластер Kubernetes состоит из множества узлов, которые
можно разделить на два типа:
Ведущий узел (мастер), на котором размещена плоскость управления (Control
Plane) Kubernetes, контролирующая и управляющая всей системой Kubernetes
Рабочие узлы, на которых выполняются развертываемые приложения.
Плоскость управления – это то, что управляет кластером и заставляет его
функционировать.
Компоненты плоскости управления содержат и управляют состоянием кластера,
но не выполняют приложения. Это делается рабочими узлами

15. Kubernetes clusters in dev-zone

В контуре DEV существует два рабочих
За группами разработки или отдельными
Каждый кластер в DEV-контуре состоит
В каждом кластере выделено больше 110
кластера Kubernetes - dev1 и dev2
из:
3 экземпляров хранилищ данных ETCD (
компонент плоскости управления,
надежное распределенное хранилище
данных, которое непрерывно сохраняет
конфигурацию кластера)
3 экземпляров ведущего узла (master
nodes)
> 50 экземпляров рабочих узлов (workers)
2 балансировщиков нагрузки (load
balancers)
разработчиками закреплены свои стенды
стендов
О принадлежности к определенному
кластеру нам говорит префикс названия
стенда: dev1-100 (первый кластер),
dev2-100 (второй кластер)
Сквозная нумерация стендов в кластере
существует для их очевидного
разделения между разработчиками.
Однако, простой нумерации для
развертывания сервисов недостаточно

16. Dev-stands

Необходимо разделять сервисы, которые могут связываться с внешним миром и
создают определенные риски безопасности, и сервисы, которые работают "под
капотом" и не должны контактировать ни с кем, кроме других сервисов.
В нашей продуктивной среде существуют определенные подсети, которые
позволяют разделить такие сервисы:
DMZ - подсеть, где располагаются front-балансировщики и front-сервисы системы ШЦП.
Подсети DMZ имеют выход в Интернет
INSIDE - подсеть, где располагаются backend-сервера и сервисы. Подсети INSIDE не
имеют выход Интернет
В Kubernetes для группировки объектов в отдельные, неперекрывающиеся группы
используется пространство имен - namespace
Мы группируем DEV-стенды не только по принципу сквозной нумерации, а также
добавляем к этой группировке признак DMZ-сервисов и INSIDE-сервисов.

17. Dev-stands

Таким образом, стенды – это namespace в кластере Kubernetes. Наименование этих namespace: devX-
YY-dmz и devX-YY-inside, где X – номер кластера, а YY – сквозной номер стенда
Физические ресурсы, касающиеся размера оперативной памяти, общего
объема диска, количества ядер процессора и т.д. распределены на кластер, а не
на namespace!
Специфичные названия стендов неочевидны, потому что при запуске деплоя сервисов мы выбираем
стенд из списка, где нет четких разделений на зоны
Однако, для корректного развертывания приложения нам необходимо сообщить Kubernetes, где
именно мы хотим развернуть тот или иной компонент

18. Deploy with Jenkins: pipeline script

Обычное расположение в GIT-репозитории: distribution/Jenkins-
ci/deploy.groovy
Основные параметры:
STAND_NAME – номер стенда, на который требуется развернуть
сервис.
DOCKER_TAG – докер-тег собранного образа из задачи по сборке
приложения.
Тег проверяется на наличие нужных образов в Harbor, а также
используется в качестве версии для установки приложения на стенд
CONFIG_BRANCH – ветка конфигураций для Kubernetes (название
может быть дополнено названием сервиса или аббревиатурой K8S).
По умолчанию, наименование ветки парсится из DOCKER_TAG.
Указывает Jenkins, с какой веткой необходимо клонировать
репозиторий для определения параметров запуска развертывания
приложения.

19. Deploy with Jenkins: main stages

Основные этапы и шаги развертывания, без привязки к наименованию,
заключаются в следующем:
Проверка наличия обязательных параметров
Инициализация необходимых переменных для развертывания
Копирование репозитория в рабочее пространство Jenkins с указанной веткой
конфигурации
Проверка конфигураций для развертывания:
Если сервис уже перешел на HELM, проверка с lint корректности написанных шаблонов
Если сервис развертывается с манифестами k8s, то проверяется наличие манифестов k8s
приложения в скопированном репозитории, а также осуществляется замена переменных в
манифестах на полученные значения на ранних этапах задачи Jenkins
Деплой сервиса на стенд

20. Deploy with Jenkins: main jobs

Наиболее часто используемые задачи по развертыванию в Jenkins следующие:
Job Name
Repository
Deployment method
BackDeploy
edu-back
Helm
FrontDeploy
edu-front
Helm
CatalogBackDeploy
edu_catalog
Helm
S21_deploy_front
s21-application
Helm
S21_deploy_front_exam
s21-application-exam
Helm
S21_deploy_front_admin
s21-administration
Helm
Deploy_with_helmfile
Перечень микросервисов
Helm
Deploy_Service
dataspace-core
k8s
03_AppDeploy
edu-mfe-designer, edu-frontend-mfe
Helm
BootcampFrontDeploy
Bootcamp
Helm

21. Deploy with Jenkins: FULLDEPLOY

Перечисленные на предыдущем слайде задачи входят в состав FullDeploy
FullDeploy позволяет развернуть несколько сервисов, без использования
поочередного ручного запуска
Как и в других задачах по деплою, в качестве основного параметра необходимо
передать номер стенда, куда требуется развернуть свежие сервисы
Учитывая, что количество сервисов большое, нам не получится передать один
единственный DOCKER_TAG для всех
Для того, чтобы передать теги, существует репозиторий edu-deploy_version, в
котором находится файл edupower_deploy_versions.yaml, в котором перечислены
сервисы для деплоя, с указанием ветки конфигурации и докер-тега

22. Deploy with Jenkins: FULLDEPLOY

В edupower_deploy_versions.yaml
включены последовательности и словари.
У каждого сервиса есть набор свойств (пар
«ключ-значение»):
Имя сервиса, для разграничения
Признак развертывания (deploy: true/false)
Тег (dockerTag: <value>)
Ветка конфигурации (k8s_config_branch:
<value>)
В разных ветках репозитория эти свойства
будут различаться

23. Deploy with Jenkins: FULLDEPLOY

FullDeploy не перегружен той логикой, которая прописана в Pipeline задач по
деплою отдельных сервисов
FullDeploy вызывает задачи, относящиеся к сервису, у которого был проставлен
признак развертывания
В качестве параметров передаются: номер стенда, докер-тег и ветка конфигурации
(как основные)
Чем больше сервисов указано для развертывания, тем дольше будет выполняться
задача
Некоторые этапы развертывания выполняются параллельно

24. Stand diagnostics

Kibana
https://kibana-dev.pcbltools.ru/
Инструмент визуализации и изучения данных, который применяется для таких
задач, как анализ журналов и временных рядов, мониторинг приложений и текущих
процессов.
Rancher
первый кластер: https://rancher01.pcbltools.ru/login
второй кластер: https://rancher02.pcbltools.ru/login
Платформа для управления Kubernetes-кластерами. Продукт ориентирован на легкое
управление локальными и/или облачными кластерами контейнеров.
С помощью этой платформы можно просматривать логи запущенного контейнера на стенде,
выполнять команды внутри него, перезапускать/останавливать контейнеры