Построение Pipeline в Jenkins

Построение CI/CD Pipeline для автоматизации тестирования и деплоя в Jenkins. Сбор артефактов и уведомления по электронной почте.

  • 00:01:04 - Создание Jenkinsfile
  • 00:04:43 - Добавление GitHub-репозитория в Jenkins
  • 00:11:44 - Просмотр multibranch-проекта
  • 00:13:40 - Вывод временных меток в логах
  • 00:16:32 - Валидация Jenkinsfile
  • 00:18:09 - Переменная окружения CI
  • 00:19:45 - Доработка docker-compose pull
  • 00:21:51 - Команды init и down c защитой в post
  • 00:23:38 - Первый и повторный запуск
  • 00:27:27 - Установка git и make на машину-агент
  • 00:28:39 - Сравнение производительности
  • 00:30:05 - Этап valid
  • 00:30:33 - Параллельный запуск линтеров
  • 00:33:16 - Анализаторы и тесты
  • 00:34:30 - Переменная REGISTRY для реестра
  • 00:38:03 - Генерация тегов с номером сборки
  • 00:43:05 - Сборка production образов
  • 00:44:08 - Запуск Smoke и E2E тестов
  • 00:45:03 - Оптимизация числа потоков
  • 00:47:58 - Аутентификация в Docker-реестре и push
  • 00:52:04 - Автодеплой на production-сервер
  • 00:56:59 - Имя пользователя для деплоя
  • 00:57:44 - Отключение интерактивной SSH-проверки
  • 00:58:33 - Генерация SSH-ключа для деплоя
  • 01:06:38 - Подключение через плагин SSH Agent
  • 01:09:24 - Работа со Staging-сервером
  • 01:11:40 - Сохранение артефактов
  • 01:17:05 - Добавление Email-уведомлений
Скрытый контент
Комментарии (22)
Arunas

чудотворный урок, спасибо.

Ответить
Дмитрий Елисеев

Спасибо! Стараемся.

Ответить
fedot

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

Ответить
Дмитрий Елисеев

С GitHub Actions просидел так три дня. В итоге и запись видео заняла шесть часов, так как каждый прогон Pipeline шёл несколько минут и в случае ошибок после каждого исправления приходилось всё перезапускать.

Ответить
fedot

Понятно, ещё раз спасибо за труд, аналогов таким урокам не видел, там рецепты почти на все случаи жизни собраны, хоть понятно куда копать теперь.

Ответить
Andrey

Дмитрий, спасибо большое за урок! Вопрос, будет ли рассмотрен вариант использоваться докер образа с Git lab или вообще Git lab как инструмента? Там же есть встроенная возможность и репозиторий для docker организовать и ci\cd настраивать...

Ответить
Дмитрий Елисеев

Да, скоро рассмотрим.

Ответить
Yevhenii Lykholai

Огромное спасибо за труд.

Ответить
Merlin

А сколько всего планируется уроков?

Ответить
Дмитрий Елисеев

Сколько получится. Плюс некоторые добавляются по просьбам из комментариев.

Ответить
Александр

Спасибо!

Ответить
Valentin

Этот урок просто бесценный, спасибо

Ответить
Андрей

А что если надо сделать деплой на две разных машины? Ну т.е. чтобы было 2 копии сайта. Как это сконфигурировать?

Ответить
Дмитрий Елисеев

Для этого вместо Docker Compose мы в следующих эпизодах будем использовать Docker Swarm. И он уже задеплоит проект на все подключенные серверы.

Ответить
Андрей

А что если у нас есть shared данные. Например, изображения загруженные пользователями. Понятное дело, что можно заиметь ftp сервер какой-нибудь и грузить все туда. Но если все таки без сервера, т.е. хранить изображения надо где-то в отдельной папке, то как тогда ее монтировать в контейнер? Причем надо не забывать, что у нас может быть staging (или даже несколько staging).

Ответить
Дмитрий Елисеев

Обычно их помещают на отдельный файловый сервер по S3 или FTP.

А если без него, то просто монтируем папку public/upload через volume. И для тестов отдельной командой вроде:

docker run --rm php-cli copy docker/testing/demo/photos public/upload/photos

заполняем тестовыми данными.

Ответить
Андрей

А почему в Jenkinsfile для make deploy мы явно указываем BUILD_NUMBER=${env.BUILD_NUMBER} make deploy? Ведь остальные переменные по типу HOST мы же не указываем....

Ответить
Дмитрий Елисеев

В принципе да. Если имя переменной совпадает, то можно не присваивать повторно и работать сразу с ${BUILD_NUMBER} без env.

Ответить
Александр

Замечательный урок. Спасибо.

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

Ответить
Дмитрий Елисеев

возможность автоматического отката к прошлой рабочей версии

Например, в Prod объявить подсекцию post { failure { ... } } по аналогии со сбором артефактов и там вызвать команду make auto-rollback, которая выполнит перезапуск из прошлой рабочей папки по симлинку cd site && docker-compose up ...

не забивать дисковое пространство

В папке деплоя у нас хранятся только два файла на ~5 КБ. Тысяча таких папок займёт всего 5 МБ.

Ответить
Александр

Спасибо за ответ. Я немного не верно задал вопрос. У меня есть продакшен на котором после деплоя выполняется еще мануальное тестирование и если я нахажу там критические баги то надо откатить продакшен до предыдущей версии. но т.к. мы не используем теги для деплоя мы не можем просто взять и задеплоить предыдущий релиз. Нужен какой то способ запустить деплой предыдущего смерженого пулл реквест.

Так же под файлами деплоя я имелл ввиду не файлы логов а файлы проекта я не использую билд образов и не пушу эти образы в реджестри а просто пулю ветку мастер на сервере и перезапускаю докер композ и была идея просто каждый релиз делать в отдельную папку с номером билда но остается проблема с местом на диске т.к. весь проект знимает прилично места и хотелось бы как то удалять все папки релизов кроме последних 4-х

Ответить
Дмитрий Елисеев

Тогда можно поробовать деплоить через Deployer или Capistrano. Они как раз будут оставлять только нужное число папок.

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий