Automation implantação de Docker WebLogic Cluster Em Qualquer Nuvem
fundo
desenvolvedores Java e profissionais DevOps têm lutado muito para automatizar a implantação de aplicações corporativas Java. A natureza complexa dessas aplicações normalmente significava que as dependências de aplicativos e integrações externas tiveram que ser re-configurado cada vez que um aplicativo foi implantado em ambientes / Teste desenv.
Muitas soluções anunciado a mensagem "modelar uma vez, implemente em qualquer lugar" para implantações de aplicativos. Na realidade, no entanto, havia sempre meandros que seria muito difícil voltar a usar um modelo de aplicação em tanto um ambiente virtual on-premise vSphere e um ambiente AWS, por exemplo.
Mais recentemente, no entanto, recipientes Docker popularizou a idéia de componentes de aplicações de embalagem em Linux Os recipientes que podem ser implantados exatamente o mesmo em qualquer máquina Linux, enquanto Docker motor está instalado.
Infelizmente 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 realizar dia 2-operações como backups agendados, Container Updates usando script bash plug-ins, e Scale In / out. 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.
Neste blog, vamos falar sobre a automação de implementação end-to-end de um WebLogic cluster baseado no Docker. Nós vamos cobrir:
- Construir o modelo de aplicativo para WebLogic Cluster que podem re-usado em qualquer máquina 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 WebLogic Cluster nos Servidores Rackspace nuvem
- Implementando o Carrinho de arquivo Java WAR no Server Admin
- Acessando o Terminal no navegador para Running Containers
- 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
- Monitoramento da CPU, memória e I / O dos recipientes de serviço
Construir O modelo de aplicação para o Oracle WebLogic 12c Cluster
O nce conectado para DCHQ (seja o DCHQ.io hospedado ou on-premise versão), um usuário pode navegar para App & Machine e clique sobre o + botão para criar um novo Docker Compose modelo.
Nós criamos um modelo de aplicação WebLogic Cluster usando uma imagem personalizada nós construímos alavancar a imagem do Radu Dobrinescu (radudobrinescu / wls12c: 2,0).
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). Nós usamos isso para definir o tamanho de cluster Servidor Gerenciado.
O anfitrião parâmetro permite que você especifique o host que você gostaria de usar para implementações de contêineres. 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
- <IP endereço 1, endereço IP 2, etc.> - permite que um usuário para especificar os endereços IP real para usar para implementações de contêiner
- <Hostname 1, Host 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
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, nós fizemos uma ligação neste caes: admin_hostname = {{AdminServer | ip}} - em que o IP do host Server Admin é resolvido dinamicamente em tempo de solicitação e é usado para garantir que os Servidores Gerenciados pode estabelecer uma conexão com o servidor admin.
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 do contêiner 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.
A construção real da imagem de encaixe WebLogic pode ser automatizado através DCHQ bem. Um usuário pode clicar em construir a imagem e clique no botão +. Um usuário pode criar uma imagem usando um um projeto GitHub público / privado que tem um Dockerfile Dockerfile ou.
A imagem que criamos para WebLogic foi construído usando a imagem do Radu Dobrinescu (radudobrinescu / wls12c: 2,0) ( https://hub.docker.com/r/radudobrinescu/wls12c/ ). Fizemos um par de modificações para a imagem em nossa própria Dockerfile e, em seguida, empurrou a nova imagem para o nosso próprio repositório (dchq / weblogic: mais recente). A construção de imagens pode ser programado usando uma expressão cron. Além disso, um usuário pode usar {{}} timestamp no nome da marca, a fim de criar nomes de marcas exclusivas com cada nova compilação. Dessa forma, o usuário pode reverter para imagens mais antigas para backup.
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 13 pontos finais nuvem diferentes, incluindo vSphere, OpenStack, CloudStack, a Amazon Web Services, Rackspace, Microsoft Azure, DigitalOcean, HP Pública nuvem, 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.
Um usuário pode agora fornecer um número de Cloud Servers no cluster recém-criado ao navegar 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. Um cluster é selecionado e o número de Cloud Servers pode ser especificado.
Implementando o WebLogic Cluster para os servidores Rackspace nuvem
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 Executar.
Uma vez que o Cluster WebLogic é provisionado, um usuário pode acessar o Admin Console Server para se certificar de que os Servidores Gerenciados são descobertos e em execução. O URL seria http: // <admin_server_host_ip>: 7001 / console . As credenciais padrão seria weblogic / welcome1.
Implantando O Carrinho arquivo Java WAR usando a estrutura do Plug-In
Uma vez que o Cluster WebLogic está instalado e funcionando, o usuário pode executar um plug-in script BASH para implantar um Java GUERRA arquivo em um dos servidores. Neste caso, nós simplesmente invocado um plug-in para implantar o aplicativo de carrinho de compras no Server Admin. Do ações de menu, o usuário pode selecionar os plug-ins e, em seguida, selecione o recipiente (s) em que o plug-in será executado. Um usuário pode então procurar o plug-in e substituir os argumentos expostos.
Neste simples plug-in, nós estamos pegando três arquivos de um servidor remoto, acessível, a fim de implantar o aplicativo.
- deploy.py
- deploy_app.sh
- shoppingcart.war
Aqui estão os arquivos usados:
deploy.py
---------------------
deploy_app.sh
---------------------
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.
Neste caso, usamos a linha de comandos para se certificar de que o arquivo deploy.py foi efectivamente transferido para o Server Admin. Ao fazer uma simples /oracle/fmwhome/wlst_custom/deploy.py cat - fomos capazes de verificar se o arquivo realmente existe nesse recipiente.
Em seguida, acessou o Admin Console Server e navegado para implantações para garantir que a aplicação Compras foi de fato implantado.
Finalmente, acessado a aplicação real em http: // <admin_server_host_ip>: 7001 / shoppingcart
Acompanhamento A CPU, memória e utilização de I / O do RunningContainers
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.
Observe que o plug-in script BASH pode ser personalizado para garantir que a sequência correta de passos é levado para o WebLogic Server. Por exemplo, um usuário pode desejar usar um plano de implementação específico ou executar alguns scripts antes un-Implantação e, em seguida, implantar o novo arquivo WAR.
Desenvolvedores, como resultado terá sempre o mais recente arquivo WAR Java implantado em seus recipientes de funcionamento em ambientes / Teste desenv.
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.
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.
No comments:
Post a Comment