Что такое jenkins и зачем он нужен

Что такое Jenkins

Опубликовано: 06.11.2020

бесплатная программа, позволяющая организовать процесс непрерывной интеграции (CI или Continuous Integration) и доставки (CD или Continuous Delivery) программного продукта (постоянное объединение рабочих копий в основную ветку разработки). Разработана на Java и является веб-приложением. Для своей работы требует веб-сервер Tomcat.

Скачать программу можно на официальном сайте. Jenkins можно установить на все популярные операционные системы — Windows, Linux, Mac OS и другие. Поддерживается установка на саму систему или в виде контейнера Docker. В Linux также можно установить из репозитория. Системные требования не высокие:

1. JDK 1,5 или выше.
2. От 256 Мб ОЗУ (рекомендуется от 2 Гб).
3. Дисковое пространство, достаточное для хранение проектов.

Получить документацию также можно на официальном сайте. Также можно просмотреть онлайн курс для начинающих (на русском) на YouTube канале ADV-IT.

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

Среди аналогов можно отметить:

• Bamboo.
• GitLab CI/CD.
• TeamCity
• circleci.

Подробнее о Jenkins на Википедии.

Встречается в статьях

Мини-инструкции:

1. Как установить Jenkins на операционную систему Linux CentOS
2. Установка и настройка системы CI/CD Teamcity на Linux Ubuntu Server
3. Как установить Jenkins на систему Linux Ubuntu Server
4. Как работать с pipeline в Jenkins — подготовка системы, пример Groovy-скрипта
5. Как настроить автоматический запуск конвейера CI/CD в Jenkins при коммитах в Subversion
6. Пример сборки проекта, написанного на Java, с помощью системы сборки Maven

Делаем Jenkins Pipeline: шаг за шагом

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

Я буду отталкиваться от того, что у тебя уже установлен Jenkins. Установка Jenkins’а неплохо описана и показана в сети. Мы же будем смотреть на то, как создается Jenkins Pipeline или труба (конвейер) Jenkins.

Для чего всё это

Что вообще такое Jenkins? Jenkins это крутая программа, которая реализует практики DevOps. Практики DevOps, в свою очередь, это логичные действия, которые позволяют повысить качество создаваемых продуктов. Под «качеством» будем понимать сразу много преимуществ – уменьшение количества ошибок в продукте, снижение Time-to-Market, повышение пользовательской лояльности и т.д.

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

О DevOps и его практиках

DevOps, грубо говоря, регламентирует «завод» и «конвейер» на нём.

Одной из практик DevOps является CI/CD/CDP. Эта практика описывает шаги «конвейера».

CI (Continuous Integration, непрерывная интеграция) – начальная стадия «конвейера» по сборке кода и загрузке собранного ПО в среду разработки.

CD (Continuous delivery, непрерывная поставка) – является продолжением CI. В этой практике производится автоматизированное развертывание на тестовую среду продукта и разнообразные тесты над ним.

CDP (Continuous Deployment, непрерывное развертывание) – поставка результатов работы CI и CD практик в промышленную среду.

Jenkins, в свою очередь, может реализовать CI/CD/CDP на практике.

Описание примера

Теперь, имея представление что такое Jenkins и для чего он нужен, сделаем тестовую трубу, которая реализует в очень урезанном виде CI/CD практику.

В качестве разворачиваемого продукта будем использовать SSIS-пакет. SSIS (SQL Server Integration Services) – это инструмент создания решений по интеграции и преобразованию данных. То есть, решение по переносу данных из одного источника в другой с возможностью преобразования этих данных в процессе переноса.

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

Чтобы было ещё интереснее, сделаем задачу со звёздочкой – в одном SSIS-проекте будет сразу несколько SSIS-пакетов.

Опишу шаги, которые будет делать труба:

1. Чекаут из Git (в моём случае Bitbucket)
2. Сборка SSIS-проекта
3. Развертывание собранного файла проекта в среду разработки.

Мой подопытный SSIS-кролик выглядит следующим образом:

Внутри проекта «AUDIT_Import_ALL» находится четыре SSIS-пакета с расширением «.dtsx». Если этот проект собрать, то получится один файл с именем «AUDIT_Import_ALL» и расширением «.ispac». Данный файл предназначен для развертывания проекта в MS SQL Server.

Подготовительные шаги

Проект «AUDIT_Import_ALL» загружен в Bitbucket. В репозиторий проекта я добавлю папку, содержащую Jenkinsfile.

Jenkinsfile – это простой текстовый файл с кодом на языке Groovy, который используется для конфигурации трубы Jenkins.

Теперь я создам тестовую трубу в самом Jenkins. Для этого на главной странице пространства Jenkins нажимаю «New Item», далее выбираю Pipeline и задаю имя.

После нажатия «ОК», открывается окно с настройками. Не будем подробно останавливаться на этом окне. Для тестового примера мне никакие настройки здесь не нужны, кроме раздела с расширенными настройками. А именно, окно настройки «Pipeline».

В нём я свяжу Jenkinsfile, который находится в Bitbucket, с только что созданной трубой Jenkins. Для этого в пункте «Definition» выбираем «Pipeline script from SCM». Этим пунктом я сообщаю Jenkins что мой Jenkinsfile лежит в SCM (source control management – система контроля версий).

На следующем шаге я выбираю SCM, где лежит мой файл. В моём случае это Git (Bitbucket). Далее я прописываю путь до репозитория в SSH формате (возможно и в HTTPS) и указываю учетные данные в поле «Credentials» (или добавляю новую учетную запись через кнопку «Add»).

Jenkinsfile лежит в master-ветке репозитория в Bitbucket, поэтому я не трогаю пункт «Branch Specifier (blank for ‘any’)». Так же, не трогаю следующие два пункта. А вот
пункт «Script Path» мне необходимо поменять, потому что по умолчанию Jenkins будет
искать Jenkinsfile в корне репозитория. Отдельная папка нужна затем, что файлов для работы Jenkins-трубы может быть несколько и содержать их в корне проекта будет просто не удобно.

Jenkins SSIS стенд

Хочу затронуть архитектурное решение моего Jenkins-стенда. Для тех, кто не будет строить DevOps для SSIS, можно перейти сразу к следующему разделу.

Архитектурно Jenkins строится по принципу master-slave. Есть один ведущий узел, который управляет множеством ведомых. У меня уже была развернута master-нода Jenkins. К ней я подключил slave-ноду, которая была создана под задачу DevOps SSIS. На этом сервере находится программа SSISBuild.exe, предоставляемая Microsoft как раз для наших нужд. SSISBuild предназначена для удаленной сборки SSIS-проектов и не требует установленной Visual Studio или среды выполнения SSIS.

Сервер, куда я буду развертывать SSIS-проект, содержит установленный MS SQL Server с установленной службой Integration Services. На этом сервере установлена вторая программа для DevOps SSIS – SSISDeploy.exe. SSISDeploy предназначена для развертывания файлов проектов (файлов с расширением ispac).

Более подробную информацию о SSISBuild и SSISDeploy вы сможете найти по ссылке.

Jenkinsfile

Итак, труба настроена, связь с Bitbucket установлена, необходимые сервера на связи. Осталось совсем чуть-чуть до запуска. Разберем Jenkinsfile чтобы понимать, как будут происходить те шаги, которые я описал в начале статьи.

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

Все операции с конвейером должны быть заключены в блок «pipeline»:

pipeline < /* Ваши инструкции для конвейера */ >

Блок «pipeline» содержит разделы. Первым разделом является «agent». Раздел «agent» указывает, где будет выполняться труба Jenkins. Раздел должен быть определен на верхнем уровне внутри блока «pipeline».

В моём случае конвейер будет работать на сервере TestNode:

agent < node < label 'TestNode' >>

Раздел «options» позволяет настраивать параметры конвейера непосредственно из Jenkinsfile. Эти параметры также можно задавать в графическом интерфейсе Jenkins.

 ansiColor('xterm') timestamps() disableConcurrentBuilds() timeout(time: 1, unit: 'HOURS') buildDiscarder(logRotator(artifactDaysToKeepStr: '7', artifactNumToKeepStr: '10', daysToKeepStr: '7', numToKeepStr: '50')) >

Раздел «parameters» задает список параметров, которые пользователь должен предоставить при запуске трубы. Заданные пользователем значения становятся доступными для шагов конвейера через объект params. Я создам два булевых параметра, с помощью которых можно будет управлять запуском шагов конвейера:

parameters

Раздел «environment» определяет глобальные и локальные (в пределах конкретного «step») переменные в Jenkinsfile. Глобальные переменные удобно использовать для подстановки статических значений:

environment

Раздел «stages» является местом, где будет происходить основная часть работы конвейера. Раздел делится на этапы, которые содержат описание шагов. У меня будет три этапа:

stages < // Извлекаем проект из Bitbucket stage('Checkout') < >// Собираем проект. Получаем на выходе пакетный файл AUDIT_Import_ALL.ispac stage('Build') < >// Загружаем архив с проектом на удаленный сервер. Деплоим его на MS SQL Server stage('Deploy') < >>

Теперь рассмотрим шаги на каждом этапе.

 1) Checkout stage('Checkout') < steps < // Удаление всех файлов из рабочего каталога на сервере TestNode bat 'del /F /S /Q *.*' // Удаление всех папок из рабочего каталога на сервере TestNode bat 'for /d %%x in (.\\*) do @rd /s /q %%x' // Вывод echo в консоль Jenkins echo 'step Git Checkout' // Извлечение из системы контроля версий в рабочий каталог на сервере TestNode checkout scm >> 2) Build stage('Build') < // Команда when позволяет конвейеру определять, следует ли выполнять этап в зависимости от заданного условия. when < // Заданное условие expression. Оно задается пользователем при запуске конвейера и передается в скрипт через параметр "BUILD" expression < return params.BUILD >> // Начало шага сборки SSIS-проекта steps < // Вызов функции PrintStage(). Её мы рассмотрим далее. PrintStage() echo "step Build Solution" /* Вызов SSISBuild.exe на TestNode. Кстати, здесь применяется три подстановки: - переменная среды $- абсолютный путь рабочей области. - глобальные переменные $ и $ - они задавались в разделе environment */ bat "$ -p:$\\$" > > 3) Deploy stage("Deploy to Dev Env") < when < expression < return params.DEPLOY >> steps < PrintStage() // Использование стандартного плагина Jenkins для архивации собранного SSIS-проекта zip zipFile: 'archive.zip', archive: false // Самое интересное. Для деплоя полученного файла будем применять службу удаленного управления Windows WinRM в PowerShell // Используем учетную запись 'WINRM_PASS' для извлечения SecretText из Jenkins. Учетная запись заведена в Jenkins. Как её добавить я покажу ниже withCredentials([string(credentialsId: 'WINRM_PASS', variable: 'WINRM_PASS')]) < // Применение скриптового синтаксиса внутри декларативного. script < // Определяем переменные def err def stdout = powershell label: 'deploy', returnStdout: true, script: ''' # Задаем пароль учетной записи WinRM в SecureString $pw = convertto-securestring -AsPlainText -Force -String $env:WINRM_PASS # Задаем учетные данные для создания сессии WinRM $cred = new-object -typename System.Management.Automation.PSCredential -argumentlist "Domain\\User",$pw # Открываем сессию $s = New-PSSession -ComputerName -Credential $cred #Создаем папку на удаленном сервере для копирования архива $remotePath = \'D:\\DIGAUD\\TestSSISPipeline\' $job = Invoke-Command -Session $s ` -ScriptBlock < if (!(Test-Path -Path \'D:\\DIGAUD\\TestSSISPipeline\')) > ` -AsJob Wait-Job $job $r = Receive-Job $job # Копируем архив $path = Get-Location $dest = Join-Path $path "archive.zip" Copy-Item -Path $dest ` -Destination $remotePath ` -ToSession $s # Распаковываем архив $job = Invoke-Command -Session $s ` -ScriptBlock < Expand-Archive -LiteralPath \'D:\\Jenkins\\TestSSISPipeline\\archive.zip' -DestinationPath \'D:\\Jenkins\\TestSSISPipeline\' >` -AsJob Wait-Job $job $r = Receive-Job $job #Деплоим $job = Invoke-Command -Session $s ` -ScriptBlock < C:\\SSIS_DEV_OPS\\ssisdeploy.exe -s:\"D:\\Jenkins\\TestSSISPipeline\\AUDIT_Import_ALL\\bin\\Development\\AUDIT_Import_ALL.ispac\" -d:\"catalog;/SSISDB/AUDIT_Import_ALL;mssql_server,port\" -at:win >` -AsJob Wait-Job $job $r = Receive-Job $job Remove-PSsession $s ''' > > > > >

Раздел «post» определяет дополнительные действия, которые будут выполняться после завершения работы основного кода конвейера или этапа (в зависимости где стоит post).

post < // Код ниже будет выполнен вне зависимости от статуса сборки трубы или этапа always < script < # Устанавливаю результат сборки трубы currentBuild.result = currentBuild.result ?: 'SUCCESS' # Уведомляю Bitbucket о результате сборки notifyBitbucket() >> >

На этом мой блок «pipeline» в Jenkinsfile заканчивается.
Далее располагается метод «PrintStage», который встречался на этапах Build и Deploy:

// Метод, который принимает на вход один текстовый аргумент. По умолчанию аргумент пустой void PrintStage(String text="")< // Применение тернарного оператора // Если аргумент text пустой, в консоль Jenkins будет выведено десять звёздочек, название этапа, десять звёздочек // Если аргумент text не пустой, в консоль Jenkins будет выведено его значение text=="" ? println ('* '*10 + env.STAGE_NAME.toUpperCase() + " *"*10) : println (text) >

Теперь всё готово к запуску. Открываю окно нашего конвейера и нажимаю кнопку «Собрать с параметрами».

Откроется окно с параметрами, которые я определил в разделе «parameters». Выбираю этапы, которые хочу запустить и нажимаю «собрать».

Далее, труба начинает собираться и если всё сделано правильно, то Jenkins нарисует красивую картинку:

Как добавить учетную запись в Jenkins

Для этого на главной странице вашего пространства нажмите кнопку «Credentials», далее выбрать «Folder».

Наведите курсор на пункт «Global credentials (unrestricted)» и у вас появится «галочка» для вызова выпадающего списка. Нажмите на неё. Всплывет маленькое окошко «Add credentials» — нажимайте!

Здесь вы можете задать вашу учетную запись. В моём примере с учетной записью WinRM, я использовал «Secret text» для хранения пароля.

Выводы

По итогу, мы сделали трубу, которая собирает и деплоит SSIS-пакеты на MS SQL Server. Данный пример является учебным , но его можно взять за основу и доработать под ваши задачи. Например, если вы делаете веб-приложение на ASP.NET, то вместо ssisdeploy можно использовать webdeploy. По аналогии можно добавить шаги с разнообразными тестами, созданием release notes, загрузкой дистрибутива в централизованное хранилище и т.д.

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

Буду рад, если моя статья была кому-то полезна.

Если у вас остались вопросы оставляйте их в комментариях – я обязательно отвечу.

Руководство по Jenkins

В руководстве мы расскажем, зачем нужен Jenkins, а также покажем, как установить Jenkins на Ubuntu.

Jenkins — это сервис, с помощью которого можно автоматизировать процесс непрерывной интеграции программного обеспечения. Непрерывная интеграция (Continuous Integration) — один из этапов разработки, на котором происходит сборка рабочих копий проекта в единый макет-черновик, их тестирование, доставка или развёртывание программного обеспечения. Во время интеграции можно выявить слабые места и возможные ошибки в проекте и сразу их исправить.

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

Преимущества Jenkins:

• имеет открытый исходный код, написанный на Java;
• поддерживает свыше 1000 плагинов для интеграции с инструментами тестирования, разработки и деплоя;
• работает больше чем в двух средах одновременно без потери эффективности;
• Jenkins хорошо подойдёт для проектов, которые написаны на Python;
• оптимизирует рабочий процесс: вам не нужно нанимать штат профессиональных программистов, в Jenkins можно разобраться даже без специальной подготовки;
• выявляет и устраняет нестандартные ошибки без привлечения человека;
• минимизирует количество ошибок, возникающих в связи с человеческим фактором.

Jenkins можно установить на Windows, macOS, Debian, Ubuntu, CentOS и другие операционные системы. Также Jenkins можно установить через системные пакеты, Docker или запустить автономно на любом компьютере с настроенной Java Runtime Environment (JRE).

Jenkins можно установить с официального сайта одним из двух способов: скачать из раздела «Download» или использовать команды из раздела «Documentation». Для Jenkins документация на русском не разработана, однако именно в этом разделе можно найти рекомендации для быстрой установки. Поэтому установим Jenkins на Ubuntu версий 16.04/18.04/20.04 вторым способом.

Как установить Jenkins

Для Jenkins системные требования следующие:

• 256 Мб оперативной памяти,
• минимум 1 Гб дискового пространства при установке на ОС и 10 Гб при запуске в качестве контейнера Docker.

Основы CI/CD. Знакомство с Jenkins

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

CI/CD: что это такое и зачем нужно

Скорость разработки продуктов — одно из главных конкурентных преимуществ в разработке ПО. Поэтому на смену старым моделям программирования пришла новая концепция CI/CD.

CI (Continuous Integration) — непрерывная интеграция. Разработчики, применяющие данный паттерн, могут проверять основную ветку репозитория каждый раз, когда что-то замержили в неё. Не просто запускать локальные проверки, а в рамках CI-пайплайна выполнять автоматические тесты, unit-тесты и др.

CD, (Continuous Delivery) — непрерывная поставка. На этой стадии происходит автоматическое развертывание на стенды и тестовые окружения. Ещё CD расшифровывают как Continuous Deployment — непрерывное развёртывание. Это более продвинутый путь, на шаг дольше, чем непрерывная поставка. При таком подходе каждое изменение, которое мы коммитим в основную ветку репозитория, автоматически проходит все этапы CI и CD и затем попадает на продакшн.

Continuous Deployment Pipeline — высший пилотаж, который редко встречается на практике, потому что всегда есть определённые ограничения. Эти ограничения могут быть как в самом пайплайне, так и в бизнес-процессах с точки зрения безопасности. Но, однозначно, Continuous Deployment Pipeline — то, к чему нужно стремиться.

Цели CI/CD:

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

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

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

Третий принцип — сокращение цикла обратной связи. В рамках CI/CD мы стремимся увеличить скорость внесения изменений и согласования правок.

Четвертый принцип — реализация среды. У разработчиков должно быть общее пространство для работы с основной веткой или со вспомогательными ветками. Это пространство должно быть отказоустойчивым и удобным для работы.

Основные этапы CI/CD выглядят так:

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

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

Когда продукт попадает к пользователям, мы продолжаем следить за ним — этап поддержки и мониторинга. Мы контролируем, как пользователь идёт по бизнес-процессу, корректно ли работают интеграции. Если на стадии мониторинга мы обнаруживаем ошибку, возвращаемся к самому началу — к планированию. Аналитики разбирают, что пошло не так и предлагают новое решение, разработчики пишут код, и снова начинается процесс сборки.

Как и у любой методологии, у CI/CD есть свои плюсы и минусы:

Плюсы

Минусы

Минимальное время от запроса клиента до запуска в использование — мы быстрее доставляем новые фичи

Сложность обеспечения взаимодействия — и DevOps-инженеры, и разработчики должны понимать, что было сделано и зачем

Возможность проверки вариантов — можем моментально проверять изменения и при необходимости откатывать назад

Требования к опыту — нужен опыт настройки CI/CD, который почти всегда добывается с болью

Качество результата — можем быстро обнаружить и пофиксить ошибки

Реализовать принципы CI/CD, свести к минимуму ошибки интеграции, а также ускорить релизы и повысить их качество помогает Jenkins.

Что такое Jenkins

Jenkins – не просто инструмент CI/CD. Это Framework, потому что он:

• Гибок и расширяем. Jenkins — опенсорсный проект с множеством внешних расширений.
• Минимален из коробки. У Jenkins есть контроллер. Вы можете подключить к нему несколько слоев и уже на этом сетапе собрать минимальный пайплайн, который позволит автоматизировать работу по обновлению сервисов.
• Требует настройки. Jenkins — один из кубиков, с помощью которого можно построить большую систему автоматизации. Но прежде чем сделать что-то, его придётся настроить.

Jenkins — это Java-приложение. У него есть контроллер или Master Mode — управляющий центр, который занимается планированием задач. Он запускает задачи согласно установленному расписанию на слэйвах, которые вы к нему прикрепили. Помимо этого контроллер хранит логи наших задач. Вся история хранится только на Master Mode, поэтому важно помнить о настройке правильной ротации логов.

Слэйвы или агенты — это то, что непосредственно выполняет сами задания.

Коротко их взаимодействие можно описать так: контроллер запускает задачу и говорит агенту выполнить её, агент выполняет задачу и возвращает результат контроллеру. Контроллер получает результат и сохраняет его в build-логе.

Установка Jenkins

Разберём, как установить Jenkins, как настроить параметры JVM и почему это важно. Дополнительно познакомимся с Jenkins Home: что это за зверь и с чем его едят. Все действия будем выполнять на Ubuntu.

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

root@vs01:~# java --version

По умолчанию из коробки Java нет:

Рекомендуется использовать Java 11, потому что у неё более продвинутый Garbage Collector. Поставим её:

root@vs01:~# apt install openjdk-11-jre-headless

Проверим, что Java установилась:

root@vs01:~# java --version

Теперь нужно сконфигурировать файл limit.com. Но в Linux всё — файл, поэтому нужно установить фан-лимит, чтобы снять ограничения и позволить Jenkins генерировать файлы, дампы и др. Если не сделать этого, в каких-то случаях мы не сможем получить данные и понять, что же с Jenkins пошло не так.

Редактируем лимиты на Ubuntu:

root@vs01:~# vi/etс/security/limits.conf

И добавляем секцию управления и устанавливаем права на различные лимиты: хардовые, софтовые, size-файлы и др:

Дальше нужно установить фаервол на Ubuntu:

root@vs01:~# apt-get install ufw

Обязательно разрешаем OpenSSH-порт, потому что больше не сможем подключиться к этой машине:

root@vs01:~# ufw allow OpenSSH

8080 — порт, по которому работает Jenkins.

root@vs01:~# ufw allow 8080

Проверяем Jenkins репозиторий, потому что по умолчанию его нет в стоке Ubuntu:

root@vs01:~# wget -q -o – http://pkg.jenkins.io/Debian-stable/jenjins.io.key|sudo gpg --dearmor -o /usr/share/keyrings/Jenkins.gpg

После того, как скопировали ключи, устанавливаем Jenkins в sources list:

Важно для Ubuntu делать apt-get update:

root@vs01:~# apt-get update -y

Теперь можем поставить Jenkins:

root@vs01:~# apt-get install Jenkins -y

Установка проходит довольно быстро. Если посмотреть верхнеуровнево, то Jenkins — это war-файл. И вы можете не устанавливать его в систему через system, а просто скачать war-файл и запускать через war.

Мы можем посмотреть статус Jenkins App:

root@vs01:~# systemctl status jenkins

Он активный, но нам этого недостаточно. Jenkins — это Java, а Java очень требовательно относится к памяти. Поэтому дальше поговорим про Garbage Collector — службу, которая очищает память от неиспользованных объектов.

Мы немного «подтюним» Java-машину и добавим опции в файл etc systemd/system/jenkins.service:

root@vs01:~# vi /lib/systemd/system/Jenkins.service

Найдём Java OPTS:

Добавим больше опций:

Обратите внимание, что в настройках мы указываем Xmx512m и Xms512 — размер оперативной памяти, который выделяем Java-машине для работы. Вообще размер зависит от количества доступной памяти в операционной системе и корректируется в соответствии с ней. По рекомендациям Cloud Business и личному опыту, нужно ставить не больше 16 гигабайт на hip size. Но при этом важно не забывать, что у вас есть Meta Space и система, которые тоже занимают память. Если у вас на машине 20 гигабайт памяти, смело можно ставить 16. Если у вас всего 18 гигабайт памяти, и вы выделяете 16 гигабайт под Jenkins и Java, не удивляйтесь, когда машина начнёт работать плохо, а в какой-то момент просто умрёт.

Здесь выставляем Garbage Collector — UseG1GC:

И добавляем снятие автоматического дампа при out of memory:

Это полезная опция, когда Jenkins падает. Конечно, падения все равно будут случаться — мы не всегда можем рассчитать нагрузку и определить, сколько потребуется памяти для работы. Но параметр поможет понять, что произошло.

Также в Garbage Collector выставляем лог — /var/lib/jenkins/gc.log:

Нужно перезагрузить Jenkins, но перед этим сделать daemon-reload:

root@vs01:~# systemctl daemon-reload root@vs01:~# systemctl restart Jenkins

root@vs01:~# systemctl status Jenkins

oot@vs01:~# cat /proc/http://Jenkins.s043218.edu.slurm.io^C root@vs01:~# cat /proc/67043/cmdline

Видим, что Java настроена как раз под те опции, что мы ей передали, и запускается Jenkins war:

Теперь откроем веб-интерфейс http://jenkins.s043218.edu.slurm.io. Он предлагает разблокировать Jenkins:

То есть первоначальная установка предполагает, что вы введете некий мастер-пароль. Jenkins сам подсказывает, где этот мастер-пароль можно найти — var/lib/jenkins/secret/initialAdminPassword. Давайте пойдём туда и посмотрим:

root@vs01:~# cd var/lib/jenkins/

root@vs01:/var/lib/jenkins/# cd secrets/ root@vs01:/var/lib/jenkins/secrets# ls -al

Initial password — пароль, который вы можете использовать один раз при первой установке Jenkins. После вы переключитесь на внутреннюю базу авторизации.

Следующий шаг — установить Suggested-плагины или самостоятельно выбрать плагины, которые хотите поставить.

Список плагинов, которые используются в Suggested, достаточно правильный, поэтому рекомендуется просто поставить эти плагины автоматом.

А пока Jenkins делает плагины, посмотрим на Home-директорию:

root@vs01:/var/lib/jenkins/secrets# cd .. root@vs01:/var/lib/jenkins# ls -la

У Jenkins нет выделенной базы, как у некоторых систем. В качестве базы данных он использует директорию Jenkins Home, которая есть в каталоге файловой системы того сервера, на который выставили контролер. Здесь хранятся: конфиги, плагины, задания, которые мы делаем и всё, что связано с ними и т.д.

Вернёмся к Jenkins — он уже поставил домен и предлагает нам настроить первого пользователя. Заполним поля:

Далее Jenkins предлагает настроить URL:

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

Итак, мы поставили Jenkins. Пока нет никаких заданий, но мы можем немного пройтись по Manage Jenkins:

Из наиболее интересного здесь:

• System information — хранит всю основную информацию (Java Home, версия Java, версия Ubuntu и т.д.).
• System log — то, куда нужно смотреть, если непонятно, почему не подключается агент или не работает скрип.
• Load statistics — показывает, сколько экзекьюторов всего онлайн.

На этом всё. В рамках первого урока мы повторили цели CI/CD, узнали, что такое Jenkins и рассмотрели область его применения. Ещё попробовали самостоятельно установить Jenkins на Ubuntu-сервер и познакомились с содержимым Jenkins Home. В следующих уроках подробно разберём администрирование Jenkins, научимся настраивать интеграции, создавать конфигурации Jenkins As a Code и многое другое.

• Блог компании Слёрм
• Системное администрирование
• IT-инфраструктура
• Администрирование баз данных
• DevOps