Virtualizatio’n’automation
How to create credentials in Jenkins
Every system, application or another solution has some authentication providers. Sometimes it’s a local password storage, sometimes administrator can implement AD (or another LDAP), Radius, OAuth etc. Nobody can reach the system without username and password, private key, secret token etc. Words below are so obvious that I feel stupid for writing them. But anyway it’s a very important entry into my today post – how to create credentials in Jenkins. Because even Jenkins has to use credentials in its projects and builds.
If you have ever used Jenkins, you probably know that you can pass username and password as a parameter. It’s great for the beginners but completely unsafe with a production environment. If you have no idea what about I am talking, take a look at this example:
Passing credentials in the parameters
Let’s create a new project. In this example, we want to connect to the vCenter Server and get a list of all datacenters. When we use parameter for password storing, our project will look like on the following picture (contains only one parameter of “password” type):
As you can see it is possible and even you have something you can call “soft safety”. The password is being displayed not as a plain text, but in the password-type field. Nobody will see your secrets unless he uses browser developer tools. It allows everybody to manipulate the whole front-end code, including the possibility of changing fields type (of course not on the server side). So let’s open our developer tools, navigate to the field with password and change type from “password” to “text”:
Whoa! I see dead peop… khem… I see the password! It’s a simple and obvious trick, so as you can see it’s not safe to use this method. But don’t worry. Jenkins has its own mechanism for storing passwords – username/pass pair, secret files, tokens etc. With an additional plugin, you can use them in your project to provide safe passing credentials.
How to create credentials in Jenkins?
Some theory…
Probably everything in Jenkins is based on the plugins. Also, possibility to store credentials depends on the plugin – Credential Plugin. I won’t discuss it in details, so you can read Jenkins Wiki if you are interested in. In a nutshell, the plugin allows you to store your credentials and also organize them in many domains. It does not mean an Active Directory domain of course. Domain, in this case, is the mechanism which is used for the logical organize groups of passwords, files, and another authentication data. According to the Plugin Wiki page:
For example, you may use the same username with a different password on multiple services. e.g. Wile E Coyote may have an account with Acme Industries, Jenkins CI, etc. in each case using the same username but a different password.
If you need to select the credentials to use when connecting to a service, it can be difficult to ensure that you select the correct one. Selecting the wrong one may mean that the incorrect password triggers a service lockout.
Credential Domains are a solution to help with this problem.
At the beginning, you start with one, Global domain. In fact, it’s not a domain literally, but the place, where you can collect all of these credentials, which should be independent of the domains’ configuration. For my purpose, I will create a credential with the username and password of the vCenter Server to which I want to connect, and I will do it in “Global credentials” (just for show you how it works).
…and a little practice!
At first, you need to find the “Credentials” in the left menu on the main page.
As you can see you can add new domain from this menu. But now we focus on the simple credential creation in the “Global credential” group. If you do not have other domains, you should see the table with the only one row:
Now you can enter the “Global credentials (unrestricted)” link. You will see the following screen (please look especially at the left menu):
There you have the possibility to create a new credential. You just need to use “Add Credentials”. Here you can specify the type of your credentials. The valid options are:
Depending on what you choose, you will have different options to configure. In my case, I need simple username and password pair, so I choose “Username with password”.
Now just click ok and it’s done! You can create credentials in Jenkins fast and easily.
What is the Scope?
The scope allows you to choose between Global and System options. The first one should be used for credentials you want to use in nodes configurations, projects, builds, jobs and much more. If some object inherits configuration from its parent, credentials from Global scope can be used. System scope is more restricted. Credentials are available only for that object, which is associated with that secrets. This scope is useful for example in working with nodes and their communication with the master node. System scope prevents nodes credentials from using them in the jobs.
Are my credentials safe?
I’m sure you wonder whether is it safe? Are credentials encrypted or just hashed? Can somebody do the same trick with changing field value? The answer is: credentials are quite safe. They are encrypted (just try to decode them with some Base-64 tool), but of course nobody can guarantee full security. Some weird thing is that Jenkins returns encrypted value in the form field. Fortunately, it’s not the plain text and changing field type will not give you any interesting things.
If you want, you may explore the code of Jenkins on GitHub – you will find more details of how Jenkins encrypts strings. I also recommend this short article about credential storing – it’s quite old, but after the fast code review I must say that there are many common things.
Short summary
Jenkins stores credentials as encrypted objects. You can use Credentials Plugin for creating, managing and organizing your secrets. The plugin allows you to use passwords, public keys, tokens or the whole files. It’s not recommended to use passwords as the parameters of the build.
Как настроить Jenkins в связке с Ansible
Эта статья — способ заглянуть в курс «Ansible: от первых шагов до большого проекта». Всеволод Севостьянов, Lead Engineer в Vene, отвечающий за пайплайны и deployment, показал, как настраивать Jenkins в связке с Ansible.
Первые шаги
Предположим что у нас есть система с установленным Jenkins и мы хотим привязать к ней IaaC в виде Ansible. После изначальной установки Jenkins, необходимо настроить связку с Ansible. Нужно договориться об условиях:
Jenkins установлен со стандартными плагинами;
Все пайплайны запускаются на машине, где установлен Jenkins (стандартный build agent), но для remote-агентов будет то же самое.
После установки Jenkins создаём новую сборочную задачу:
Вы можете создать Freestyle project — шаблон для Jenkins, в котором есть все этапы «Спулить код» → «Запустить работу», они позволяют с помощью шаблонов выбрать готовые пайплайны. Эта опция была добавлена в Jenkins чтобы повысить дружелюбность интерфейса к начинающим администраторам и автоматизаторам. Но мы выберем Pipeline.
Окно со свойствами проекта:
Здесь можно задать описание проекта, настроить как будут вести себя пайплайны. Во вкладке Build Triggers можно поставить параметры для автоматического запуска пайплайна, например запускать раз в день, или запускать, если появился новый коммит в определенной ветке Git.
Обратите внимание на поле ниже — Pipeline:
Jenkins, как и Gitlab, использует скрипт, который умеет выполнять консольные команды для запуска пайплайна по шагам. В отличие от Gitlab, Jenkins использует Groovy — полноценный язык программирования, который дает возможность тоньше кастомизировать работы и позволяет полноценно использовать программные конструкции для автоматизации. Но его сложнее освоить.
Итак, с помощью Pipeline достигнем целей:
Запустим Ansible и выведем его версию;
Скачаем Playbook с Github и запустим его;
Постучимся в другую машину изнутри Jenkins;
Используем специальный плагин Ansible для предыдущих трёх пунктов.
Запускаем Ansible и выводим его версию
Начнем с очень простой задачи — запустим Ansible в пайплайне и выведем его версию в консоль билда.
Пайплайны в Jenkins задаются очень простым путем: пишется Stage, аналогично стейджу в Gitlab, а внутри него перечисляются Steps. Все системы CI/CD основаны на одном принципе, дьявол именно в деталях.
Напишем свой Stage, назовем его Deploy и вызовем там версию Ansible.
pipeline < // задаем тон groovy, даем понять что здесь у нас шаги пайплайна
agent any // если у нас есть какие то jenkins агенты специально для Ansible мы можем их указать здесь, у меня только один агент, поэтому я поставлю any
Сохраняем пайплайн, выходим в главное окно проекта и нажимаем Build Now.
Если у вас на машине уже установлен Ansible, все пройдет успешно. Первый пайплайн готов.
Заглянем ему под капот
Нажмем на #1 внизу в Build history. Каждый пайплайн создает history, которую можно ограничить настройками билда, чтобы предотвратить засорение диска логами и артефактами сборки. По умолчанию ничего не удаляем, я рекомендую на период настройки пайплайнов не удалять билды, чтобы вернуться на любой шаг и посмотреть необходимую информацию.
Жмем на Console Output чтобы посмотреть вывод:
Дальше — шаги пайплайна подсвеченные серым, а вывод консоли черным цветом. После отображения папки, где был запущен пайплайн, выводятся результаты работы нашей sh команды, которая покажет версию Ansible в привычном виде, как если бы мы запустили ее из консоли.
Запускаем Playbook с Github
Для изначального тестирования я создам очень простой плейбук:
Учимся разворачивать микросервисы. Часть 4. 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 по ссылке.
Установка и настройка Jenkins
Установка
Существует несколько способов установить Jenkins:
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. Оставим этот способ настройки за рамками данной статьи. Для интересующихся ссылка.
Плагины
Для нашего проекта нам понадобится установить два плагина: Remote File Plugin и Kubernetes CLI. Remote File Plugin позволяет хранить Jenkinsfile в отдельном репозитории, а Kubernetes CLI предоставит доступ к kubectl внутри нашего пайплайна.
Установка Helm
Глобальные переменные среды
Так как у нас два сервиса, то мы создадим два пайплайна. Некоторые данные у них будут совпадать, поэтому логично вынести их в одно место. Это можно сделать, задав глобальные переменные среды, которые будут установлены перед выполнением любого билда на сервере Jenkins. Отмечу, что не стоит с помощью этого механизма передавать пароли — для этого существуют секреты.
Секреты
| Имя секрета | Тип | Описание |
|---|---|---|
| github-creds | username with password | Логин/пароль от git-репозиториев |
| dockerhub-creds | username with password | Логин/пароль от реестра Docker-образов |
| kubernetes-creds | secret text | Токен сервисного аккаунта нашего кластера |
В предыдущей части в файле NOTES.txt нашего чарта мы описали последовательность команд для получения токена сервисного аккаунта. Вывести эти команды для кластера можно, запросив статус Helm-инсталляции ( helm status msvc-project ).
Конфигурация пайплайна
Как уже было упомянуто ранее, пайплайны описываются на Groovy, и могут быть написаны в декларативном и императивном стилях. Мы будем придерживаться декларативного подхода.
В Jenkins процесс выполнения пайплайна (билд) поделен на ряд шагов (stage). Каждый шаг выполняется определенным агентом (agent).
Наши пайплайны будут состоять из следующих шагов:
Структура файла конфигурации
Файл конфигурации будет иметь следующую структуру:
Агенты в Jenkins подчиняются типичным правилам «наследования» — если в шаге не определен агент, то будет использован агент родительского шага. Тег pipeline может рассматриваться как корневой шаг для всех остальных. Корневой шаг мы используем для объявления переменных среды и опций, которые по тому же правилу наследования будут иметь силу для всех вложенных шагов. Поэтому для тега pipeline установлен агент ‘none’. Использование этого агента подразумевает, что вложенные шаги обязаны переопределить этот агент для выполнения каких-либо полезных действий.
Агент в шагах 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 можно с легкостью добавлять дополнительные фазы, такие как статический анализ кода или интеграционное тестирование.
В фазе тестирования командой junit ‘**/target/surefire-reports/TEST-*.xml’ мы указываем Jenkins’у на файл с результатами тестов. Это позволит их отобразить прямо в веб-интерфейсе.
На последнем шаге мы генерируем jar-архив с нашим приложением.
Создание и отправка Docker-образа в реестр
На следующем шаге мы должны собрать Docker-образы и запушить их в реестр. Мы будем делать это средствами Jenkins, но в качестве альтернативы можно реализовать это и с помощью Maven-плагина.
Для начала нам надо доработать докер-файлы наших сервисов, которые мы разработали в первой статье цикла. Эти докер-файлы собирали приложение из исходников прямо в процессе создания образа. Сейчас же у нас имеется протестированный архив, следовательно один из шагов создания образа уже выполнен средствами Jenkins. Мы назовем этот новый файл Dockerfile-packaged.
Докер-файл для микросервиса шлюза аналогичен.
В конце шага происходит удаление установленных локально образов.
Обновление кластера Kubernetes
Финальным шагом осталось сообщить Kubernetes, что в реестре появился новый образ, и необходимо запустить процедуру обновления подов одного из микросервисов.
Итоговый Jenkinsfile
Jenkinsfile для микросервиса шлюза полностью аналогичен.
Подключение пайплайна
В Jenkins существует несколько видов пайплайнов. В данном проекте мы используем 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-адрес). Подключение веб-хуков оставим за рамками данной статьи.
Запуск
После того как наш пайплайн настроен, можно его запустить. Наиболее удобно это сделать из меню Blue Ocean (Open Blue Ocean). Первый запуск может занять продолжительное время, так как потребуется время на загрузку Maven-зависимостей. После выполнения билда можно подключиться к кластеру и убедиться в том, что тег образа микросервиса был изменен ( helm get values msvc-project ).
В дальнейшем Jenkins будет отслеживать изменения в репозитории микросервиса и запускать билд автоматически.
Заключение
Jenkins — очень гибкая система, позволяющая реализовывать процесс непрерывной интеграции и развертывания любой сложности. В этой статье мы только коснулись этого инструмента, создав простенький пайплайн для микросервисов нашего проекта. В будущем этот пайплайн можно значительно дорабатывать и улучшать, например, добавив уведомления, дополнительные шаги, веб-хуки и многое-многое другое.
Jenkins. Continuous Integration — это просто. Ну, почти
У нас есть сервер, на котором лежит множество проектов на WordPress и Magento CMS. Мне как PHP-разработчику была поставлена задача внедрить Jenkins для этих проектов, чтобы публикация изменений исходного кода на сервер происходила быстрее.
К чему нам Continuous Integration?
Вопрос повышения эффективности разработки и сопровождения программных продуктов для меня, как для веб-разработчика, всегда был и остается актуальным и интересным. Процессы сборки проекта и публикации его на сервер являются тем звеном, которое может быть легко автоматизированно при помощи средств Continuous Integration (CI).
CI многими уже давно и успешно применяется. Использование этого метода разработки позволяет существенно сократить время на публикацию проекта на сервер, сводя эту работу к исполнению нескольких консольных команд. Кроме того, при применении CI имеется возможность в любое время оперативно вернуться к предыдущей версии проекта, благодаря тому, что Continuous Integration неразрывно связана с репозиторием системы контроля версий.
Принцип работы CI довольно прост. В моем случае участвовало 3 сервера:
Сразу после изменения репозитория в системе контроля версий, сервер СКВ инициирует выполнение задачи на сервере CI (как правило, с помощью веб-хука). Эта задача выполняет сборку и развертывание исходного кода из репозитория СКВ на сервер рабочей версии проекта.
Развертывание исходного кода из репозитория СКВ на сервер рабочей версии проекта
Более подробно о преимуществах, которые предоставляет использование Continuous Integration, можно почитать в этой статье.
Данное руководство собирает в себе информацию, достаточную для того, чтобы быстро сконфигурировать систему CI Jenkins и начать работу с ней. Также здесь представлена информация по настройке и организации взаимодействия такой популярной системы CI, как Jenkins и не менее известной системы контроля версий Git. В качестве веб-сервиса для git будем использовать GitHub.
Внимание, задача
Необходимо установить и настроить Jenkins таким образом, чтобы при push-е в репозиторий GitHub происходило обновление измененных файлов на сервере рабочей версии проекта. В наличии:
Предварительным требованием является установленный git на обеих машинах. Про то, как его установить, можно прочитать здесь.
Решение
1. Установка Jenkins
Установку выполним на выделенном для CI сервере. Вводим следующие команды для добавления репозитория Jenkins в список репозиториев системы:
Обновим apt и установим Jenkins:
Теперь порт 8080 сервера CI будет «прослушиваться» Jenkins. Это значит, что при переходе в браузере по адресу 8080, пользователь попадет в панель управления Jenkins. Конечно, такой способ доступа является не очень удобным, поэтому на сервере CI можно настроить доступ к Jenkins с помощью виртуальных хостов в Apache или Nginx.
Приветственное окно Jenkins
Следующим важным шагом является настройка прав доступа. Это очень важно, особенно если сервер доступен через Интернет. Без соответствующих настроек он будет открыт для всех.
2. Добавление администратора
Manage Jenkins → Configure Global Security (глобальная настройка безопасности).
1. Заполняем необходимую информацию:
2. Сохраняем настройки.
Теперь при попытке входа в панель управления Jenkins будет требовать от пользователя авторизоваться.
3. Создание пользователя для GitHub
Теперь необходимо создать учетные данные для доступа GitHub к серверу Jenkins.
В панели управления Jenkins переходим Manage Jenkins → Manage Users → Create User. Заполняем форму регистрации, идентичную той, которая была при регистрации администратора, нажимаем Sign Up.
После создания пользователя следует дать ему необходимые права. Для этого перейдем в Manage jenkins → Configure Global Security (настройка глобальной безопасности).
Из всех этих настроек нам необходима матрица безопасности.
Для начала добавим пользователя в эту матрицу. В поле «User/group to add» вводим имя созданного пользователя и нажимаем Add. Пользователь появится в матрице. Предоставим ему права на чтение и сборку. Для этого в подстолбцах Read и Build столбца «Job» напротив имени созданного пользователя устанавливаем чек-боксы и нажимаем Save.
Создание пользователя для GitHub
4. Установка плагина для GitHub
Переходим в Manage Jenkins → Manage Plugins → Вкладка «Available». Выбираем для установки три плагина:
Нажимаем на кнопку «Download now and install after restart» и ожидаем завершения установки.
5. Настройка сервера для работы с Jenkins
На продукционном сервере проекта (куда будет производиться автодеплой) необходимо создать пользователя «jenkins»:
Далее на сервере необходимо сгенерировать ssh ключи. От пользователя «jenkins» выполняем команду:
И вводим необходимую информацию.
Также для доступа необходимо добавить публичный ключ в файл. /jenkins/.ssh/authorized_keys (если файла нет, его необходимо создать)
Кроме этого требуется создать на GitHub открытый SSH ключ для данного сервера. О том, как это сделать, можно посмотреть здесь.
Данный этап завершен.
Если что-то по ssh-аутентификации является непонятным, рекомендую прочитать очень полезную статью на данную тему.
6. Настройка доступа к серверу
Для того чтобы Jenkins при автодеплое на сервере с рабочей версией проекта мог авторизовываться на нем, в панели управления требуется создать необходимые данные для аутентификации. Для этого в панели управления Jenkins переходим Credentials → Global credentials → Add Credentials и делаем следующее:
Теперь необходимо настроить подключение к серверу. Для этого в панели управления jenkins перейдем Manage Jenkins → Manage Nodes → New Node. Производим следующие действия:
Через некоторое время, подключение к серверу должно успешно установиться. Если все прошло успешно, в Manage Jenkins → Manage Nodes вы должны увидеть примерно следующую картину:
Настройка подключения к серверу
Если подключение не устанавливается, нажимаем на созданное подключение («target»), выбираем «Log» в левом навигационном меню и смотрим, что произошло не так.
Наиболее распространенными ошибками являются:
Первое решение — изменить в настройках подключения корневую директорию на домашнюю директорию пользователя Jenkins.
Второе решение — предоставить пользователю Jenkins права на запись и чтение указанной в настройках подключения директории.
7. Настройка хука GitHub
Для GitHub-репозитория, который будет использоваться, необходимо настроить веб-хук так, чтобы при обновлении репозитория, хук отсылал запрос на обновление Jenkins. Для этого:
8. Создание задачи Jenkins
Теперь необходимо создать задачу, которая будет выполняться при обновлении репозитория. В панели администрирования Jenkins делаем следующее:
Первая строка производит синхронизацию на продукционном сервере рабочей директории Jenkins с целевой директорией проекта. Вторая строка —
установка владельца файлов проекта.
Чтобы не возникло никаких проблем с правами при выполнении команд, необходимо в файл sudoers с помощью команды visudo дописать пару строчек:
Вот и все! Теперь, при push-e кода в GitHub репозиторий, происходит автодеплой кода на продукционный сервер проекта. Цель достигнута!
