Вы можете клонировать этот образец "имена каталогов" Java приложение из GitHub. Gitclone https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example.git
Шаг за шагом руководство для Dockerizing и управления приложения Java, состоящий из:
- HTTP - сервер Apache (HTTPD) и Nginx ( для балансировки нагрузки )
- JBoss , Tomcat и Jetty ( в качестве сервера приложений )
- Solr ( для полнотекстового поиска )
- Монго , Cassandra , MySQL и Oracle ( для базы данных )
Это является продолжением этого проекта ( https://github.com/dchqinc/dchq-docker-java-example~~HEAD=pobj ). Приложение теперь поддерживает Solr для полнотекстового поиска и как Монго и Кассандру , как поддерживаемых баз данных.
Для запуска и управления 24 шаблонов приложений Java в этом проекте на 13 различных облаков и платформ виртуализации ( в том числе Vsphere, OpenStack, AWS, Rackspace, Microsoft Azure, Google Compute Engine, DigitalOcean, IBM SoftLayer и т.д.), убедитесь , что вы либо :
- Скачать DCHQ на предпосылке Standard Edition бесплатно - http://dchq.co/dchq-on-premise-download.html
Задний план
Containerizing Java корпоративных приложений по-прежнему является проблемой в основном потому, что существующие рамки состав приложения не учитывают сложные зависимости, внешние объединения или автоматическое масштабирование рабочих процессов пост-положение. Кроме того, эфемерная конструкция контейнеров означает, что разработчикам пришлось раскручивать новые контейнеры и заново создать сложные зависимости & внешние интеграции с каждым обновлением версии.
DCHQ, доступен в размещенных и на предпосылке версиях, устраняет все эти проблемы и упрощает контейнеризации корпоративных Java-приложений через рамки композиции предварительной заявки, которая простирается Docker Compose с переменными окружения кросс-изображений привязок, расширяемых Баш скрипт плагинов, которые могут вызывается во время запроса или после предоставления, а также применение кластеризации для высокой доступности в нескольких хостов или регионах с поддержкой автоматического масштабирования.
После того, как приложение подготовлено, пользователь может контролировать процессора, памяти и ввода / вывода запущенных контейнеров, получать уведомления & уведомления, и получить доступ к резервным копиям приложений, автоматический масштаб в / из рабочих процессов, а также плагин выполнения рабочих процессов для обновление контейнеров работает. Кроме того, из-из коробки рабочие процессы, которые облегчают непрерывную доставку с Дженкинс позволяют разработчикам обновить WAR файл Java запущенного приложения, не нарушая существующих зависимостей & интеграции.
В предыдущих блогах, мы продемонстрировали автоматизацию развертывания конца в конец различных Java - приложений (например , Pizza Shop и Movie магазин приложений) на многоуровневую Docker основе стеков приложений в 13 различных облаков & платформ виртуализации. Для получения полного списка этих блогов, вы можете посетить эту страницу: http://dchq.co/docker-java-applications.html~~HEAD=dobj
Тем не менее многие пользователи были до сих пор путают на некоторые из фундаментальных аспектов моделирования приложений. Эти вопросы включают в себя:
- Где эти переменные окружения приходят из вашей YAML на основе шаблона приложения?
- Каким образом база данных инициализируется с соответствующими схемами , необходимыми из моего приложения Java?
- У меня уже есть план развертывания для моего сервера WebLogic Application. Могу ли я запустить свой собственный сценарий для развертывания приложения Java?
Для решения этих вопросов, мы создали образец "имен каталогов" Java приложений в этом проекте GitHub, которые могут быть развернуты на этих стеков приложений:
- HTTP-сервер Apache (HTTPD) и Nginx (для балансировки нагрузки)
- JBoss, Tomcat и Jetty (в качестве сервера приложений)
- Solr (для полнотекстового поиска)
- Монго, Cassandra, MySQL и Oracle (для базы данных)
В этом проекте, мы обеспечим руководство шаг за шагом для конфигурирования, развертывания и управления этим приложением Java с использованием различных стеки приложений и на различных облачных / виртуальной инфраструктуры.
Мы рассмотрим:
- Настройка файлов Java для переменных среды подключение к базе данных и Solr
- Использование LiquiBase компонент для инициализации базы данных, подключенный
- Построение шаблонов приложений YAML основе, которые могут повторно использоваться на любом хосте Linux работает в любом месте
- Provisioning & автоматическое масштабирование базовой инфраструктуры на любом облаке (с Rackspace быть примером в этом блоге)
- Развертывание многоуровневой Java приложения на кластере Rackspace
- Мониторинг CPU, памяти и ввода / вывода бегущего контейнеров
- Включение непрерывного рабочего процесса доставки с Дженкинс, чтобы обновить файл WAR из запущенных приложений, когда сборка запускается
- Масштабирование кластера сервера приложений, когда приложение с ограниченными ресурсами с использованием рамок Service Discovery для обновления службы балансировки нагрузки
Конфигурирование файлов Java для баз данных и Solr Переменные среды соединения
Вы можете клонировать этот образец "имена каталогов" приложения Java из GitHub.
Это самый важный шаг в "Dockerizing" приложения Java. Чтобы эффективно использовать переменные окружения, вы можете передать при запуске контейнеров, вам нужно будет убедиться, что ваше приложение настроено таким образом, что позволит вам изменить определенные свойства во время запроса - как:
- Порт URL & Solr вы хотели бы использовать
- Драйвер базы данных вы хотели бы использовать
- URL базы данных
- Учетные базы данных
- Любые другие параметры, которые вы хотели бы изменить во время запроса (например, мин / макс размер пула соединений, тайм-аут простоя и т.д.)
Для достижения этой цели мы создали несколько Java-файлов, чтобы объявить переменные окружения, которые нам необходимо использовать для подключения к базе данных и Solr. В Java-файлы можно найти в каталоге конфигурации:
Давайте сначала examine SolrConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/SolrConfig.java
Вы заметите , что solr_host и solr_port объявлены как переменные окружения , которые можно передать при запуске контейнера сервера приложений.
Теперь давайте examine DatabaseConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/DatabaseConfig.java
Вы заметите , что database_driverClassName , database_url , database_username и database_password объявлены как переменные окружения , которые можно передать при запуске контейнера сервера приложений. Они будут использоваться для подключения баз данных MySQL, PostgreSQL и Oracle.
Далее мы examine MongoConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/MongoConfig.java
Вы заметите , что mongo_url объявлен как переменные окружения , которые можно передать при запуске контейнера сервера приложений.
Однако MongoConfig.java также используется для заполнения базы данных с правой схемы и таблицы при запуске - если эта таблица еще не найден.
И, наконец, мы будем examine CassandraConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/CassandraConfig.java
Вы заметите , что cassandra_url объявлен как переменные окружения , которые можно передать при запуске контейнера сервера приложений.
С помощью LiquiBase Bean для инициализации Connected MySQL, PostgreSQL и базы данных Oracle
Как правило, мы рекомендуем инициализировать схему базы данных, как часть самого развертывания приложений Java. Таким образом, вам не придется беспокоиться о сохранении отдельных файлов SQL, которые должны быть выполнены на базе данных по отдельности.
Однако , если у вас уже есть эти SQL файлы , и вы по- прежнему предпочитают их выполнения на базе данных по отдельности - то DCHQ может помочь вам автоматизировать этот процесс с помощью своего плагина в рамках. Вы можете обратиться к этому разделу для получения дополнительной информации.
Инициализация базы данных Монго и Кассандрой покрыта в файлах MongoConfig.java и CassandraConfig.java.
Для MySQL, PostgreSQL и Oracle, то LiquiBase боб используется в файле DatabaseConfig.java для проверки DataSource и запустить SQL заявления от upgrade.sql. LiquiBase отслеживает , какие заявления журнала изменений забежавших против каждой базы данных.
Вот фактическая upgrade.sql файл с высказываниями SQL для инициализации схемы на подключенной базе данных MySQL, PostgreSQL или Oracle.
Здании YAML основе шаблонов приложений, которые могут повторно использоваться на любом хосте Linux Запуск Anywhere
После входа в систему, чтобы DCHQ (либо принимал DCHQ.io или на предпосылке версии), пользователь может перейти к App & Machine , а затем нажмите на + кнопку , чтобы создать новый Докер Compose шаблон.
Мы создали 24 шаблонов приложений , используя официальные изображения из Докер Hub для той же "имена каталогов" Java приложения - но для разных серверов приложений и баз данных.
Шаблоны включают примеры следующих стеков приложений (для одного приложения Java):
- HTTP - сервер Apache (HTTPD) и Nginx - для балансировки нагрузки
- Solr - для полнотекстового поиска
- Tomcat, Jetty и JBoss - для серверов приложений
- Монго, Cassandra, MySQL и Oracle XE - для баз данных
Подключаемые модули Настройка веб-серверов и серверов приложений На время запроса и пост-Положению
Во всех этих шаблонов приложений, вы заметите, что некоторые из контейнеров вызова Баш скрипт плагины во время запроса, чтобы настроить контейнер. Эти плагины могут быть выполнены пост-положение, а также.
Эти плагины могут быть созданы путем перехода к Плагины . После того , как скрипт BASH предусмотрен, агент DCHQ выполнит этот скрипт внутри контейнера . Пользователь может указать аргументы , которые могут быть переопределены во время запроса и после предоставления. Все , что предшествует $ знак считается аргумент - например, $ FILE_URL может быть аргументом , который позволяет разработчикам указать URL загрузки для файла WAR. Это может быть отменено во время запроса и после предоставления , когда пользователь хочет обновить файл Java WAR на запущенном контейнере.
необходимо предусмотреть при определении шаблона приложения YAML на основе плагин ID. Например, для вызова Баш скрипт плагин для Nginx, мы бы ссылаться на плагин ID следующим образом:
В примерах шаблонов, мы призываете 4 Баш скрипт плагинов.
Nginx является вызовом Баш скрипт плагин, который впрыскивает контейнер IP-адресов серверов приложений в файле default.conf динамически (или во время запроса). Плагин идентификатор 0H1Nk .
HTTP - сервер Apache (HTTPD) является вызовом Баш скрипт плагин, который впрыскивает контейнер IP-адресов серверов приложений в файле httpd.conf динамически (или во время запроса). Плагин идентификатор uazUi .
Красота Nginx и Apache HTTP Server (HTTPD) плагинов в том , что они могут быть выполнены пост-положения в рамках шкалы кластерного сервера приложений в или масштабировать. Это дает возможность определить автоматического масштабирования политики , которая автоматически обновляет веб - сервер (или систему балансировки нагрузки). Это является частью DCHQ в Service Discovery рамках.
Service Discovery с вставными жизненным циклом Этапы
Жизненный цикл параметр плагинов позволяет указать точный этап или событие для выполнения плагина. Если указан не жизненный цикл, то по умолчанию, плагин будет выполнять on_create . Поддерживаются следующие этапы жизненного цикла:
- on_create - выполняет плагин при создании контейнера
- on_start - выполняет плагин после контейнера начинается
- on_stop - выполняет плагин перед тем контейнере остановок
- on_destroy - выполняет плагин перед уничтожением контейнера
- post_create - выполняет плагин после того, как будет создан и запущен контейнер
- post_start [: узел] - выполняет плагин после того, как начинается другой контейнера
- post_stop [: узел] - выполняет плагин еще через контейнерных остановок
- post_destroy [: узел] - выполняет плагин после того, как другой контейнер разрушается
- post_scale_out [: узел] - выполняет плагин после того, как другой кластер контейнеров масштабироваться
- post_scale_in [: узел] - выполняет плагин после того, как другой кластер контейнеров масштабируется
Чтобы получить доступ к серверу Nginx и Apache HTTP (HTTPD) плагинов по лицензии EULA, убедитесь, что вы либо:
- Скачать DCHQ на предпосылке Standard Edition бесплатно - http://dchq.co/dchq-on-premise-download.html
Серверы приложений (Tomcat, Jetty, и JBoss) также вызовом Баш скрипт плагин для развертывания Java-файл WAR из доступных URL GitHub.
Tomcat, JBoss и Причал призываете точно такой же Баш скрипт плагин (подключаемый модуль ID: oncXN ) - за исключением файла WAR становится развернут на различных каталогах:
- Tomcat - реж = / USR / местные / Tomcat / WebApps / ROOT.war
- Причал - реж = / Var / Библиотека / Пристань / WebApps / ROOT.war
- JBoss - реж = / Opt / JBoss / wildfly / автономный / развертываний / ROOT.war
Solr ссылается на действующие иначе Баш скрипт плагин (плагин ID: doX8s ) , который получит файл names.zip и распаковать его в / Opt / Solr / сервер / Solr /
CLUSTER_SIZE и хостовой Параметры для HA развертывания программного обеспечения на нескольких хостов
Вы заметите , что CLUSTER_SIZE параметр позволяет указать количество контейнеров для запуска (с теми же зависимостей приложений).
Хоста параметр позволяет указать хост вы хотели бы использовать для развертывания контейнеров. Это возможно , если вы выбрали Плетение в качестве сетевого уровня при создании кластеров. Таким образом , вы можете обеспечить высокую доступность для ваших кластеров серверов приложений в различных хостов (или регионах) , и вы можете соблюдать правила сродства , чтобы гарантировать , что база данных работает на отдельном хосте, например. Ниже приведены значения , которые поддерживаются для параметра хоста:
- host1, host2, host3 и т.д. - выбирает хост случайным образом в пределах дата-центра (или кластер) для развертывания контейнеров
- IP - адрес 1, 2 IP - адрес и т.д. - позволяет пользователю определить фактические IP - адреса , чтобы использовать для развертывания контейнеров
- Hostname 1, Hostname 2 и т.д. - позволяет пользователю определить фактические имена хостов использовать для развертывания контейнеров
- Подстановочные (например , "db- ", или "приложение-srv- ") - указание использовать групповые символы в имени хоста
Переменной окружения Наручники Across Images
Кроме того, пользователь может создавать кросс-изображения переменных среды привязок, сделав ссылку на переменную окружения другого изображения. В этом случае, мы сделали несколько привязок - в том числе database_url = JDBC: MySQL: // {{MySQL | container_hostname}}: 3306 / {{MySQL | MYSQL_DATABASE}} - в котором имя контейнера базы данных решается динамически во время запроса и используется, чтобы гарантировать, что серверы приложений могут установить соединение с базой данных.
Ниже приведен список поддерживаемых значений переменной окружения:
- {{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}} - позволяет ввести значение переменной окружения изображение в в переменной окружения другого образа. Случаи использования здесь безграничны - как большинство многоуровневых приложений будет иметь зависимости кросс-изображения.
Вот четыре примера. Вы можете найти настройки и запустить все 24 шаблоны самостоятельно.
Многоуровневая Java (Nginx-Tomcat-Solr-Монго)
Многоуровневая Java (Nginx-JBoss-Solr-Oracle XE)
Многоуровневая Java (ApacheLB-Tomcat-Solr-Cassandra)
Многоуровневая Java (ApacheLB-Пристань-Solr-Монго)
Provisioning & Auto-Scaling подстилающей инфраструктуры на любом облаке
После того, как приложение сохраняется, пользователь может зарегистрировать поставщика облако автоматизировать выделение ресурсов и автоматическое масштабирование кластеров на 12 различных облачных конечных точек, включая VMware Vsphere, OpenStack, CloudStack, Amazon Web Services, Rackspace, Microsoft Azure, DigitalOcean, IBM SoftLayer, Google Compute Engine, и многие другие.
Во- первых, пользователь может зарегистрировать поставщика облако для Rackspace (например), перейдя в облачных провайдеров , а затем нажав на + кнопку , чтобы выбрать Rackspace . Rackspace Ключ API должен быть обеспечен , - которые могут быть извлечены из раздела Параметры учетной записи на панели управления Rackspace Cloud.
Затем пользователь может создать кластер с автоматической масштабной политики для автоматического раскрутки новых серверов Облако. Это может быть сделано путем перехода к кластерам страницы , а затем нажав на + кнопке. Вы можете выбрать политику размещения мощностей на основе , а затем Плетение в качестве сетевого уровня для того , чтобы облегчить безопасный, защищенный паролем кросс-контейнеровоз связь между несколькими хостами в кластере. Политика Auto-Scale , например, может установить максимальное количество VM (или Cloud Servers) до 10.
Пользователь может в настоящее время положение несколько облачных серверов на вновь созданном кластере либо через рабочий процесс ПИориентированного или путем определения простого YAML на основе шаблона Machine Compose, которая может быть запрошена из библиотеки самообслуживания.
Рабочий процесс UI на основе - Пользователь может запросить Rackspace Cloud Servers, перейдя в машинах , а затем нажав на + кнопку , чтобы выбрать Rackspace . После того, как поставщик Облако выбран, пользователь может выбрать область, размер и изображение , необходимое. Порты открываются по умолчанию на Rackspace Cloud Servers , чтобы приспособить некоторые требования порта (например 32000-59000 для Докер, 6783 для Weave, и 5672 для RabbitMQ). Кластер затем выбирается и может быть определено количество облачных серверов.
YAML основе Machine Compose Template - пользователь может сначала создать шаблон машины для Compose Rackspace, перейдя машин , а затем выбрав Machine Compose .
Вот шаблон для запроса сервера 4GB Cloud.
Поддерживаются следующие параметры для шаблона машины Compose приведены ниже:
- Описание : Описание Blueprint / шаблона
- instanceType : Облачный провайдер конкретное значение (например , general1-4)
- регион : Облачный провайдер конкретное значение (например , IAD)
- Изображение : обязательно - полное изображение ID / имя (например , IAD / 5ed162cc-b4eb-4371-b24a-a0ae73376c73 или Vsphere VM Имя шаблона)
- Имя пользователя : Необязательно - только для пользователя Vsphere VM Template
- Пароль : Необязательно - только для Vsphere VM Template зашифрованный пароль. Вы можете шифровать пароль с помощью конечной точки https://www.dchq.io/#/encrypt~~HEAD=dobj
- Сеть : Дополнительно - Облако поставщик конкретное значение (например , по умолчанию)
- SecurityGroup : Облачный провайдер конкретное значение (например , dchq-безопасности группа)
- KeyPair : Облачный провайдер конкретное значение (например , секретный ключ)
- openPorts : Необязательно - разделенные запятыми значения портов
- не считать : общее количество ВМ, по умолчанию 1.
После того , как шаблон Machine Compose сохраняется, пользователь может запросить эту машину от Self-Service Library . Пользователь может щелкнуть Настройка , а затем выберите поставщика облако и кластера использовать для инициализации этих Rackspace Cloud Servers.
Развертывание многоуровневой Java приложения, установленного на Rackspace кластера
После того, как серверы облачными подготовлено, пользователь может развернуть многоуровневую, Docker на основе Java-приложений на новых серверах Cloud. Это может быть сделано путем перехода к библиотеке Self-Service, а затем нажав на кнопку Настройка, чтобы запросить применение многоуровневой.
Пользователь может выбрать тег окружающей среды (например , DEV или QE) и кластер , созданный Rackspace , прежде чем нажать на Create машины .
Доступ в-браузер терминалов для функционирования контейнеров
Значок командной строки должна быть доступна рядом с именами контейнеров "на странице Живая Apps. Это позволяет пользователям входить в контейнер с помощью защищенного протокола связи через очереди сообщений агента. Белый список команд может быть определен арендатором администратора, чтобы гарантировать, что пользователи не делают никаких вредных изменений на подножку контейнеров.
Для развертывания Tomcat, например, мы использовали командную строку, чтобы убедиться, что файл WAR Java был развернут под / USR / местные / TOMCAT / WebApps / директории.
Мониторинг процессора, памяти и утилизации I / O бегущего Контейнеры
После того, как приложение и работает, наши разработчики мониторинг процессора, памяти и ввода / вывода запущенных контейнеров для получения оповещений, когда эти показатели превышают заранее определенный порог. Это особенно полезно, когда наши разработчики выполняют функциональное и нагрузочное тестирование.
Пользователь может выполнить исторический анализ мониторинга и соотнести проблемы с обновлением контейнера или построить развертываний. Это можно сделать, нажав на действия меню запущенного приложения , а затем по мониторингу . Диапазон дат можно выбрать для просмотра процессора, памяти и ввода / вывода исторически.
Включение непрерывного рабочего процесса доставки с Jenkins Чтобы обновить файл WAR бегущего приложения Когда сборки Срабатывает
Для разработчиков, желающих следовать модели "неизменные" контейнеров путем восстановления изображений Docker, содержащих код приложения и раскручивается новые контейнеры с каждым обновлением приложения, DCHQ обеспечивает автоматизированную функцию сборки, которая позволяет разработчикам автоматически создавать Docker изображения из Dockerfiles или частных проектов GitHub, содержащих Dockerfiles.
Тем не менее, многие разработчики , возможно , пожелают обновить сервер контейнеров запущенного приложения последней Java WAR файл вместо. Для этого, DCHQ позволяет разработчикам включить непрерывный рабочий процесс поставки с Дженкинс. Это можно сделать, нажав на действия меню запущенного приложения , а затем выберите непрерывной доставки . Пользователь может выбрать экземпляр Дженкинс , который уже зарегистрирован в DCHQ, фактическое работы на Дженкинс , который будет производить последнюю версию файла WAR, а затем Баш скрипт плагин , чтобы захватить эту сборку и развернуть его на работающем сервере приложений. После того, как эта политика будет сохранена, DCHQ будет взять последнюю версию файла WAR из Дженкинс любое время , когда сборка срабатывает и развернуть его на работающем сервере приложений.
Разработчики, как результат всегда будет иметь последнюю версию файла Java WAR развернут на своих текущих контейнеров в средах / TEST DEV.
Горизонтальное масштабирование котом Application Server Cluster и использовать Служба обнаружения Framework обновить балансировки нагрузки
Если работающее приложение становится ограниченным ресурсом, пользователь может масштабировать приложение для удовлетворения возрастающей нагрузкой. Кроме того, пользователь может планировать масштабирование в рабочее время и в масштабе в выходные дни, например.
Для того, чтобы масштабировать кластер серверов Tomcat от 1 до 2, пользователь может нажать на действия меню запущенного приложения , а затем выберите Scale Out . Затем пользователь может указать новый размер кластера , а затем нажмите на Run Now .
По мере того как масштабирование выполняется, структура Service Discovery будет использоваться для обновления балансировки нагрузки. Плагин будет автоматически выполняться на Apache HTTP Server , чтобы обновить файл httpd.conf Apache HTTP Server, так что это известно о новом сервере приложений добавлен. Это потому , что мы определили post_scale_out: AppServer как событие жизненным циклом для этого плагина.
An application time-line is available to track every change made to the application for auditing and diagnostics. This can be accessed from the expandable menu at the bottom of the page of a running application. In this case, the Service Discovery framework executed the Apache HTTP Server pluginautomatically right after the Application Server cluster was scaled out.
Предупреждения и уведомления доступны, когда контейнеры или хосты вниз или, когда ЦП и памяти Использование либо узлов или контейнеров превышает определенный порог.
Вывод
Containerizing Java корпоративных приложений по-прежнему является проблемой в основном потому, что существующие рамки состав приложения не учитывают сложные зависимости, внешние объединения или автоматическое масштабирование рабочих процессов пост-положение. Кроме того, эфемерная конструкция контейнеров означает, что разработчикам пришлось раскручивать новые контейнеры и заново создать сложные зависимости & внешние интеграции с каждым обновлением версии.
DCHQ, доступен в размещенных и на предпосылке версиях, устраняет все эти проблемы и упрощает контейнеризации корпоративных Java-приложений с помощью передовой основы композиции приложений, что облегчает переменных среды кросс-изображений привязок, расширяемый Баш скрипт плагины, которые могут быть вызваны в запросить время или пост-положения, а также применение кластеризацию для обеспечения высокой доступности между несколькими хостами или регионах с поддержкой автоматического масштабирования.
чтобы получить доступ к вышедших из коробки шаблонов многоуровневая Java приложений наряду с функциональностью управления жизненным циклом приложений, таких как мониторинг, обновление контейнеров, окалины в / из и непрерывной доставки.
No comments:
Post a Comment