Управление рабочими процессами с Дженкинсом и Докером

Большинство реальных трубопроводов более сложны, чем канонический поток BUILD → TEST → STAGE → PRODUCTION. Эти конвейеры часто имеют этапы, которые не должны запускаться, если не выполнены определенные условия, в то время как другие должны запускаться, только если условия первого не выполнены. Jenkins Workflow помогает создавать эти конвейеры, позволяя Jenkins лучше представлять и обслуживать сложные развертывания.

Плагин Jenkins Workflow Docker еще больше расширяет эти рабочие процессы, обеспечивая первоклассную поддержку образов и контейнеров Docker. Этот плагин позволяет Jenkins создавать / выпускать образы Docker и использовать контейнеры Docker для настраиваемых и воспроизводимых подчиненных сред.

Что такое Докер?

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

Docker-контейнеры — это облегченные среды выполнения, которые состоят из приложения и его зависимостей. Эти контейнеры работают «на металле» машины, что позволяет им избежать 1-5% загрузки ЦП и 5-10% загрузки памяти, связанных с традиционными технологиями виртуализации. Они также могут быть созданы из доступного только для чтения шаблона, называемого образом Docker.  

Образы Docker могут быть созданы из определения среды, называемого Dockerfile, или из работающего контейнера Docker, который был зафиксирован как образ. Как только образ Docker существует, его можно отправить в реестр, такой как Docker Hub, и из этого образа можно создать контейнер, создав среду выполнения с гарантированным набором инструментов и приложений, установленных на нем. Аналогично, контейнеры могут быть переданы в изображения, которые затем передаются в Docker Hub. 

Что такое рабочий процесс?

Jenkins Workflow — это новый плагин, который позволяет Jenkins рассматривать непрерывную доставку как первоклассный тип работы в Jenkins. Рабочий процесс позволяет пользователям определять процессы рабочих процессов в одном месте, избегая необходимости координировать потоки между несколькими заданиями сборки. Это может быть особенно важно в сложных корпоративных средах, где работа, релизы и зависимости должны координироваться между командами. Рабочие процессы определяются как сценарий Groovy либо в задании Workflow, либо регистрируются в рабочей области из внешнего репозитория, такого как Git.

Докер для простоты

В двух словах, плагин CloudBees Docker Workflow добавляет специальную точку входа с именем Docker, которую можно использовать в любом скрипте Workflow Groovy. Он предлагает ряд функций для создания и использования образов и контейнеров Docker, которые, в свою очередь, могут использоваться для упаковки и развертывания приложений или в качестве сред сборки для Jenkins.

Вообще говоря, существует две области функциональности: использование собственных образов Docker или созданных мировым сообществом для упрощения автоматизации сборки; и создание и тестирование новых изображений. Некоторым проектам понадобятся оба аспекта, и вы можете следовать за полным проектом, который использует оба: см. Демонстрационное руководство . 

Среда и рабочий процесс сборки Jenkins

Прежде чем углубляться в детали, полезно узнать историю настройки сред сборки в Jenkins. Большинство сборок проектов имеют какие-то ограничения на компьютере, который может запустить сборку. Даже если скрипт сборки (например, Ant build.xml) теоретически самодостаточен и не зависит от платформы, вы должны начать где-нибудь и сказать, какие инструменты вы ожидаете использовать.

Поскольку многим людям нужно было сделать это, еще в 2009 году я работал с Kohsuke Kawaguchi и Tom Huybrechts, чтобы добавить средство к предшественнику Jenkins — Hudson — для «инструментов». Теперь администратор Jenkins может перейти на страницу конфигурации системы и сказать, что Ant 1.9.0 и JDK 1.7.0_67 следует предлагать проектам, которые хотят их, поэтому загружайте и устанавливайте их с общедоступных сайтов по запросу.

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

node(‘libqwerty’) {
 withEnv([“PATH=${tool ‘Ant 1.9.0’}/bin:${env.PATH}”]) {
   sh ‘ant dist-package’
 }
 archive ‘app.zip’
}

FROM webratio/ant:1.9.4
RUN apt-get install libqwerty-devel=1.4.0

// OK, here we come
node(‘docker’) {
 // My project sources include both build.xml and a Dockerfile to run it in.
 git ‘https://git.mycorp.com/myproject.git’
 // Ready?
 docker.build(‘mycorp/ant-qwerty:latest’).inside {
   sh ‘ant dist-package’
 }
 archive ‘app.zip’
}

node(‘docker’) {
 git ‘https://git.mycorp.com/myproject.git’
 docker.image(‘webratio/ant:1.9.4’).inside {
   sh ‘ant dist-package’
 }
 archive ‘app.zip’
}

def buildIn(env) {
 node(‘docker’) {
   git ‘https://git.mycorp.com/myproject.git’
   docker.image(env).inside {
     sh ‘ant dist-package’
   }
 }
}
parallel older: {
 buildIn ‘webratio/ant:1.9.3’
}, newer: {
 buildIn ‘webratio/ant:1.9.4’
}