Блог о веб-разработке

Используем Docker для разработки и развертывания React-приложений. Часть 3.

July 28, 2019

Я не являюсь экспертом в DevOps, данный материал предназначен для новичков и может использоваться в ознакомительных целях.

Это третья часть, в которой мы постараемся разобраться с тем, как сделать простейший CI с помощью Jenkins.

В прошлой части мы написали два Dockerfile для CI/CD. Сегодня мы рассмотрим как можно организовать простейший CI для нашего React-приложения.

Репозиторий с итоговым кодом для этой статьи

Препологается, что у вас уже есть vps сервер с установленным linux и статическим ip(либо доменом), а так же доступ по ssh.
В качестве ОС я использовал ubuntu 18.04
Ниже представлен список статей, с помощью которых я осуществил первоначальную настройку и установил Jenkins на мой сервер.

  1. Первоначальная настройка ubuntu (RU)
  2. Установка Jenkins (EN)
  3. Установка Docker (RU)

Введение

Для начала давайте разберемся, как будет построен процесс.

  1. Пушим коммит в репозиторий.
  2. С помощью webhooks github будет оповещать Jenkins о том, что произошел пуш.
  3. Jenkins запускает Job, который подписан на это событие.
  4. Job запускает jenkins-pipeline, который собирает образ и при сборке запускает тесты.

Давайте попробуем визуализировать все этапы этого процесса.

ci-with-docker-jenkins-and-react

Давайте сделаем так, чтобы github оповещал Jenkins при событии пуша

Чтобы добавить webhook перейдите в репозиторий -> settings -> webhooks Добавление webhook

Настроим webhook Настройка webhook Разберем пошагово:

  1. Payload URL - это тот URL куда github будет слать POST-запрос при событии пуша. Имеет вид: http://jenkins-domain/github-webhook/ К примеру: http://105.196.135.40:8080/github-webhook/
  2. Указываем тип данных в запросе
  3. Указываем триггер срабатывания webhook
  4. Добавляем webhook

Добавленный webhook будет выглядеть следующим образом: Добавленный webhook

Теперь когда мы запушим коммит в репозиторий, github будет слать POST-запрос по указанному URL, что в свою очередь должно тригернуть нашу будущую Job.

Создание Job с jenkins-pipeline

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

Сначала создадим задачу, а затем опишем pipeline.

Создаем задачу: Создаем задачу

Необходимо задать имя и тип задачи: Задаем имя и тип задачи

Укажем что триггером запуска задачи будет событие пуша в репозиторий: Указываем, что триггером запуска задачи будет событие пуша в репозиторий

Укажем откуда брать pipeline: Указываем откуда брать pipeline

Пошагово разберемся:

  1. Говорим Jenkins, что pipeline находится в репозитории
  2. Указываем Git в качестве системы контроля версий
  3. Указываем URL репозитория(здесь должен быть URL вашего репозитория)
  4. Указываем ветку, которую нужно собирать при событии пуша.
  5. Указываем путь до файла с jenkins-pipeline (от корня приложения)
  6. Жмем “Save”

Описываем pipeline

В корне проекта создадим файл jenkins.ci со следующим содержанием:

pipeline {
    agent any

    stages {
        stage('Build docker image. Run tests and build app.') {
            steps {
                git 'https://github.com/RenatRysaev/dockerized-react'
                sh 'sudo docker build -t dockerized-react:test -f Dockerfile.test .'
            }
        }
    }
}

Именно за этим файлом Jenkins будет ходить, чтобы получить описание pipeline. Не будем заострять внимание, потому что pipeline достаточно декларативен.

Вкратце: клонируется репозиторий и выполняется команда сборки контейнера, в котором у нас запускаются тесты и собирается приложение.

Если упадут тесты или не соберется приложение, то задача будет считаться неудачной.

Давайте попробуем вручную запустить нашу Job: Ручной запуск CI

Если вы столкнулись с ошибкой “sudo: no tty present and no askpass program specified”, то вам нужно на вашем сервере с Jenkins в терминале выполнить следующую команду:

sudo visudo

А затем добавить в файле в секцию ”# Allow members of group sudo to execute any command” следующее:

jenkins ALL=(ALL) NOPASSWD: ALL

Обсуждение этой проблемы на stackoverflow

Если вы все сделали правильно, то увидите примерно следующее: Успешный CI

Готово, теперь можете протестировать как работает ваш CI, сделав пуш в репозиторий.

Обычно в CI добавляют разные механизмы для того, чтобы узнать как прошла сборка. Это может быть сообщение в мессенджер со статусом, или примитивный статус в README, а может быть и то и другое.

Если вы хотите прикрутить что-то подобное, то можете начать с этого.

В следующей финальной части мы разберемся с CD(Continuous Delivery).


Ренат Рысаев

Персональный блог Рената Рысаева

Я пишу о интересных мне технологиях в веб-разработке