Como as especificidades do trabalho com servidores de aplicativos estão mudando usando o exemplo OpenLiberty

Olá Habr!

O discurso de Sebastian Dashner em um encontro em Java no escritório da IBM em Moscou (encontrou um registro de desempenho semelhante) me levou a começar a conhecer meus servidores de aplicativos leves, em particular o OpenLiberty. E então eu pensei:

1. Quais são os benefícios de um servidor de aplicativos leve?
2. Como a especificidade do trabalho muda ao usá-los?
3. Por que empacotar um servidor de aplicativos em um contêiner?

Respondendo a essas perguntas, notei que há pouca informação pública sobre esse tópico, então decidi coletá-las e sistematizá-las aqui.

Eu posto os resultados sob o corte.

Quais são os benefícios de um servidor de aplicativos leve?

Anteriormente, os servidores de aplicativos Java EE corporativos (como JBoss AS, Oracle WebLogic e IBM WebSphere AS) eram considerados um design pesado e pesado, especialmente quando falamos sobre tempos de inicialização e implantação. Mas a tecnologia em nuvem está capturando uma parte cada vez maior do setor e os requisitos do servidor de aplicativos estão mudando.

E agora, no lugar de servidores de aplicativos corporativos completos, vêm servidores de aplicativos pequenos, rápidos e modulares, focados em uma tarefa específica: Thorntail , Payara Micro - os irmãos mais novos WildFly e Payara; O Meecrowave é um servidor JAX-RS + CDI + JSON leve , o KumuluzEE é um servidor que permite estender o Java EE usando Node.js, Go e outros.

Esta lista também inclui o OpenLiberty - um servidor de aplicativos de código aberto (distribuído de acordo com EPL-1.0) que suporta os mais recentes padrões Java EE / Microprofile, nos quais o WebSphere Liberty é executado.


Vamos ver quais benefícios podemos obter ao implantar o aplicativo em um contêiner com o OpenLiberty. (Você deve ter qualquer versão do java instalada, etapas adicionais devem ser executadas enquanto estiver no diretório wlp)

Velocidade:

A velocidade é o indicador mais importante para um aplicativo em nuvem, porque, para que um aplicativo em nuvem seja escalado, gerencie e lide rapidamente com a carga crescente, ele deve ser iniciado em segundos. Um servidor de aplicativos leve pode fazer isso. Para verificar, faça o download do servidor OpenLiberty e execute bin / server run ( lista completa de comandos ):

$ bin/server run  defaultServer (Open Liberty 19.0.0.6/wlp-1.0.29.cl190620190617-1530)  Java HotSpot(TM) 64-Bit Server VM  1.8.0_212-b10 (ru_US) [AUDIT ] CWWKE0001I:  defaultServer . [AUDIT ] CWWKZ0058I:   dropins  . [AUDIT ] CWWKF0012I:     : [el-3.0, jsp-2.3, servlet-3.1]. [AUDIT ] CWWKF0011I:  defaultServer      .  defaultServer   1,709 . 

Modularidade e flexibilidade

A maioria dos aplicativos não precisa do Java EE como um todo, mas requer um conjunto dedicado de padrões, usado com mais freqüência em aplicativos corporativos. Graças à OSGI, podemos escolher o conjunto de padrões Java EE e / ou MicroProfile que precisamos, ignorando todo o resto.

Por exemplo, declare JAX-RS do Java EE e mpHealth do Microprofile adicionando algumas linhas ao featureManager bloqueie usr / servers / serverName / serverName /server.xml

 <?xml version="1.0" encoding="UTF-8"?> <server description="new server"> <!-- Enable features --> <featureManager> <feature>jsp-2.3</feature> <feature>mpHealth-1.0</feature> <feature>jaxrs-2.1</feature> </featureManager> <!-- To access this server from a remote client add a host attribute to the following element, eg host="*" --> <httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" /> <!-- Automatically expand WAR files and EAR files --> <applicationManager autoExpand="true"/> </server> 

Atualização dinâmica

Durante o desenvolvimento, o código e a configuração do programa mudam constantemente.
O servidor de aplicativos está configurado para monitorar alterações e, se necessário, reconfigura e implanta o aplicativo rapidamente. Por exemplo, uma reação a mudanças recentes:

 [AUDIT ] CWWKG0016I:    . [AUDIT ] CWWKG0017I:      0,475 . [AUDIT ] CWWKF0012I:     : [cdi-2.0, jaxrs-2.1, jaxrsClient-2.1, jndi-1.0, json-1.0, jsonp-1.1, mpHealth-1.0, servlet-4.0]. [AUDIT ] CWWKF0013I:     : [servlet-3.1]. [AUDIT ] CWWKF0008I:     0,476 . 

Tamanho e montagem da imagem

Os tamanhos dos servidores de aplicativos diminuíram significativamente e agora permitem implantar
cada aplicativo em um servidor de aplicativos separado para embalá-los em contêineres, oferecendo a maior flexibilidade. Além disso, desde a imagem consiste em camadas, ao remontar e distribuir artefatos, apenas a camada do aplicativo é copiada, o SO, o tempo de execução e o servidor de aplicativos são armazenados em cache.

O Dockerhub possui imagens pré-construídas que contêm um servidor OpenLiberty pré-configurado. Usaremos um deles e criaremos um Dockerfile:

 FROM open-liberty COPY usr/servers/defaultServer /opt/ol/wlp/usr/servers/defaultServer ENTRYPOINT ["/opt/ol/wlp/bin/server", "run"] CMD ["defaultServer"] 

Vamos montar a imagem:

 docker build -t app . 

Execute-o como um contêiner:

 docker run -d --name app -p 9080:9080 app 

Verifique o resultado http: // localhost: 9080 / health /



Para parar o contêiner:

 docker stop app 

Existem muitos outros cenários para o uso do contêiner e, em geral, esta é uma ocasião para artigos individuais, portanto, voltemos às perguntas.

Como a especificidade do trabalho está mudando?

Pacote

A imagem do contêiner deve ser coletada apenas uma vez e, em seguida, executada em todos os ambientes. Portanto, é recomendável coletar cada aplicativo junto com o servidor de aplicativos. Isso simplifica o ciclo de vida e a implantação de aplicativos e se encaixa perfeitamente no mundo moderno da tecnologia de contêineres.

Assembléia

Agora não é mais necessário agrupar blocos técnicos diferentes em arquivos separados. Toda a lógica de negócios, juntamente com serviços da Web e funcionalidade de ponta a ponta, é compactada em um único arquivo de guerra. Isso simplifica bastante a instalação do projeto, bem como o procedimento de montagem. Você não precisa mais compactar o aplicativo em vários níveis hierárquicos e descompactá-lo novamente em uma instância do servidor.

Lançamento

O servidor de aplicativos e o próprio aplicativo são adicionados à imagem durante o processo de construção. A configuração potencial de fontes de dados, unidades ou módulos de servidor também é especificada durante o processo de construção, adicionando arquivos de configuração especializados. Todas as diferenças na configuração devem ser gerenciadas não de dentro do aplicativo, mas de fora. Portanto, o aplicativo não deve ser implantado em um contêiner já em execução, mas deve ser adicionado a ele no estágio de montagem da imagem no diretório de implantação automática para iniciá-lo quando o contêiner for iniciado.

Extensão de funcionalidade

Contêineres, sistemas de implantação e dimensionamento, serviços de monitoramento e grades de serviço nos deram a oportunidade de configurar a detecção, o monitoramento, o gerenciamento, a autenticação, o dimensionamento, o rastreamento, a estabilidade no topo do aplicativo, transferindo de forma transparente uma grande quantidade de lógica para outro nível, facilitando o aplicativo e simplificando seu desenvolvimento.

Por que empacotar um servidor de aplicativos em um contêiner?

Primeiro, ao empacotar um servidor de aplicativos em um contêiner, você oferece a cada equipe a oportunidade de configurar independentemente seu servidor de aplicativos e se concentrar na implementação de funções, economizando tempo dos desenvolvedores em operações manuais, middleware e várias aprovações.

Como bônus, você tem a oportunidade de desfrutar plenamente dos benefícios dos contêineres e de todas as ferramentas criadas em torno deles. O aplicativo é fácil de gerenciar e dimensionar, atualizar e automatizar a montagem e a implantação de artefatos com tempo de inatividade zero.