Что такое джоба в jenkins
Разворачиваем Jenkins как код
Прим. перев.: это перевод статьи из инженерного блога компании Preply о том, как можно использовать конфигурацию как код для такого популярного CI/CD инструмента как Jenkins.
В нашей компании, мы стараемся следовать практикам «Все как код», это касается не только инфраструктурных ресурсов, но и мониторинга, Jenkins джоб и т.д. В статье я расскажу, о том, как мы используем эту практику при разворачивании и поддержке Jenkins. Причем это касается не только инфраструктуры для сервера и агентов, но и плагинов, доступов, джоб и множества других вещей.
Кроме того, в данной статье мы попробуем найти ответы на такие вопросы как:
Введение
Обычно, первое что приходит в голову при упоминании словосочетания «инструменты DevOps» — это CI/CD система. К примеру, мы используем Jenkins, потому что мы запускаем сотни задач каждый день, а это десятки тысяч билдов. Некоторые возможности, которые мы используем в Jenkins либо отсутствуют в других CI/CD системах, либо имеют ограниченный функционал.
Нам бы хотелось управлять Jenkins полностью из кода, включая инфраструктуру, конфигурации, джобы и плагины. Мы пробовали запускать Jenkins в Kubernetes, однако под наши нужды он не вписался, плюс непросто было масштабироваться из-за его архитектуры.
Вот об этом пойдет речь
Инфраструктура для Jenkins
Мы используем AWS и конфигурируем всю инфраструктуру с помощью Terraform и других инструментов из хашистека, таких как Packer и Vault.
Здесь же, мы используем обычные ресурсы AWS: EC2 инстансы, SSL-сертификаты, балансировщики, Cloudfront и т.д. Образ ОС (AMI ) сконфигурирован с помощью Packer, который отлично интегрируется с Terraform и Vault.
Пример того, как выглядит конфигурация образа ОС в Packer
В свою очередь, файл packer_bootstrap.sh содержит в себе набор команд, с помощью которых устанавливается софт внутрь образа. К примеру, мы можем установить Docker, docker-compose и vaultenv или Datadog-агент для мониторинга. Касаемо инфраструктуры под этот образ, мы можем использовать Terraform, Cloudformation, Pulumi или даже Ansible.
Вот пример возможной инфраструктуры на AWS для Jenkins
Пользователи заходят на Jenkins через внутренний балансер, а Github-хуки попадают на сервер через внешний. Мы используем интеграцию Jenkins с GitHub, поэтому некоторые ссылки сервера должны быть доступны из интернета. Здесь есть множество различных решений (к примеру белый список для IP-адресов, урлов или токенов, и т.д.), в нашем случае мы используем комбинацию разрешенных урлов и валидации токена.
Итак, после проделанных нами манипуляций, у нас уже есть готовая инфраструктура с собранным образом ОС, возможностью мониторинга и доступом к корпоративному хранилищу секретов.
Используем Docker для установки Jenkins и его плагинов
Следующее чем мы займемся, это установкой Jenkins и его плагинов. У нас постоянно возгникали проблемы с обновлением плагинов, поэтому основной целью было иметь четкий слепок установленных плагинов и их версий в коде.
И здесь нам поможет Docker, ведь мы можем взять уже готовый предустановленный Docker-образ и использовать его как базовый, для нашей конфигурации.
Получить список установленных плагинов в Jenkins можно по ссылке https://our-jenkins-url/script и сохранив вывод в файл plugins.txt
И наконец, конфигурация для docker-compose, которая будет запускать Jenkins в Docker.
Мы также используем vaultenv для проброса секретов из Vault
Обратите внимание на некоторые параметры Java, которые помогли нам со сборкой мусора и ограничением ресурсов. Вот в этой статье очень классно расписано о тюнинге Jenkins.
Ну и конечно теперь мы можем локально развернуть копию Jenkins и экспериментировать с новыми версиями сервера и плагинов. Это очень удобно.
Теперь у нас есть чистая инсталляция Jenkins и плагинов, которая легко может запускаться в проде. Давайте добавим больше конфигурации для нее.
Настройка плагина Jenkins as a Code (JCaSC) для конфигурации сервера
В общем, есть такой плагин под названием Jenkins Configuration as Code (JCasC), который позволяет хранить конфигурацию сервера в человекочитаемом текстовом формате.
С помощью этого плагина можно описывать конфигурации безопасности, доступы, настройки плагинов, агентов, вкладок и многое другое.
Конфигурация представлена в формате YAML и разделена на 5 блоков:
Помимо этого, плагин предоставляет поддержку различных провайдеров секретов, однако, в данном примере будем просто использовать переменные окружения.
Вот так можно описывать секреты
Мы также используем плагин Amazon EC2 для поднятия агентов в AWS, и его конфигурация также может быть описана с помощью этого плагина. Матричная авторизация позволяет нам конфигурировать доступы пользователей с помощью кода.
Описание агентов и доступов
Плагин поддерживает и некоторые другие штуки, которые мы используем. С правильно организованным процессом локального тестирования Jenkins, можно эффективно находить и исправлять баги перед тем как они потенциально могут попасть в прод Jenkins.
Теперь у нас есть воспроизводимая конфигурация для сервера, осталось дело за малым, а именно — джобы.
Используем Job Builder для freestyle-проектов
Существует несколько способов создания freestyle-джоб в Jenkins:
Вот так (упрощенно) выглядит структура конфигурации джобы на ФС
Конфигурационный файл JJB также выглядит просто.
Применение новых изменений легко может быть запущено с помощью команды jenkins-jobs update
Само собой, пользователь, для которого создавался токен, должен иметь соответствующие привилегии для создания и настройки джоб. Нам всего лишь необходимо применить одну инициализационную джобу (seed job), которая будет применять изменения с помощью JJB в Jenkins.
Стоит упомянуть, что JJB не является «серебрянной пулей», так как некоторые не очень популярные плагины не поддерживаются. Однако, это очень гибкий инструмент для хранения джоб в коде, в том числе с поддержкой макросов.
Итоги
Теперь, когда мы дошли до конца этой статьи, хотелось бы вернуться в начало и ответить на вопросы заданные в начале. На каждый из поставленных вопросов мы можем ответить — «да».
В этой статье мы не углублялись в тонкости настройки тех или иных технологий или в то, как правильно настраивать Jenkins, мы всего лишь делимся своим опытом, который, возможно, пригодится и вам.
Управление задачами в 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. За счет гибкости и функционала вы можете использовать разные подходы, которые позволят именно вам управлять задачами максимально просто и удобно исходя из ваших требований и требований инфраструктуры.
DATAENGINER
Что такое Jenkins?
Jenkins — это инструмент автоматизации с открытым исходным кодом, написанный на Java, с плагинами, созданными для непрерывной интеграции. Jenkins используется для непрерывной сборки и тестирования ваших программных проектов, что облегчает разработчикам интеграцию изменений в проект и облегчает пользователям получение новой сборки. Это также позволяет вам непрерывно поставлять программное обеспечение, интегрируя с большим количеством технологий тестирования и развертывания.
С помощью Jenkins организации могут ускорить процесс разработки программного обеспечения за счет автоматизации. Jenkins объединяет процессы жизненного цикла разработки всех видов, включая сборку, документацию, тестирование, пакет, этап, развертывание, статический анализ и многое другое.
Jenkins достигает непрерывной интеграции с помощью плагинов. Плагины позволяют интегрировать различные этапы DevOps. Если вы хотите интегрировать определенный инструмент, вам нужно установить плагины для этого инструмента. Например: Git, проект Maven 2, Amazon EC2, HTML-издатель и т. д.
На изображении ниже показано, что Jenkins интегрирует различные этапы DevOps:
Преимущества Jenkins включают в себя:
В Jenkins есть некоторые вещи, которые отличают его от других инструментов непрерывной интеграции. Давайте рассмотрим эти моменты.
Ключевые моменты Jenkins.
Ниже приведены некоторые факты о Jenkins, которые делают его лучше, чем любые другие инструменты непрерывной интеграции:
Из вышесказанного видно, что спрос на Jenkins в мире очень высок. Прежде чем мы углубимся в Jenkins, важно знать, что такое непрерывная интеграция и почему она была введена.
Что такое непрерывная интеграция?
Непрерывная интеграция — это практика разработки, при которой разработчики обязаны фиксировать изменения в исходном коде в общем хранилище несколько раз в день или чаще.
Каждый коммит, сделанный в хранилище, затем создается. Это позволяет командам обнаруживать проблемы на ранней стадии. Помимо этого, в зависимости от инструмента Continuous Integration, есть несколько других функций, таких как развертывание приложения сборки на тестовом сервере, предоставление заинтересованным группам результатов сборки и тестирования и т. д.
Чтобы понять важность непрерывной интеграции, давайте взглянем на один из вариантов использования.
Я уверен, что вы все пользовались телефонами Nokia в какой-то момент вашей жизни. В проекте Nokia по разработке программного продукта был процесс под названием Nightly builds., Ночные сборки можно рассматривать как предшественника непрерывной интеграции. Это означает, что каждую ночь автоматизированная система извлекает код, добавленный в общий репозиторий в течение дня, и создает этот код. Идея очень похожа на Continuous Integration, но, так как код, который создавался ночью, был довольно большим, поиск и исправление ошибок было настоящей болью. В связи с этим Nokia приняла технологию непрерывной интеграции (CI). В результате каждый коммит, сделанный с исходным кодом в репозитории, был собран.
Если результат сборки показывает, что в коде есть ошибка, то разработчикам нужно только проверить этот конкретный коммит. Это значительно сократило время, необходимое для выпуска нового программного обеспечения.
Сейчас самое время понять, как в Jenkins работает непрерывная интеграция.
Непрерывная интеграция с Jenkins
Давайте представим сценарий, в котором полный исходный код приложения был собран, а затем развернут на тестовом сервере для тестирования. Это звучит как идеальный способ разработки программного обеспечения, но этот процесс имеет много недостатков. Я постараюсь объяснить их один за другим:
Из вышеуказанных проблем видно, что не только процесс доставки программного обеспечения стал медленным, но и качество программного обеспечения также ухудшилось. Это приводит к недовольству клиента. Таким образом, для преодоления такого хаоса существовала острая необходимость в существующей системе, в которой разработчики могли бы непрерывно запускать сборку и тестирование для каждого изменения, внесенного в исходный код. Вот что такое CI.Jenkins является наиболее зрелым из доступных инструментов CI, поэтому давайте посмотрим, как непрерывная интеграция с Jenkins преодолела вышеуказанные недостатки.
Сначала я объясню вам общую схему непрерывной интеграции с Jenkins, чтобы она стала понятной, как Jenkins преодолевает вышеуказанные недостатки:
Теперь вы знаете, как Jenkins преодолевает традиционные недостатки SDLC. В таблице ниже показано сравнение между «До и после 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 репозиторий, происходит автодеплой кода на продукционный сервер проекта. Цель достигнута!