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 "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/.

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

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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 3

      +1
      Про разворачивание приложение в публичном облаке OpenShift куча статей, а вот про разворачивание всего этого чуда на своем сервере информации немного. Я пробовал по инструкции от digitalcloud. И оно даже работало, но многое пришлось додумывать, дописывать, догугливать. Может поделитесь своим опытом в этом вопросе?
        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
          0
          Бесплатный аккаунт дает возможность не только пользоваться доменом rhcloud.com но и привязать свой домен через cname

          Only users with full accounts can post comments. Log in, please.