Hola Habr!
El discurso de Sebastian Dashner en una reunión de Java en la oficina de IBM en Moscú (encontró un
registro de un rendimiento similar) me llevó a comenzar a conocer servidores de aplicaciones livianos, en particular, con OpenLiberty. Y luego pensé:
- ¿Cuáles son los beneficios de un servidor de aplicaciones ligero?
- ¿Cómo cambia la especificidad del trabajo cuando se usan?
- ¿Por qué empacar un servidor de aplicaciones en un contenedor?
Respondiendo a estas preguntas, noté que no hay mucha información pública sobre este tema, así que decidí recopilarla y sistematizarla aquí.
Publico los resultados debajo del corte.
¿Cuáles son los beneficios de un servidor de aplicaciones ligero?
Anteriormente, los servidores de aplicaciones Java EE empresariales (como JBoss AS, Oracle WebLogic, IBM WebSphere AS) se consideraban un diseño pesado y engorroso, especialmente en lo que respecta a los tiempos de inicio y despliegue. Pero la tecnología en la nube está capturando una parte cada vez más grande de la industria y los requisitos del servidor de aplicaciones están cambiando.
Y ahora, en lugar de servidores de aplicaciones corporativos con todas las funciones, vienen servidores de aplicaciones rápidos, modulares y pequeños enfocados en una tarea específica:
Thorntail ,
Payara Micro - los hermanos menores WildFly y Payara;
Meecrowave es un
servidor ligero JAX-RS + CDI + JSON,
KumuluzEE es un servidor que le permite extender Java EE utilizando Node.js, Go y otros.
Esta lista también incluye OpenLiberty, un servidor de aplicaciones de código abierto (distribuido según EPL-1.0) que admite los últimos estándares Java EE / Microprofile, en los que se ejecuta WebSphere Liberty.
Características de EPL-1.0 de un vistazo (Eclipse Public License Version 1.0)EPL 1.0 se basa en CPL y no es compatible con la GPL, le permite cumplir con otras licencias y patentes que se utilizan en el trabajo, y proporciona el derecho de licenciar el producto bajo cualquier otra licencia, se debe incluir una copia de la licencia en todas las copias del programa.
Las adiciones al producto principal se pueden licenciar por separado e incluso bajo una licencia comercial. Sin embargo, los cambios y adiciones que son trabajos derivados deben tener licencia bajo la misma licencia EPL, que requiere que abra el código fuente.
Asociar un proyecto de software con código protegido por la licencia EPL (por ejemplo, usar este código como biblioteca), en general, no convierte este proyecto en un trabajo derivado y no impone las obligaciones correspondientes.
Un Miembro que incluye el Programa en una cotización debe hacerlo de tal manera que se evite la responsabilidad potencial para otros Miembros. (renuncia expresamente a cualquier garantía o responsabilidad en nombre de todos los autores)
Por ejemplo: Un participante puede incluir el Programa en una cotización, producto X. Entonces este participante es un participante Comercial. Si este Comerciante hace reclamos sobre velocidad u ofrece garantías para el Producto X, estas afirmaciones y ofertas son responsabilidad personal del Comerciante. Bajo esta sección, el Miembro Comercial debe proteger a otros Miembros de reclamos relacionados con el desempeño y las garantías, y si el tribunal requiere que cualquier otro Miembro pague cualquier daño resultante, el Miembro Comercial debe pagar estas pérdidas.
Veamos qué beneficios podemos obtener al implementar la aplicación en un contenedor con OpenLiberty. (Debe tener instalada cualquier versión de java, se deben realizar más pasos mientras esté en el directorio wlp)
Velocidad:
La velocidad es el indicador más importante para una aplicación en la nube, porque para que una aplicación en la nube pueda escalar, administrar y hacer frente rápidamente a la carga creciente, debe iniciarse en segundos. Un servidor de aplicaciones liviano puede hacer esto. Para verificar,
descargue el servidor OpenLiberty y ejecute 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 .
Modularidad y flexibilidad.
La mayoría de las aplicaciones no necesitan Java EE en su conjunto, pero requieren un conjunto dedicado de estándares, que se utilizan con mayor frecuencia en aplicaciones empresariales. Gracias a OSGI, podemos elegir el conjunto de estándares Java EE y / o MicroProfile que necesitamos, ignorando todo lo demás.
Por ejemplo, declare JAX-RS de Java EE y mpHealth de Microprofile agregando un par de líneas al bloque de FeatureManager usr / server / 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>
Actualización dinámica
Durante el desarrollo, el código y la configuración del programa cambian constantemente.
El servidor de aplicaciones está configurado para monitorear los cambios y, si es necesario, reconfigura e implementa la aplicación sobre la marcha. Por ejemplo, una reacción a los cambios recientes:
[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 .
Tamaño de imagen y montaje
El tamaño del servidor de aplicaciones ha disminuido significativamente y ahora le permite implementar
cada aplicación en un servidor de aplicaciones separado para empaquetarlos en contenedores, brindando la mayor flexibilidad. Además, desde la imagen consta de capas, al volver a ensamblar y distribuir artefactos, solo se copia la capa de la aplicación, el sistema operativo, el tiempo de ejecución y el servidor de aplicaciones se almacenan en caché.
Dockerhub tiene imágenes preconstruidas que contienen un servidor OpenLiberty preconfigurado. Usaremos uno de ellos y crearemos un Dockerfile:
FROM open-liberty COPY usr/servers/defaultServer /opt/ol/wlp/usr/servers/defaultServer ENTRYPOINT ["/opt/ol/wlp/bin/server", "run"] CMD ["defaultServer"]
Ensamblemos la imagen:
docker build -t app .
Ejecútelo como un contenedor:
docker run -d --name app -p 9080:9080 app
Verifique el resultado
http: // localhost: 9080 / health /
Para detener el contenedor:
docker stop app
Hay muchos escenarios adicionales para usar el contenedor, y en general, esta es una ocasión para artículos individuales, así que volvamos a las preguntas.
¿Cómo está cambiando la especificidad del trabajo?
Paquete paquete
La imagen del contenedor debe recopilarse solo una vez y luego ejecutarse en todos los entornos. Por lo tanto, se recomienda recopilar cada aplicación junto con el servidor de aplicaciones. Esto simplifica el ciclo de vida y la implementación de aplicaciones y se adapta perfectamente al mundo moderno de la tecnología de contenedores.
Asamblea
Ahora ya no es necesario empaquetar diferentes bloques técnicos en archivos separados. Toda la lógica empresarial, junto con los servicios web y la funcionalidad de extremo a extremo, está empaquetada en un único archivo war. Esto simplifica enormemente la instalación del proyecto, así como el procedimiento de montaje. Ya no tiene que empaquetar la aplicación en varios niveles de jerarquía, luego descomprimirla nuevamente en una instancia de servidor.
Lanzamiento
Tanto el servidor de aplicaciones como la propia aplicación se agregan a la imagen durante el proceso de compilación. La configuración potencial de las fuentes de datos, unidades o módulos de servidor también se especifica durante el proceso de compilación agregando archivos de configuración especializados. Todas las diferencias en la configuración deben gestionarse no desde dentro de la aplicación, sino desde el exterior. Por lo tanto, la aplicación no debe implementarse en un contenedor que ya se está ejecutando, sino que debe agregarse en la etapa de ensamblaje de imágenes en el directorio de implementación automática para iniciarla cuando se inicia el contenedor.
Extensión de funcionalidad
Los contenedores, los sistemas de implementación y escalado, los servicios de monitoreo y las cuadrículas de servicios nos dieron la oportunidad de configurar la detección, monitoreo, administración, autenticación, escalado, rastreo, estabilidad en la parte superior de la aplicación, transfiriendo de manera transparente una gran cantidad de lógica a otro nivel, facilitando la aplicación y simplificando su desarrollo.
¿Por qué empacar un servidor de aplicaciones en un contenedor?
En primer lugar, al empaquetar un servidor de aplicaciones en un contenedor, le da a cada equipo la oportunidad de configurar de forma independiente su servidor de aplicaciones y enfocarse en implementar funciones, ahorrando tiempo a los desarrolladores en operaciones manuales, middleware y varias aprobaciones.
Como beneficio adicional, tiene la oportunidad de disfrutar plenamente de los beneficios de los contenedores y todas las herramientas construidas a su alrededor. La aplicación es fácil de administrar y escalar, actualizar y automatizar el ensamblaje y la implementación de artefactos con cero tiempo de inactividad.
Encontrarás más práctica aquí.Además de la
documentación , el sitio web del proyecto tiene una gran cantidad de tutoriales: cómo crear aplicaciones web con maven / gradle, empaquetar e implementar aplicaciones, implementar y configurar microservicios en kubernetes, administrar el tráfico con istio e implementar en
IBM Cloud desde otros proveedores de nube populares y mucho mas
Sebastian Dashner (entusiasta de Java y OSS, campeón de Java, miembro de IBMer, JCP, comitente de Yakarta EE) publica artículos útiles sobre cómo usar OpenLiberty, como el
monitoreo de Open Liberty con Prometheus y Grafana , en su
blog , y su libro
Architecting Modern Java Aplicaciones de EE se utilizó en la preparación de este artículo.
Liberty-maven-plugin (alternativa a
gradle ) puede simplificar enormemente su trabajo. Por cierto, los manuales tienen buenos ejemplos de su uso.
También puedes contribuir al
proyecto .