В этой статье я покажу, как быстро развернуть среду для сборки, тестирования и публикации приложений используя платформу 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.
source $OPENSHIFT_CARTRIDGE_SDK_BASH
alias rsync="rsync --delete-after -azS -e '$GIT_SSH'"
upstream_ssh="УникальныйID@php-${OPENSHIFT_NAMESPACE}.rhcloud.com"
# remove previous metadata, if any
rm -f $OPENSHIFT_HOMEDIR/app-deployments/current/metadata.json
if ! marker_present "force_clean_build"; then
# don't fail if these rsyncs fail
set +e
rsync $upstream_ssh:'$OPENSHIFT_BUILD_DEPENDENCIES_DIR' $OPENSHIFT_BUILD_DEPENDENCIES_DIR
rsync $upstream_ssh:'$OPENSHIFT_DEPENDENCIES_DIR' $OPENSHIFT_DEPENDENCIES_DIR
set -e
fi
# Build/update libs and run user pre_build and build
gear build
# Run tests here
echo "OK or not OK, that is the qestion ;)";
# Deploy new build
# Stop app
$GIT_SSH $upstream_ssh "gear stop --conditional --exclude-web-proxy --git-ref $GIT_COMMIT"
deployment_dir=`$GIT_SSH $upstream_ssh 'gear create-deployment-dir'`
# Push content back to application
rsync $OPENSHIFT_HOMEDIR/app-deployments/current/metadata.json $upstream_ssh:app-deployments/$deployment_dir/metadata.json
rsync --exclude .git $WORKSPACE/ $upstream_ssh:app-root/runtime/repo/
rsync $OPENSHIFT_BUILD_DEPENDENCIES_DIR $upstream_ssh:app-root/runtime/build-dependencies/
rsync $OPENSHIFT_DEPENDENCIES_DIR $upstream_ssh:app-root/runtime/dependencies/
# Configure / start app
$GIT_SSH $upstream_ssh "gear remotedeploy --deployment-datetime $deployment_dir"
После комментария «# 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/.
В итоге мы получили свой лунопарк для тестирования и публикации проектов. А если всё это развернуть на своих мощностях, то он ещё и без ограничений да с дополнениями.
Спасибо за внимание.
Автор: Lelik13a
