Jenkins для начинающих.
В прошлых заметках уже немного упоминал о том, что начал потихоньку разбираться с вопросами CI∕CD. Чтобы закрепить у себя и попутно нанести пользу моим 59 подписчикам решил запилить небольшую серию постов по этим экспериментам. Самые основы со скриншотами.
Для начала минимум терминологии, CI∕CD включает в себя 2 понятия:
- Continuous integration (непрерывная интеграция) — подход при котором ПО раз в определенное время или после каждого коммита (обычно подразумевается одобренный коммит в мастер или dev) компилируется, тестируется и, если успешно прошло тесты, собирается в новую версию.
- Continuous deployment (непрерывное развертывание) — подход при котором новый пакет приложения (или новые образы докера и т.д.) автоматически отправляются на боевой сервер и развертываются незаметно для пользователя.
Как понятно из описания, это по большей части концепции и подходы. Их исполнение можно обеспечить множеством инструментов. Мы будем говорить преимущественно о Jenkins, но также заденем тестирование и bash скрипты.
Jenkins — программная система с открытым кодом на Java, которая как раз позволяет наладить непрерывную интеграцию и развертывание вашего проекта.
В этой части установим Jenkins и «подружим» с github, а уже в следующей накидаем наноприложение с тестами и напишем jenkins pipeline.
Установка Jenkins
Поскольку сам jenkins написан на Java, и в пайплайнах частично использует её синтаксис, перед установкой необходимо поставить openjdk-8-jdk.
После этого добавляем Jenkins репозиторий и устанавливаем само приложение.
$ sudo sh -c ‘echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list’
Проверить статус установленного сервиса можно так:
Если приложение активно, вы должны будете увидеть что-то подобное:
После этого заходим в браузере на localhost:8080 и видим стартовую страницу настройки:
$ sudo cat /var/lib/jenkins/secrets/initialAdminPassword
Получаем пароль для запуска -> устанавливаем необходимые плагины (можно просто выбрать установку по умолчанию) -> создаем профиль (для теста можно просто продолжить как админ.) -> Та-дааа! Можно создавать первый пайплайн.
Поскольку это тестовый запуск «на поиграться», можно отключить авторизацию с помощью пароля.
-> открываем файл /var/lib/jenkins/config.xml
-> меняем ` true ` на false
-> в браузере прописываем localhost:8080/restart (или другую ссылку /restart, если вы меняли url при установке)
Настраиваем права доступа
Linux
Генерируем пару ssh ключей (чуть более подробно о генерации ключей писал здесь ).
В левом верхнем меню переходим во вкладку `credentials`
Установка Jenkins и Bonobo Git Server под ОС Windows для сборки Android приложений
Дистрибутивы
Последние приготовления
Можете с самого начала установить JDK, Git for Windows и Android SDK Tools с настройками по дефолту.
Bonobo Git Server
Простой и лёгкий git сервер под собой требует установки IIS и ASP.MVC что включает MS SQL Server Express 2008
IIS Server
Тут ничего необычного, добавляем роль Web Server (IIS):
Главное на следущей форме не пропустить добавить ASP.NET 4.5 в Feature:
ASP.NET MVC4
Попутно установится MS SQL Server 2008 Express и нас спросят пароль для УЗ sa. Надеюсь без надобности она более не потребуется:
После установки MVC нужно по новой пройтись в настройки серверных ролей (не features, а раньше) и добавить web-серверу поддержку ASP.NET4.5. До установки ASP.NET MVC 4 этого подраздела (Application Development) в компонентах IIS не было!
Bonobo Git Server
Всё, теперь можно перейти к непосредственно развёртыванию git сервера. Разархивируем содержимое дистрибутива в wwwroot IIS-сервера и даём права УЗ IIS_IUSERS на модификацию каталога App_Data:
Запускаем IIS Manager и конвертируем в приложение BonoboGitServer:
Если всё пошло так как надо справа в IIS Manager в Action жмём Browse: *:80(http) и попадаем (если вы не изменили имя и порт) на localhost/BonoboGitServer:
Логин и пароль для первого входа admin/admin. У сервера не так много настроек (во всяком случае через web-интерфейс), можно например поменять язык интерфейса:
и создать новых пользователей, например developer и jenkins. Под первым мы будем работать сами, второй нужен будущему серверу сборок.
Создадим новый репозиторий и дадим права на него разработчику и сборщику (УЗ jenkins, на скрине нет, но он там должен быть если делать всё по порядку. )
Пример странички репозитория с заветным адресом .git. Т.к. я заходил на сервер из браузера на этой же машине в адресе у меня фигурирует localhost, но у вас может быть нормальное DNS-имя сервера или IP.
Можно создать какой-нибудь проект в Android Studio указать в качестве удалённой ветки адрес нашего репозитория. Всю эту локальную часть я пропущу.
Jenkins
Jenkins устанавливается из msi и особо ни о чём не спрашивает, в конце установки автоматически открывается страничка с адресом где нам нужно скопировать из файла initialAdminPassword и вставить пароль:
В дальнейшем пароль УЗ admin тоже можно поменять.
Пришла пора установить необходимые плагины и настроить сервер. Переходим в Manage Jenkins — Manage Plugins — Avaliable и отмечаем:
- JDK Parameter Plugin
- Git plugin
- Android Emulator Plugin
- Gradle plugin
После перезапуска Jenkins необходимо перейти в раздел Manage Jenkins — Configure System и прописать путь к Android SDK в двух местах:
И в самом низу этой же странички в Android SDK root:
Если данного параметра не появилось что-то не то с Android Emulator Plugin, возможно он просто не установился.
Далее перейти на страничку конфигурации Manage Jenkins — Global Tool Configuration проверить и при необходимости указать пути к компонентам:
Git можно не трогать, если в переменной path указан путь к исполняемому файлу git и он доступен в командной строке то и Jenkins сможет его использовать:
А Gradle пусть скачается автоматически. В принципе такой же фокус можно было бы сделать с JDK но при установке Android SDK требует зарегистрированной в системе JDK, а куда Jenkins скачивает JDK я не раскопал.
Создание задачи на автоматическую сборку
В основном боковом меню Jenkins жмём New Item, придумываем название задачи с типом «Freestyle project» и жмём ок, попадаем в конфигурацию задачи. Не забываем поставить галочку Discard old builds а то наш сервер вскоре заполнится успешными билдами всех версий:
В разделе Source Code Management указываем URL репозитория git нашего проекта. Забегая вперёд, не заводим и не подставляем никакие учётные данные для доступа к репозиторию:
Будем собирать ветку master. Также можно настроить автоматическую сборку, в частности опрос репозитория ежеминутно и старт сборки в случае обнаружения новых коммитов. Отмечаем Poll SCM и пишем * * * * *:
В разделе build нажимаем Add build step и настраиваем сборку Gradle. Gradle version должен быть доступен тот, что мы указали в Global Tools Configurations. Пишем простой Task — «clean build». Это задачи, доступные нам в gradlew.bat tasks в корне проекта. Вы можете вызывать тут и другие задачи сборщика, в т.ч. с ключами.
Также добавляем одно Post-build Action — будем сохранять наши APK-шники — приложения Android. Так и пишем:
Сборка
Сохраняем и запускам сборку и видим что-то подобное, висим 10 минут и не можем достучатся в репозиторий:
Мы же никак не авторизовались в репозитории git! Добавление пары Login/Password в хранилище Jenkins (там где мы оставили -none- в Source Code Management) не сработало, как бы я не пробовал. Надо попробовать поискать другие пути.
Командная строка запускается от имени УЗ сеанса, Jenkins от имени System и ничего об этом не знает, в хранилище Credential Manager похоже что тоже не случится. Т.е. это не поможет:
Дополнительный поиск по сети дал несколько советов:
- Перенос ssh-ключей из УЗ сеанса в system, которые я так и не смог найти;
- Второй способ (Авторизация git), который сработал.
Авторизация git
Для этого нам потребуется PsExec.exe из набора утилит PsTools. С её помощью мы можем запустить cmd.exe из под System. Запускаем cmd.exe с повышенными правами и выполняем:
В новой консоли всё что нужно сделать это постучатся в нужный нам репозиторий, например попробовать в командной строке склонировать его. будут запрошены учётные данные:
С помощью которых Jenkins сможет обращаться к данному репозиторию. Это та самая УЗ, которую мы создавали при настройках Bonobo Git Server наряду с developer’ом. Если в дальнейшем потребуется изменить данные учётные данные придётся пройти процедуру повторно.
Нехватка компонентов и акцептов лицензий на компоненты Android SDK
Может случится так что в SDK будут отсутствовать какие-нибудь модули и консоль сборки выдавать сообщения подобного характера:
В таком случае вам надо запустить с повышенными правами SDK Manager и установить недостающие компоненты:
Всё, после всех шаманств сборка прошла успешно!
Можете разводить команду Android-разработчиков.
Как собирать проекты в Jenkins, если нужно много разных окружений
На Хабре много статей о Jenkins, но мало где описывается пример работы Jenkins и докер агентов. Все популярные инструменты сборки проектов типа Drone.io, Bitbucket Pipeline, GitLab, GitHub actions и другие, могут собирать все в контейнерах. Но как же Jenkins?
На сегодняшний день есть решение проблемы: Jenkins 2 замечательно умеет работать с Docker агентами. В статье я хочу поделиться опытом и показать, как вы можете это сделать сами.
Почему я занялся решением этой проблемы?
Так как мы в компании Citronium используем множество различных технологий, то на сборочной машине приходится держать разные версии Node.JS, Gradle, Ruby, JDK и прочих. Но зачастую конфликтов версий не избежать. Да, вы будете правы если скажете, что есть различные менеджеры версий типа nvm, rvm, но не всё так гладко с ними и у этих решений есть проблемы:
- большой объем рантаймов, который разработчики забывают чистить;
- есть конфликты между разными версиями одних рантаймов;
- каждому разработчику нужен разный набор компонентов.
Есть и другие проблемы, но давайте я лучше расскажу про решение.
Jenkins в Docker
Так как сейчас Docker уже хорошо укоренился в сфере разработки, то почти все можно запустить при помощи Docker. Мое же решение в том, чтобы Jenkins был в Docker и мог запускать другие Docker контейнеры. Этим вопросом стали задаваться еще в 2013 году в статье «Docker can now run within Docker».
Если вкратце просто необходимо в рабочий контейнер установить сам Docker и примонтировать файл /var/run/docker.sock .
Вот пример Dockerfile, который получился для Jenkins.
Таким образом мы получили Docker контейнер который может выполнять Docker команды на хостовой машине.
Настройка сборки
Не так давно Jenkins получил возможность описывать свои правила при помощи Pipeline синтаксиса, что позволяет достаточно просто менять скрипт сборки и хранить его в репозитории.
Так давайте же мы поместим в сам репозиторий специальный Dockerfile, который будет содержать в себе все необходимые для сборки библиотеки. Таким образом сам разработчик может подготовить повторяемую среду и не нужно будет OPS просить поставить на хост определенную версию Node.JS.
Такой сборочный образ подходит для большинства Node.JS приложений. А если вам, например, нужен образ для JVM проекта со включенным внутрь Sonar сканером? Вы сами вольны выбирать нужные для сборки компоненты.
Мы описали сборочное окружение, но при чем тут Jenkins? А Jenkins агенты умеют работать с такими Docker образами и проводить сборку внутри.
Директива agent использует свойство docker , где вы можете указать:
- имя сборочного контейнера согласно вашей политике нейминга;
- аргументы необходимые для запуска сборочного контейнера, где в нашем случае мы монтируем текущую директорию как директорию внутри контейнера.
А уже в шагах сборки мы указываем, какие команды выполнить внутри сборочного Docker агента. Это может все что угодно, таким образом я так же запускаю деплой приложений при помощи ansible.
Ниже я хочу показать общий Jenkinsfile, который может собрать простое Node.JS приложение.
Что же вышло?
Благодаря такому способу мы решили следующие проблемы:
- время конфигурации сборки окружения сводится к 10 — 15 минутам на проект;
- полностью повторяемое окружение сборки приложения, так как можно так собирать и на локальном компьютере;
- нет проблем с конфликтами разных версий сборочных инструментов;
- всегда чистый воркспейс, который не забивается.
Само по себе решение простое и очевидное и позволяет получить одни плюсы. Да, порог входа чуточку поднялся по сравнению с простыми командами для сборок, но зато теперь есть гарантия, что будет собираться всегда и разработчик сам может выбрать все, что необходимо для его процесса сборки.
Так же вы можете воспользоваться собранным мною образом Jenkins + Docker. Все исходники открыты и лежат на rmuhamedgaliev/jenkins_docker.
В ходе написания статьи появилась дискуссия о использовании агентов на удаленных серверах, чтобы не грузить мастер ноду при помощи плагина docker-plugin. Но об этом я расскажу в будущем.