Jenkins Jobs

Август 4, 2022

Содержание

2. CONTINUOUS INTEGRATION (CI) Непрерывная интеграция Практика включает в себя: Хранение кода в системе контроля версий (VCS)
3. CONTINUOUS DELIVERY (CD) Непрерывная поставка Практика включает в себя: Хранение инсталляционного пакета(дистрибутива) в централизованном хранилище. Гарантирование
4. PART I BUILD
5. BUILD WITH JENKINS: PIPELINE SCRIPT Pipeline plugin — решение, реализованное в виде плагина к Jenkins, позволяющее
6. BUILD WITH JENKINS: MAIN STAGES SCM – Source Control Management Проверка наличия GIT-репозитория Проверка наличия указанной
7. BUILD WITH JENKINS: DOCKER Docker – платформа, позволяющая упаковывать приложение вместе со всей его средой. Три
8. BUILD WITH JENKINS: DOCKER-TAG В pipeline dockerTag формируется на этапе «Set Env» Имя ветки и коммит
9. BUILD WITH JENKINS: CREATE IMAGES Образы, которые должны быть собраны в рамках текущей задачи в Jenkins,
10. BUILD WITH JENKINS: PUSH IMAGES На этапе «Push images» образы отправляются в централизованное хранилище Harbor В
11. ERROR ANALYSIS USING JENKINS Характерным признаком того, что сборка закончилась неудачно, является покраснение любого из этапов
12. ERROR ANALYSIS USING JENKINS Для анализа ошибок можно использовать два инструмента: Console Output: выводит логи сборки
13. PART II DEPLOY
14. KUBERNETES CLUSTER ARCHITECTURE Kubernetes – это программная система, которая позволяет легко развертывать контейнеризированные приложения и управлять
15. KUBERNETES CLUSTERS IN DEV-ZONE В контуре DEV существует два рабочих кластера Kubernetes - dev1 и dev2
16. DEV-STANDS Необходимо разделять сервисы, которые могут связываться с внешним миром и создают определенные риски безопасности, и
17. DEV-STANDS Таким образом, стенды – это namespace в кластере Kubernetes. Наименование этих namespace: devX-YY-dmz и devX-YY-inside,
18. DEPLOY WITH JENKINS: PIPELINE SCRIPT Обычное расположение в GIT-репозитории: distribution/Jenkins-ci/deploy.groovy Основные параметры: STAND_NAME – номер стенда,
19. DEPLOY WITH JENKINS: MAIN STAGES Основные этапы и шаги развертывания, без привязки к наименованию, заключаются в
20. DEPLOY WITH JENKINS: MAIN JOBS Наиболее часто используемые задачи по развертыванию в Jenkins следующие:
21. DEPLOY WITH JENKINS: FULLDEPLOY Перечисленные на предыдущем слайде задачи входят в состав FullDeploy FullDeploy позволяет развернуть
22. DEPLOY WITH JENKINS: FULLDEPLOY В edupower_deploy_versions.yaml включены последовательности и словари. У каждого сервиса есть набор свойств
23. DEPLOY WITH JENKINS: FULLDEPLOY FullDeploy не перегружен той логикой, которая прописана в Pipeline задач по деплою
24. STAND DIAGNOSTICS Kibana https://kibana-dev.pcbltools.ru/ Инструмент визуализации и изучения данных, который применяется для таких задач, как анализ
26. Скачать презентацию

Слайд 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
Сборка проекта с 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
В 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

Пример для разбора (все совпадения случайны):
Ветка d/SM-98339-demo-branch
Хэш коммита 71173edd7df0127465dcec352cf…

Слайд 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
Для анализа ошибок можно использовать два инструмента:
Console Output:

выводит логи сборки в текстовом формате, с простым форматированием
Чтобы воспользоваться этим инструментом, необходимо перейти в провалившеюся сборку и в контекстном меню слева выбрать «Console Output».
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 существует два рабочих кластера Kubernetes

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

следующие:

Слайд 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: )
Ветка конфигурации (k8s_config_branch: )
В разных ветках репозитория эти свойства будут различаться

Слайд 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-кластерами. Продукт ориентирован на легкое управление локальными и/или облачными кластерами контейнеров. С помощью этой платформы можно просматривать логи запущенного контейнера на стенде, выполнять команды внутри него, перезапускать/останавливать контейнеры

Jenkins Jobs

Содержание

CONTINUOUS INTEGRATION (CI)Непрерывная интеграция Практика включает в себя:Хранение кода в системе

CONTINUOUS DELIVERY (CD)Непрерывная поставкаПрактика включает в себя:Хранение инсталляционного пакета(дистрибутива) в централизованном

PART I BUILD

BUILD WITH JENKINS: PIPELINE SCRIPTPipeline plugin — решение, реализованное в виде плагина к Jenkins,

BUILD WITH JENKINS: MAIN STAGESSCM – Source Control ManagementПроверка наличия GIT-репозиторияПроверка наличия

BUILD WITH JENKINS: DOCKERDocker – платформа, позволяющая упаковывать приложение вместе со всей его

BUILD WITH JENKINS: DOCKER-TAGВ pipeline dockerTag формируется на этапе «Set Env»Имя ветки

BUILD WITH JENKINS: CREATE IMAGESОбразы, которые должны быть собраны в рамках текущей

BUILD WITH JENKINS: PUSH IMAGESНа этапе «Push images» образы отправляются в централизованное

ERROR ANALYSIS USING JENKINSХарактерным признаком того, что сборка закончилась неудачно, является

ERROR ANALYSIS USING JENKINSДля анализа ошибок можно использовать два инструмента:Console Output:

PART II DEPLOY

KUBERNETES CLUSTER ARCHITECTUREKubernetes – это программная система, которая позволяет легко развертывать

KUBERNETES CLUSTERS IN DEV-ZONEВ контуре DEV существует два рабочих кластера Kubernetes

DEV-STANDSНеобходимо разделять сервисы, которые могут связываться с внешним миром и создают

DEV-STANDSТаким образом, стенды – это namespace в кластере Kubernetes. Наименование этих

DEPLOY WITH JENKINS: PIPELINE SCRIPTОбычное расположение в GIT-репозитории: distribution/Jenkins-ci/deploy.groovyОсновные параметры:STAND_NAME – номер

DEPLOY WITH JENKINS: MAIN STAGESОсновные этапы и шаги развертывания, без привязки к

DEPLOY WITH JENKINS: MAIN JOBSНаиболее часто используемые задачи по развертыванию в Jenkins

DEPLOY WITH JENKINS: FULLDEPLOYПеречисленные на предыдущем слайде задачи входят в состав FullDeployFullDeploy

DEPLOY WITH JENKINS: FULLDEPLOYВ edupower_deploy_versions.yaml включены последовательности и словари. У каждого сервиса

DEPLOY WITH JENKINS: FULLDEPLOYFullDeploy не перегружен той логикой, которая прописана в Pipeline

STAND DIAGNOSTICSKibana https://kibana-dev.pcbltools.ru/ Инструмент визуализации и изучения данных, который применяется для таких

Похожие презентации