Где jenkins хранит файлы
как изменить папку Дженкинса по умолчанию в Windows, где Дженкинс работает как служба Windows. Я хочу измениться до d:Jenkins из-за нехватки места на C: раздел (каждая сборка занимает ~10 МБ свободного места). Я не хочу переустанавливать Jenkins как служба Windows. Я просто хочу изменить папку существующего Jenkins экземпляра. В случае отсутствия глобального решения я мог сосредоточиться только на привлечении jobs папка.
заранее спасибо за вашу помощь.
- остановить службу Дженкинса
- движение до d:\Jenkins
- используя regedit, измените HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Jenkins\ImagePath to "d:\Jenkins\jenkins.exe"
- запустить службу
по-видимому, ответ грамма работает, но не является предпочтительным. В Windows программное обеспечение и файлы данных/конфигурации должны находиться в разных местах. Это должно быть хорошо известно ребятам Unix, это в основном похоже на наличие домашнего каталога. Однако формулировка в отношении JENKINS_HOME в любом случае нарушена, поскольку установка переменной среды не помогает, несмотря на то, что говорится в тексте справки.
- остановить службу Дженкинса
- изменить запись на jenkins.xml в каталоге установки Jenkins. Это будет что-то вроде C:\Program Files (x86)\Jenkins . В вашем случае value должна быть d:\Jenkins
переместить файлы из каталога установки в новое место назначения, d:\Jenkins , все кроме (некоторые из них могут не существовать в свежем установка)
- папка jre
- Дженкинс.ошибаться.log
- Дженкинс.exe
- Дженкинс.исполняемый.config
- Дженкинс.из.log
- Дженкинс.война!--16-->
- Дженкинс.война.бак!--16-->
- Дженкинс.война.tmp
- Дженкинс.обертка.log
когда вы читаете Администрирование Дженкинс вы можете прочитать все параметры, как изменить переменную среды JENKINS_HOME.
On этот сайт вы можете прочитать, Как настроить контейнер Tomcat для переопределения переменной среды JENKINS_HOME, они советуют создать файл $CATALINA_BASE/conf/localhost / jenkins.xml, со следующим содержанием:
и в дополнение к ответу grams наиболее важной частью является создание переменной среды с именем JENKINS_HOME со значением "D:\Jenkins". Без этого, на старте Дженкинса он бы снова создал свое .папка jenkins в домашней папке пользователя.
установка только %JENKINS_HOME% как системная переменная среды Windows не имела никакого эффекта!
мы установили, сбрасывая .война в Tomcat, и может установить домой просто настройка переменной среды JENKINS_HOME (с перезапуском службы).
Jenkins needs some disk space to perform builds and keep archives. You can check this location from the configuration screen of Jenkins.
By default, this is set to ~/.jenkins , but you can change this in one of the following ways:
- Set "JENKINS_HOME" environment variable to the new home directory before launching the servlet container.
- Set "JENKINS_HOME" system property to the servlet container.
- Set JNDI environment entry "JENKINS_HOME" to the new directory.
See the container specific documentation collection for more about how to do this for your container.
You can change this location after you've used Jenkins for a while, too. To do this, stop Jenkins completely, move the contents from old JENKINS_HOME to the new home, set the new JENKINS_HOME, and restart Jenkins.
JENKINS_HOME has a fairly obvious directory structure that looks like the following:
All the settings, build logs, artifact archives are stored under the JENKINS_HOME directory. Simply archive this directory to make a back up. Similarly, restoring the data is just replacing the contents of the JENKINS_HOME directory from a back up.
Back ups can be taken without stopping the server, but when you restore, please do stop the server.
- Move a job from one installation of Jenkins to another by simply copying the corresponding job directory.
- Make a copy of an existing job by making a clone of a job directory by a different name.
- Rename an existing job by renaming a directory. Note that the if you change a job name you will need to change any other job that tries to call the renamed job.
Those operations can be done even when Jenkins is running. For changes like these to take effect, you have to click "reload config" to force Jenkins to reload configuration from the disk.
Back up the Controller Key Separately
Never include the controller key in your Jenkins backup!
The controller key is used to encrypt data in the secrets directory that secures credentials. It is stored in the $JENKINS_HOME/secrets/hudson.util.Secret file in the $JENKINS_HOME/secrets/ directory and encrypted with master.key . If you need to restore a system from a backup, you will need this file. And, if someone else accesses your backups and has this key, they have full access to all your information.
You should treat your controller key like you treat your SSH private key and NEVER include it in a regular backup. Instead, back up the master.key file separately and store it in a very secure location away from your other backups. It is a very file small that is seldom changed. If you need to do a full system restore, you will need to restore the rest of the system and then apply the backup of the master.key file separately.
$JENKINS_HOME
Backing up the entire $JENKINS_HOME directory preserves the entire Jenkins instance. To restore the system, just copy the entire backup to the new system.
Note, however, that JENKINS_HOME includes a number of files that do not really need to be backed up. Selecting specific directories and files to back up yields smaller backups but may require a greater effort to restore a system. One approach is to back up different directories on different schedules.
Configuration files
Configuration files are stored directly in the $JENKINS_HOME directory. ./config.xml is the main Jenkins configuration file. Other configuration files also have the .xml suffix. Specify $JENKINS_HOME/*.xml to back up all configuration files.
Configuration files can also be stored in an SCM repository. This keeps copies of all previous versions of each file that can be retrieved using standard SCM facilities.
Filesystem snapshots
Filesystem snapshots provide maximum consistency for backups. They also run faster than live backups, reducing the possibility of copying different data at different time points. They are supported by:
The Linux Logical Volume Manager (LVM)
Solaris ZFS (which also supports incremental backups)
OpenZFS on Linux
Some other file system architectures
Many cloud providers
Some separate storage devices also let you create snapshots at the storage level.
Подключение пайплайна
В Jenkins существует несколько видов пайплайнов. В данном проекте мы используем Multibranch pipeline. Как и следует из названия, билд будет запускаться для любого коммита в произвольной ветке.
После того как файлы конфигурации готовы, осталось настроить пайплайн в Jenkins. Это можно сделать в меню New Item -> Multibranch Pipeline. Интересующие нас разделы:
Branch sources. Выбираем GitHub, в графе 'Credentials' выбираем секрет с логином/паролем от аккаунта и указываем URL репозитория с исходным кодом микросервиса.
Build Configuration. В Mode выбираем 'by Remote File Plugin', основное поле — Repository URL, в котором надо указать адрес репозитория с Jenkinsfile, а также Script Path с путем к этому файлу.
Scan Repository Triggers. В этом разделе настроим период, с которым Jenkins будет проверять, появились ли какие-то изменения в отслеживаемом репозитории. Недостаток этого подхода в том, что Jenkins будет генерировать трафик, даже когда в репозитории ничего не менялось. Более грамотный подход — настроить веб-хуки. При этом хранилище исходного кода само будет инициировать запуск билда. Очевидно, что сделать это можно, только если Jenkins доступен по сети для хранилища исходных кодов (они должны быть либо в одной сети, либо Jenkins должен иметь публичный IP-адрес). Подключение веб-хуков оставим за рамками данной статьи.
Конфигурация пайплайна
Как уже было упомянуто ранее, пайплайны описываются на Groovy, и могут быть написаны в декларативном и императивном стилях. Мы будем придерживаться декларативного подхода.
В Jenkins процесс выполнения пайплайна (билд) поделен на ряд шагов (stage). Каждый шаг выполняется определенным агентом (agent).
Наши пайплайны будут состоять из следующих шагов:
- Build. Компиляция проекта
- Test. Выполнение тестов. В проекте у нас только модульные тесты, но с помощью Maven нетрудно сделать отдельный шаг и для интеграционных тестов
- Package. Сборка jar-архива
- Push Images. Создание Docker-образов и их загрузка в реестр образов. Мы будем пушить два образа — с тегом latest и конкретной версией
- Trigger Kubernetes. Команда Kubernetes обновить Docker-образ в подах кластера
Структура файла конфигурации
Файл конфигурации будет иметь следующую структуру:
Агенты в Jenkins подчиняются типичным правилам "наследования" — если в шаге не определен агент, то будет использован агент родительского шага. Тег pipeline может рассматриваться как корневой шаг для всех остальных. Корневой шаг мы используем для объявления переменных среды и опций, которые по тому же правилу наследования будут иметь силу для всех вложенных шагов. Поэтому для тега pipeline установлен агент 'none'. Использование этого агента подразумевает, что вложенные шаги обязаны переопределить этот агент для выполнения каких-либо полезных действий.
Шаги Build, Test и Package будут выполняться в отдельном Docker-контейнере для изоляции билдов друг от друга. Также использование Docker-образа избавляет нас от необходимости настраивать для наших сервисов Java 11 (Jenkins поставляется с Java 8). Для того чтобы выполнить эти шаги в едином контейнере, мы вложим их в шаг 'Prepare container' с агентом 'docker'. В параметре args мы привяжем директорию .m2 в создаваемом контейнере к одноименной директории в контейнере Jenkins'а. В папке .m2 содержатся зависимости системы сборки Maven, которые будет переиспользоваться между билдами, что здорово сократит время выполнения.
Агент в шагах Push Images и Trigger Kubernetes равен 'any'. Это значит, что шаг может быть выполнен на любом доступном агенте. В простейшем случае это означает выполнение в контейнере Jenkins'а. Также эти шаги будут выполнены только для коммитов в мастер-ветку ( when < branch 'master' >).
Далее мы более пристально посмотрим на каждый из шагов, а также на блоки options и environment.
Опции
Блок опций может быть использован для настройки выполнения пайплайна или же отдельного шага. Мы используем следующие опции:
skipStagesAfterUnstable заставит Jenkins сразу прервать билд, eсли тесты были провалены. Поведение по умолчанию предусматривает установку статуса билда в UNSTABLE и продолжение выполнения. Это позволяет в сложных случаях более гибко обрабатывать подобные ситуации.
skipDefaultCheckout отключает автоматический чекаут репозитория проекта. Дефолтно Jenkins делает force чекаут репозитория для каждого шага с собственным агентом (в нашем случае Prepare Checkout, Push images и Trigger Kubernetes). То есть по сути затирает все изменения. Это может быть полезно при использовании пайплайна с несколькими различными образами. Однако нам нажно получить исходники с репозитория только единожды — на шаге Build. Применив опцию skipDefaultCheckout, мы получаем возможность произвести чекаут вручную. Также стоит заметить, что Jenkins будет автоматически переносить артефакты между шагами. Так, например, скомпилированные исходники из шага Build будут полностью доступны в шаге Test.
Переменные среды
Переменные среды могут быть также объявлены как для всего пайплайна, так и для отдельного шага. Их можно использовать, чтобы вынести какие-то редкоизменяемый свойства. В этом блоке мы определим имя файла докера и имена создаваемых Docker-образов.
В предыдущих статьях при работе с кластером мы всегда использовали наиболее свежие latest образы, но напомню, что это не лучший вариант из-за проблем при откатах к предыдущим версиям. Поэтому мы предполагаем, что в начальный момент времени кластер создается из самых свежих образов, а потом уже будет обновляться на конкретную версию. Тег IMAGE_TAG будет зависеть только от номера билда, который можно получить из предустановленной глобальной переменной среды BUILD_NUMBER. Таким образом наши версии будут составлять монотонную последовательность при условии того, что пайплайн не будет пересоздаваться (это приведет к сбросу номера билда). При неуспешных билдах BUILD_NUMBER также будет инкрементирован, следовательно последовательность версий образов может содержать "пробелы". Основное преимущество такого подхода к версионированию — его простота и удобство восприятия человеком. В качестве альтернативы можно подумать об использовании метки времени, чексуммы коммита или даже внешних сервисов.
Компиляция, тестирование, сборка
Чисто технически фазы компиляции, тестирования и сборки возможно объединить в один шаг, но для лучшей наглядности мы опишем их как отдельные шаги. С помощью плагинов Maven можно с легкостью добавлять дополнительные фазы, такие как статический анализ кода или интеграционное тестирование.
На первом шаге мы выполняем чекаут репозитория проекта командой checkout scm . Адрес репозитория мы укажем после, при настройке пайплайна в Jenkins. Далее запускаем bash-команду на компиляцию проекта.
В фазе тестирования командой junit '**/target/surefire-reports/TEST-*.xml' мы указываем Jenkins'у на файл с результатами тестов. Это позволит их отобразить прямо в веб-интерфейсе.
На последнем шаге мы генерируем jar-архив с нашим приложением.
Создание и отправка Docker-образа в реестр
На следующем шаге мы должны собрать Docker-образы и запушить их в реестр. Мы будем делать это средствами Jenkins, но в качестве альтернативы можно реализовать это и с помощью Maven-плагина.
Для начала нам надо доработать докер-файлы наших сервисов, которые мы разработали в первой статье цикла. Эти докер-файлы собирали приложение из исходников прямо в процессе создания образа. Сейчас же у нас имеется протестированный архив, следовательно один из шагов создания образа уже выполнен средствами Jenkins. Мы назовем этот новый файл Dockerfile-packaged.
Докер-файл для микросервиса шлюза аналогичен.
Шаг Push Images:
Изначально Jenkins поддерживал описание пайплайна только в императивном стиле, а поддержка декларативного подхода появилась намного позже. Разработчики Jenkins рекомендуют использовать именно декларативный подход как более выразительный, однако некоторые функции удобно вызывать внутри блока императивного кода командой script .
Командой docker.build мы собираем образ. Имя образа (уже включающее тег) может быть получено из переменных среды конструкцией $ . Во втором аргументе команды docker.build мы передаем опции для команды докера, а именно имя используемого докер-файла.
В конце шага происходит удаление установленных локально образов.
Обновление кластера Kubernetes
Финальным шагом осталось сообщить Kubernetes, что в реестре появился новый образ, и необходимо запустить процедуру обновления подов одного из микросервисов.
Команда withKubeConfig предоставляется плагином Kubernetes CLI и позволяет подключить kubectl к кластеру. После остается только прописать команду обновления свойств Helm-инсталляции. Также обращу внимание на использование предварительно объявленных глобальных переменных Jenkins, как, например, $ .
Итоговый Jenkinsfile
Jenkinsfile для микросервиса шлюза полностью аналогичен.
Creating a Backup
Various schemes can be used to create backups. These are discussed in this section:
Plugins for backup
Write a shell script that backs up the Jenkins instance
Установка и настройка Jenkins
Установка
Существует несколько способов установить Jenkins:
- Из war-архива
- Напрямую из Docker-образа
- Развернуть в Kubernetes
War-архив с программой можно запустить из командной строки или же в контейнере сервлетов (№ Apache Tomcat). Этот вариант мы не будем рассматривать, так как он не обеспечивает достаточной изолированности системы.
Устранить этот недостаток можно, установив Jenkins в Docker. Из коробки Jenkins поддерживает использование докера в пайплайнах, что позволяет дополнительно изолировать билды друг от друга. Запуск докера в докере — плохая идея (здесь можно почитать почему), поэтому необходимо установить дополнительный контейнер 'docker:dind', который будет запускать новые контейнеры параллельно контейнеру Jenkins'а.
Также возможно развернуть Jenkins в кластере Kubernetes. В этом случае и Jenkins, и дочерние контейнеры будет работать как отдельные поды. Любой билд будет полностью выполняться в собственном контейнере, что максимально изолирует выполнения друг от друга. Из недостатков этот способ имеет довольно специфичную конфигурацию. Из приятных бонусов Jenkins в Google Kubernetes Engine может быть развернут одним кликом.
Хоть третий способ и кажется наиболее продвинутым, мы выберем прямолинейный путь и развернем Jenkins в Docker напрямую. Это упростит настройку, а также избавит нас от нюансов работы со stateful приложениями в Kubernetes. Хорошая статья для любопытствующих про Jenkins в Kubernetes.
Так как проект учебный, то мы установим Jenkins на локальной машине. В реальной обстановке можно посмотреть в сторону, например, Google Compute Engine. В дополнение замечу, что изначально я пробовал использовать Jenkins на Raspberry Pi, но из-за разной архитектуры "малинки" и машин кластера они не могут использовать одни и те же Docker-образы. Это делает невозможным применение Raspberry Pi для подобных вещей.
После установки Jenkins открываем http://localhost:8080/ и следуем инструкциям. Настроить Jenkins можно через UI, либо программно. Последний подход иногда называют "инфраструктура как код" (IaC). Он подразумевает описание конфигурации сервера с помощью хуков — скриптов на Groovy. Оставим этот способ настройки за рамками данной статьи. Для интересующихся ссылка.
Плагины
Меню работы плагинов доступно из настроек (Manage Jenkins -> Manage Plugins). Многие полезные плагины уже установлены. Особо среди них выделю 'Blue Ocean', предоставляющий удобный интерфейс для работы с вашими пайплайнами.
Для нашего проекта нам понадобится установить два плагина: Remote File Plugin и Kubernetes CLI. Remote File Plugin позволяет хранить Jenkinsfile в отдельном репозитории, а Kubernetes CLI предоставит доступ к kubectl внутри нашего пайплайна.
Установка Helm
Так как наше приложение развернуто с помощью Helm-чарта, то для обновления кластера нам нужно установить еще и Helm. Плагина для Helm я не нашел, поэтому стоит установить его вручную. Для этого коннектимся к контейнеру ( docker exec -it jenkins-blueocean bash ), скачиваем бинарник по ссылке с официального сайта и помещаем его в /usr/bin. Далее надо зарегистрировать наш Helm-репозиторий:
Глобальные переменные среды
Так как у нас два сервиса, то мы создадим два пайплайна. Некоторые данные у них будут совпадать, поэтому логично вынести их в одно место. Это можно сделать, задав глобальные переменные среды, которые будут установлены перед выполнением любого билда на сервере Jenkins. Отмечу, что не стоит с помощью этого механизма передавать пароли — для этого существуют секреты.
Установим следующие глобальные переменные среды (Manage Jenkins -> Configure System -> Global properties -> Environment Variables):
- CLUSTER_URL — адрес мастер-ноды Kubernetes. Можно получить командой kubectl cluster-info
- CLUSTER_NAMESPACE — неймспейс нашего кластера
- HELM_PROJECT — имя инсталляции Helm
- HELM_CHART — имя Helm-чарта. В нашем случае это 'msvc-repo/msvc-chart'
Секреты
В Jenkins для хранения конфиденциальной информации существуют секреты нескольких типов, например, связка логин-пароль, секретный текст, секретный файл и др. Установим следующие секреты через меню Credentials -> System -> Global credentials -> Add Credentials:
Имя секрета | Тип | Описание |
---|---|---|
github-creds | username with password | Логин/пароль от git-репозиториев |
dockerhub-creds | username with password | Логин/пароль от реестра Docker-образов |
kubernetes-creds | secret text | Токен сервисного аккаунта нашего кластера |
В предыдущей части в файле NOTES.txt нашего чарта мы описали последовательность команд для получения токена сервисного аккаунта. Вывести эти команды для кластера можно, запросив статус Helm-инсталляции ( helm status msvc-project ).
./jobs Subdirectory
The $JENKINS_HOME/jobs directory contains information related to all the jobs you create in Jenkins.
./builds — Contains build records
./builds/archive — Contains archived artifacts
Back this up if it is important to retain these artifacts long-term
These can be very large and may make your backups very large
./workspace — Contains files checked out from the SCM
It is usually not necessary to back up these files. You can perform a clean checkout after restoring the system.
./plugins/*.hpi — Plugin packages with specific versions used on your system
./plugins/*.jpi — Plugin packages with specific versions used on your system
Plugins for backup
Several plugins are available for backup. Go to menu:Manage Jenkins[Manage Plugins>Available] and search for backup. Note that none of the open source plugins are currently being maintained. You can try these plugins but you may have problems with them.
Заключение
Jenkins — очень гибкая система, позволяющая реализовывать процесс непрерывной интеграции и развертывания любой сложности. В этой статье мы только коснулись этого инструмента, создав простенький пайплайн для микросервисов нашего проекта. В будущем этот пайплайн можно значительно дорабатывать и улучшать, например, добавив уведомления, дополнительные шаги, веб-хуки и многое-многое другое.
Which Files Should Be Backed Up?
The number of files you back up can affect both the time required to run the backup and the size of the resulting backup. It also impacts the complexity of restoring the system from the backup. Here we discuss why various files should be backed up and list some files that could safely be excluded from at least some backups.
Writing a shell script for backups
You can write your own shell script that copies the appropriate files and directories to a backup location. Use cron to schedule when the backup script runs.
The shell script should create a directory such as /mnt/backup to which the backup will be written; be sure that you have write permissions to that directory. Consider creating /mnt/backup as a separate filesystem with its own mount point. An alternative method is to create a subdirectory in /var . Note that if you use this method, you might need to use the sudo command to execute the restore operation. Backing up to /tmp is not advised because /tmp may be cleaned on reboot.
Create a unique identifier for each backup (use a timestamp, for example) to ensure that today’s backup does not overwrite yesterday’s backup.
Writing files to a local file system is the fastest way to take the backup. Consider copying the completed backup to a remote backup server or device for long term storage.
Validating a backup
Your backup strategy should include validation of each backup. You do not want to learn that your backup is no good when you need it!
A simple way to validate a full backup is to restore it to a temporary location. Create a directory for the test validation (such as /mnt/backup-test) and restore the backup to that directory.
Я добавляю непрерывную интеграцию в проект EC2 на работе с помощью Jenkins. Сама машина Дженкинса хранится на машине EC2 - той, которую может потребоваться отключить и вернуть на совершенно другой экземпляр EC2 в любой момент. У нас есть куча кукольных манифестов, позволяющих нам легко переустановить программное обеспечение на экземпляре EC2, но пользовательские файлы конфигурации, такие как для заданий, которые я создаю в Jenkins, будут удалены после перемещения.
теперь, если Дженкинс хранит, какие задания должны выполняться на нем в XML-файле или наборе XML-файлов где-нибудь, я мог бы настроить систему, где эти файлы фиксируются на сервере управления версиями, а затем загружаются обратно на вновь созданный сервер как часть манифеста puppet. Кто-нибудь знает, где хранятся эти файлы? Я пробовал копировать /var/lib/jenkins/jobs , но это, похоже, хранит выходные данные заданий Дженкинса, а не входные данные.
Дженкинс хранит конфигурацию для каждого задания в одноименном каталоге в jobs/ . Файл конфигурации задания config.xml , сборки хранятся в builds/ , а рабочий каталог - workspace/ . Вижу руководство для визуального представления и уточнения деталей.
в Linux можно найти домашний каталог Дженкинса, который ищет файл, который содержит дом Дженкинса, например:
Дженкинс 1.627, OS X 10.10.5 /Users/Shared/Jenkins/Home/jobs//config.xml
Я добавляю несколько вещей, связанных с хранилищем файлов конфигурации jenkins.
в соответствии с моим пониманием все хранилища файлов конфигурации в машине или ос, которые вы установили jenkins.
задания, которые вы собираетесь создать в jenkins, будут сохранены на сервере jenkins, и вы можете найти конфигурацию.XML и т. д., здесь.
после установки jenkins вы найдете рабочее пространство jenkins на сервере.
для полноты картины: macOS High Sierra, Jenkins 2.x, установка через Homebrew
~/.jenkins/jobs//config.xml
все файлы конфигурации хранятся внутри главного сервера jenkins.Просто могу сказать
Это четвертая и заключительная часть серии статей "Учимся разворачивать микросервисы", и сегодня мы настроим Jenkins и создадим пайплайн для микросервисов нашего учебного проекта. Jenkins будет получать файл конфигурации из отдельного репозитория, собирать и тестировать проект в Docker-контейнере, а затем собирать Docker-образ приложения и пушить его в реестр. Последней операцией Jenkins будет обновлять кластер, взаимодействуя с Helm (более подробно о нем в прошлой части).
План серии статей:
Ключевые слова: Java 11, Spring Boot, Docker, image optimization
Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets
Ключевые слова: Helm 3, chart deployment
Настройка Jenkins и пайплайна для автоматической доставки кода в кластер
Ключевые слова: Jenkins configuration, plugins, separate configs repository
Jenkins — это сервер непрерывной интеграции, написанный на Java. Он является чрезвычайно расширяемой системой из-за внушительной экосистемы разнообразных плагинов. Настройка пайплайна осуществляется в декларативном или императивном стиле на языке Groovy, а сам файл конфигурации (Jenkinsfile) располагается в системе контроля версий вместе с исходным кодом. Это удобно для небольших проектов, однако, часто более практично хранить конфигурации всех сервисов в отдельном репозитории.
Код проекта доступен на GitHub по ссылке.
Batch renaming jobs
Replacing spaces in job names with underscores
Sometimes you want to remove a job from Jenkins but do so in such a way that you can resurrect it later, if the need arises. You can do this by going to $JENKINS_HOME and create an archive of the job directory. The following command illustrates how to archive a job 'xyz' and remove it.
As long as you are not building the xyz project while you create an archive, you can do this operation without taking Jenkins offline.
Useful for trouble-shooting, diagnostics or batch updates of jobs Jenkins provides a script console which gives you access to all Jenkins internals.
These scripts are written in Groovy and you'll find some samples of them in this page.
Having good backups of your Jenkins instance is critically important. Backups are used for:
Recovering an older configuration (an accidental configuration change may not be discovered for some time).
Recovering a file that is corrupted or was deleted accidentally.
This page discusses the following:
How to create a backup
Files that should be backed up
How to validate a backup to ensure that it is usable
What may not need to be backed up
The following files and directories do not usually need to be included in every routine backup because you can download the latest version when you are restoring a system. However, some disaster recovery experts recommend against doing any upgrades while restoring the system, to avoid delays caused by compatibility issues that might arise. If your disaster recovery plan specifies that you restore the system using the same software versions that were previously running, you can make an infrequent backup of the system and all downloaded tools and use that to restore the system..
./war — Exploded war file
To restore a system, download the latest war file.
./cache — Downloaded tools
To restore a system, download the current version of the tools.
./tools — Extracted tools
To restore a system, extract the tools again.
./plugins/xxx — Subdirectories of installed plugins
These will be automatically populated on the next restart.
Запуск
После того как наш пайплайн настроен, можно его запустить. Наиболее удобно это сделать из меню Blue Ocean (Open Blue Ocean). Первый запуск может занять продолжительное время, так как потребуется время на загрузку Maven-зависимостей. После выполнения билда можно подключиться к кластеру и убедиться в том, что тег образа микросервиса был изменен ( helm get values msvc-project ).
В дальнейшем Jenkins будет отслеживать изменения в репозитории микросервиса и запускать билд автоматически.
Читайте также: