Jenkins копирование файлов на удаленный сервер

Обновлено: 06.07.2024

We are using Jenkins server for our daily build process and executes some bash scripts on remote hosts over SSH. This scripts are generating html log files on remote hosts.

We are using Copy to slave plugin to copy files on slave machines and Publish over ssh plugin to manage SSH sessions in build process.

Now the question is, We want to copy some files (log files of Scripts) from remote ssh host to Jenkins Server. Which will be possible and better option for the same (plugin will be better if any).

EDIT :

sshpass is an option, but looking for any plugin or better way to do the job.

4,148 1 1 gold badge 37 37 silver badges 70 70 bronze badges Hav you considered using an Archive Artifacts step? It would keep the logs associated with the build on the Jenkins server. the file is generated by execution script. it is not the jenkins log. Artifacts is available for this file also ?? As long as it is created while the Jenkins job is running and you have access to it, it is an Artifact. In fact, those types of files (generated html, compiled binaries, etc) are exactly what Archive Artifacts is designed for. ok, will try to implement it tomorrow morning..thank you for your efforts.. Care to share a more verbose description of your sshpass command solution?

3 Answers 3

use sshpass command to send file in

Build Environment -> Execute Shell script on remote host using ssh -> Post build script

This will skip password prompt for scp command and will provide password to scp .

4,148 1 1 gold badge 37 37 silver badges 70 70 bronze badges For this, I need to install sshpass or not? Because currently this not work for me. Yup, you need to. Here is another SO answer which can help you for the same. Use keys, not plain passwords stored in Jenkins config.

I think you can generate ssh keypair and pass it to the slave as a parameter with, for example, Config File Provider Plugin

Then just use scp to retrieve files using this keypair for authentication process.

Obviously way too late, but in case you're already using publish-over-ssh , want to avoid duplicating the credentials and have a shared library you can use this piece of groovy to obtain the host configuration:

As mentioned, this either requires a Global Shared Library (so that your code is trusted) or (probably) a number of admin approvals, sorry for that.

For a password connection you can do:

This copies the file to your local work directory. Probably not the best code ever, but I'm not a groovy specialist. It works and that is enough for me. (the set +x is to avoid it echoing the command in the log, showing the password). Getting rid of anything Non-CPS ( sshHost = null ) before you perform a CPS call saves you a lot of headaches :)

Since it took me quite a while to figure out I wanted to share this for whoever comes next.

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

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

Как я могу экспортировать всю информацию Дженкинса с моего текущего ПК на мой новый сервер?

  • установите свежий экземпляр Jenkins на новый сервер
  • убедитесь, что старые и новые экземпляры Jenkins остановлены
  • архивировать все содержимое JENKINS_HOME старого экземпляра Jenkins
  • извлеките архив в новый каталог JENKINS_HOME
  • запустите новый экземпляр Jenkins
  • Не забудьте изменить документацию / ссылки на ваш новый экземпляр Jenkins:)
  • Не забудьте изменить владельца новых файлов Дженкинса: chown -R jenkins:jenkins $JENKINS_HOME

JENKINS_HOME по умолчанию находится в

в случае каталог JENKINS_HOME слишком велик для копирования, и все, что вам нужно, это настроить те же задания, Плагины Дженкинса и конфигурации Дженкинса (и не нужны старые артефакты задания и отчеты), тогда вы можете использовать Плагин ThinBackup:

    установите ThinBackup как на исходный, так и на целевой серверы Jenkins

настройка каталога резервного копирования на обоих (в Manage Jenkins --> ThinBackup --> Настройки)

на курс Дженкинс перейти к ThinBackup --> резервное копирование сейчас

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

Если у вас была аутентификация пользователя на исходном Jenkins, и теперь заблокирован целевой Дженкинс, а затем отредактируйте конфигурацию Дженкинса.xml, set <useSecurity> в false и перезапустите Jenkins.

это сработало для меня, чтобы перейти от Ubuntu 12.04 (Jenkins ver. 1.628) в Ubuntu 16.04 (Jenkins ver. 1.651.2). Я первый установлен Дженкинс из репозиториев.

скопировать JENKINS_HOME (например, /var/lib/jenkins) со старого сервера на новый. Из консоли в новом сервере:

rsync -av username@old-server-IP:/var/lib/jenkins/ /var/lib/jenkins/

возможно, Вам это не нужно, но я должен был

  • Manage Jenkins и Reload Configuration from Disk .
  • отключите и снова подключите всех рабов.
  • проверьте это в Configure System > Jenkins Location , the Jenkins URL правильно назначается новому серверу Jenkins.

Автоматизация Сервера Дженкинса:

настройте репозиторий для хранения дома Дженкинса (задания, конфигурации, плагины и т. д.) в локальном репозитории GitLab или в частном репозитории GitHub и регулярно обновляйте его, нажимая любые новые изменения в Jenkins jobs, плагинах и т. д.

настройка кукол host-group / role для Дженкинса, который можно использовать для создания новых серверов Дженкинса. Сделайте все основные конфигурация в кукольном рецепте и убедитесь, что он устанавливает последнюю версию Jenkins и настраивает отдельный каталог/mount для JENKINS_HOME .

раскрутите новую машину, используя конфигурацию Jenkins-puppet выше. Когда все будет установлено, возьмите / клонируйте конфигурацию Jenkins из репозитория Git в домашнюю директорию Jenkins и перезапустите Jenkins.

перейти к URL Дженкинса,Управление ДженкинсУправление Плагинами и обновить все плагины, которые требуют обновления.

можно использовать Докер Рой или Kubernetes для автоматического масштабирования подчиненных узлов.

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

для миграции плагин:

    сделать запрос: /pluginManager/api/json?depth=1 вы получите список плагинов, установленных с их версией.

для миграции работы:

  1. вы можете получить список заданий, установленных на с помощью вызова REST, /view/All/api/json
  2. затем вы можете получить каждую конфигурацию задания.xml-файл из заданий на с помощью URL задания /job/ .
  3. используйте эту конфигурацию.xml-файл для публикации содержимого XML-файла в и создания задания на .

Я создал утилиту, управляемую меню в Python, которая просит пользователя запустить плагин или миграцию Дженкинса и использует вызовы Jenkins REST API для этого.

Я добавляю непрерывную интеграцию в проект 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.Просто могу сказать


Имеется две EC2, на одной будет запущен Jenkins, который будет мастером, второй EC2 надо настроить и подключить как slave для Jenkins.

На Jenkins потребуется SSH Slaves Plugin.

Начинаем со слейва.

Настройка Jenkins Unix slave

Установка Java

Подключаемся на слейв, устанавливаем Java. Тут Ubuntu, поэтому apt :

OpenJDK Runtime Environment (build 1.8.0_162-8u162-b12-0ubuntu0.16.04.2-b12)

Добавление пользователя

Создаём пользователя, под которым будет подключаться Jenkins:

Настройка Master

Установка Docker

Переключаемся на мастер, устанавливаем Docker:

И Docker Compose:

Digest: sha256:f5233545e43561214ca4891fd1157e1c3c563316ed8e237750d59bde73361e77 Status: Downloaded newer image for hello-world:latest

Создание пользователя

Создаём каталог для $JENKINS_HOME и $HOME для пользователя ( /home/jenkins для RSA ключей, в /jenkins будут данные самого Jenkins):

Добавляем его в группу docker :

Меняем владельца каталогов:

Настройка SSH

Переключаемся на пользователя jenkins , создаём ключ:

$ ssh-keygen -t rsa

Enter file in which to save the key (/home/jenkins/.ssh/id_rsa):

Добавляем его в /home/jenkins/.ssh/authorized_keys на слейве.

Проверяем SSH с мастера:

$ ssh jenkins@34.253.207.173 -i .ssh/id_rsa

ECDSA key fingerprint is SHA256:830kEWjBvWnsgF8TdWJHQSKrEiOYK8+V98a0dbGPLYU. Are you sure you want to continue connecting (yes/no)? yes

ОК, тут всё работает.

Запуск Jenkins

На мастере переключаемся на пользователя jenkins :

Создаём Compose файл:

$ docker-compose -f jenkins-compose.json up

Из лога запуска получаем пароль, заходим на Jenkins, активируем:





Добавление Jenkins Slave

Проверяем наличие плагина SSH Slaves Plugin:


Переходим в Manage Jenkins > Manage Nodes:



Кликаем New node:


Создаём новый слейв:

Копируем содержимое /home/jenkins/.ssh/id_rsa , и вставляем в Private Key:


В Host Key Verification Strategy можно использовать Manually trusted, результат:


Жмём Save, переходим к агенту, слева жмём Trust SSH Host Key:

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