Monday, 18 April 2016

Docker Java Application With Solr, Mongo, & Cassandra: Design, Deployment, Service Discovery, And Management In Production


Você pode clonar este exemplo "Names Directory" aplicação Java a partir GitHub. Gitclone https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example.git
Um Guia Passo a Passo para Dockerizing e gerenciando uma aplicação Java que consiste em:
  • Apache HTTP Server (httpd) e Nginx ( para balanceamento de carga )
  • JBoss , Tomcat e Jetty ( como o servidor de aplicativos )
  • Solr ( para a pesquisa de texto completo )
  • Mongo , Cassandra , MySQL e do Oracle ( para o banco de dados )
Esta é uma extensão deste projecto ( https://github.com/dchqinc/dchq-docker-java-example ). A aplicação suporta agora Solr para pesquisa de texto completo e ambos Mongo & Cassandra como os bancos de dados suportados.
Para executar e gerenciar os 24 modelos de aplicativos Java no projeto em 13 nuvens diferentes e plataformas de virtualização (incluindo vSphere, OpenStack, a AWS, Rackspace, Microsoft Azure, o Google Compute Engine, DigitalOcean, IBM SoftLayer, etc.), certifique-se que você quer :
fotografia

fundo

Containerizing aplicações corporativas Java ainda é um desafio principalmente porque os quadros de composição de aplicação existentes não abordam dependências complexas, integrações externas ou auto-scaling fluxos de trabalho de pós-disposição. Além disso, o design efêmera de recipientes significa que os desenvolvedores tinham que girar novos contentores e recriar as complexas dependências e integrações externas com cada atualização de versão.
DCHQ, disponível nas versões hospedadas e no local, aborda todos esses desafios e simplifica a conteinerização de aplicações corporativas Java através de um quadro composição aplicação antecipada que se estende Docker Compor com ligações de variáveis ​​de ambiente cross-imagem, script bash plug-ins extensível que pode ser invocado em tempo de requisição ou pós-disposição, e clustering aplicativo para alta disponibilidade em vários hosts ou regiões com suporte para auto escala.
Uma vez que um aplicativo é provisionado, um usuário pode monitorar a CPU, memória, & I / O dos recipientes de funcionamento, receber notificações e alertas, e tenha acesso aos backups de aplicativos, a escala automática de entrada / saída de fluxos de trabalho, e plug-in fluxos de trabalho de execução para atualizar executando recipientes. Além disso, os fluxos de trabalho out-of-box que facilitam a entrega contínua com Jenkins permitir que desenvolvedores para atualizar o Java GUERRA arquivo de um aplicativo em execução sem interromper as dependências e integrações existentes.
Em blogs anteriores, demonstramos a automação de implementação end-to-end de várias aplicações Java (como Pizza Shop and Movie loja de aplicativos) em pilhas de aplicativos baseados em Docker multi-tier em 13 diferentes nuvens e plataformas de virtualização. Para a lista completa destes blogs, você pode visitar esta página: http://dchq.co/docker-java-applications.html
No entanto, muitos usuários ainda estavam confusos sobre alguns dos aspectos fundamentais da modelagem da aplicação. Estas questões incluem:
  • Onde é que estas variáveis ​​de ambiente vêm de no seu modelo de aplicativo baseado em YAML?
  • Como o banco de dados inicializado com os esquemas adequados necessários do meu aplicativo Java?
  • Eu já tenho um plano de implementação para o meu servidor WebLogic Application. Posso executar o meu próprio roteiro para a implantação de uma aplicação Java?
Para responder a estas questões, criamos uma amostra "Names Directory" aplicação Java neste projeto GitHub que pode ser implantado nessas pilhas de aplicação:
  • Apache HTTP Server (httpd) e Nginx (para balanceamento de carga)
  • JBoss, Tomcat e Jetty (como o servidor de aplicativos)
  • Solr (para a pesquisa de texto completo)
  • Mongo, Cassandra, MySQL e Oracle (para o banco de dados)
Neste projecto, iremos fornecer um guia passo-a-passo para a configuração, implementação e gerenciamento de esta aplicação Java usando pilhas diferentes aplicações e em diferentes nuvem de infra-estrutura / virtual.
Nós vamos cobrir:
  • Configurando os arquivos Java para variáveis ​​de ambiente de conexão de banco de dados e Solr
  • Usando o feijão liquibase para inicializar o banco de dados conectado
  • Construir os modelos de aplicações baseadas em YAML que podem re-utilizados em qualquer host Linux rodando em qualquer lugar
  • Provisionamento e auto-dimensionamento da infra-estrutura subjacente em qualquer nuvem (com Rackspace sendo o exemplo neste blog)
  • Implementando o aplicativo Java multi-tier no cluster Rackspace
  • Monitoramento da CPU, memória e I / O dos recipientes de serviço
  • Permitindo que o fluxo de trabalho de entrega contínua com Jenkins para atualizar o arquivo WAR dos aplicativos em execução quando uma compilação é acionado
  • Dimensionando o Cluster Application Server quando o aplicativo está usando a estrutura do Serviço de Descoberta para atualizar o serviço de balanceamento de carga de recursos limitados

Configurar os arquivos Java para banco de dados e Solr Variáveis ​​Connection Ambiente

Você pode clonar este exemplo "Names Directory" aplicação Java a partir GitHub.
Este é o passo mais importante em seu aplicativo Java "Dockerizing". A fim de alavancar as variáveis ​​de ambiente você pode passar ao executar recipientes, você vai precisar para se certificar de que a sua candidatura está configurado de uma maneira que permitirá que você para alterar certas propriedades em tempo de pedido - como:
  • A porta Solr URL e você gostaria de usar
  • O motorista do banco de dados que você gostaria de usar
  • A URL do banco de dados
  • As credenciais de banco de dados
  • Todos os outros parâmetros que você gostaria de mudar em tempo de solicitação (por exemplo, o min / tamanho pool de conexão max, idle timeout, etc.)
Para isso, criamos vários arquivos Java para declarar as variáveis ​​de ambiente que precisamos usar para se conectar ao banco de dados e Solr. Os arquivos Java pode ser encontrado no diretório de configuração:
fotografia
Você vai notar que solr_host e solr_port são declaradas como variáveis ​​de ambiente que você pode passar ao executar o contêiner servidor de aplicativos.

fotografia
Você vai notar que database_driverClassName , database_url , database_username e DATABASE_PASSWORD são declaradas como variáveis ​​de ambiente que você pode passar ao executar o contêiner servidor de aplicativos. Estes serão utilizados para conectar os bancos de dados MySQL, PostgreSQL e Oracle.
fotografia
Você vai notar que mongo_url é declarado como variáveis ​​de ambiente que você pode passar ao executar o contêiner servidor de aplicativos.
No entanto, o MongoConfig.java também é usado para preencher o banco de dados com o esquema certo e mesa na inicialização - se esta tabela não é já encontrados.
fotografia
Você vai notar que cassandra_url é declarado como variáveis ​​de ambiente que você pode passar ao executar o contêiner servidor de aplicativos.

Usando O Liquibase feijão para inicializar o Conectado MySQL, PostgreSQL e bancos de dados Oracle

Normalmente, recomendamos inicializar o esquema de banco de dados como parte da própria implantação de aplicativos Java. Desta forma, você não precisa se preocupar com a manutenção de arquivos SQL separadas que precisam ser executadas no banco de dados separadamente.
No entanto, se você já tem esses arquivos SQL e você ainda preferem executá-los no banco de dados separadamente - então DCHQ podem ajudar a automatizar este processo através do seu quadro plug-in. Você pode se referir a esta seção para obter mais informações.
Inicializar os bancos de dados Mongo e Cassandra é coberto nos arquivos MongoConfig.java e CassandraConfig.java.
Para o MySQL, PostgreSQL e Oracle, a liquibase feijão é usado no arquivo DatabaseConfig.java para verificar a origem de dados e executar instruções SQL de Upgrade.sql. Faixas Liquibase que declarações changelog foram executados contra cada banco de dados.
fotografia
Aqui está o arquivo Upgrade.sql real com as instruções SQL para inicializar o esquema no banco de dados MySQL, PostgreSQL ou Oracle conectado.
fotografia

Construir Os modelos de aplicativo baseado em YAML Isso pode re-utilizado em qualquer Linux host executando qualquer lugar

Uma vez conectado para DCHQ (seja o DCHQ.io hospedado ou versão on-premise), um usuário pode navegar para App & Machine e clique sobre o + botão para criar um novo Docker Compose modelo.
Nós criamos 24 modelos de aplicativos usando as imagens oficiais de Docker Hub para a mesma aplicação Java "Names Directory" - mas para diferentes servidores de aplicativos e bancos de dados.
Os modelos incluem exemplos das seguintes pilhas de aplicativos (para a mesma aplicação Java):
  • Apache HTTP Server (httpd) & Nginx - para balanceamento de carga
  • Solr - para a pesquisa de texto completo
  • Tomcat, Jetty, e JBoss - para os servidores de aplicativos
  • Mongo, Cassandra, MySQL e Oracle XE - para os bancos de dados

Plug-Ins para configurar servidores Web e servidores de aplicações a pedido Tempo & Post-Provision

Em todos estes modelos de aplicativos, você vai notar que alguns dos recipientes estão invocando script bash plug-ins em tempo de requisição, a fim de configurar o contêiner. Esses plug-ins podem ser executadas pós-disposição também.
Esses plug-ins podem ser criados por navegando para plug-ins . Uma vez que o script BASH é fornecido, o agente DCHQ irá executar este script no interior do recipiente . Um usuário pode especificar os argumentos que podem ser substituídas em tempo de pedido e pós-disposição. Qualquer coisa precedida pelo $ sinal é considerado um argumento - por exemplo, $ FILE_URL pode ser um argumento que permite aos desenvolvedores para especificar a URL de download de um arquivo WAR. Isso pode ser substituído na hora da solicitação e pós-provisão quando um usuário deseja atualizar o arquivo Java WAR em um recipiente de execução.
O plug-in ID deve ser fornecida ao definir o modelo de aplicativo baseado em YAML. Por exemplo, para chamar um plug-in script BASH para Nginx, que faria referência ao plug-in ID da seguinte forma:
fotografia
Nos exemplos de modelos, estamos invocando 4 BASH script de plug-ins.
Nginx está invocando um plug-in script que injeta recipiente IP de um dos servidores de aplicativos no arquivo default.conf dinamicamente (ou no momento do pedido). O ID plug-in é 0H1Nk .
Apache HTTP Server (httpd) está invocando um script plug-in que injeta recipiente IP de um dos servidores de aplicativos no arquivo httpd.conf dinamicamente (ou no momento do pedido). O ID plug-in é uazUi .
A beleza das Nginx e Apache HTTP Server (httpd) plug-ins é que eles podem ser executados pós-disposição como parte da escala de cluster de servidor de aplicação ou escalar. Isso torna possível a definição de políticas escala auto que atualizam automaticamente o servidor web (ou balanceador de carga). Isso faz parte do do DCHQ Service Discovery quadro.

Serviço de descoberta com Plug-in Fases do Ciclo de Vida

O ciclo de vida de parâmetro no plug-ins permite que você especifique o estágio exato ou evento para executar o plug-in. Se não ciclo de vida for especificado, por padrão, o plug-in será executar on_create . Aqui estão as etapas do ciclo de vida suportados:
  • on_create - executa o plug-in quando o recipiente criando
  • on_start - executa o plug-in após um recipiente começa
  • on_stop - executa o plug-in antes de um recipiente paradas
  • on_destroy - executa o plug-in antes de destruir um recipiente
  • post_create - executa o plug-in depois do recipiente ser criado e funcionando
  • post_start [: Nó] - executa o plug-in após o outro container inicia
  • post_stop [: Nó] - executa o plug-in depois de um outro recipiente paradas
  • post_destroy [: Nó] - executa o plug-in após o outro recipiente é destruída
  • post_scale_out [: Nó] - executa o plug-in após o outro conjunto de recipientes é escalado para fora
  • post_scale_in [: Nó] - executa o plug-in após o outro conjunto de recipientes é escalado em
Para ter acesso ao servidor Nginx e Apache HTTP (httpd) plug-ins sob a licença EULA, certifique-se que você quer:
Os servidores de aplicação (Tomcat, Jetty, e JBoss) também estão invocando um plug-in script BASH para implementar o arquivo Java WAR do URL GitHub acessível.

Tomcat, JBoss e Jetty está chamando o exato roteiro mesma BASH plug-in (ID plug-in: oncXN ) - exceto o arquivo WAR está sendo implantado em diferentes diretórios:
  • Tomcat - dir = / usr / local / tomcat / webapps / ROOT.war
  • Jetty - dir = / var / lib / Pontão / webapps / ROOT.war
  • JBoss - dir = / opt / jboss / JBoss Application Server / autônomo / implantações / ROOT.war
Solr está invocando um plug-in diferente script BASH (plug-in ID: doX8s ) que irá receber o arquivo names.zip e descompactá-lo em / opt / Solr / servidor / Solr /

CLUSTER_SIZE e Host Parameters Para implantação HA em vários hosts

Você vai notar que o CLUSTER_SIZE parâmetro permite especificar o número de recipientes para lançar (com as mesmas dependências de aplicativos).
O anfitrião parâmetro permite que você especifique o host que você gostaria de usar para implementações de contêineres. Isto é possível se você tiver selecionado Weave como a camada de rede ao criar seus clusters. Dessa forma, você pode garantir a alta disponibilidade para seus clusters de servidor de aplicativos em diferentes hospedeiros (ou regiões) e você pode cumprir com as regras de afinidade para garantir que o banco de dados é executado em um host separado, por exemplo. Estes são os valores suportados para o parâmetro host:
  • host1, host2, host3 , etc. - seleciona uma série aleatoriamente dentro de um centro de dados (ou cluster) para implementações de contêiner
  • Endereço IP 1, endereço IP 2, etc. - permite que o usuário especifique os endereços IP reais a usar para implementações de contêiner
  • Hostname 1, hostname 2, etc. - permite que um usuário para especificar os nomes de host reais a ser usado para implantações de contentores
  • Wildcards (por exemplo, "db- ", ou "app-srv- ") - para especificar os wildcards para uso dentro de um nome de host

Ligações variável de ambiente entre as imagens

Além disso, um usuário pode criar cross-imagem ligações de variáveis ​​de ambiente, fazendo uma referência a variável de ambiente de outra imagem. Neste caso, temos feito várias ligações - incluindo database_url = jdbc: mysql: // {{MySQL | container_hostname}}: 3306 / {{MySQL | MYSQL_DATABASE}} - em que o nome do recipiente de banco de dados é resolvido dinamicamente em tempo de pedido e é utilizado para assegurar que os servidores de aplicação pode estabelecer uma ligação com o banco de dados.
Aqui está uma lista de valores de variáveis ​​de ambiente suportadas:
  • {{alphanumeric | 8}} - cria um 8 caracteres seqüência alfanumérica aleatória. Isso é mais útil para criar senhas aleatórias.
  • {{Image Name | ip}} - permite que você digite o endereço IP do host de um recipiente como um valor para uma variável de ambiente. Isto é muito útil para permitir que a camada de middleware para estabelecer uma ligação com o banco de dados.
  • {{Image Name | container_ip}} - permite que você insira o nome de um recipiente como um valor para uma variável de ambiente. Isto é muito útil para permitir que a camada de middleware para estabelecer uma ligação segura com o banco de dados (sem expor a porta de base de dados).
  • {{Image Name | container_private_ip}} - permite que você insira o endereço IP interno de um recipiente como um valor para uma variável de ambiente. Isto é muito útil para permitir que a camada de middleware para estabelecer uma ligação segura com o banco de dados (sem expor a porta de base de dados).
  • {{Image Name | port_Port Number}} - permite que você digite o número da porta de um recipiente como um valor para uma variável de ambiente. Isto é muito útil para permitir que a camada de middleware para estabelecer uma ligação com o banco de dados. Neste caso, o número de porta especificado deve ser o número da porta interna - ou seja, não a porta externa que é atribuído ao recipiente. Por exemplo, {{PostgreSQL | port_5432}} irá ser traduzido para a porta externa real que vai permitir que a camada de middleware para estabelecer uma ligação com o banco de dados.
  • {{Image Name | Environment Variable Name}} - permite que você insira o valor variável de ambiente de uma imagem em variável de ambiente de outra imagem. Os casos de uso aqui são infinitas - como a maioria das aplicações multi-tier terá dependências cross-imagem.
Aqui estão quatro exemplos. Você pode encontrar personalizar e executar todos os 24 modelos de si mesmo.
fotografia

Multi-Nível Java (Nginx-Tomcat-Solr-Mongo)

fotografia
fotografia

Multi-Nível Java (Nginx-JBoss-Solr-Oracle XE)

fotografia
fotografia

Multi-Nível Java (ApacheLB-Tomcat-Solr-Cassandra)

fotografia
fotografia

Multi-Nível Java (ApacheLB-Jetty-Solr-Mongo)

fotografia
fotografia

Provisioning & Auto-dimensionamento da infra-estrutura subjacente On Any Nuvem

Depois que um aplicativo é salvo, um usuário pode registrar um provedor de nuvem para automatizar o provisionamento e auto-scaling de clusters em 12 pontos finais nuvem diferentes, incluindo VMware vSphere, OpenStack, CloudStack, a Amazon Web Services, Rackspace, Microsoft Azure, DigitalOcean, IBM SoftLayer, o Google Compute Engine, e muitos outros.
Primeiro, um usuário pode registrar um provedor de nuvem para Rackspace (por exemplo), navegando para provedores de nuvem e, em seguida, clicando no + botão para selecionar Rackspace . A API Key Rackspace precisa ser fornecido - que pode ser obtida a partir da seção Configurações da conta do painel de controle Rackspace Cloud.

Um usuário pode, então, criar um cluster com uma política de escala automática para girar automaticamente novas Cloud Servers. Isso pode ser feito ao navegar para   Clusters de página e, em seguida, clicando no + botão. Você pode selecionar uma política de posicionamento por capacidade e, em seguida, Tecer como a camada de rede, a fim de facilitar a comunicação cross-recipiente seguro, protegido por senha em vários hosts dentro de um cluster. A Política de Auto-Scale por exemplo, pode definir o número máximo de VM (ou Cloud Servers) a 10.
Um usuário pode agora fornecer um número de Cloud Servers no cluster recém-criado, quer através do fluxo de trabalho baseado UI ou pela definição de um modelo de máquina de composição baseada em YAML simples que pode ser solicitada a partir da Biblioteca de autoatendimento.
Fluxo de trabalho baseado em UI - Um usuário pode solicitar Servidores Rackspace Nuvem navegando para Máquinas e depois clicar no + botão para selecionar Rackspace . Uma vez que o provedor de nuvem é selecionado, o usuário pode selecionar a região, tamanho e imagem necessários. Portas são abertas por padrão em servidores Rackspace Cloud acomodar alguns dos requisitos de porta (por exemplo, 32.000-59.000 para Docker, 6783 para Weave, e 5672 para RabbitMQ). Um cluster é selecionado e o número de Cloud Servers pode ser especificado.

Template Compose máquina baseada em YAML - Um usuário pode criar primeiro um modelo de máquina de compor para Rackspace navegando para Máquinas e selecionando Máquina Compose .
Aqui está o modelo para solicitar um servidor de 4GB Cloud.

fotografia
Os parâmetros suportados para o modelo de máquina Compose estão resumidos abaixo:
  • Descrição : Descrição do modelo / template
  • instanceType : Nuvem valor específico provedor (por exemplo general1-4)
  • região : Nuvem valor específico provedor (por exemplo IAD)
  • Imagem : Obrigatório - totalmente qualificado imagem ID / nome (por exemplo IAD / 5ed162cc-b4eb-4371-b24a-a0ae73376c73 ou vSphere VM Template nome)
  • nome de usuário : Opcional - apenas para VM Template vSphere nome de usuário
  • password : Opcional - apenas para VM Template vSphere senha criptografada. Você pode criptografar a senha utilizando o endpoint https://www.dchq.io/#/encrypt
  • rede : Opcional - Nuvem valor específico provedor (por exemplo padrão)
  • SecurityGroup : Nuvem valor específico provedor (por exemplo dchq-security-grupo)
  • keyPair : Nuvem valor específico provedor (chave por exemplo, privados)
  • OpenPorts : Opcional - valores de porta separados por vírgulas
  • contar : Nº total de VM, o padrão é 1.
Uma vez que o modelo de máquina Compose é salvo, um usuário pode solicitar esta máquina do Self-Service Biblioteca . Um usuário pode clicar em Personalizar e, em seguida, selecionar o provedor de nuvem e Cluster para usar para provisionar esses servidores Rackspace nuvem.

Implantando O Multi-camada de aplicativo Java no cluster Rackspace

Uma vez que os Cloud Servers são provisionados, um usuário pode implantar um multi-tier, aplicativos Java baseados em Docker sobre as novas Cloud Servers. Isso pode ser feito ao navegar para a biblioteca de Self-Service e em seguida, clicando em Personalizar para solicitar uma aplicação multi-tier.
Um usuário pode selecionar um Tag Ambiente (como DEV ou QE) eo Cluster Rackspace criado antes de clicar em Criar máquinas .

Acessando O In-Browser Terminal para os recipientes de corrida

Um ícone de prompt de comando deve estar disponível ao lado dos nomes dos recipientes na página ao vivo Apps. Isso permite aos usuários entrar no recipiente utilizando um protocolo de comunicação seguro através da fila de mensagens do agente. A lista branca de comandos podem ser definidos pelo inquilino de administração para garantir que os usuários não fazer quaisquer alterações prejudiciais sobre os recipientes de funcionamento.

Para a implantação Tomcat por exemplo, usamos o prompt de comando para certificar-se de que o arquivo WAR Java foi implantado sob a usr / local / tomcat / webapps / /.

Acompanhamento A CPU, memória & S Utilização / dos recipientes de serviço

Uma vez que o aplicativo está instalado e funcionando, nossos desenvolvedores monitorar a CPU, memória, & I / O dos recipientes de funcionamento para receber alertas quando essas métricas exceder um limite pré-definido. Isto é especialmente útil quando nossos desenvolvedores estão realizando testes funcionais e de carga.
Um usuário pode executar a análise de monitoramento histórico e correlacionar questões a atualizações de contentores ou construir implementações. Isso pode ser feito clicando no ações de menu do aplicativo em execução e, em seguida, em Monitoring . Um intervalo de datas personalizado pode ser selecionado para ver CPU, memória e I / O historicamente.


Permitindo que o fluxo de trabalho de Distribuição Contínua Com Jenkins Para atualizar o arquivo WAR do aplicativo em execução Quando uma compilação é acionado

Para os desenvolvedores que desejam seguir o modelo de contentores "imutáveis" por reconstruir imagens Docker contendo o código do aplicativo e girando-se novos recipientes com cada actualização da aplicação, DCHQ fornece um recurso de compilação automatizada que permite aos desenvolvedores criar automaticamente imagens Docker de Dockerfiles ou projetos GitHub privadas que contenham Dockerfiles.

No entanto, muitos desenvolvedores podem desejar atualizar os recipientes de servidor de aplicativos em execução com o último arquivo WAR Java em vez disso. Para isso, DCHQ permite que os desenvolvedores para permitir um fluxo de trabalho de entrega contínua com Jenkins. Isso pode ser feito clicando no ações de menu do aplicativo em execução e, em seguida, selecionar Distribuição Contínua . Um usuário pode selecionar uma instância Jenkins que já foi registrado com DCHQ, o trabalho real no Jenkins que irá produzir o arquivo WAR mais recente, em seguida, um script plug-in para agarrar esta compilação e implantá-lo em um servidor de aplicativos em execução. Uma vez que esta política é salvo, DCHQ vai pegar o mais recente arquivo WAR de Jenkins qualquer momento uma compilação é acionado e implantá-lo no servidor de aplicativos em execução.
Desenvolvedores, como resultado terá sempre o mais recente arquivo WAR Java implantado em seus recipientes de funcionamento em ambientes / Teste desenv.

fotografia

Dimensionando o Tomcat Application Server Cluster e alavancar o Discovery Service Framework para atualizar o Load Balancer

Se o aplicativo em execução torna-se recursos limitados, um usuário pode dimensionar o aplicativo para atender a crescente carga. Além disso, um usuário pode programar a escala para fora durante o horário comercial e da escala em nos fins de semana, por exemplo.
Para dimensionar o cluster de servidores Tomcat 1-2, um usuário pode clicar no ações de menu do aplicativo em execução e, em seguida, selecione Scale Out . Um usuário pode, em seguida, especifique o novo tamanho para o cluster e, em seguida, clique em Executar agora .
Como o fora de escala é executado, o quadro Service Discovery será utilizado para atualizar o balanceador de carga. Um plug-in será automaticamente executado no Apache HTTP Server para atualizar o arquivo httpd.conf do Apache HTTP Server para que ele está ciente do novo servidor de aplicativos acrescentou. Isso é porque nós temos especificado post_scale_out: AppServer como o evento do ciclo de vida para este plugin.
fotografia
Um pedido de tempo-line está disponível para acompanhar todas as mudanças feitas ao pedido de auditoria e diagnósticos. Isso pode ser acessado a partir do menu expansível na parte inferior da página de um aplicativo em execução. Neste caso, o quadro Service Discovery executado o plug-in do servidor Apache HTTP automaticamente logo após o cluster Application Server foi escalado para fora.
Alertas e notificações estão disponíveis para quando recipientes ou anfitriões são para baixo ou quando a CPU & Memória Utilização de qualquer hosts ou recipientes exceder um limite definido.

Conclusão

Containerizing aplicações corporativas Java ainda é um desafio principalmente porque os quadros de composição de aplicação existentes não abordam dependências complexas, integrações externas ou auto-scaling fluxos de trabalho de pós-disposição. Além disso, o design efêmera de recipientes significa que os desenvolvedores tinham que girar novos contentores e recriar as complexas dependências e integrações externas com cada atualização de versão.

DCHQ, disponível nas versões hospedadas e no local, aborda todos esses desafios e simplifica a conteinerização de aplicações corporativas Java através de um quadro composição aplicação antecipada que facilita ligações de variáveis ​​de ambiente cross-imagem, plug-ins extensíveis script que podem ser invocados pelo solicitar tempo ou pós-disposição, e clustering aplicativo para alta disponibilidade em vários hosts ou regiões com suporte para auto escala.

Registe-se já na http://DCHQ.io ou baixar DCHQ On-Premise
para ter acesso aos modelos multi-camada de aplicativo Java out-of-box juntamente com a funcionalidade Application Lifecycle Management como monitoramento, atualizações de contentores, a escala in / out de entrega e contínua.


Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)