Автоматизация развертывания Докер WebLogic кластера на любом облаке
Задний план
Java-разработчики и специалисты DevOps уже давно пытались автоматизировать развертывание корпоративных Java-приложений. Сложный характер этих приложений, как правило, означает, что зависимостей приложений и внешних интеграций должны были быть перенастроен каждый раз, когда приложение было развернуто в средах / TEST DEV.
Многие решения рекламировали сообщение "модель один раз, развернуть в любом месте" для развертывания приложений. В действительности, однако там всегда были хитросплетения, которые сделали его очень трудно повторно использовать шаблон приложения через одновременно на предпосылке Vsphere виртуальной среде и среде AWS, например.
Совсем недавно, однако, Docker контейнеры популяризировали идею компонентов упаковки приложения в Linux Контейнеры, которые могут быть развернуты точно так же на любом хосте Linux, пока установлен Docker двигателя.
К сожалению containerizing Enterprise Java приложений все еще проблема в основном потому, что существующие рамки состав приложения не учитывают сложные зависимости, внешние объединения или автоматическое масштабирование рабочих процессов пост-положение. Кроме того, эфемерная конструкция контейнеров означает, что разработчикам пришлось раскручивать новые контейнеры и заново создать сложные зависимости & внешние интеграции с каждым обновлением версии.
DCHQ, доступен в размещенных и на предпосылке версиях, устраняет все эти проблемы и упрощает контейнеризации корпоративных Java-приложений через рамки композиции предварительной заявки, которая простирается Docker Compose с переменными окружения кросс-изображений привязок, расширяемых Баш скрипт плагинов, которые могут вызывается во время запроса или после предоставления, а также применение кластеризации для высокой доступности в нескольких хостов или регионах с поддержкой автоматического масштабирования.
После того, как приложение подготовлено, пользователь может контролировать процессора, памяти и ввода / вывода запущенных контейнеров, получать уведомления & уведомления, а также выполнять 2-й день-операции, как резервное копирование по графику, Контейнер обновлений с использованием Баш скрипт плагинов, и масштаб In / Out. Кроме того, из-из коробки рабочие процессы, которые облегчают непрерывную доставку с Дженкинс позволяют разработчикам обновить WAR файл Java запущенного приложения, не нарушая существующих зависимостей & интеграции.
В этом блоге мы будем идти по автоматизации развертывания от конца до конца Docker на основе WebLogic Cluster. Мы рассмотрим:
- Построение шаблона приложения для WebLogic Cluster, которые могут повторно использоваться на любом хосте Linux работает в любом месте
- Provisioning & автоматическое масштабирование базовой инфраструктуры на любом облаке (с Rackspace быть примером в этом блоге)
- Развертывание WebLogic Cluster на серверах Rackspace Cloud
- Развертывание Корзина Java WAR файл на сервер администратора
- Доступ к In-Browser Terminal для запуска контейнеров
- Включение непрерывного рабочего процесса доставки с Дженкинс, чтобы обновить файл WAR из запущенных приложений, когда сборка запускается
- Мониторинг CPU, памяти и ввода / вывода бегущего контейнеров
Создание шаблона приложения для The Oracle WebLogic 12c Cluster
O сть вход в DCHQ (либо размещенного DCHQ.io или на предпосылке версии), пользователь может перейти к App & Machine , а затем нажмите на + кнопку , чтобы создать новый Докер Compose шаблон.
Мы создали шаблон приложения WebLogic Cluster с помощью пользовательского образа мы построили Усиливая изображение Раду Dobrinescu в (radudobrinescu / wls12c: 2,0).
Вы заметите , что CLUSTER_SIZE параметр позволяет указать количество контейнеров для запуска (с теми же зависимостей приложений). Мы используем эту функцию, чтобы определить Managed размер кластера серверов.
Хоста параметр позволяет указать хост вы хотели бы использовать для развертывания контейнеров. Таким образом , вы можете обеспечить высокую доступность для ваших кластеров серверов приложений в различных хостов (или регионах) , и вы можете соблюдать правила сродства , чтобы гарантировать , что база данных работает на отдельном хосте, например. Ниже приведены значения , которые поддерживаются для параметра хоста:
- host1, host2, host3 и т.д. - выбирает хост случайным образом в пределах дата-центра (или кластер) для развертывания контейнеров
- <IP - адрес 1, 2 IP - адреса и т.д.> - позволяет пользователю указать фактический IP - адреса используются для развертывания контейнеров
- <Hostname 1, Hostname 2 и т.д.> - позволяет пользователю определить фактические имена хостов использовать для развертывания контейнеров
- Подстановочные (например , "db- *" или "приложение-srv- *") - указание использовать групповые символы в имени хоста
Кроме того, пользователь может создавать кросс-изображения переменных среды привязок, сделав ссылку на переменную окружения другого изображения. В этом случае, мы сделали одно связывание в этом CAES: ADMIN_HOSTNAME = {{AdminServer | ф}} - в котором Администратор хост-сервер IP разрешен динамически во время запроса и используется для обеспечения того, чтобы управляемые серверы могут установить соединение с администратором сервера.
Ниже приведен список поддерживаемых значений переменной окружения:
- {{alphanumeric | 8}} - создает случайный 8-символьный буквенно - цифровой строки. Это особенно полезно для создания случайных паролей.
- {{<Image Name> | ip}} - позволяет ввести IP - адрес хоста контейнера в качестве значения переменной окружения. Это наиболее полезно для обеспечения возможности промежуточного программного обеспечения яруса , чтобы установить соединение с базой данных.
- {{<Image Name> | container_ip}} - позволяет ввести имя контейнера контейнера в качестве значения переменной окружения. Это наиболее полезно для обеспечения возможности промежуточного программного обеспечения яруса , чтобы установить безопасное соединение с базой данных (не подвергая порт базы данных).
- {{<Image Name> | container_private_ip}} - позволяет ввести внутренний IP контейнера в качестве значения переменной окружения. Это наиболее полезно для обеспечения возможности промежуточного программного обеспечения яруса , чтобы установить безопасное соединение с базой данных (не подвергая порт базы данных).
- {{<Image Name> | port _<Port Number>}} - позволяет ввести номер порта контейнера в качестве значения переменной окружения. Это наиболее полезно для обеспечения возможности промежуточного программного обеспечения яруса , чтобы установить соединение с базой данных. В этом случае номер порта , указанный должен быть внутренний номер порта - то есть не внешний порт , который выделяется в контейнер. Например, {{PostgreSQL | port_5432}} будет переведен к фактической внешний порт , что позволит промежуточное программное обеспечение уровня для установления соединения с базой данных.
- {{<Image Name> | <Environment Variable Name>}}} - позволяет ввести значение переменной окружения изображение в в переменной окружения другого образа. Случаи использования здесь безграничны - как большинство многоуровневых приложений будет иметь зависимости кросс-изображения.
Фактическое построение изображения Docker WebLogic можно автоматизировать с помощью DCHQ , а также. Пользователь может нажать на изображение Строить , а затем нажмите на кнопку +. Пользователь может создать изображение , используя либо Dockerfile или частный / общественный проект GitHub , который имеет Dockerfile.
Изображение , которое мы создаем для WebLogic был построен с использованием изображения Radu Dobrinescu в (radudobrinescu / wls12c: 2.0) ( https://hub.docker.com/r/radudobrinescu/wls12c/ ). Мы сделали несколько модификаций к изображению в нашем собственном Dockerfile , а затем толкнул новый образ в собственном хранилище (dchq / WebLogic: последние). Здание изображений можно запланировать с помощью выражения хрон. Кроме того, пользователь может использовать {{}} метка времени в имени тега, чтобы создать уникальные имена тегов с каждой новой сборки. Таким образом , пользователь может вернуться к старым изображениям для резервного копирования.
Provisioning & Auto-Scaling подстилающей инфраструктуры на любом облаке
После того, как приложение сохраняется, пользователь может зарегистрировать поставщика облако автоматизировать выделение ресурсов и автоматическое масштабирование кластеров по 13 различных облачных конечных точек, включая Vsphere, OpenStack, CloudStack, Amazon Web Services, Rackspace, Microsoft Azure, DigitalOcean, HP Public Облако, IBM SoftLayer, Google Compute Engine, и многие другие.
Во- первых, пользователь может зарегистрировать поставщика облако для Rackspace (например), перейдя в облачных провайдеров , а затем нажав на + кнопку , чтобы выбрать Rackspace . Rackspace Ключ API должен быть обеспечен , - которые могут быть извлечены из раздела Параметры учетной записи на панели управления Rackspace Cloud.
Затем пользователь может создать кластер с автоматической масштабной политики для автоматического раскрутки новых серверов Облако. Это может быть сделано путем перехода к кластерам страницы , а затем нажав на + кнопке. Вы можете выбрать политику размещения мощностей на основе , а затем Плетение в качестве сетевого уровня для того , чтобы облегчить безопасный, защищенный паролем кросс-контейнеровоз связь между несколькими хостами в кластере.
Пользователь может в настоящее время положение несколько облачных серверов на вновь созданном кластере, перейдя в машинах , а затем нажав на + кнопку , чтобы выбрать Rackspace . После того, как поставщик Облако выбран, пользователь может выбрать область, размер и изображение , необходимое. Кластер затем выбирается и может быть определено количество облачных серверов.
Развертывание WebLogic кластеров к Rackspace Cloud Servers
После того, как серверы облачными подготовлено, пользователь может развернуть многоуровневую, Docker на основе Java-приложений на новых серверах Cloud. Это может быть сделано путем перехода к библиотеке Self-Service, а затем нажав на кнопку Настройка, чтобы запросить применение многоуровневой.
Пользователь может выбрать тег окружающей среды (например, DEV или QE) и кластер Rackspace, созданный, прежде чем нажать на Run.
После того , как WebLogic кластера подготовлено, пользователь может получить доступ к консоли администратора сервера , чтобы убедиться , что управляемые серверы будут обнаружены и работает. URL будет HTTP: // <admin_server_host_ip>: 7001 / консоли . Учетные данные по умолчанию будет WebLogic / welcome1.
Развертывание Корзине Java WAR файл с помощью Plug-In Framework
После того , как WebLogic Cluster запущен и работает, пользователь может выполнить Баш скрипт плагин для развертывания Java WAR файла на одном из серверов. В этом случае мы просто вызывается плагин для развертывания приложения корзины покупок в администратора сервера. Из действия меню, пользователь может выбрать подключаемые модули , а затем выберите контейнер (ы) , на котором будет выполняться плагин. Затем пользователь может искать плагин и переопределить аргументы подвергаются.
В этой простой плагин, мы захватывая три файла с удаленного сервера, доступного для развертывания приложения.
- deploy.py
- deploy_app.sh
- shoppingcart.war
Вот файлы, используемые:
deploy.py
---------------------
deploy_app.sh
---------------------
Доступ в-браузер терминалов для функционирования контейнеров
Значок командной строки должна быть доступна рядом с именами контейнеров "на странице Живая Apps. Это позволяет пользователям входить в контейнер с помощью защищенного протокола связи через очереди сообщений агента. Белый список команд может быть определен арендатором администратора, чтобы гарантировать, что пользователи не делают никаких вредных изменений на подножку контейнеров.
В этом случае, мы использовали командную строку, чтобы убедиться, что deploy.py файл действительно был загружен на сервер администратора. Делая простой кот /oracle/fmwhome/wlst_custom/deploy.py - мы смогли убедиться, что файл действительно существует в этом контейнере.
Затем мы получили доступ к консоли администратора сервера и переходите, Развертываниям, чтобы убедиться, что приложение Корзина действительно была развернута.
И, наконец, мы получили доступ к фактической приложения на HTTP: // <admin_server_host_ip>: 7001 / ShoppingCart
Мониторинг процессора, памяти & Применение I / вывода RunningContainers
После того, как приложение и работает, наши разработчики мониторинг процессора, памяти и ввода / вывода запущенных контейнеров для получения оповещений, когда эти показатели превышают заранее определенный порог. Это особенно полезно, когда наши разработчики выполняют функциональное и нагрузочное тестирование.
Пользователь может выполнить исторический анализ мониторинга и соотнести проблемы с обновлением контейнера или построить развертываний. Это можно сделать, нажав на действия меню запущенного приложения , а затем по мониторингу . Диапазон дат можно выбрать для просмотра процессора, памяти и ввода / вывода исторически.
Включение непрерывного рабочего процесса доставки с Jenkins Чтобы обновить файл WAR бегущего приложения Когда сборки Срабатывает
Для разработчиков, желающих следовать модели "неизменные" контейнеров путем восстановления изображений Docker, содержащих код приложения и раскручивается новые контейнеры с каждым обновлением приложения, DCHQ обеспечивает автоматизированную функцию сборки, которая позволяет разработчикам автоматически создавать Docker изображения из Dockerfiles или частных проектов GitHub, содержащих Dockerfiles.
Тем не менее, многие разработчики , возможно , пожелают обновить сервер контейнеров запущенного приложения последней Java WAR файл вместо. Для этого, DCHQ позволяет разработчикам включить непрерывный рабочий процесс поставки с Дженкинс. Это можно сделать, нажав на действия меню запущенного приложения , а затем выберите непрерывной доставки . Пользователь может выбрать экземпляр Дженкинс , который уже зарегистрирован в DCHQ, фактическое работы на Дженкинс , который будет производить последнюю версию файла WAR, а затем Баш скрипт плагин , чтобы захватить эту сборку и развернуть его на работающем сервере приложений. После того, как эта политика будет сохранена, DCHQ будет взять последнюю версию файла WAR из Дженкинс любое время , когда сборка срабатывает и развернуть его на работающем сервере приложений.
Обратите внимание, что Баш скрипт плагин может быть настроен, чтобы гарантировать, что правая последовательность шагов берется для WebLogic Server. Например, пользователь может захотеть использовать конкретный план развертывания или запустить несколько сценариев перед не-разместившей и последующее развертывание нового файла WAR.
Разработчики, как результат всегда будет иметь последнюю версию файла Java WAR развернут на своих текущих контейнеров в средах / TEST DEV.
Вывод
Containerizing Java корпоративных приложений по-прежнему является проблемой в основном потому, что существующие рамки состав приложения не учитывают сложные зависимости, внешние объединения или автоматическое масштабирование рабочих процессов пост-положение. Кроме того, эфемерная конструкция контейнеров означает, что разработчикам пришлось раскручивать новые контейнеры и заново создать сложные зависимости & внешние интеграции с каждым обновлением версии.
DCHQ, доступен в размещенных и на предпосылке версиях, устраняет все эти проблемы и упрощает контейнеризации корпоративных Java-приложений с помощью передовой основы композиции приложений, что облегчает переменных среды кросс-изображений привязок, расширяемый Баш скрипт плагины, которые могут быть вызваны в запросить время или пост-положения, а также применение кластеризацию для обеспечения высокой доступности между несколькими хостами или регионах с поддержкой автоматического масштабирования.
чтобы получить доступ к вышедших из коробки шаблонов многоуровневая Java приложений наряду с функциональностью управления жизненным циклом приложений, таких как мониторинг, обновление контейнеров, окалины в / из и непрерывной доставки.
No comments:
Post a Comment