Что такое credentials в jenkins
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.
Using credentials
There are numerous 3rd-party sites and applications that can interact with Jenkins, for example, artifact repositories, cloud-based storage systems and services, and so on.
A systems administrator of such an application can configure credentials in the application for dedicated use by Jenkins. This would typically be done to «lock down» areas of the application’s functionality available to Jenkins, usually by applying access controls to these credentials. Once a Jenkins manager (i.e. a Jenkins user who administers a Jenkins site) adds/configures these credentials in Jenkins, the credentials can be used by Pipeline projects to interact with these 3rd party applications.
Note: The Jenkins credentials functionality described on this and related pages is provided by the Credentials Binding plugin.
Credentials stored in Jenkins can be used:
anywhere applicable throughout Jenkins (i.e. global credentials),
by a specific Pipeline project/item (read more about this in the Handling credentials section of Using a Jenkinsfile),
by a specific Jenkins user (as is the case for Pipeline projects created in Blue Ocean).
Jenkins can store the following types of credentials:
Docker Host Certificate Authentication credentials.
Credential security
To maximize security, credentials configured in Jenkins are stored in an encrypted form on the controller Jenkins instance (encrypted by the Jenkins instance ID) and are only handled in Pipeline projects via their credential IDs.
This minimizes the chances of exposing the actual credentials themselves to Jenkins users and hinders the ability to copy functional credentials from one Jenkins instance to another.
Configuring credentials
This section describes procedures for configuring credentials in Jenkins.
Credentials can be added to Jenkins by any Jenkins user who has the Credentials > Create permission (set through Matrix-based security). These permissions can be configured by a Jenkins user with the Administer permission. Read more about this in the Authorization section of Managing Security.
Otherwise, any Jenkins user can add and configure credentials if the Authorization settings of your Jenkins instance’s Configure Global Security settings page is set to the default Logged-in users can do anything setting or Anyone can do anything setting.
Adding new global credentials
To add new global credentials to your Jenkins instance:
If required, ensure you are logged in to Jenkins (as a user with the Credentials > Create permission).
From the Jenkins home page (i.e. the Dashboard of the Jenkins classic UI), click Manage Jenkins > Manage Credentials.
Under Stores scoped to Jenkins on the right, click on Jenkins.
Under System, click the Global credentials (unrestricted) link to access this default domain.
Click Add Credentials on the left.
Note: If there are no credentials in this default domain, you could also click the add some credentials link (which is the same as clicking the Add Credentials link).
From the Kind field, choose the type of credentials to add.
From the Scope field, choose either:
Add the credentials themselves into the appropriate fields for your chosen credential type:
Specify an optional Description for the credential/s.
Click OK to save the credentials.
Как настроить 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
Для изначального тестирования я создам очень простой плейбук:
Управление задачами в Jenkins CI
Jenkins сейчас используется, пожалуй, практически в любой компании, где есть необходимость в автоматическом деплое приложений и инфраструктуры, а также в удобном управлении различного рода задач.
На рынке сейчас представлено много других инструментов (как платных, так и бесплатных), позволяющих построить процесс непрерывной интеграции максимально комфортно.
Jenkins является бесплатным инструментом, обладающим огромными возможностями в виде тысяч плагинов, которые постоянно добавляются и обновляются.
Базовый подход к управлению задачами предлагается нам через веб-интерфейс самого Jenkins, где мы можем что угодно сконфигурировать, но поддерживать это при большом количестве задач и их разнотипности становится сложнее.
Ниже мы рассмотрим, как упростить и ускорить создание задач в Jenkins.
Инструменты, которые будем использовать
Jenkins job builder
Это python-утилита, позволяющая описывать задачи в YAML- или JSON форматах, которые через HTTP API загружаются на сервер. Для работы достаточно установить ее на локальной машине, написать конфигурацию с подключением и описать требуемые задачи.
Актуальная документация проекта
DSL Plugin
Это плагин для Jenkins, с помощью которого мы сможем описывать задачи на специальном языке (DSL, Domain Specific Language) и создавать их на основе этих описаний. Работает локально на самом Jenkins-сервере.
Страница плагина
Jenkins Pipeline
Это тип задачи в Jenkins, с помощью которого мы можем описать необходимый нам процесс деплоя или сборки приложения по стадиям. Описывать pipeline мы будем в специальном Jenkinsfile, который будет храниться в репозитории проекта.
Gitlab и Gitlab CI
Наиболее популярный и развивающийся сейчас selfhosted проект, который также используется во многих компаниях. Он включает в себя версию для сообщества и энтерпрайз-решение.
Внутри имеется собственный CI, написанный на Go, который через специальные подключаемые агенты (runners) позволяет нам проводить различные стадии сборки и деплоя.
Итак, начнем
Для начала поставим необходимые инструменты.
Jenkins-job-builder в нашем случае необходимо установить как на локальную машину, так и на машину, где будет работать агент gitlab. Можно обойтись просто локальной машиной gitlab.
Локально на linux и mac установим последнюю доступную версию:
Локально для описания нашего seed job мы сможем протестировать его работоспособность.
Добавлю, что seed job в терминологии DSL Plugin является задача типа Free-style project, которая создает остальные задачи из DSL-скриптов.
На gitlab-сервере установка будет ничем не отличаться от локальной установки на linux-машину:
На всякий случай запустим утилиту и проверим, что она работает:
Установка плагина
Теперь установим плагин в Jenkins. Для установки можно воспользоваться как классическим UpdateCenter в разделе Manage Jenkins → Manage Plugins → Available, так и используя установку с помощью curl/wget, скачав плагин с официальной страницы плагина:
Создание репозитория
Создадим репозитории под код с описанием задач.
Для начала подготовим наш seed job — так называется задача, которая генерирует из себя все остальные. Репозиторий будет состоять из следующих файлов:
jenkins.ini
job-generator.yml
.gitlab-ci.yml
После подключения он будет выглядеть примерно так:
Теперь закоммитим изменения и в разделе Jobs у нашего проекта увидим следующее:
Вся схема выглядит следующим образом:
Подготовим репозиторий с описанием задач. Создадим его с названием repo-dsl и плоской структурой. Все файлы располагаются как есть.
Положим в него файл с нашим pipeline:
И настроим webhook по запуску seed-job, который мы создали ранее.
В данной версии gitlab webhooks располагаются в проекте в разделе Settings → Integrations.
Создаем webhook на push ( gitlab:pass@ci.org/project/job-generator ). Схематично это выглядит вот так:
Теперь в нашем Jenkins есть две задачи:
В тестовом pipeline мы будем собирать docker-образ, который после будет загружаться в локальный docker registry. Файл с образом будет браться с другого проекта.
В проекте с названием sample-project создадим Jenkinsfile следующего содержания:
В итоге готовый pipeline будет выглядеть следующим образом в интерфейсе blueocean в Jenkins:
Или так в классическом интерфейсе:
Для запуска этой задачи автоматически мы можем добавить webhook в проекте с docker-image, где после отправки изменений в репозиторий будет запускаться эта задача.
В заключении отметим, что данная статья описывает лишь один из множества подходов управления задачами в jenkins. За счет гибкости и функционала вы можете использовать разные подходы, которые позволят именно вам управлять задачами максимально просто и удобно исходя из ваших требований и требований инфраструктуры.
Введение новичка в Дженкинс – CI/CD
В этом руководстве для начинающих мы познакомимся с Jenkins, сервером автоматизации CI/CD, а также запустим и автоматизируем процесс сборки простого проекта.
Вступление
Ключевые концепции Дженкинса
Чтобы понять, почему кто-то должен использовать Дженкинса, нам нужно понять, какие проблемы Дженкинс стремится решить.
Конвейер CI/CD
От начала до конца жизненный цикл программного обеспечения состоит из нескольких этапов. Автоматизация помогает нам преодолеть разрывы между ними, делая весь процесс бесшовным. В качестве примера возьмем простой, обычный рабочий процесс-сервер автоматизации будет прослушивать новые версии разработки, извлекать их и запускать соответствующие команды для создания и тестирования новой версии и, наконец, запускать новую версию в производство, если все прошло успешно.
Архитектура Контроллера-Агента
Плагины
Плагины являются основой успеха Дженкинса. Любой разработчик Java может написать свой собственный плагин и поделиться им с сообществом. Дженкинс очень подчеркивает это и написал несколько очень подробных руководств по этому вопросу. Какой бы инструмент вы ни хотели использовать в конвейере, Дженкинс, вероятно, снабдит вас плагином, который облегчит весь процесс настройки и интеграции с этим инструментом.
Помимо аспекта рабочего процесса, существует множество плагинов, написанных непосредственно для управления самим Дженкинсом – от более красивого пользовательского интерфейса до более простого управления несколькими пользователями и их правами доступа.
Соглашения об именовании
На протяжении всего жизненного цикла Дженкинса номенклатура немного менялась, в том числе из-за того, что определенная терминология может рассматриваться как оскорбительная.
Несмотря на то, что некоторые соглашения об именах были введены много лет назад, сообщество по-прежнему использует их взаимозаменяемо. Чтобы избежать путаницы, вот несколько синонимичных терминов:
Более старая Ведущая/Ведомая архитектура была переименована в Контроллер/Агент архитектура из-за негативных коннотаций терминологии.
Установка
Установка JDK/JRE
Давайте продолжим и установим openjdk-11-jdk :
Обновление списка источников и установка с помощью apt
Дженкинс недоступен в официальном репозитории Linux, поэтому нам придется добавить его собственный репозиторий. Мы собираемся установить версию LTS ( Долгосрочная поддержка ), которая обновляется каждые 12 недель, согласно веб-сайту Дженкинса.
Наконец, мы можем продолжить и зарегистрировать Дженкинса в качестве сервиса и запустить его через терминал:
Доступ к Дженкинсу из браузера
Использование Дженкинса
Дженкинс-это большой и сложный проект, и мы рассмотрим большинство наиболее важных функций.
Для этого мы рассмотрим три примера рабочего процесса:
Простая Локальная Сборка
Чтобы легко настроить Maven – мы установим плагин Maven для Дженкинса.
Установка плагинов
Перейдите к опции Управление плагинами в разделе Управление Дженкинсом :
Дождитесь установки плагина, прежде чем продолжить.
Настройка Maven
Настройка электронной почты
Создание проекта
Git Essentials
Ознакомьтесь с этим практическим руководством по изучению Git, содержащим лучшие практики и принятые в отрасли стандарты. Прекратите гуглить команды Git и на самом деле изучите это!
Запуск сборки
Настроив шаги, мы можем начать сборку. Боковая панель сообщит нам о ходе работы, а также покажет историю сборки. Неудачные сборки (#1) будут отображаться другим цветом.
Перейдите к параметру Вывод на консоль для получения более подробной информации:
Отслеживание репозитория GitHub и чтение файла Дженкинса
Нам пришлось рассмотреть более простой пример выше, чтобы понять, как работает Дженкинс. Следующий пример, безусловно, является наиболее частым способом настройки любого конвейера. Размещение конфигурации конвейера в текстовом файле и в CVS обеспечивает большую переносимость и возможность настройки.
Учетные данные GitHub
Для создания пары ключей мы будем использовать команду ssh-keygen :
Выберите, где хранить ключи, и установите пароль, если хотите.
Теперь пришло время создать проект и настроить его.
Создание проекта
Маршрут Git также является более общим, поскольку процедура одинакова для любого удаленного репозитория Git – он не обязательно должен размещаться на GitHub, но, возможно, на сервере компании или в другой службе хостинга, такой как BitBucket и GitLab.
Написание файла Дженкинса
Давайте продолжим и напишем сценарий, похожий на Groovy, под названием “Файл Дженкинса” (без расширения) и зафиксируем/переместим его в корневой каталог вашего репозитория:
После завершения этапа будет отправлено электронное письмо с уведомлением о завершении конвейера, содержащее некоторую информацию и ссылку на URL-адрес сборки для получения дополнительной информации.
Этот процесс или любой другой, если бы мы вносили изменения в файл Дженкинса, будет выполняться каждый раз, когда новая фиксация будет отправлена в репозиторий.
Служебные задачи в командной строке
Он входит в комплект каждой установки Дженкинса:
Чтобы узнать, сможем ли мы подключиться к Дженкинсу, давайте введем следующую команду:
Соединение прошло успешно. Давайте свяжемся с пользователем с более широкими правами доступа, чтобы иметь возможность управлять проектами, плагинами, сборками и т.д. Чтобы избежать ввода пароля в консоли, можно настроить маркер API.
Создание маркера API
Давайте создадим токен для нашего пользователя-администратора, выполним действия на изображении и скопируем полученный текст:
Список заданий и запущенных сборок
Импорт/Экспорт Существующих Заданий
Все конфигурации в Jenkins определяются с помощью XML. Это позволяет легко повторно использовать существующие конфигурации или импортировать новые. Помимо определений проектов, глобальные конфигурации, такие как плагины и учетные данные, все написаны в XML.
Вывод
Ключевой вывод здесь – это мощь автоматизации. Стоит вложить некоторое время и усилия в мощный инструмент, тщательно все настроить и больше никогда не тратить время на ручную работу. Отдача от инвестиций неоценима.
Это руководство предназначено для ознакомления с мощью и расширяемостью Дженкинса. Хорошо понимая основные принципы, ваши знания о Дженкинсе взлетят до небес, как только вы начнете экспериментировать с различными проектами, смешивая и сопоставляя различные инструменты сборки, языки и среды сборки.