Для чего нужен дженкинс

Битва Jenkins и GitLab CI/CD

В последнее десятилетие достигнуты значительные успехи в сфере разработки инструментов непрерывной интеграции (Continuous Integration, CI) и непрерывного развёртывания (Continuous Delivery, CD). Развитие технологий интеграции разработки и эксплуатации ПО (Development Operations, DevOps) привело к быстрому росту спроса на CI/CD-инструменты. Существующие решения постоянно улучшаются, стремясь идти в ногу со временем, выходят их новые версии, в мире контроля качества ПО (Quality Assurance, QA) постоянно появляется множество новых продуктов. При таком богатстве выбора подбор подходящего инструментария оказывается нелёгкой задачей.

Среди всех существующих CI/CD инструментов существуют два проекта, на которые, определённо, стоит обратить внимание тому, кто ищет что-то из этой сферы. Речь идёт о Jenkins и об инструменте GitLab CI/CD, который является частью платформы GitLab. У Jenkins имеется более 16000 звёзд на GitHub. Репозиторий GitLab на gitlab.com набрал чуть больше 2000 звёзд. Если сравнить популярность репозиториев, то окажется, что Jenkins набрал в 8 раз больше звёзд, чем платформа, в состав которой входит GitLab CI/CD. Но при выборе CI/CD-инструмента это — далеко не единственный показатель, на который стоит обращать внимание. Есть и масса других, и это объясняет то, что во многих сравнениях Jenkins и GitLab CI/CD оказываются очень близко друг к другу.

Возьмём, например, данные с платформы G2, которая аккумулирует отзывы о самых разных продуктах и оценки, которые ставят им пользователи. Здесь средний рейтинг Jenkins, выведенный на основе 288 отзывов, составляет 4,3 звезды. А о GitLab тут имеется 270 отзывов, средний рейтинг этого инструмента составляет 4,4 звезды. Мы не ошибёмся, заявив, что Jenkins и GitLab CI/CD конкурируют друг с другом на равных условиях. Интересно отметить то, что проект Jenkins появился в 2011 году и с тех времён он является излюбленным инструментом тестировщиков. Но при этом проект GitLab CI/CD, запущенный в 2014 году, занял свои позиции, очень высокие, благодаря предлагаемым этой платформой передовым возможностям.

Если говорить о популярности Jenkins в сравнении с другими аналогичными платформами, то отметим, что мы, опубликовав статью, где сравнивались платформы Travis CI и Jenkins, устроили опрос. В нём поучаствовало 85 пользователей. Респондентам было предложено выбрать CI/CD-инструмент, который нравится им больше всего. 79% выбрали Jenkins, 5% выбрали Travis CI, а 16% указали, что они предпочитают другие инструменты.

Среди других CI/CD-инструментов чаще всего упоминался GitLab CI/CD.

Если вы всерьёз занимаетесь DevOps, то вам нужно тщательно подбирать соответствующие инструменты, учитывая особенности проекта, его бюджет и другие требования. Для того чтобы помочь вам сделать правильный выбор, мы собираемся провести анализ Jenkins и GitLab CI/CD. Это, хочется надеяться, поможет вам сделать правильный выбор.

Знакомство с Jenkins

Jenkins — это широко известный, гибкий CI/CD-инструмент, предназначенный для автоматизации множества задач, связанных с программными проектами. Jenkins полностью написан на Java, он выпущен под лицензией MIT. Он обладает мощным набором возможностей, направленных на автоматизацию задач, связанных со сборкой, тестированием, развёртыванием, интеграцией, выпуском программного обеспечения. Этот инструмент можно использовать в различных операционных системах. Среди них — macOS, Windows и множество дистрибутивов Linux, например — OpenSUSE, Ubuntu и Red Hat. Существуют установочные пакеты Jenkins, предназначенные для различных ОС, этот инструмент можно установить в Docker и в любой системе, где есть JRE (Java Runtime Environment).

Разработчики Jenkins создали ещё один проект, Jenkins X, который рассчитан на работу в среде Kubernetes. В Jenkins X интегрированы Helm, сервер Jenkins CI/CD, Kubernetes и другие инструменты, предназначенные для создания CI/CD-конвейеров, соответствующих передовым методам DevOps. Например, здесь используется GitOps.

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

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

Особенности Jenkins

Среди широко известных особенностей Jenkins можно отметить простоту настройки, высокий уровень автоматизации различных операций и отличную документацию. Если говорить о решении DevOps-задач, то здесь Jenkins считается весьма надёжным инструментом, используя который, как правило, нет смысла пристально наблюдать за всем процессом обработки проекта. В случае с другими CI/CD-инструментами это не так. Давайте поговорим о некоторых важнейших возможностях Jenkins.

▍1. Бесплатность, открытый исходный код, поддержка множества платформ

Jenkins может работать на платформах macOS, Windows и Linux. Он может функционировать и в среде Docker, что позволяет организовать единообразное и быстрое выполнение автоматизированных задач. Этот инструмент, кроме того, может выполняться в виде сервлета в контейнерах, поддерживающих Java, в таких, как Apache Tomcat и GlassFish. Установка Jenkins качественно документирована.

▍2. Развитая экосистема плагинов

Экосистема плагинов Jenkins выглядит гораздо более развитой по сравнению с экосистемами подключаемых модулей других CI/CD-инструментов. В настоящее время существует более 1500 плагинов для Jenkins. Эти плагины направлены на решение широкого спектра задач, с их помощью можно автоматизировать самые разные проекты. Богатство выбора бесплатных подключаемых модулей означает, что у того, кто использует Jenkins, нет острой необходимости в покупке дорогостоящих платных плагинов. Существует возможность интеграции Jenkins с множеством DevOps-инструментов.

▍3. Простая установка и настройка

Jenkins довольно просто устанавливать и настраивать. При этом и процесс обновления системы тоже устроен очень удобно. Тут, опять же, стоит упомянуть о качестве документации, так как в ней можно найти ответы на самые разные вопросы, связанные с установкой и настройкой Jenkins.

▍4. Дружелюбное сообщество

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

▍5. Наличие REST API

В ходе работы с Jenkins можно пользоваться REST API, что расширяет возможности системы. API для удалённого доступа к системе представлен в трёх вариантах: XML, JSON с поддержкой JSONP, Python. Вот страница документации, раскрывающая подробности о работе с REST API Jenkins.

▍6. Поддержка параллельного выполнения задач

Jenkins поддерживает распараллеливание DevOps-задач. Его можно легко интегрировать с соответствующими инструментами и получать уведомления о результатах выполнения задач. Выполнение тестирования кода можно ускорить за счёт организации параллельной сборки проекта с использованием различных виртуальных машин.

▍7. Поддержка работы в распределённых средах

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

Знакомство с GitLab

GitLab CI/CD можно назвать одним из самых новых и самых любимых DevOps-инженерами инструментов. Этот бесплатный опенсорсный инструмент встроен в систему контроля версий GitLab. У платформы GitLab есть community-версия, она поддерживает управление репозиториями, средства для отслеживания проблем, организацию код-ревью, механизмы, ориентированные на создание документации. Компании могут устанавливать GitLab локально, связывая эту систему с Active Directory и с LDAP-серверами для организации безопасной авторизации и аутентификации пользователей.

Вот видеоруководство, которое поможет вам узнать о том, как создавать CI/CD-конвейеры с использованием возможностей GitLab CI/CD.

Изначально GitLab CI/CD был выпущен как самостоятельный проект, но в 2015 году этот набор инструментов был интегрирован в GitLab 8.0. Отдельный GitLab CI/CD-сервер может поддерживать работу более чем 25000 пользователей. На основе подобных серверов можно создавать системы, отличающиеся высокой доступностью.

GitLab CI/CD и основной проект GitLab написаны на Ruby и на Go. Они выпущены под лицензией MIT. GitLab CI/CD, помимо обычных возможностей CI/CD-инструментов, поддерживать и дополнительные возможности, связанные, например, с планированием работ.

Интегрировать GitLab CI/CD в проект очень просто. При использовании GitLab CI/CD процесс обработки кода проекта делится на стадии, каждая из которых может состоять из нескольких задач, выполняемых в определённом порядке. Задачи поддаются тонкой настройке.

Задачи могут выполняться параллельно. После настройки последовательности стадий и задач CI/CD-конвейер готов к работе. За ходом его выполнения можно наблюдать, отслеживая состояние задач. В результате пользоваться GitLab CI/CD очень удобно, пожалуй, удобнее, чем другими подобными инструментами.

Особенности GitLab CI/CD и GitLab

GitLab CI/CD — это один из самых популярных DevOps-инструментов. Проект отличается качественной документацией, его возможностями легко и удобно пользоваться. Если вы пока не знакомы с GitLab CI/CD, следующий список возможностей этого инструмента даст вам общее представление о том, чего от него можно ожидать. Надо отметить, что многие из этих возможностей имеют отношение к самой платформе GitLab, в которую интегрирован GitLab CI/CD.

▍1. Популярность

GitLab CI/CD — это сравнительно новый инструмент, нашедший широкое применение. GitLab CI/CD постепенно стал чрезвычайно популярным CI/CD-инструментом, используемым для автоматизированного тестирования и развёртывания программного обеспечения. Его просто настраивать. Это, к тому же, бесплатный CI/CD-инструмент, встроенный в платформу GitLab.

▍2. Поддержка GitLab Pages и Jekyll

▍3. Возможности по планированию проектов

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

▍4. Автоматическое масштабирование CI-раннеров

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

▍5. Средства для отслеживания проблем

Мощные возможности GitLab по отслеживанию проблем привели к тому, что эту платформу используют многие опенсорсные проекты. GitLab CI/CD позволяет выполнять параллельное тестирование различных веток кода. Результаты испытаний удобно анализировать в интерфейсе системы. Это выгодно отличает GitLab CI/CD от Jenkins.

▍6. Ограничение доступа к репозиториям

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

▍7. Активная поддержка сообщества

Вокруг GitLab сложилось активное сообщество, которое способствует развитию этой платформы и её инструментов, в частности — GitLab CI/CD. Глубокая интеграция GitLab CI/CD и GitLab, кроме прочего, упрощает нахождение ответов на вопросы, возникающие при работе с GitLab CI/CD.

▍8. Поддержка работы с различными системами контроля версий

GitLab CI/CD — это система, которая способна работать не только с кодом, размещённым в репозиториях GitLab. Например, код можно хранить в GitHub-репозитории, а CI/CD-конвейер можно организовать на базе GitLab с использованием GitLab CI/CD.

Сравнение Jenkins и GitLab CI/CD

Различия между Jenkins и GitLab CI/CD

Описав и сравнив Jenkins и GitLab CI/CD, давайте сосредоточимся на различиях этих DevOps-инструментов. Знание об этих различиях позволит понять тех, кто предпочитает один из этих инструментов другому.

Jenkins и GitLab CI/CD: сильные и слабые стороны

Сейчас у вас сложилось некоторое представление о Jenkins и GitLab CI/CD. Теперь, чтобы вы ещё лучше познакомились с этими инструментами, давайте разберём их сильные и слабые стороны. Полагаем, что вы уже приняли решение о том, какой именно инструмент вам нужен. Хочется надеяться, этот раздел позволит вам проверить себя.

▍Сильные стороны Jenkins

▍Слабые стороны Jenkins

▍Сильные стороны GitLab CI/CD

▍Слабые стороны GitLab CI/CD

Итоги

И Jenkins, и GitLab CI/CD имеют сильные и слабые стороны. Ответ на вопрос о том, что именно выбрать, зависит от нужд и особенностей конкретного проекта. Каждый из рассмотренных сегодня CI/CD-инструментов отличается определёнными особенностями, хотя созданы эти инструменты для решения одной и той же задачи. При этом Jenkins — это автономный инструмент, а GitLab CI/CD — это часть платформы, предназначенной для совместной работы над кодом.

Выбирая CI/CD-систему стоит, помимо её возможностей, принимать во внимание и те затраты, которые могут быть с ней связаны, и то, с чем именно привыкли работать DevOps-инженеры, поддерживающие проект.

Источник

Введение новичка в Дженкинс – CI/CD

В этом руководстве для начинающих мы познакомимся с Jenkins, сервером автоматизации CI/CD, а также запустим и автоматизируем процесс сборки простого проекта.

Вступление

Ключевые концепции Дженкинса

Чтобы понять, почему кто-то должен использовать Дженкинса, нам нужно понять, какие проблемы Дженкинс стремится решить.

Конвейер CI/CD

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

Архитектура Контроллера-Агента

Плагины

Плагины являются основой успеха Дженкинса. Любой разработчик Java может написать свой собственный плагин и поделиться им с сообществом. Дженкинс очень подчеркивает это и написал несколько очень подробных руководств по этому вопросу. Какой бы инструмент вы ни хотели использовать в конвейере, Дженкинс, вероятно, снабдит вас плагином, который облегчит весь процесс настройки и интеграции с этим инструментом.

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

Соглашения об именовании

На протяжении всего жизненного цикла Дженкинса номенклатура немного менялась, в том числе из-за того, что определенная терминология может рассматриваться как оскорбительная.

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

Более старая Ведущая/Ведомая архитектура была переименована в Контроллер/Агент архитектура из-за негативных коннотаций терминологии.

Установка

Установка JDK/JRE

Давайте продолжим и установим openjdk-11-jdk :

Обновление списка источников и установка с помощью apt

Дженкинс недоступен в официальном репозитории Linux, поэтому нам придется добавить его собственный репозиторий. Мы собираемся установить версию LTS ( Долгосрочная поддержка ), которая обновляется каждые 12 недель, согласно веб-сайту Дженкинса.

Наконец, мы можем продолжить и зарегистрировать Дженкинса в качестве сервиса и запустить его через терминал:

Доступ к Дженкинсу из браузера

Использование Дженкинса

Дженкинс-это большой и сложный проект, и мы рассмотрим большинство наиболее важных функций.

Для этого мы рассмотрим три примера рабочего процесса:

Простая Локальная Сборка

Чтобы легко настроить Maven – мы установим плагин Maven для Дженкинса.

Установка плагинов

Перейдите к опции Управление плагинами в разделе Управление Дженкинсом :

Дождитесь установки плагина, прежде чем продолжить.

Настройка Maven

Настройка электронной почты

Создание проекта

Git Essentials

Ознакомьтесь с этим практическим руководством по изучению Git, содержащим лучшие практики и принятые в отрасли стандарты. Прекратите гуглить команды Git и на самом деле изучите это!

Запуск сборки

Настроив шаги, мы можем начать сборку. Боковая панель сообщит нам о ходе работы, а также покажет историю сборки. Неудачные сборки (#1) будут отображаться другим цветом.

Перейдите к параметру Вывод на консоль для получения более подробной информации:

Отслеживание репозитория GitHub и чтение файла Дженкинса

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

Учетные данные GitHub

Для создания пары ключей мы будем использовать команду ssh-keygen :

Выберите, где хранить ключи, и установите пароль, если хотите.

Теперь пришло время создать проект и настроить его.

Создание проекта

Маршрут Git также является более общим, поскольку процедура одинакова для любого удаленного репозитория Git – он не обязательно должен размещаться на GitHub, но, возможно, на сервере компании или в другой службе хостинга, такой как BitBucket и GitLab.

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

Давайте продолжим и напишем сценарий, похожий на Groovy, под названием “Файл Дженкинса” (без расширения) и зафиксируем/переместим его в корневой каталог вашего репозитория:

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

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

Служебные задачи в командной строке

Он входит в комплект каждой установки Дженкинса:

Чтобы узнать, сможем ли мы подключиться к Дженкинсу, давайте введем следующую команду:

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

Создание маркера API

Давайте создадим токен для нашего пользователя-администратора, выполним действия на изображении и скопируем полученный текст:

Список заданий и запущенных сборок

Импорт/Экспорт Существующих Заданий

Все конфигурации в Jenkins определяются с помощью XML. Это позволяет легко повторно использовать существующие конфигурации или импортировать новые. Помимо определений проектов, глобальные конфигурации, такие как плагины и учетные данные, все написаны в XML.

Вывод

Ключевой вывод здесь – это мощь автоматизации. Стоит вложить некоторое время и усилия в мощный инструмент, тщательно все настроить и больше никогда не тратить время на ручную работу. Отдача от инвестиций неоценима.

Это руководство предназначено для ознакомления с мощью и расширяемостью Дженкинса. Хорошо понимая основные принципы, ваши знания о Дженкинсе взлетят до небес, как только вы начнете экспериментировать с различными проектами, смешивая и сопоставляя различные инструменты сборки, языки и среды сборки.

Источник

Непрерывная интеграция и развертывание (Deployment) с помощью Jenkins

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

Прежде всего, что такое Jenkins?

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

По сути, это означает, что Jenkins (и многие другие инструменты) позволяют автоматизировать процесс развертывания или предоставления изменений в вашем программном обеспечении пользователям сразу после того, как эти изменения готовы. Представим насколько удобно пользователям видеть обновленные сайты сразу после объединения PR с master (или main).

Почему именно Jenkins?

У него сильное сообщество, поэтому найти поддержку не проблема.

Jenkins можно легко настроить, и я надеюсь доказать это в данной статье, так что читайте дальше.

В этом руководстве мы узнаем, как выполнить CI/CD для приложения Node с помощью Jenkins. Давайте начнем с определения всех шагов, которые мы предпримем, а затем подробно объясним их ниже:

Создайте репозиторий GitHub для приложения node

Создайте простое приложение node и поместите его на GitHub

Создайте приложение Heroku для развертывания

Добавьте веб-хук GitHub для внесения изменений в Jenkins

Сконфигурируйте приложение с помощью Jenkins

Добавьте плагины GitHub в Jenkins

Сконфигурируйте Jenkins для развертывания на Heroku после успешного тестирования

Необходимые условия

Учетная запись на GitHub. Можно зарегистрироваться здесь.

Учетная запись Heroku. Можно зарегистрироваться здесь.

Учетная запись на GitHub. Можно зарегистрироваться здесь.

Учетная запись Heroku. Можно зарегистрироваться здесь.

Итак, давайте начнем!

После создания репозитория, клонируйте его на локальную машину с помощью следующей команды:

Не забудьте изменить repository_url на свой.

Вы можете удалить или изменить то, что находится в блоке скриптов вашего файла package.json, и добавить start и test для запуска и тестирования приложения:

Мы будем использовать express для нашего примера приложения node, поэтому инсталлируйте его, запустив эту команду в терминале:

Далее создайте файл index.js, который будет служить точкой входа в наше приложение node, и добавьте в него следующие строки:

Запустите npm start и зайдите на http://localhost:4000/ через браузер для просмотра приложения Node, на экране появится Hello world.

Далее мы добавим пару тестов в наше приложение, впоследствии, с помощью CI, мы должны убедиться, что тесты доступны и выполняются перед тем как объединить изменения.

Итак, вернитесь в терминал, убедитесь, что вы находитесь в корневом каталоге вашего проекта, и установите пакеты jest и supertest с помощью следующей команды:

Далее в корневом каталоге проекта создайте папку и назовите ее __test__ (два знака подчеркивания, предшествующий и завершающий). Внутри этой папки __test__ создайте файл index.test.js и добавьте в него по крайней мере следующий код (вы всегда можете сделать свои тесты более полными).

Запустите npm test или npm run test в терминале, и вы убедитесь, что тест(ы) прошел(и):

Теперь, когда наш код запущен и тесты пройдены, можно закоммитить изменения и отправить их на GitHub.

Войдите в свою панель управления Heroku.

Посмотрите в правый верхний угол и нажмите на New.

Выберите Create new app (Создать новое приложение).

Добавьте App name (название приложения) по своему выбору и выберите регион (Choose a region), в котором вы находитесь.

Нажмите Создать приложение (Create app).

Вернитесь в терминал вашего проекта и login (войдите) в Heroku с помощью Heroku CLI. Если вы еще не установили Heroku CLI, вы можете прочесть эту статью.

После этого добавьте remote в ваш локальный репозиторий с помощью:

Затем введите код с помощью:

Это делается для того, чтобы убедиться, что все работает правильно, прежде чем автоматизировать его. Вы можете нажать open app (открыть приложение) на приборной панели приложения Heroku, чтобы проверить, правильно ли оно работает.

Откройте новый терминал и войдите на свой сервер под учетной записью пользователя non-root.

После этого мы можем обновить ядро с помощью следующей команды:

Выполните следующую команду для установки java runtime:

Выполните следующие команды одну за другой для установки Jenkins.

Теперь, когда Jenkins и все зависимости инсталлированы мы можем запустить его с помощью:

Вы можете проверить успешность запуска Jenkins, используя:

Он должен показать active:

Поскольку Jenkins выполняется на порту 8080, давайте откроем его с помощью ufw:

Вы можете проверить состояние ufw с помощью:

Теперь посетите сайт http://ip_address:8080 для настройки Jenkins, на котором вы должны увидеть экран Unlock Jenkins.

Чтобы разблокировать Jenkins, вернитесь к терминалу и введите следующую команду для отображения пароля. Скопируйте пароль и вставьте его в поле Administrator password (Пароль администратора).

На следующем экране отображается Customize Jenkins (Настроить Jenkins), нажмите на Install suggested plugins (Установите предложенные плагины).

После завершения установки мы перейдем к экрану Create First Admin User (Создание первого пользователя-администратора). Введите Username (имя пользователя), Password (пароль), Full name (полное имя) и E-mail address (адрес электронной почты) для вашего пользователя, затем Save and Continue (Сохранить и продолжить).

После этого введите IP-адрес сервера, т.е. http://ip_address:8080, затем Save and Finish (Сохранить и Завершить).

Ура, Jenkins готов! Нажмите на Start using Jenkins (Начать использование Jenkins).

В репозитории GitHub приложения перейдите в Settings (Настройки), затем на боковой панели нажмите на Webhooks. Нажмите на Add webhooks (Добавить веб-хуки) и введите url Jenkins с приставкой /github-webhook/ в поле Payload URL.

Выберите application/json для Content-type.

Выберите Just the push event для события, запускающего веб-хук.

Установите флажок Active и нажмите Add webhook. Теперь GitHub может успешно отправлять события в Jenkins.

Откройте новую вкладку или окно терминала и войдите на свой сервер с той же учетной записью пользователя non-root.

В том же терминале включите привилегии root, используя:

После переключения пользователя с правами root и инсталляции npm, Jenkins автоматически создает нового пользователя после завершения установки. Переключитесь на него с помощью этой команды.

Сгенерируйте новый ключ SSH с помощью следующей команды:

Нажмите клавишу Enter для ввода местоположения и не указывайте пароль при запросе, просто нажмите клавишу Enter.

После завершения процесса распечатайте информацию об открытом ключе с помощью:

Скопируйте открытый ключ.

Теперь войдите обратно как пользователь non-root в новом терминале.

Откройте папку authorized_keys следующей командой:

Вставьте открытый ключ id_rsa и выйдите.

Чтобы убедиться, что ключи настроены правильно, переключитесь на терминал сервера jenkins и попробуйте войти в систему как пользователь non-root, используя ssh. Вы успешно войдете в систему, если будете следовать всем вышеописанным действиям.

На приборной панели Jenkins перейдите в раздел Manage jenkins (Управление jenkins), а затем нажмите на Manage plugins (Управление плагинами).

На вкладке Available найдите github и выберите Github Integration plugin (Интеграционный плагин Github).

Нажмите на Install without restart (Установить без перезагрузки), и плагин будет установлен через несколько секунд.

Теперь, когда GitHub подключен к Jenkins, мы можем создать новый проект.

На боковой панели нажмите на New Item (Новая тема), выберите Freestyle project из предложенных вариантов и нажмите OK.

Далее вы должны попасть на страницу конфигурации, но если этого не произошло, можно открыть ее, нажав Configure на левой боковой панели.

Далее прокрутите вниз до раздела Source Code Management (Управление исходным кодом), выберите Git и добавьте Repository URL с расширением .git (тот же url, который вы использовали для клонирования репозитория).

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

Нажмите на кнопку Add repository (Добавить репозиторий), чтобы добавить второй репозиторий, указывающий на ваше приложение Heroku.

Чтобы получить ссылку на репозиторий приложения Heroku, перейдите в App settings (настройки приложения) на панели управления Heroku и скопируйте ссылку.

Вернитесь на приборную панель Jenkins и вставьте эту ссылку в Repository URL.

Нам понадобятся новые учетные данные, поэтому нажмите на Add, чтобы создать их для нашего приложения Heroku.

Выберите Jenkins из списка, и у вас должно появиться всплывающее окно.

Введите username (имя пользователя) по своему выбору, но лучше всего, чтобы оно было каким-нибудь описательным. Я буду использовать heroku в качестве имени пользователя.

Далее нам нужно будет добавить Heroku Api key (Api-ключ) в поле Password

(Пароль) и Save (Сохранить). Чтобы получить Heroku Api key, перейдите на приборную панель Heroku, нажмите на Account Settings (Настройки аккаунта) и прокрутите вниз, чтобы увидеть Api key. Скопируйте его и вставьте в поле Password (Пароль).

Вы можете добавить Description (Описание) для этой учетной записи, если хотите.

Нажмите Add (Добавить), чтобы завершить создание учетной записи.

Теперь убедитесь, что в выпадающем списке выбраны новые учетные данные, которые мы только что создали. Если нет, нажмите на выпадающий список и выберите их.

Далее нажмите на advanced и добавьте Name, чтобы идентифицировать это хранилище среди других удаленных хранилищ. Это имя понадобится нам позже. Я назвал свое хранилище jenkinsTest, потому что это легко и понятно.

Далее прокрутите вниз до раздела Build Triggers и отметьте опцию GitHub hook trigger for GITScm polling (Триггер хука GitHub для опроса GITScm).

В разделе Build нажмите на кнопку Add build step (Добавить шаг сборки) и затем нажмите на Execute shell (Выполнить командную оболочку). Введите в оболочку следующий код:

Нажмите на Add post-build action (Добавить действие после сборки), выберите Git Publisher и укажите опцию Push Only If Build Succeeds (Запускать только в случае успеха сборки).

Нажмите на Add Branch (Добавить ветвь), введите имя ветви для развертывания в поле Branch to Push и добавьте Name, используемое для идентификации репозитория приложения Heroku, в поле Target remote name (мое имя было jenkinsTest, если вы помните, поэтому добавьте сюда свое).

Затем Save (сохраните).

Перейдите на приборную панель проекта, нажмите Build now (Построить сейчас) на левой боковой панели и с удовольствием наблюдайте за успешной сборкой вашего кода!

Внесите изменения в свой код и опубликуйте его на GitHub. Затем посмотрите, как ваш код будет автоматически развернут на Heroku.

Приглашаем всех желающих ознакомиться с онлайн-курсами, которые помогут прокачаться в JavaScript-разработке:

Источник