1. Обзор
«Конвейер как код» — это идея, позволяющая всем участникам DevOps создавать и поддерживать конвейеры Jenkins. На самом деле существует два способа применения принципа «конвейер как код» в жизни: сценарии и декларативные конвейеры . «Конвейер как код» позволяет Jenkins обрабатывать конвейеры как обычные файлы. Люди, вовлеченные в DevOps, могут хранить, совместно использовать и использовать эти файлы с SCM.
2. Декларативные конвейеры и их преимущества
Декларативные конвейеры — это более свежий подход к принципу «конвейер как код». Их довольно легко написать и понять. Структура может показаться немного сложной, но в целом она содержит всего пару основных разделов. Блок «конвейер» — это основной блок, содержащий полное объявление конвейера. В этом примере мы рассмотрим только секции «agent» , «stages» и «steps» :
конвейер — содержит весь конвейер
агент — определяет машину, которая будет обрабатывать этот конвейер
stages — объявляет этапы пайплайна
шаги - небольшие операции внутри определенного этапа
Давайте проверим, как эта структура будет выглядеть в нашем декларативном пайплайне:
pipeline {
agent any
stages {
stage('Hello World') {
steps {
sh 'echo Hello World'
}
}
}
}
Другой важной частью декларативных конвейеров являются директивы . На самом деле директивы — это удобный способ включения дополнительной логики. Они могут помочь включить инструменты в конвейер, а также могут помочь с настройкой триггеров, переменных среды и параметров. Некоторые директивы могут предлагать пользователям ввести дополнительную информацию. Существует простой в использовании генератор , который может помочь в создании этих директив.
В предыдущем примере «шаги» — это директива, содержащая логику, которая будет выполняться на этапе. Существует специальный генератор фрагментов, который обеспечивает удобный способ создания шагов.
Сила декларативных конвейеров в основном исходит от директив. Декларативные конвейеры могут использовать возможности скриптовых конвейеров с помощью директивы script. Эта директива будет выполнять строки внутри как конвейер по сценарию.
3. Скриптовые конвейеры и их преимущества
Скриптовые конвейеры были первой версией принципа «конвейер как код». Они были разработаны как сборка DSL с Groovy и обеспечивают выдающийся уровень мощности и гибкости. Однако для этого также требуются базовые знания Groovy, что иногда нежелательно.
Эти виды трубопроводов имеют меньше ограничений по конструкции. Также в них всего два базовых блока: «узел» и «этап». Блок «узел» указывает машину, на которой выполняется конкретный конвейер, тогда как блоки «стадии» используются для группировки шагов, которые, взятые вместе, представляют собой отдельную операцию. Отсутствие дополнительных правил и блоков делает эти пайплайны достаточно простыми для понимания :
node {
stage('Hello world') {
sh 'echo Hello World'
}
}
Думайте о скриптовых конвейерах как о декларативных конвейерах, но только с этапами. Блок «узел» в данном случае играет роль как блока «конвейер», так и директивы «агент» из декларативных конвейеров.
Как упоминалось выше, шаги для скриптовых пайплайнов можно генерировать с помощью того же генератора сниппетов . Поскольку этот тип конвейера не содержит директив, шаги содержат всю логику. Для очень простых конвейеров это может сократить общий код.
Однако для некоторых шаблонных настроек может потребоваться дополнительный код, который можно решить с помощью директив. Более сложная логика в таких пайплайнах обычно реализуется в Groovy.
4. Сравнение сценариев и декларативных конвейеров
Давайте проверим трехэтапный конвейер, который извлекает проект из git, затем тестирует, упаковывает и развертывает его:
pipeline {
agent any
tools {
maven 'maven'
}
stages {
stage('Test') {
steps {
git 'https://github.com/user/project.git'
sh 'mvn test'
archiveArtifacts artifacts: 'target/surefire-reports/**'
}
}
stage('Build') {
steps {
sh 'mvn clean package -DskipTests'
archiveArtifacts artifacts: 'target/*.jar'
}
}
stage('Deploy') {
steps {
sh 'echo Deploy'
}
}
}
}
Как мы видим, вся логика находится внутри разделов «шаги». Таким образом, если мы хотим преобразовать этот декларативный конвейер в скриптовый конвейер, эти части не будут изменены:
node {
stage('Test') {
git 'https://github.com/user/project.git'
sh 'mvn test'
archiveArtifacts artifacts: 'target/surefire-reports/**'
}
stage('Build') {
sh 'mvn clean package -DskipTests'
archiveArtifacts artifacts: 'target/*.jar'
}
stage('Deploy') {
sh 'echo Deploy'
}
}
Заскриптованный конвейер для той же функциональности выглядит более плотным , чем его декларативный аналог. Однако мы должны убедиться, что все переменные среды установлены правильно на сервере. В то же время, если версий Maven несколько, нам нужно будет изменить их прямо в пайплайне. Для этого мы можем использовать конкретный путь напрямую или переменную среды.
Также есть шаг withEnv, который может быть полезен в скриптовых конвейерах. С другой стороны, с декларативными конвейерами довольно легко изменить версию инструментов в конфигурациях Jenkins.
Предыдущий пример показывает, что для простых повседневных задач эти подходы практически не отличаются. Если шаги могут покрыть все основные потребности для конвейеров, эти два подхода будут почти идентичными. Декларативные конвейеры по-прежнему предпочтительнее, поскольку они могут упростить некоторую общую логику.
5. Вывод
Скриптовые и декларативные конвейеры преследуют одну и ту же цель и используют одну и ту же конвейерную подсистему под капотом. Основные различия между ними заключаются в гибкости и синтаксисе. Это всего лишь два разных инструмента для решения одной и той же проблемы, поэтому мы можем и должны использовать их взаимозаменяемо.
Лаконичный синтаксис декларативных конвейеров обеспечит более быстрый и плавный вход в эту область. В то же время конвейеры со сценариями могут предоставить больше возможностей более опытным пользователям. Чтобы получить лучшее из обоих миров, мы можем использовать декларативные конвейеры с директивами сценария.