OpenShift + Jenkins + Bitbucket, безперервна інтеграція та публікація з коробки


У цій статті я покажу, як швидко розгорнути середовище для збірки, тестування і публікації додатків використовуючи платформу 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 "or not OK OK, that is the qestion ;)";

# Deploy new build

# App Stop
$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/
.

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

Дякую за увагу.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.