Fondo
Los desarrolladores de Java y profesionales DevOps han luchado durante mucho tiempo para automatizar el despliegue de aplicaciones empresariales Java. La compleja naturaleza de estas aplicaciones por lo general significa que las dependencias de aplicaciones e integraciones externas tuvieron que ser re-configurado cada vez que una aplicación se ha desplegado en entornos / PRUEBA DEV.
Muchas soluciones anuncian el mensaje "modelo una vez, desplegar en cualquier lugar" para la implementación de aplicaciones. En realidad, sin embargo, siempre había complejidades que hacía muy difícil volver a utilizar una plantilla de aplicación en todos a la vez un entorno virtual de vSphere en las instalaciones y un entorno de AWS, por ejemplo.
Más recientemente, sin embargo, los contenedores Docker popularizaron la idea de componentes de aplicaciones de envasado en recipientes de Linux que puede ser desplegado exactamente igual en cualquier host Linux, siempre y cuando se instala acoplable motor.
Desafortunadamente contenerización de aplicaciones empresariales Java sigue siendo un desafío sobre todo porque los marcos de composición de aplicaciones existentes no abordan dependencias complejas, integraciones externas o auto-escala flujos de trabajo de post-prestación. Por otra parte, el diseño efímero de contenedores significa que los desarrolladores tenían que girar nuevos contenedores y volver a crear las complejas dependencias y integraciones externas con cada actualización de versión.
DCHQ, disponible en versiones alojados y en las instalaciones, se dirige a todos estos retos y simplifica la contenerización de aplicaciones empresariales Java a través de un marco de composición solicitud previa que se extiende acoplable Componer con asociaciones de variables de entorno-imagen Cruz, extensibles escritura del golpe plug-ins que pueden ser invocado durante la petición o posterior a la disposición, y la agrupación de aplicaciones de alta disponibilidad a través de múltiples hosts o regiones con soporte para escalado automático.
Una vez que se aprovisiona una aplicación, un usuario puede monitorizar la CPU, memoria, I / O y de los contenedores de funcionamiento, recibir notificaciones y alertas, y realizar dia-2 operaciones como copias de seguridad programadas, Recipiente actualizaciones usando escritura del golpe de plug-ins, y la Escala Dentro fuera. Por otra parte, los flujos de trabajo fuera de la caja que faciliten la entrega continua con Jenkins permiten a los desarrolladores para actualizar el archivo WAR de Java de una aplicación que se ejecuta sin interrumpir las dependencias y las integraciones existentes.
En este blog, vamos a ir sobre la automatización de extremo a extremo de una aplicación Java llamada Pizza Shop que se implementa en dos pilas de aplicación en contenedores diferentes:
- Nginx (para el equilibrio de carga), en clúster Tomcat y MariaDB (como la base de datos)
- Nginx (para el equilibrio de carga), agrupado embarcadero y MariaDB (como la base de datos)
El mismo archivo WAR de Java será implementado en dos servidores de aplicaciones diferentes. DCHQ no sólo automatiza las implementaciones de aplicaciones - pero también se integra con 12 diferentes nubes para automatizar el aprovisionamiento y la auto-escala de conglomerados con redes definidas por software. Vamos a cubrir:
- La construcción de las plantillas de aplicaciones que se pueden volver a utilizarse en cualquier sistema Linux corriendo en cualquier parte
- Aprovisionamiento y de auto-escalar la infraestructura subyacente en cualquier nube (con Rackspace es el ejemplo en este blog)
- La implementación de los múltiples niveles basados en Java aplicaciones Pizza Shop en el clúster Rackspace
- El control de la CPU, memoria y E / S de los contenedores Operando
- Habilitación del flujo de trabajo de entrega continua con Jenkins para actualizar el archivo WAR de las aplicaciones que se ejecutan cuando se desencadena una acumulación
- El escalado horizontal del clúster de servidores de aplicaciones para las pruebas de escalabilidad
La construcción de las plantillas de aplicación para el basadas en Java Pizza Shop aplicación en Tomcat y embarcadero
Después de registrarse en DCHQ (ya sea el DCHQ.io instalado o la versión on-premise), un usuario puede navegar a App & Machine y luego haga clic en el botón + para crear una nueva plantilla acoplable Componer.
Hemos creado cuatro plantillas de aplicaciones que utilizan las imágenes oficiales de estibador de concentradores para la misma aplicación Pizza Shop - pero para cuatro servidores de aplicaciones diferentes.
- 3-Tier PizzaShop (Nginx - Tomcat - MariaDB)
- 3-Tier PizzaShop (Nginx - Embarcadero - MariaDB)
A través de ambas plantillas, se dará cuenta de que Nginx está invocando un script BASH plug-in para añadir el contenedor IP de los servidores de aplicaciones en el archivo default.conf dinámicamente (o en el momento de la solicitud).
Los servidores de aplicaciones (Tomcat y Jetty) también están invocando un script BASH plug-in para implementar los archivos Pizza Shop Java guerra desde una URL externa Tomcat, JBoss y el embarcadero se dé aplicación a la misma de plug-in - excepto el archivo WAR está siendo desplegado en diferentes directorios:
- Tomcat - dir = / usr / local / tomcat / webapps / ROOT.war
- Embarcadero - dir = / var / lib / embarcadero / webapps / ROOT.war
Usted se dará cuenta de que el parámetro CLUSTER_SIZE le permite especificar el número de contenedores para poner en marcha (con las mismas dependencias de la aplicación).
El parámetro host le permite especificar el host que desea utilizar para las implementaciones de contenedores. De esta manera se puede garantizar una alta disponibilidad para sus clústeres de servidores de aplicaciones a través de los diferentes huéspedes (o regiones) y se puede cumplir con las reglas de afinidad para asegurar que la base de datos se ejecuta en un equipo diferente, por ejemplo. Éstos son los valores admitidos para el parámetro host:
- host1, host2, host3 , etc. - selecciona un host al azar dentro de un centro de datos (o clúster) para implementaciones de contenedores
- <Dirección IP 1, dirección IP 2, etc.> - permite a un usuario especificar el actual direcciones IP a usar para implementaciones de contenedores
- <Nombre de host 1, 2 Nombre de host, etc.> - permite a un usuario especificar los nombres de host reales de usar para los despliegues de contenedores
- Los comodines (por ejemplo, "db- *", o "app-SRV-*") - para especificar los caracteres comodín para utilizar dentro de un nombre de host
Además, un usuario puede crear imagen-cruz asociaciones de variables de entorno, haciendo referencia a la variable de entorno de otra imagen. En este caso, hemos hecho varias fijaciones - includingdatabase.url = jdbc: mysql: // {{MariaDB | container_ip}}: 3306 / {{MariaDB | MYSQL_DATABASE}} - en la que el contenedor de base de datos de IP se resuelve dinámicamente en tiempo de solicitud y se utiliza para garantizar que los servidores de aplicaciones pueden establecer una conexión con la base de datos.
Aquí está una lista de valores de variables de entorno soportados:
- {{alphanumeric | 8}} - crea una cadena alfanumérica de 8 caracteres al azar. Esto es muy útil para crear contraseñas aleatorias.
- {{<Image Name> | ip}} - le permite introducir la dirección IP del host de un recipiente como un valor para una variable de entorno. Esto es muy útil para permitir que el nivel de middleware para establecer una conexión con la base de datos.
- {{<Image Name> | container_ip}} - le permite introducir la dirección IP interna de un recipiente como un valor para una variable de entorno. Esto es muy útil para permitir que el nivel de middleware para establecer una conexión segura con la base de datos (sin exponer el puerto de base de datos).
- {{<Image Name> | port _<Port Number>}} - le permite introducir el número de puerto de un recipiente como un valor para una variable de entorno. Esto es muy útil para permitir que el nivel de middleware para establecer una conexión con la base de datos. En este caso, el número de puerto especificado tiene que ser el número de puerto interno - es decir, no el puerto externo que se asigna al recipiente. Por ejemplo, {{PostgreSQL | port_5432}} será traducido al puerto externo real que permitirá que la capa de middleware para establecer una conexión con la base de datos.
- {{<Image Name> | <Environment Variable Name>}} - le permite introducir el valor de la variable de entorno de una imagen en la variable de entorno de otra imagen. Los casos de uso son infinitas - como la mayoría de las aplicaciones de varios niveles tendrán dependencias imagen cruz.
Aprovisionamiento y auto-escala la infraestructura subyacente En Cualquier Nube
Una vez que se guarda una aplicación, un usuario puede registrar un proveedor de nube para automatizar el aprovisionamiento y la auto-escala de los racimos en 12 diferentes nube de puntos finales, incluyendo OpenStack, CloudStack, Servicios Web de Amazon, Rackspace, Microsoft Azure, digitalocean, HP nube pública, IBM SoftLayer, Google Compute Engine, y muchos otros.
En primer lugar, un usuario puede registrar un proveedor de nube de Rackspace (por ejemplo) navegando a proveedores de la nube y luego hacer clic en el botón + para seleccionar Rackspace. La clave de API de Rackspace debe ser proporcionada - que puede ser recuperada de la sección Configuración de la cuenta del Panel de control Rackspace Cloud.
Un usuario puede crear un clúster con una política de auto-escala para girar automáticamente los nuevos servidores de la nube. Esto puede hacerse navegando a la página Clústeres y luego hacer clic en el botón +. Puede seleccionar una política de colocación basadas en la capacidad y luego Tejer como la capa de red con el fin de facilitar la comunicación-contenedor cruz protegido por contraseña segura a través de múltiples hosts dentro de un grupo. Política TheAuto-Escala en este ejemplo se establece el número máximo de VM (o Servidores Cloud) a 10.
Un usuario puede ahora suministrar un número de servidores de nube en el clúster recién creado por la navegación a máquinas y luego hacer clic en el botón + para seleccionar Rackspace. Una vez seleccionado el proveedor de la nube, un usuario puede seleccionar la región, el tamaño y la imagen sea necesario. Los puertos pueden estar abiertos en los nuevos servidores de la nube (por ejemplo 32000 a 59000 de estibador, 6783 para la armadura, y 5672 para RabbitMQ). Un centro de datos (o clústeres) Luego se activa y el número de Servidores Cloud se puede especificar.
El despliegue de Pizza Shop aplicación basada en Java Multi-Nivel en el clúster Rackspace
Una vez que los Servidores Cloud se aprovisionan, un usuario puede desplegar un multi-capas, las aplicaciones Java basadas en estibador en los nuevos servidores de la nube. Esto puede hacerse navegando a la Biblioteca de autoservicio y luego hacer clic en Personalizar para solicitar una aplicación multi-nivel.
Un usuario puede seleccionar una Etiqueta para el Medio Ambiente (como DEV o QE) y el Cluster Rackspace creado antes de hacer clic en Ejecutar
El monitoreo de la CPU, memoria e I O Utilización / de los contenedores Operando
Una vez que la aplicación está en funcionamiento, nuestros desarrolladores monitorear la CPU, memoria, I / O y de los contenedores de funcionamiento para recibir alertas cuando estas métricas superan un umbral predefinido. Esto es especialmente útil cuando nuestros desarrolladores están realizando pruebas funcionales y de carga.
Un usuario puede realizar el seguimiento del análisis histórico y correlacionar las cuestiones a las actualizaciones de contenedores o construir implementaciones. Esto se puede hacer haciendo clic en el menú Acciones de la aplicación en ejecución y luego onMonitoring. Un intervalo de fechas personalizado se puede seleccionar para ver la CPU, memoria y E / S históricamente.
El flujo de trabajo que permite la entrega continua con Jenkins para actualizar el archivo WAR de la aplicación se ejecuta cuando se activa A Físico
Para los desarrolladores que deseen seguir el modelo de contenedores "inmutables" mediante la reconstrucción de imágenes acoplables que contienen el código de la aplicación y girando nuevos contenedores con cada actualización de la aplicación, DCHQ proporciona una característica de construcción automatizado que permite a los desarrolladores crear automáticamente imágenes acoplables de Dockerfiles o proyectos de GitHub privados que contienen Dockerfiles.
Sin embargo, muchos desarrolladores pueden desear actualizar los contenedores de servidor de aplicaciones en ejecución con el último archivo WAR de Java en su lugar. Por eso, DCHQ permite a los desarrolladores para permitir un flujo de trabajo continuo con la entrega Jenkins. Esto se puede hacer haciendo clic en el menú Acciones de la aplicación en ejecución y luego seleccionando entrega continua. Un usuario puede seleccionar una instancia de Jenkins que ya ha sido registrada con DCHQ, el trabajo real de Jenkins que producirá el último archivo WAR, y luego una secuencia de comandos BASH plug-in para agarrar esta acumulación y desplegarlo en un servidor de aplicación que se ejecuta. Una vez que esta política se guarda, DCHQ va a agarrar el último archivo WAR de Jenkins cualquier momento una acumulación se activa y desplegarlo en el servidor de aplicación que se ejecuta.
Los desarrolladores, como resultado siempre tendrán la última archivo WAR de Java implementado en sus contenedores se ejecutan en entornos / PRUEBA DEV.
El escalado horizontal Application Cluster servidor Tomcat
Si la aplicación que se ejecuta queda limitada de recursos, un usuario puede escalar a cabo la aplicación para satisfacer el aumento de la carga. Por otra parte, un usuario puede programar la escala a cabo durante el horario laboral y la escala en los fines de semana, por ejemplo.
Para escalar el grupo de servidores Tomcat de 2 a 4, un usuario puede hacer clic en el menú Acciones de la aplicación en ejecución y seleccione Escala de salida. Un usuario puede especificar el nuevo tamaño para el clúster y luego haga clic en Ejecutar ahora.
A continuación, utiliza el BASH plug-in para actualizar el archivo de default.conf Nginx para que esté al tanto del nuevo servidor de aplicaciones añadido. Los plug-ins de escritura del golpe también se pueden programar para dar cabida a los casos de uso como la limpieza de registros o actualizar las configuraciones en las frecuencias definidas. Una línea de tiempo de la aplicación está disponible para realizar un seguimiento de todos los cambios realizados a la solicitud de auditoría y de diagnóstico.
Para ejecutar un plug-in en un contenedor de funcionamiento, un usuario puede hacer clic en el menú Acciones de la aplicación que se ejecuta y luego seleccione Plug-ins. Un usuario puede seleccionar el contenedor equilibrador de carga (Nginx), buscar el plug-in que necesita ser ejecutado, permitir el reinicio contenedor utilizando el botón de activación. El argumento por defecto para este plug-in se resolverá de forma dinámica todo el recipiente de IP de los servidores Tomcat en ejecución y añadirlos como parte del archivo default.conf.
Una línea de tiempo de la aplicación está disponible para realizar un seguimiento de todos los cambios realizados a la solicitud de auditoría y de diagnóstico. Esto se puede acceder desde el menú extensible en la parte inferior de la página de una aplicación en ejecución.
Las alertas y notificaciones están disponibles para cuando los contenedores o sistemas principales son, o cuando la CPU y memoria La utilización de cualquiera de los anfitriones o contenedores supera un umbral definido.
Conclusión
Contenerización de aplicaciones empresariales Java sigue siendo un desafío sobre todo porque los marcos de composición de aplicaciones existentes no abordan dependencias complejas, integraciones externas o auto-escala flujos de trabajo de post-prestación. Por otra parte, el diseño efímero de contenedores significa que los desarrolladores tenían que girar nuevos contenedores y volver a crear las complejas dependencias y integraciones externas con cada actualización de versión.
DCHQ, disponible en versiones alojados y en las instalaciones, se dirige a todos estos retos y simplifica la contenerización de aplicaciones empresariales Java a través de un marco de composición solicitud previa que facilita enlaces de variables de entorno-imagen Cruz, extensibles escritura del golpe plug-ins que se pueden invocar en solicitar tiempo o después de la prestación, y la agrupación de aplicaciones de alta disponibilidad a través de múltiples hosts o regiones con soporte para escalado automático.
Inscríbete GRATIS en http://DCHQ.io
para obtener acceso a las plantillas de aplicaciones Java de varias filas fuera de la caja junto con la funcionalidad de gestión del ciclo de vida de aplicaciones como monitoreo, actualizaciones de contenedores, en escala / entrega y continua.
No comments:
Post a Comment