Статьи

Современный конвейер непрерывной интеграции и развертывания с Jenkins, GitHub и Docker

Декабрь 10, 2018

Установка сцены

Последние два года я работал над проектом Node.js. Мы использовали GitHub для управления исходным кодом и Jenkins для непрерывной интеграции. У нас также был инструмент развертывания, основанный на Docker и Terraform.

За это время мы сделали несколько улучшений конфигурации. Одним из изменений, которое оказало положительное влияние, стало использование конвейера CI в филиалах и просмотр обратной связи в GitHub.

Проверка результата сборки перед слиянием PR предотвратила множество поломок из-за мелких ошибок. Например, забыть запустить линтер или добавить новый файл. Как только мы решили автоматизировать обновление зависимостей, обратная связь сделала это быстрым и безопасным.

В этом посте я собираюсь объяснить, как настроить конвейер интеграции и развертывания Continuos, используя:

  • Дженкинс за конфигурацию сборки. Многоотраслевой конвейер для создания сборок. Jenkinsfile для решения, что выполнять в каждой сборке
  • GitHub для хранения исходников, проверки выходных данных сборки и объединения веток с master
  • Docker для изоляции сборки от среды выполнения. Будь то машина разработчика или узел Дженкинса

Характеристики

Конфигурация конвейера сборки версионируется вместе с исходным кодом. Это дает вам:

  • История старых конфигов и возможность отката
  • Атомные изменения конфигурации и источника
  • Использование веток для экспериментов с самой конфигурацией

Создание и обратная связь с филиалами означает, что вы можете:

  • Посмотрите на результат сборки во время обзора кода
  • Не допускайте слияния веток, если они нарушают сборку
  • Автоматизировать слияние неразрывных изменений

Другие мелочи:

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

Недостатки

  • Вам нужно будет изучить синтаксис Jenkinsfile
  • Есть два различных синтаксических параметра (сценарий и декларативный), которые вы должны знать
  • Документация о том, как использовать плагины, не всегда понятна и часто не имеет примеров.

Приложение

Я создал веб-приложение Node.js в качестве примера. Для простоты сборки приложение не имеет внешних зависимостей времени выполнения, таких как базы данных или службы. Можно расширить эту конфигурацию, чтобы справиться с внешними зависимостями без ущерба для изоляции; например, предоставляя зависимости с помощью Docker Compose.

Dockerfile

1
2
3
4
5
6
7
FROM node:lts-slim
WORKDIR /opt/app
COPY package.json yarn.lock ./
RUN yarn
COPY . .
EXPOSE 8080
CMD yarn start

Docker — самое популярное решение для контейнеризации приложений. Для полного знакомства с Docker я бы порекомендовал Containers with Docker от Andre Torres .

В этом конвейере CI Docker изолирует код приложения от узла Jenkins.

Изоляция позволяет репликации. Если в Jenkins происходит сбой сборки, и нам нужно исследовать сбой, мы можем воспроизвести его на компьютере разработчика, поскольку состояние узла Jenkins и его программного обеспечения не влияет на контейнер.

Изоляция также решает проблему наличия различных сред выполнения. Каждое приложение может указывать разные версии Node.js в Dockerfile для использования при тестировании и при развертывании.

Дженкинсфайл

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
pipeline {
    agent any
 
    stages {
        stage('Build') {
            steps {
                sh 'docker build -t codurance/jenkins-pipeline-blog:latest .'
            }
        }
 
        stage('Test') {
            steps {
                sh 'docker run codurance/jenkins-pipeline-blog:latest yarn test'
            }
        }
 
        stage('Deploy') {
            when {
                branch 'master'
            }
            steps {
                sh 'docker push codurance/jenkins-pipeline-blog:latest'
            }
        }
    }
 
    post {
        failure {
            echo 'build is broken. notify team!'
        }
    }
}

Этот простой файл заменяет длинные веб-формы, обычно используемые для настройки заданий в Jenkins. В этом примере конвейер состоит из трех этапов (Build, Test, Deploy), каждый из которых реализуется пошагово.

Этап развертывания запускается только при воздействии на главную ветвь или магистраль. В этом примере он публикует образ на hub.docker.com, но вы, вероятно, замените его на команды инфраструктуры, которые вы используете для развертывания своего приложения.

В конвейере также есть раздел, который называется post с такими шагами, как always и failure которые запускаются после завершения сборки. Эти точки расширения могут интегрировать системы обмена сообщениями, такие как Slack, в ваш рабочий процесс.

Настройка Jenkins

Дженкинс нужен доступ к GitHub. В моем случае сработало создание учетных данных имени пользователя и пароля в Jenkins с использованием нового личного токена GitHub в качестве пароля. Это зависит от того, как ваш пользователь настроен в GitHub, поэтому он может не работать для вашей учетной записи. Я нашел подробное объяснение в базе знаний CloudBees

Настроив учетные данные, пришло время создать новую работу в Jenkins. При запросе типа выберите «Многоотраслевой трубопровод»

Трубопровод развертывания

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

Трубопровод развертывания

Вы можете настроить, какие коммиты, ветки или PR запускают конвейер. С настройкой, показанной выше, конвейер будет запущен при нажатии на мастер, при переходе к филиалам и при создании PR.

Как только вы сохраните конфигурацию, хорошей идеей будет проверить webhook в GitHub. Дженкинс настроит webhook в репозитории для запуска конвейера, как только будет нажата фиксация или создан PR. Для этого требуется, чтобы Jenkins был доступен из Интернета, предпочтительно с действующим сертификатом SSL.

Трубопровод развертывания

При нажатии на работу Дженкинса вольным стилем знакомое зрелище — это список уменьшающихся номеров сборок. Теперь это еще один клик, потому что каждая ветвь и PR получают свою собственную последовательность номеров сборки.

Состояние сборки для веток в GitHub сообщается через крестики и отметки, которые ссылаются на Jenkins.

Трубопровод развертывания

В случае PR конвейер запускается после слияния с мастером, и он виден вместе с диалогом PR.

Трубопровод развертывания

GitHub также может быть настроен как привратник, чтобы PR с ошибочными тестами не могли быть объединены. Эта функция называется Защищенные ветви .

Трубопровод развертывания

С конвейером, настроенным в соответствии с вашим рабочим процессом, вы готовы начать разработку приложения.

Куда пойти отсюда?

Современное состояние не означает идеальное. Это лучшее, что я знаю сейчас, я хочу узнать больше и оглянуться на это как на хороший шаг к чему-то лучшему.

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

В этой статье не рассматривается, как работать с приложением, имеющим внешние зависимости. Я расскажу об этом в следующем посте.

Дайте мне знать, что вы думаете, отправив мне твиттер в @jaramir или @codurance .

Счастливого взлома!

Ресурсы

См. Оригинальную статью здесь: Современный конвейер непрерывной интеграции и развертывания с Jenkins, GitHub и Docker.

Мнения, высказанные участниками Java Code Geeks, являются их собственными.

43
Share: