Содержание


Автоматизация динамического развертывания с помощью IBM DevOps Services for Bluemix

Comments

Лучший способ привлечения новых пользователей и сохранения существующих – создавать привлекательные приложения, работа которых никогда не прерывается. Потребители избегают сайтов, которые бывают недоступными (ввиду регулярного обслуживания или по каким-то иным причинам). А по мере того как ваша группа повышает частоту выпуска новых версий, проблема исключения перерывов в обслуживании становится все острее.

Динамическое развертывание (rolling deployments) – это процесс развертывания новых версий приложения в среде без прерывания обслуживания клиентов. Если вы хотите наращивать свою базу пользователей, то вы должны реализовать динамическое развертывание.

Простую в применении платформу для динамического развертывания предоставляет IBM Bluemix™. Я покажу, как легко автоматизировать процесс динамического развертывания в Bluemix с помощью IBM DevOps Services и службы Delivery Pipeline.

Что для этого нужно

  • Учетные записи Bluemix
  • Знакомство с возможностями IBM Delivery Service, такими как создание служб Builder и Deployer с параметрами по умолчанию. При необходимости изучите руководство Getting Started with IBM Bluemix and DevOps Services Using Java.
  • Знакомство с bash-сценариями.

Увидеть конвейерПолучить примера кода

Динамическое развертывание необходимо для любого приложения производственного уровня во избежание прерываний в обслуживании.

Я написал простой пример Hello World с конвейером автоматизации динамического развертывания. Этот код можно просматривать в процессе чтения руководства. Конвейер общедоступен, так что можно увидеть конфигурации процесса автоматического развертывания и его журналы.

Я покажу, как создать процесс автоматического динамического развертывания в DevOps Services. Используйте эту последовательность действий только в качестве примера, изменяя действия и сценарии с учетом своих потребностей — или для их совершенствования с учетом моих скромных способностей в области написания bash-сценариев.

Шаг 1. Копирование примера проекта

Начните с копирования примера проекта, чтобы у вас был свой собственный проект DevOps Services с необходимым исходным кодом.

  1. Нажмите кнопку Получить код примера в начале этого руководства.
  2. На обзорной странице проекта danberg | Pipeline_hello нажмите кнопкуEDIT CODE (введите свои учетные данные DevOps Services, если вы еще не вошли) и выберите пункт FORK из меню.
  3. Введите имя своего нового проекта, установите флажок Deploy to Bluemix и выберите организацию и пространство для процесса выставления счетов.
  4. Нажмите кнопку Save, чтобы создать новый проект готовым с исходным кодом.

Шаг 2. Добавление нового этапа сборки

Когда проект будет создан, приступайте к настройке конвейера доставки, добавив к конвейеру этап сборки.

  1. Нажмите кнопку BUILD & DEPLOY в верхней части страницы.
  2. По умолчанию процесс доставки не включен. Нажмите кнопку ADVANCED, чтобы включить дополнительную функцию конвейера доставки.
  3. Нажмите кнопку add a builder, чтобы выбрать компоновщик для проекта. Сохраните настройки по умолчанию (компоновщик Ant) и введите out в поле Build archive directory. Скриншот диалогового окна конфигурации компоновщика
    Скриншот диалогового окна конфигурации компоновщика
  4. Нажмите кнопку SAVE, чтобы сохранить параметры компоновщика.
  5. Нажмите кнопку add a stage, чтобы настроить средство развертывания. Нажмите кнопку SAVE, чтобы сохранить параметры по умолчанию. Мы настроим средство развертывания на динамические выпуски в последующих пунктах.

Шаг 3. Настройка конвейера доставки на использование сценария развертывания

Так как динамическое развертывание немного сложнее других процессов развертывания, желательно организовать в своей системе управления версиями (SCM) сценарий развертывания. Для этого нужно настроить свои компоновщик и средство развертывания на выполнение сценария развертывания.

  1. Нажмите кнопку EDIT CODEсвоего проекта.
  2. Выберите файл build.xml и заметьте, что он содержит следующий фрагмент для копирования в каталог архива файла deploy.sh – сценария, используемого для динамического развертывания. Этот код необходим для того, чтобы файл deploy.sh был доступен на этапе развертывания:
    <echo message="Copy files to ${artifact_dir} for deployment"/> 
    <copy todir="${artifact_dir}"> 
        <fileset file="manifest.yml" /> 
        <fileset file="deploy*.sh" /> 
    </copy>
  3. Откройте конвейер, нажав кнопку BUILD & DEPLOY.
  4. Щелкните на значке настройки Скриншот значка настройки в правом верхнем углу окна Deployer для редактирования конфигурации.
  5. Укажите в поле Application name значение, указывающее на ваш проект. В процессе развертывания это имя будет использоваться для составления имени нового приложения.
  6. Замените содержимое раздела Script следующим кодом:
    # Использование сценария из результата сборки
    source deploy.sh

    Использование source в тексте сценария – правильный способ вызова bash-сценария, который входит в число артефактов сборки. Скриншот раздела сценария
    Скриншот раздела сценария
  7. Нажмите кнопку Save.

Шаг 4. Изучение сценария динамического развертывания

Следите за файлом сценария примера deploy.sh по мере моего описания основных разделов, необходимых для bash-сценария автоматизации развертывания. (На этом этапе вам не нужно вносить никаких изменений).

  1. В начале сценария определим переменные, которые будут использоваться позже:
    ############# 
    # Colors    # 
    ############# 
    green='\e[0;32m' 
    red='\e[0;31m' 
    label_color='\e[0;33m' 
    no_color='\e[0m' 
     
    # Используется для создания общедоступного маршрута в 
    # пространстве для доступа к развернутому приложению. 
    # Для указания уникального имени маршрута в пространстве 
    # используется зарезервированная переменная CF_SPACE 
    # (настраивается в Deployer). 
    if [ "${CF_SPACE}" == "prod" ]; then 
       PUBLIC_HOST=${CF_APP} 
    else 
       PUBLIC_HOST="${CF_SPACE}-${CF_APP}" 
    fi 
     
    # Извлечь сборку с выбранным номером из зарезервированной 
    # переменной BUILD_SELECTOR. 
    SELECTED_BUILD=$(grep -Eo '[0-9]{1,100}' <<< "${BUILD_SELECTOR}") 
     
    # Вычислить уникальное имя приложения, используя зарезервированное 
    # имя CF_APP (настраивается в Deployer или посредством файла manifest.yml), 
    # номер сборки и отметку времени (допускается несколько развертываний 
    # одной и той же сборки). 
    NEW_APP_NAME="${CF_APP}-$SELECTED_BUILD-$(date +%s)" 
     
    # При необходимости можно настроить домен. 
    DOMAIN=mybluemix.net  
    # Используется для определения временного маршрута для проверки вновь 
    # развернутого приложения 
    TEST_HOST=$NEW_APP_NAME 
    # Развертываемый артефакт Java. Должен совпадать с результатом процесса сборки. 
    WAR=Pipeline_hello1.war 
    MEMORY=256M
    NEW_APP_NAME имеет важное значение, потому что показывает, как я вычисляю имя нового приложения при каждом развертывании на основе номера сборки и отметки времени. Переменные цвета используются для упрощения чтения файлов журнала. Имя приложения, указанное в конфигурации Deployer, вводится в сценарий из переменной среды CF_APP, а целевое пространство –из переменной CF_SPACE.
  2. Находим имена уже развернутых приложений в пространстве (чтобы позднее удалить их). Я ищу в пространстве все приложения, связанные с PUBLIC_HOST, игнорируя вычисляемый номер сборки и метку времени:
    rm -f apps.txt 
    echo -e "${label_color}Find all existing deployments:${no_color}" 
    cf apps | { grep $PUBLIC_HOST || true; } | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g"  
       &> apps.txt 
    cat apps.txt 
    # Сохранить только имена развернутых приложений 
    awk '{ print $1 }' apps.txt > app_names.txt 
    rm -f apps.txt
  3. Перенесем обновления из выбранной сборки, используя вычисленное имя и маршрут:
    echo -e "${label_color}Pushing new deployment - ${green}$NEW_APP_NAME${no_color}" 
    cf push $NEW_APP_NAME -p $WAR -d $DOMAIN -n $TEST_HOST -m $MEMORY 
    DEPLOY_RESULT=$? 
    if [ $DEPLOY_RESULT -ne 0 ]; then 
       echo -e "${red}Deployment of $NEW_APP_NAME failed!!" 
       cf logs $NEW_APP_NAME --recent 
       return $DEPLOY_RESULT 
    fi 
    echo -e "${label_color}APPS:${no_color}" 
    cf apps | grep ${CF_APP}

    Я использовал простую команду push. Применяя этот метод для будущих приложений, вы можете настроить команду push в соответствии со своими потребностями — включая создание необходимых служб.
  4. Проверим, что новое приложение функционирует. Здесь я использую простую команду cURL, чтобы убедиться, что приложение отвечает на запросы. Вам, вероятно, захочется глубже протестировать приложение, чтобы определить, готово ли оно взять на себя нагрузку:
    echo -e "${label_color}Testing new app - ${green}$NEW_APP_NAME${no_color}" 
    curl "http://$TEST_HOST.$DOMAIN" 
    TEST_RESULT=$? 
    if [ $TEST_RESULT -ne 0 ]; then 
       echo -e "${red}New app did not deploy properly - ${green}$NEW_APP_NAME${no_color}" 
       return $TEST_RESULT 
    else 
       echo -e "${green}Test PASSED!!!!${no_color}"    
    fi
  5. Направим трафик к новому приложению, связав как существующее, так и новое приложения с общедоступным маршрутом. Bluemix автоматически направляет трафик в оба экземпляра:
    echo -e "${label_color}Map public space route to new app - ${green}$NEW_APP_NAME${no_color}" 
    cf map-route $NEW_APP_NAME $DOMAIN -n $PUBLIC_HOST 
     
    echo -e "${label_color}Public route bindings:${no_color}" 
    cf routes | { grep $PUBLIC_HOST || true; }
  6. Удалим временный тестовый маршрут, который больше не нужен. Этот шаг не строго обязателен, но он помогает очистить маршруты, которые больше не используются:
    echo -e "${label_color}Remove and delete test route - ${green}$TEST_HOST${no_color}" 
    cf unmap-route $NEW_APP_NAME $DOMAIN -n $TEST_HOST 
    if [ $? -ne 0 ]; then 
       echo -e "${label_color}Test route isn't mapped and doesn't need to be removed.${no_color}" 
    fi 
    cf delete-route $DOMAIN -n $TEST_HOST -f
  7. Теперь удалим старую версию или версии приложения, оставив только новую версию для обработки всего трафика из общедоступного маршрута:
    while read name 
    do 
       if [ "$name" != "$NEW_APP_NAME" ]; then 
           echo -e "${label_color}Deleting old deployed application - $name${no_color}" 
          cf delete $name -f 
       fi 
    done < app_names.txt 
     
    rm -f app_names.txt

Шаг 5. Просмотр журналов запросов развертывания

Теперь, когда конвейер настроен, можно запросить новую сборку и развернуть ее.

  1. Нажмите кнопку REQUEST BUILD, чтобы собрать свой проект и автоматически инициировать процесс развертывания.
  2. Запросите другую сборку, нажав кнопку REQUEST BUILD. В этом примере запрашивается Build 68 для развертывания в пространстве dev после сборки. Номер вашей сборки будет другим, но порядок действий тот же. Скриншот конвейера после запроса на развертывание
    Скриншот конвейера после запроса на развертывание
  3. Из окна наведения (удерживайте указатель мыши на имени работающего приложения) можно узнать маршрут, используемый для доступа к приложению в пространстве dev. Щелкните на запросе развертывания (в этом примере Deployment 81), чтобы увидеть журнал развертывания. Скриншот конвейера приложения маршрутом в окне наведения
    Скриншот конвейера приложения маршрутом в окне наведения
  4. Видны назначенные переменные и существующее приложение, развернутое из сборки Build 68. Обратите внимание, что суффиксом вычисляемого имени NEW_APP_NAME служат номер сборки и отметка времени:
    Variables: 
    PUBLIC_HOST=dev-dcb-hello 
    DOMAIN=mybluemix.net 
    NEW_APP_NAME=dcb-hello-68-1408373927 
    TEST_HOST=dcb-hello-68-1408373927 
    WAR=Pipeline_hello1.war 
    MEMORY=256M 
    Find all existing deployments: 
    dcb-hello-67-1408373457   started           1/1         256M     1G     dev-dcb-hello.mybluemix.net
  5. Содержимое сборки Build 68 передается в Bluemix с использованием вычисленного имени:
    Pushing new deployment - dcb-hello-68-1408373927 
    Creating app dcb-hello-68-1408373927 in org danberg@us.ibm.com / space dev as danberg@us.ibm.com... 
    OK 
     
    Creating route dcb-hello-68-1408373927.mybluemix.net... 
    OK 
     
    Binding dcb-hello-68-1408373927.mybluemix.net to dcb-hello-68-1408373927... 
    OK 
     
    Uploading dcb-hello-68-1408373927... 
    Uploading from: /home/jenkins/workspace/b3a8fa2f-27f8-5b88-4007-76445be089ce/ 
       0b7a50d5-2d8f-4dac-ac7b-c5b9aa3e6f27/out/Pipeline_hello1.war 
    2.5K, 3 files 
    OK 
     
    Starting app dcb-hello-68-1408373927 in org danberg@us.ibm.com / space dev as danberg@us.ibm.com... 
    OK 
    -----> Downloaded app package (4.0K) 
    -----> Uploading droplet (104M) 
     
    0 of 1 instances running, 1 starting 
    0 of 1 instances running, 1 starting 
    0 of 1 instances running, 1 starting 
    0 of 1 instances running, 1 starting 
    0 of 1 instances running, 1 starting 
    0 of 1 instances running, 1 starting 
    1 of 1 instances running 
     
    App started

    Как видите, развернуты новое и старое приложения, но на разных маршрутах. Для старой сборки Build 67 используется общедоступный маршрут, а для нового развертывания – закрытый:
    APPS: 
    dcb-hello-67-1408373457   started           1/1         256M     1G     dev-dcb-hello.mybluemix.net 
    dcb-hello-68-1408373927   started           1/1         256M     1G     dcb-hello-68-1408373927.mybluemix.net
  6. Теперь можно протестировать новое приложение из сборки Build 68 с помощью тестового маршрута:
    Testing new app - dcb-hello-68-1408373927 
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current 
                                     Dload  Upload   Total   Spent    Left  Speed 
     
      0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0 
    100    46    0    46    0     0     76      0 --:--:-- --:--:-- --:--:--    89 
    100    46    0    46    0     0     76      0 --:--:-- --:--:-- --:--:--    89 
    Rolling deployments made easy!!!0.0.0.0:63645 
    Test PASSED!!!!
  7. После успешного тестирования привязываем новое приложение к общедоступному узлу (dev-dcb-hello.mybluemix.net). Обратите внимание, что теперь старое и новое приложения привязаны к общедоступному маршруту:
    Map public space route to new app - dcb-hello-68-1408373927 
    Creating route dev-dcb-hello.mybluemix.net for org danberg@us.ibm.com / space dev as danberg@us.ibm.com... 
    OK 
    Route dev-dcb-hello.mybluemix.net already exists 
    Adding route dev-dcb-hello.mybluemix.net to app dcb-hello-68-1408373927 in org danberg@us.ibm.com /  
       space dev as danberg@us.ibm.com... 
    OK 
    Public route bindings: 
    dev-dcb-hello                                                  mybluemix.net   dcb-hello-68-1408373927, dcb-hello-67-1408373457
  8. Удаляем тестовый маршрут:
    Remove and delete test route - dcb-hello-68-1408373927 
    Removing route dcb-hello-68-1408373927.mybluemix.net from app dcb-hello-68-1408373927 in org  
       danberg@us.ibm.com / space dev as danberg@us.ibm.com... 
    OK 
    Deleting route dcb-hello-68-1408373927.mybluemix.net... 
    OK
  9. Наконец, удаляем старое приложение, оставив для обработки клиентского трафика только новое:
    Deleting old deployed application - dcb-hello-67-1408373457 
    Deleting app dcb-hello-67-1408373457 in org danberg@us.ibm.com / space dev as danberg@us.ibm.com... 
    OK 
    Sending deployment success of dcb-hello-67-1408373457 to IBM DevOps Services... 
    IBM DevOps Services notified successfully. 
    Deployed Applications: 
    dcb-hello-68-1408373927   started           1/1         256M     1G     dev-dcb-hello.mybluemix.net 
    Public route bindings: 
    dev-dcb-hello                            mybluemix.net   dcb-hello-68-1408373927    
    You have successfully executed a rolling deployment of dcb-hello-68-1408373927.

Заключение

Динамическое развертывание необходимо для любого приложения производственного уровня во избежание прерываний в обслуживании и недовольства пользователей. В Bluemix динамическое развертывание приложения можно выполнить вручную, но это утомительный путь, чреватый ошибками. Для достижения высокой повторяемости и надежности процесса динамического развертывания его лучше автоматизировать.

Я показал один из подходов к автоматизации процесса динамического развертывания с помощью службы Delivery Pipeline из DevOps Services. Я использовал тривиальное приложение, сосредоточившись на сценарий динамического развертывания; в действительности нужно также автоматизировать и процесс настройки служб (уникальный или общий).

Информация и пример из этого руководства позволят вам освоить динамическое развертывание любых своих приложений в Bluemix. Удачи в ваших собственных начинаниях! И, как всегда, с любыми вопросами обращайтесь в наш форум.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=1019658
ArticleTitle=Автоматизация динамического развертывания с помощью IBM DevOps Services for Bluemix
publish-date=11032015