Построение Pipeline в Jenkins
Построение CI/CD Pipeline для автоматизации тестирования и деплоя в Jenkins. Сбор артефактов и уведомления по электронной почте.
- 00:01:05 - Создание Jenkinsfile
- 00:04:41 - Добавление GitHub-репозитория в Jenkins
- 00:11:42 - Просмотр multibranch-проекта
- 00:13:37 - Вывод временных меток в логах
- 00:16:30 - Валидация Jenkinsfile
- 00:18:02 - Переменная окружения CI
- 00:19:39 - Доработка docker-compose pull
- 00:20:43 - Команды init и down c защитой в post
- 00:22:33 - Первый и повторный запуск
- 00:26:01 - Установка git и make на машину-агент
- 00:27:00 - Сравнение производительности
- 00:28:25 - Этап valid
- 00:28:53 - Параллельный запуск линтеров
- 00:31:36 - Анализаторы и тесты
- 00:32:44 - Переменная REGISTRY для реестра
- 00:36:14 - Генерация тегов с номером сборки
- 00:41:13 - Сборка production образов
- 00:42:13 - Запуск Smoke и E2E тестов
- 00:43:08 - Оптимизация числа потоков
- 00:46:01 - Аутентификация в Docker-реестре и push
- 00:49:55 - Автодеплой на production-сервер
- 00:54:46 - Имя пользователя для деплоя
- 00:55:31 - Отключение интерактивной SSH-проверки
- 00:56:19 - Генерация SSH-ключа для деплоя
- 01:04:14 - Подключение через плагин SSH Agent
- 01:06:58 - Работа со Staging-сервером
- 01:09:14 - Сохранение артефактов
- 01:14:38 - Добавление Email-уведомлений
Скрытый контент
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
чудотворный урок, спасибо.
Спасибо! Стараемся.
Спасибо, большое тебе Дима, ты конечно мастер. А сколько времени уходит если не секрет, что бы все скрипты заработали? Ведь на поиск правильно работающего в данной конфигурации рецепта, может уйти куча времени, иногда с виду простая вещь может упереться так, что мама не горюй, записал бы может стрим какой отдельно, как что то сложное настраивал, было бы тоже весьма познавательно.
С GitHub Actions просидел так три дня. В итоге и запись видео заняла шесть часов, так как каждый прогон Pipeline шёл несколько минут и в случае ошибок после каждого исправления приходилось всё перезапускать.
Понятно, ещё раз спасибо за труд, аналогов таким урокам не видел, там рецепты почти на все случаи жизни собраны, хоть понятно куда копать теперь.
Дмитрий, спасибо большое за урок! Вопрос, будет ли рассмотрен вариант использоваться докер образа с Git lab или вообще Git lab как инструмента? Там же есть встроенная возможность и репозиторий для docker организовать и ci\cd настраивать...
Да, скоро рассмотрим.
Огромное спасибо за труд.
А сколько всего планируется уроков?
Сколько получится. Плюс некоторые добавляются по просьбам из комментариев.
Спасибо!
Этот урок просто бесценный, спасибо
А что если надо сделать деплой на две разных машины? Ну т.е. чтобы было 2 копии сайта. Как это сконфигурировать?
Для этого вместо Docker Compose мы в следующих эпизодах будем использовать Docker Swarm. И он уже задеплоит проект на все подключенные серверы.
А что если у нас есть shared данные. Например, изображения загруженные пользователями. Понятное дело, что можно заиметь ftp сервер какой-нибудь и грузить все туда. Но если все таки без сервера, т.е. хранить изображения надо где-то в отдельной папке, то как тогда ее монтировать в контейнер? Причем надо не забывать, что у нас может быть staging (или даже несколько staging).
Обычно их помещают на отдельный файловый сервер по S3 или FTP.
А если без него, то просто монтируем папку public/upload через volume. И для тестов отдельной командой вроде:
заполняем тестовыми данными.
А почему в 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. Они как раз будут оставлять только нужное число папок.
При сборке не находится sshagent java.lang.NoSuchMethodError: No such DSL method 'sshagent' found among steps Потом все таки досмотрел видео, когда установил модуль сам)
Или войти через: