Где jenkins хранит файлы

Обновлено: 02.07.2024

Веб-приложение Jenkins написано на java и для его работы мы дополнительно установим пакет openjdk. Данная инструкция написана на примере Ubuntu Server 20.04.

Подготовка системы

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

Обновление списка пакетов в репозиториях

Для возможности установки свежих пакетов, выполняем команду:

Настройка времени

Для настройки времени зададим часовой пояс:

timedatectl set-timezone Europe/Moscow

* в данном примере московское время.

Установим службу для синхронизации времени:

apt-get install chrony

Разрешим ее автозапуск:

systemctl enable chrony

Настройка брандмауэра

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

iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

И сохраняем правило:

apt-get install iptables-persistent

Инсталляция Jenkins

Как было сказано выше, мы установим openjava, сервис Jenkins и завершим развертывания на портале. Итого, 3 этапа.

1. Установка openjdk

apt-get install default-jdk

Выбираем реализацию java по умолчанию с помощью утилиты update-alternatives:

update-alternatives --config java

There is only one alternative in link group java (providing /usr/bin/java): /usr/lib/jvm/java-11-openjdk-amd64/bin/java
Nothing to configure.

Это значит, что в системе установлена только одна реализация java. Но если их несколько, на запрос:

Selection Command
-----------------------------------------------
*+ 1 java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.9.11-0.el8_2.x86_64/bin/java)

. выбираем вариант с подходящей версией, например, последней:

Enter to keep the current selection[+], or type selection number: 1

Готово. Смотрим версию установленной java:

Мы должны увидеть что-то на подобие:

openjdk version "11.0.10" 2021-01-19
OpenJDK Runtime Environment (build 11.0.10+9-Ubuntu-0ubuntu1.20.04)
OpenJDK 64-Bit Server VM (build 11.0.10+9-Ubuntu-0ubuntu1.20.04, mixed mode, sharing)

2. Установка Jenkins

Для установки сервиса Jenkins добавляем репозиторий:

Импортируем публичный ключ для подключения к репозиторию:

Обновляем список пакетов:

apt-get install jenkins

Разрешаем автозапуск сервиса:

systemctl enable jenkins

3. Завершение установки

И так, на сервере вводим команду:

* где /var/lib/jenkins/secrets/initialAdminPassword — полный путь до файла, который отображен на стартовой странице установки.

Мы должны увидеть что-то на подобие:

Используем данный пароль и вставляем его в поле Administrator password:

В следующем окне выбираем вариант установки плагинов — рекомендованные или по выбору:

* если мы не слишком хорошо знакомы с продуктом, выбираем рекомендованные плагины.

Начнется процесс развертывания Jenkins:

После создаем учетную запись для администратора:

На последней странице мы можем задать URL-адрес для нашего портала (или оставить IP-адрес):

Другие способы установки

Кратко, рассмотрим другие методы установки Jenkins.

1. Docker

После загружаем контейнеры для Jenkins:

docker pull jenkins/jenkins

docker run -p 8080:8080 --name=jenkins-master jenkins/jenkins:latest

После выполнения установки прерываем работу контейнера в интерактивном режиме комбинацией Ctrl + С и запускаем его в бэкграунде:

docker start jenkins-master

2. Установка из файла WAR

Загружаем последнюю версию war-файла:

* на странице загрузки jenkins можно найти ссылку для скачивания LTS-версии файла war. Обратите внимание, что мы сразу размещаем файл в каталоге /usr/local/bin.

Запускаем war с помощью java:

java -jar /usr/local/bin/jenkins.war

После выполнения установки прерываем работу war в интерактивном режиме комбинацией Ctrl + С.

Создаем юнит в systemd:

[Unit]
Description=Jenkins Service
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/bin/java -jar /usr/local/bin/jenkins.war
Restart=on-abort
ExecReload=/bin/kill -HUP $MAINPID

Перечитываем юниты в systemcd:

Разрешаем автозапуск сервиса jenkins и стартуем его:

systemctl enable jenkins --now

Можно проверить состояние запущенной службы командой:

systemctl status jenkins

Работа с Jenkins в CLI

По умолчанию, необходимый для работы с Jenkins из командной строки файл jenkins-cli.jar не копируется в систему.

Его нужно скачать. Выполняем:

* таким образом, мы скачаем файл с собственного сервера и разместим его в папке /usr/local/bin/.

Теперь можно выполнять команды с синтаксисом:

Например, получить список команд можно так:

* где admin:admin — логин и пароль от административной учетной записи.

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

Список плагинов мы можем найти на официальном сайте. Мы рассмотрим 2 способа их установки — из веб-интерфейса и командной строки.

Веб-интерфейс

Переходим в раздел Настроить Jenkins:

Затем в Управление плагинами:

Переходим к вкладке Доступные, по фильтру находим нужный нам плагин, отмечаем галочкой его установку:

Кликаем по кнопке Загрузить и установить после перезагрузки:

Будет выполнена установке плагина, после чего, портал перезапустит сервис.

В командной строке для установки плагина выполняем:

* в данном примере мы установим плагин Docker Pipeline. Обратите внимание, что его идентификатор для установки docker-workflow — посмотреть данный идентификатор можно на сайте с плагинами.

После перезапускаем сервис jenkins:

systemctl restart jenkins

Возможные ошибки

Error: Unable to access jarfile jenkins-cli.jar

Ошибка появляется при попытке выполнить команду в jenkins-cli.

Причина: для работы команды необходим файл jenkins-cli.jar, который не устанавливается в системе.

Решение: выполняем действия по настройке системы для работы с jenkins-cli.

failed to start lsb: start jenkins at boot time

Ошибка возникаем при попытке запустить сервис jenkins.

Причина: как правило, отсутствие в системе установленного java.

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

Теперь, если Jenkins хранит то, что задания должны быть запущены на нем в файле XML или наборе файлов XML где-то, я мог бы настроить систему, где эти файлы фиксируются на сервере управления версиями, а затем загружаются обратно на вновь созданный сервер как часть манифеста марионетки. Кто-нибудь знает, где хранятся эти файлы? Я пробовал копировать /var/lib/jenkins/jobs , но, похоже, он хранит выходные данные заданий Jenkins, а не входные.

Я развернул jenkins в tomcat году, используя war deployment с успешными результатами. Настройка заданий & узлов происходит правильно, а CI работает хорошо. Мне было интересно, откуда берется информация о задании & узлов, хранящаяся в jenkins. Поскольку я, возможно, захочу периодически.

Jenkins хранит некоторые связанные данные сборки, такие как следующие:

Рабочий каталог хранится в каталоге /workspace/ .

Каждое задание хранит в каталоге соответствующую папку временной рабочей области /workspace/

Конфигурация для всех заданий, хранящихся в каталоге /jobs/ .

Каждое задание хранит связанные с ним данные сборки в каталоге /jobs/

Каждая папка заданий содержит:

Файл конфигурации задания /jobs//config.xml

Сборки заданий хранятся в /jobs//builds/

Визуальное представление и дополнительные сведения см. в документации Jenkins.

На Linux можно найти домашний каталог Jenkins, ищущий файл, который содержит Jenkins' home, например:

Jenkins 1.627, OS X 10.10.5 /Users/Shared/Jenkins/Home/jobs//config.xml

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

Для полноты картины: macOS High Sierra, Jenkins 2.x, установка через Homebrew

Итак, у меня есть Jenkins, работающий на экземпляре AWS EC2 windows. Я создал несколько тестовых заданий, и они отлично запускают мои сценарии автоматизации Selenium из Jenkins в моем браузере FF с помощью localhost:8080. У меня Jenkins установлен в C:\Jenkins. Однако внутри C:\Jenkins/jobs я.

Я добавляю несколько вещей, связанных с хранением файлов конфигурации jenkins.

Насколько я понимаю, все файлы конфигурации хранятся на машине или OS, которую вы установили jenkins.

Задания, которые вы собираетесь создать в jenkins, будут храниться на сервере jenkins, и вы можете найти config.xml и т. Д. Здесь.

После установки jenkins вы найдете jenkins рабочее пространство на сервере.

Что такое Дженкинс?

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

У Дженкинса есть два главных выпуска, Синий океани классика. Blue Ocean более поздняя и включает в себя упрощенный интерфейс, который значительно упрощает создание конвейеров. Мы будем использовать Blue Ocean для этого руководства, но большинство одинаковых концепций будут применяться к обеим версиям Jenkins.

Установка Дженкинс

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

Чтобы сделать платформу независимой, мы будем запускать Jenkins с помощью Docker, который в любом случае рекомендует Jenkins.

Установка Docker

Для Ubuntu вам необходимо установить некоторые предварительные условия:

Затем добавьте ключ GPG в Docker:

И добавьте сам репо:

Обновите свои источники:

И, наконец, установите Docker из apt:

Теперь в вашей системе должен быть запущен Docker, который вы можете проверить с помощью systemctl ,

Настройка Дженкинс

Когда Docker запущен и работает, вы можете настроить контейнер Docker для Jenkins. Сначала вам понадобится мостовая сеть для контейнеров общаться на:

Дженкинс на самом деле должен иметь возможность запускать Docker как часть своей работы для настройки сред сборки. Это невозможно с обычным Docker, поэтому для правильной работы вам нужно запустить «Docker in Docker» или DinD. Следующая команда запустит официальный Docker docker:dind контейнера, привяжите к нему сеть и тома, созданные на предыдущих шагах, и опубликуйте его как службу, работающую на порту 2376 для использования контейнером Jenkins. Вы можете сменить этот порт, если хотите, хотя вам придется изменить его и на следующем шаге.

С этой настройкой вы можете запустить jenkinsci/blueocean Контейнер с помощью следующей команды:

Это позволит смонтировать сеть и диски, установить DOCKER_HOST переменная для порта, на котором работает DinD, и опубликуйте сервис на порту 8080, который вы можете изменить, если он не бесплатный. (Формат host:container .) Также публикуется административное соединение Jenkin через порт 50000, если вы планируете настроить главный сервер Jenkins с несколькими распределенные сборки подключиться к нему.

Вам нужно будет ввести пароль, хранящийся в /var/jenkins_home/ , который является частью тома Docker. Чтобы получить к нему доступ, вам нужно запустить cat внутри контейнера Docker:

Это распечатает пароль, который вы можете скопировать и начать остальные настройки.

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

Создание конвейера

После настройки Jenkins вас встретит следующий экран приветствия. Нажмите «Создать новый конвейер», чтобы начать.

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

Однако лучшим решением будет просто выбрать общий «Git». Введите в свой URL хранилища, и Дженкинс даст вам открытый ключ. Поскольку Jenkins может совершать коммиты (и всегда фиксирует изменения в конфигурации конвейера), вы должны создать нового пользователя сервиса и добавить к нему открытый ключ.

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

Каждый конвейер будет иметь несколько отдельных этапов, таких как Build, Test или Deploy, которые будут содержать отдельные этапы. Они могут выполнять самые разные действия, такие как отправка электронных писем, взаимодействовать с другими службами, такими как Jira и Git, и координировать последовательность других шагов, но вы чаще всего будете использовать их для выполнения простых сценариев оболочки. Любые ошибки в возврате этих сценариев приведут к сбою конвейера.

Прежде чем добавлять какие-либо этапы, вы захотите настроить параметры среды. Обычно вы используете Docker-контейнер, такой как node:latest ,

Для этого примера мы создадим веб-приложение на основе Node. Просто добавив два шага для npm install и npm run build это все что нужно. Дженкинс выполнит эти команды и перейдет к следующему этапу с установленными артефактами сборки. На этапе тестирования настройка сценария оболочки для запуска Jest потребует прохождения всех тестов для успешной сборки.

Дженкинс может запустить несколько этапов параллельно, что полезно, если вам нужно проверить на нескольких разных платформах. Вы можете настроить этапы «Тестирование в Linux» и «Тестирование в Windows» и запускать их одновременно, чтобы не ждать, пока один из них запустит другой. Если один из них выходит из строя, конвейер все равно будет отказывать.

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

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

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

Создание Jenkins backup/restore в Unix/Linux

И так, нам понадобится установить плагин(ы) (можно и один на выбор, я использовал несколько для сравнения):

Thin backup
Backup Plugin
Periodic Backup
SCM Sync configuration

Можно заюзать и другие решения:

Перейдем к решениям!

Использование Thin backup плагина для backup/restore Jenkins-а в Unix/Linux

Плагин ThinBackup для Jenkins-а

В данном плагине имеются:

Начнем с настройки, нажимаем по нему:

Настройка thinBackup плагина для бэкапа дженкинса

Вот и все. Можно юзать данный плагин для бэкаа и рестора.

Использование Backup Plugin плагина для backup/restore Jenkins-а в Unix/Linux

В данном плагине имеются:

Я привел настройку к такому виду:

Использование Periodic Backup плагина для backup/restore Jenkins-а в Unix/Linux

Меню Periodic Backup plugin

Настройка Periodic Backup plugin

Вот и все. Можно выполнить бэкап! Данный плагин понравился больше чем другие!

Использование SCM Sync configuration плагина для backup/restore Jenkins-а в Unix/Linux

Использование bash-скрипта для backup/restore Jenkins-а в Unix/Linux

Можно написать скрипты на любой вкус, используя bash. Есть плагин для запуска скриптов через джобу. Сейчас поставим данный плагин.

настройка SCM

Т.е заполним переодичность с которой будет запускаться скрипт.

Настройка запуска скрипта с параметрами через Build-execute shell

Добавляем в поле следующий текст:

Т.е бэкапы будут хранится 7 дней, остальные будут удалены.

Вот еще один пример скрипта, который можно использовать:

Я для клиента писал вот такой скрипт:

Читайте также: