Инфраструктурные пайплайны в Jenkins
Привет, Хабр!
Jenkins позволяет автоматизировать всё, от сборки и тестирования кода до деплоя на продакшн. Jenkins работает по принципу пайплайнов, которые можно настраивать под любые нужды проекта.
Инфраструктурный пайплайн — это серия автоматизированных шагов, которые преобразуют ваш код в готовое к использованию на продакшне программное обеспечение. Главная цель всего этого — сделать процесс доставки ПО как можно более быстрым.
После установки Jenkins, запускаем его и переходим в веб-интерфейс, обычно доступный по адресу http://localhost:8080. При первом запуске Jenkins попросит вас ввести пароль, который отображается в консоли или находится в файле на сервере. После ввода пароля идет перенаправление на страницу настройки плагинов.
Для работы с инфраструктурными пайплайнами вам потребуются плагины:
Pipeline: Основной плагин для создания и управления пайплайнами в Jenkins.
Git plugin: Необходим для интеграции с Git и работы с репозиториями.
Docker Pipeline: Позволяет использовать Docker внутри пайплайнов Jenkins.
Также в сеттингах Jenkins есть раздел, связанный с настройкой систем контроля версий, и там нужно добавить репозиторий. Для Git это будет требовать указания URL репозитория и учетку
Теперь можно создать инфраструктурный пайплайн.
Создание базового пайплайна
Пайплайн состоит из серии степов, каждый из которых выполняет определённую задачу. В основном шаги выглядят так:
Checkout — извлечение исходного кода из системы контроля версий
Build — сборка проекта с помощью инструментов сборки, например мавен
Test — запуск автотестов для проверки качества кода.
Deploy — развёртывание собранного приложения на целевой сервер или в облако.
Условия определяют, при каких обстоятельствах должен или не должен выполняться каждый шаг пайплайна. Jenkins Pipeline имеет директиву when, которая позволяет ограничить выполнение шагов определёнными условиями.
Триггеры определяют, что именно запускает выполнение пайплайна:
Push в репозиторий — пайплайн запускается каждый раз, когда в репозиторий поступают новые коммиты.
Расписание — пайплайн может быть настроен на выполнение по расписанию, например, каждую ночь для ночных сборок.
Внешние события — также можно настроить пайплайн на запуск в ответ на внешние события.
Чтобы всё это заработало, необходимо создать Jenkinsfile — файл, который описывает пайплайн. Пример простого Jenkinsfile:
pipeline {
agent any
stages {
stage('Checkout') {
steps {
git 'https://your-repository-url.git'
}
}
stage('Build') {
steps {
sh 'mvn clean package'
}
}
stage('Test') {
steps {
sh 'mvn test'
}
}
stage('Deploy') {
steps {
// шаги деплоя
}
}
}
post {
success {
echo 'Пайплайн успешно завершён.'
}
}
}Jenkinsfile описывает базовый пайплайн с четырьмя стадиями: Checkout, Build, Test и Deploy.
Параметризованные сборки
Параметризированные сборки позволяют динамически управлять параметрами сборки.
Для начала необходимо определить параметры в Jenkinsfile, который используется для настройки пайплайна. Это делается с помощью директивы parameters, где можно указать различные типы параметров: string, choice, booleanParam) и тп.
pipeline {
agent any
parameters {
string(name: 'DEPLOY_ENV', defaultValue: 'staging', description: 'Target environment')
choice(name: 'VERSION', choices: ['1.0', '1.1', '2.0'], description: 'App version to deploy')
booleanParam(name: 'RUN_TESTS', defaultValue: true, description: 'Run tests?')
}
stages {
stage('Initialization') {
steps {
echo "Deploying version ${params.VERSION} to ${params.DEPLOY_ENV}"
script {
if (params.RUN_TESTS) {
echo "Tests will be run"
} else {
echo "Skipping tests"
}
}
}
}
// другие этапы
}
}Далее при запуске система предложит заполнить параметры согласно их определениям.
Можно использовать параметры для условного выполнения определенных этапов пайплайна. Например, запускать этапы тестирования только если параметр RUN_TESTS установлен в true.
Параметр DEPLOY_ENV может использоваться для динамического выбора целевого окружения для развертывания, т.е можно использовать один и тот же пайплайн для развертывания в различные среды, к примеру production.
Динамическое создание окружений
Динамическое создание окружений позволяет автоматизировать процесс подготовки и удаления временных тестовых или стейджинговых сред для каждой новой сборки, ветки или пулл-реквеста. В Jenkins это можно реализовать с помощью пайплайнов, скриптов Groovy, и интеграции с Docker, Kubernetes, Terraform и тд.
Допустим, хочется создать временное тестовое окружение для каждой ветки в Git-репозитории, используя Docker. В Jenkinsfile можно определить этапы для сборки Docker-образа, запуска контейнера для тестирования и удаления контейнера после завершения тестов:
pipeline {
agent any
stages {
stage('Build Docker Image') {
steps {
script {
// к примеру Dockerfile находится в корне проекта
sh 'docker build -t my-app:${GIT_COMMIT} .'
}
}
}
stage('Deploy to Test Environment') {
steps {
script {
// run контейнера из собранного образа
sh 'docker run -d --name test-my-app-${GIT_COMMIT} -p 8080:80 my-app:${GIT_COMMIT}'
}
}
}
stage('Run Tests') {
steps {
script {
// шаги для запуска тестов
echo 'Running tests against the test environment'
}
}
}
stage('Cleanup') {
steps {
script {
// стоп и удаление контейнера после тестирования
sh 'docker stop test-my-app-${GIT_COMMIT}'
sh 'docker rm test-my-app-${GIT_COMMIT}'
}
}
}
}
}Если Kubernetes используется для управления контейнерами, можно динамически создавать и удалять namespaces для изоляции тестовых окружений. В этом случае Jenkinsfile может выглядеть следующим образом:
pipeline {
agent any
environment {
KUBE_NAMESPACE = "test-${GIT_COMMIT}"
}
stages {
stage('Create Namespace') {
steps {
script {
// сздание нового namespace в Kubernetes
sh "kubectl create namespace ${KUBE_NAMESPACE}"
}
}
}
stage('Deploy to Kubernetes') {
steps {
script {
// развертывание приложения в созданном namespace
sh "kubectl apply -f k8s/deployment.yaml -n ${KUBE_NAMESPACE}"
sh "kubectl apply -f k8s/service.yaml -n ${KUBE_NAMESPACE}"
}
}
}
stage('Run Tests') {
steps {
script {
// тест приложения
echo 'Running tests against the Kubernetes environment'
}
}
}
stage('Cleanup') {
steps {
script {
// делит namespace и всех связанных с ним ресурсов
sh "kubectl delete namespace ${KUBE_NAMESPACE}"
}
}
}
}
}Можно легко интегрировать Prometheus
Prometheus metrics устанавливается в Jenkins через «Управление Jenkins» → «Управление плагинами».
После установки, переходим в сеттингы Jenkins и в разделе Prometheus Metrics включаем экспозицию метрик — enable prometheus metrics.
Плагин по умолчанию будет доступен по URL http://, где
В конфигурационном файле Prometheus prometheus.yml добавляем новую задачу для сбора метрик с Jenkins:
scrape_configs:
- job_name: 'jenkins'
metrics_path: '/prometheus/'
static_configs:
- targets: [':'] Далее через grafana можно указать на источник prometheus и визуализировать данные.
Больше про инфраструктуру рассказывают эксперты OTUS в рамках практических онлайн-курсов. С полным каталогом курсов можно ознакомиться по ссылке.
