OpenShift + Jenkins + Bitbucket, непрерывная интеграция и публикация из коробки20.10.2016 11:18

5caec73bfb1344e8b315b7b119cd0186.png
В этой статье я покажу, как быстро развернуть среду для сборки, тестирования и публикации приложений используя платформу 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 контейнера и названия зависимых настроек.
В свойствах контейнера включаем интеграцию с Дженкинсом.
32743d1bcfdc48a19bb1b4f5fb5cb5a6.png
Интеграция создаст в Дженкинсе задачу php-build с необходимыми настройками, которую дальше и будем настраивать. На мастер-ноде по умолчанию сборки отключены (количество сборщиков = 0), в принципе, можно это исправить, но вот публиковать приложение она не будет — не хватает утилит в базовом контейнере. Вполне возможно, это можно исправить покопавшись в контейнере руками (и головой).
Идём в настройки задачи php-build в Дженкинсе. Она уже настроена под сборку на контейнере-сборщике и публикацию в контейнер php, но нам нужно подключить bitbucket. По умолчанию подключается git в контейнере и, в принципе, можно работать и с ним.
Итак:
2b2d14232258466c83096584614d42f0.png
Где URL такой, как в опции «clone/https» bitbucket-а. Если репозиторий закрытый, то необходимо добавить параметры авторизации (Credentials → Add, провайдер Jenkins).
0634ed9fb77a4441a14fba2ed40b8775.png
Где указываются параметры авторизации bitbucket-а.

Дженкинс умеет работать и по ssh ключам, но тут мешают ограничения контейнера OpenShift, и не удаётся сохранить ключи и разрешение на доступ к хосту bitbucket-а. Возможно, проблему можно надёжно решить поковыряв внутри контейнера jenkins.
Ниже, в поле «Branches to build», указывается ветка, которая будет собираться. Имеет смысл указать явно мастера (*/master).
В полях «триггеры сборки» включаем опции по которым проект будет собираться автоматически. Можно это сделать по webhook-ам; совместно с другими проектами; периодически опрашивать git на предмет изменений и, если они есть, собирать; или просто по расписанию.
6477018cc1fc4685a445fb07d667391b.png
В данном случае включены две опции и, кроме 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 минут):
7cef4162540f43bf857a157f4976f0cb.png
Максимальное ограничение в 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/.

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

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

Комментарии (3)

  • 20 октября 2016 в 07:33

    0

    ↑

    ↓

    Про разворачивание приложение в публичном облаке OpenShift куча статей, а вот про разворачивание всего этого чуда на своем сервере информации немного. Я пробовал по инструкции от digitalcloud. И оно даже работало, но многое пришлось додумывать, дописывать, догугливать. Может поделитесь своим опытом в этом вопросе?

  • 20 октября 2016 в 07:48

    0

    ↑

    ↓

    Я для экспериментов разворачивал сборку Vagrant+VirtualBox под windows — проблем не возникло, кроме, разве что необходимости использования версии Vagrant 1.8.4 и соответственно VirtualBox 5.0.

    Так же разворачивал под текущим CentOS 7.2 — проблемы возникли, но похоже связанные с тем, что сам CentOS я виртуализировал.
    Проглядел статью, которую вы привели — она устарела и через чур усложнена. В CentOS 7 базовая установка сводится к следующему: 

    # yum install centos-release-openshift-origin epel-release
# yum update
# yum install docker origin

    Настройка докера, чтоб доверял локальному репозиторию и: 

    # oc cluster up --routing-suffix=openshift.local.domain --public-hostname=openshift.local.domain --host-data-dir=/opt/openshift --use-existing-config

    При наличии собственного ДНС, нужно прописать свои удобные имена и указать их при разворачивании кластера. Так же используем постоянную папку конфигурации /opt/openshift

  • 20 октября 2016 в 10:28

    0

    ↑

    ↓

    Бесплатный аккаунт дает возможность не только пользоваться доменом rhcloud.com, но и привязать свой домен через cname

© Habrahabr.ru