В этой статье я покажу, как быстро развернуть среду для сборки, тестирования и публикации приложений используя платформу OpenShift на примере PHP проекта. Использовать буду OpenShift online, но всё это же можно развернуть и на собственных серверах или в VirtualBox (есть готовая сборка). Git-сервером для хранения и версионирования кода будет Bitbucket.

После успешной регистрации в системе, бесплатный аккаунт получает место на серверах и возможность создавать до трёх контейнеров, работающих в связке. А также доменные имена в домене rhcloud.com, вида application-username.rhcloud.com. Этого вполне достаточно для тестирования и экспериментов. Хоть я и разворачивал PHP-контейнер, но OpenShift позволяет таким-же образом развернуть множество других приложений и фреймворков. И ничего не мешает вместо Bitbucket-а использовать GitHub или любую другую систему контроля версий. Внутри облака крутятся docker контейнера, доступ к которым можно получить используя OpenShift Client Tools, но для базовых настроек вполне достаточно и веб-интерфейса.

Приступим. Создаём контейнер Jenkins Server, с параметрами по умолчанию и именем jenkins. Add application > Jenkins Server > Create Application. Этот контейнер будет управлять сборками и публикацией приложения. Публичный URL тогда будет jenkins-username.rhcloud.com, по этому URL можно получить доступ к веб-интерфейсу Дженкинса.

Заходим в веб-интерфейс Дженкиса и в настройках, ставим обновление плагинов, и дополнительный плагин «Bitbucket Plugin» с зависимостями. Он позволит настроить сборку проекта по триггеру — webhook-у. Изначально список плагинов пуст, потому: Настроить Jenkins > управление плагинами > дополнительно, там просим проверить обновления. После установки, перегружаем Дженкинс.

В OpenShift-е создаём контейнер нужного типа приложения, в нашем случае PHP 5.4. Странно, что староват, при развёртывании нового OpenShift-а на своих серверах гораздо свежее версии и больше вариантов.

Имя у него будет php – оно определит URL контейнера и названия зависимых настроек.

В свойствах контейнера включаем интеграцию с Дженкинсом.



Интеграция создаст в Дженкинсе задачу php-build с необходимыми настройками, которую дальше и будем настраивать. На мастер-ноде по умолчанию сборки отключены (количество сборщиков = 0), в принципе, можно это исправить, но вот публиковать приложение она не будет – не хватает утилит в базовом контейнере. Вполне возможно, это можно исправить покопавшись в контейнере руками (и головой).

Идём в настройки задачи php-build в Дженкинсе. Она уже настроена под сборку на контейнере-сборщике и публикацию в контейнер php, но нам нужно подключить bitbucket. По умолчанию подключается git в контейнере и, в принципе, можно работать и с ним.

Итак:



Где URL такой, как в опции «clone/https» bitbucket-а. Если репозиторий закрытый, то необходимо добавить параметры авторизации (Credentials > Add, провайдер Jenkins).


Где указываются параметры авторизации bitbucket-а.

Дженкинс умеет работать и по ssh ключам, но тут мешают ограничения контейнера OpenShift, и не удаётся сохранить ключи и разрешение на доступ к хосту bitbucket-а. Возможно, проблему можно надёжно решить поковыряв внутри контейнера jenkins.

Ниже, в поле «Branches to build», указывается ветка, которая будет собираться. Имеет смысл указать явно мастера (*/master).

В полях «триггеры сборки» включаем опции по которым проект будет собираться автоматически. Можно это сделать по webhook-ам; совместно с другими проектами; периодически опрашивать git на предмет изменений и, если они есть, собирать; или просто по расписанию.



В данном случае включены две опции и, кроме webhook-а, будет производиться проверка обновлений каждые 10 минут.

В настройках Сборка > выполнить команду shell уже заполнен шаблон сборки, проверки и публикации проекта в контейнер php.


После комментария «# Run tests here» надо вставить какой-либо код проверки сборки, по результатам которого, либо идём дальше и публикуем, либо выводим ошибку и выходим.

Все операции производятся в контейнере–сборщике в его окружении и его утилитами. Это может наложить ограничения на возможности. Вообще, при разворачивании собственного сервера Jenkins-а, возможностей и контроля больше. А для интеграции с OpenShift можно использовать утилиты rhc и соответствующие плагины Дженкинса (хозяйке на заметку).

Сохраняем, и можно запускать сборку. При этом Дженкинс инициирует создание контейнера-сборщика в облаке OpenShift с именем phpbldr, на который настроена задача. Тут есть нюанс: контейнер поднимается довольно долго и, иногда, задача сборки снимается не дождавшись сборщика. Но, если запустить сборку ещё раз, то на готовом сборщике всё сразу пойдёт. В свойствах проекта есть параметр «Builder Timeout», но он про доменные имена, а не про это. Есть параметры для задержки сборки и количество попыток, но они тоже не помогают.

В системных настройках Дженкинса можно увеличить время жизни сборщика (по умолчанию 15 минут):


Максимальное ограничение в 60 минут прибито гвоздями. Обязательно, что-бы в облаке, на момент сборки, был свободный слот под новый контейнер.

Для настройки сборки по webhook-ам, нужно в свойстве проекта в bitbucket-е включить:
Settings > webhooks > add webhook и указать URL Jenkins-контейнера в виде:

https://jenkins-username.rhcloud.com/bitbucket-hook/, (окончание bitbucket-hook/ – как раз триггер webhook-а). В настройках можно выбрать варианты при которых он срабатывает. По всей видимости, будут дёргаться все проекты в Дженкинсе в которых указана интеграция с bitbucket-ом, но, если изменений в исходных кодах не было, то сборка запускаться не будет.

Таким образом, при коммите будет автоматически запускаться сборка и публикация проекта.
Проверить работу webhook-а можно в меню «BitBucket Hook Log» задачи в Дженкинсе.
После успешной сборки проект публикуется в контейнер php и можно насладится результатом по публичному URL: http://php-username.rhcloud.com/.

В итоге мы получили свой лунопарк для тестирования и публикации проектов. А если всё это развернуть на своих мощностях, то он ещё и без ограничений да с дополнениями.

Спасибо за внимание.