Масштабирование и балансировка нагрузки WildFly в OpenShift v3 с Fabric8

Вам понравилась первая поездка с Fabric8 и OpenShift v3? Это еще не все. После того, как мы запустили и запустили первый контейнер WildFly в Kubernetes, без необходимости справляться со всей присущей ему сложностью, я думаю, что пришло время начать масштабирование и балансировку нагрузки WildFly.

Предпосылки

Убедитесь, что у вас запущена полная среда Vagrant, Fabric8, OpenShift v3, Kubernetes. Я рассказал вам об установке в Windows в моем предыдущем сообщении в блоге , но вы также можете попробовать его на Google Container Engine или OpenShift v3 .

Основы

Вчера мы взяли наше локальное приложение Java EE 7 и докеризировали его на основе последней версии jboss / wildfly: 9.0.1.Final. После того, как это было сделано, мы создаем новый myfear / wildfly-test: последний пользовательский образ и помещаем его в реестр докеров, работающих на бродячем образе. Плагин Fabric8 Maven создал JSON Kubernetes для нас и выдвинул его в OpenShift для нас. Все это с помощью удобной и простой в использовании веб-консоли. В этом посте будет снова использован тот же пример Java EE 7, который вы можете найти в моей учетной записи на github.

Масштабирование вашего приложения Java EE в OpenShift с Fabric

Одной из самых больших функций серверов приложений Java EE является масштабирование. Высокая нагрузка на Kubernetes не совсем соответствует тому, как это обычно делалось в прошлом. С помощью Kubernetes вы можете масштабировать узлы и миньоны, контроллеры репликации и модули в соответствии с вашими потребностями. Вместо запуска новых JVM вы запускаете новые экземпляры контейнеров. И мы узнали, что Fabric8 — очень удобный инструмент администрирования для Kubernetes, поэтому мы собираемся немного расширить наше приложение.

Итак, создайте образ докера вашего приложения Java EE 7 и разверните его на Fabric8 с помощью следующих команд maven:

Если это удалось, вы можете получить доступ к своему приложению через http: //myfear-wildfly-test.vagrant.f8/. Сервлет HelloWorld показывает имя хоста и идентификатор POD

Независимо от того, как часто вы нажимаете кнопку обновления в этом пункте, в этом ответе никогда не будет другого идентификатора pod. Конечно, нет, мы работаем только с одним экземпляром до сих пор. Давайте переключимся на консоль Fabric 8 и увеличим масштаб модулей. Перейдите на вкладку «Приложения» и нажмите на маленький зеленый значок в правом нижнем углу вашего приложения. В оверлее измените количество стручков с одного на три.

Через некоторое время изменение отражается на вашей консоли, и через несколько секунд модули загружаются в зеленый цвет:

Вернемся к нашему веб-интерфейсу и пару раз нажмем кнопку «Обновить». Ничего не меняется? Что произошло? Что не так? Позвольте мне немного познакомить вас с архитектурой:

Общая архитектура

Вчерашнее сообщение в блоге оставило ваше удивление? Как все части работали вместе? Вот немного лучший обзор для вас. Оповещение о спойлере: это чрезмерно упрощает архитектуру OpenShift . Пожалуйста, покопайтесь в деталях самостоятельно. Я просто хочу дать вам очень сфокусированный взгляд на масштабирование и балансировку нагрузки с помощью Fabric8 и OpenShift.

Все зависит от маршрутизации OpenShift и управления отдельными модулями. Порты выставляются контейнерами и отображаются через сервисы. И это восходит от клиента к работающему экземпляру. И центральным компонентом, который выполняет маршрутизацию, является HAProxy, очевидно. Что является нормальным пакетом с одним небольшим исключением: у него публичный IP-адрес. Давайте посмотрим, что эта штука делает в OpenShift и как она настроена.

HAProxy как стандартный маршрутизатор на OpenShift

Реализация маршрутизатора по умолчанию в OpenShift — HAProxy. Он использует липкие сессии на основе http-keep-alive. Кроме того, подключаемый модуль маршрутизатора предоставляет имя службы и пространство имен для базовой реализации. Это может использоваться для более сложной конфигурации, такой как реализация таблиц флешек, которые синхронизируются между набором пиров.

Маршрутизатор HAProxy предоставляет веб-прослушиватель для статистики HAProxy. Вы можете просмотреть статистику в нашем примере, перейдя по адресу http: //vagrant.f8: 1936 /. Это немного сложно узнать пароль администратора. Этот пароль и порт настраиваются во время установки маршрутизатора, но их можно найти, просмотрев файл haproxy.conf в контейнере. Все, что вам нужно найти, — это модуль, войдите в него, найдите файл конфигурации и прочитайте пароль. В моем случае это был «6AtZV43YUk».

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

И если вы действительно хотите увидеть, что это на самом деле работает, вам нужно избавиться от липкости с помощью небольшого волшебства скручивания. Если у вас установлен Mysysgit в Windows, вы можете запустить небольшой пакетный скрипт в моем репозитории. Это curl, конечная точка REST, которая выдает POD ID, который обслуживает запрос:

Первые пять запросов всегда возвращают один и тот же идентификатор POD до тех пор, пока не появятся новые POD, и HAProxy начнет отправлять запросы циклически. Если вы хотите повлиять на это поведение, вы можете сделать это. Просто прочитайте больше об администрировании маршрутизатора в документации по администрированию OpenShift . А вот и полная ссылка на интерфейс командной строки «oc» . Если вам нужны идеи, как с помощью oc-клиента узнать о различных объектах и ​​типах, есть полный набор пакетных скриптов в папке fabric8 / bin на github.

Пришло время углубиться в разработку инструментов Fabric8. Оставайтесь любопытными для получения дополнительной информации в следующих сообщениях в блоге.