Puede clonar esta muestra "nombres de directorio" aplicación Java desde GitHub. Gitclonehttps://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra example.git
Una guía paso a paso para Dockerizing y gestión de una aplicación Java que consiste en:
- Apache HTTP Server (httpd) y Nginx ( para el equilibrio de carga )
- JBoss , Tomcat y el embarcadero ( como el servidor de aplicaciones )
- Solr ( para la búsqueda de texto completo )
- Mongo , Cassandra , MySQL y Oracle ( para la base de datos )
Esta es una extensión de este proyecto ( https://github.com/dchqinc/dchq-docker-java-example ). La aplicación es ahora compatible con Solr para la búsqueda de texto completo y ambos Mongo y Cassandra como las bases de datos soportadas.
Para ejecutar y administrar las 24 plantillas de aplicaciones Java en este proyecto en 13 diferentes nubes y las plataformas de virtualización (incluyendo vSphere, OpenStack, AWS, Rackspace, Microsoft Azure, Google Compute Engine, digitalocean, IBM SoftLayer, etc.), asegúrese de que sea :
Fondo
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 obtener acceso a las copias de seguridad de aplicaciones, la escala automática de entrada / salida de flujos de trabajo, y el plug-in de los flujos de trabajo de ejecución de actualizar contenedores en funcionamiento. 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 los blogs anteriores, hemos demostrado la automatización de implementación de un extremo a extremo de las diversas aplicaciones de Java (como Pizza Shop y tienda de la película aplicaciones) en pilas de aplicaciones basadas en acoplable de varios niveles a través de 13 diferentes nubes y las plataformas de virtualización. Para la lista completa de estos blogs, se puede visitar esta página: http://dchq.co/docker-java-applications.html
Sin embargo muchos usuarios aún estaban confundidos sobre algunos de los aspectos fundamentales de modelado de aplicaciones. Estas preguntas incluyen:
- ¿De dónde proceden estas variables de entorno provienen en su plantilla de aplicación basada en YAML?
- ¿Cómo es la base de datos inicializado con los esquemas apropiados necesarios de mi aplicación Java?
- Ya tengo un plan de despliegue para mi servidor de aplicaciones WebLogic. ¿Puedo llevar mi propio guión para la implementación de una aplicación Java?
Para abordar estas cuestiones, hemos creado una muestra de aplicaciones Java "nombres de directorio" en este proyecto GitHub que se puede implementar en estas pilas de aplicación:
- Apache HTTP Server (httpd) y Nginx (para el equilibrio de carga)
- JBoss, Tomcat y Jetty (como el servidor de aplicaciones)
- Solr (para la búsqueda de texto completo)
- Mongo, Cassandra, MySQL y Oracle (para la base de datos)
En este proyecto, vamos a proporcionar una guía paso a paso para configurar, desplegar y gestionar esta aplicación Java utilizando diferentes pilas de aplicaciones y en diferentes infraestructuras de nube / virtual.
Vamos a cubrir:
- Configuración de los archivos de Java para variables de entorno de conexión de base de datos y Solr
- Utilizando el frijol Liquibase para inicializar la base de datos conectada
- La construcción de las plantillas de aplicación basada en YAML que 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)
- Despliegue de la aplicación Java de varios niveles 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 aplicación cuando la aplicación está utilizando el marco de descubrimiento de servicios para actualizar el servicio de equilibrio de carga con recursos limitados
Configuración de los archivos de Java base de datos y variables de entorno de conexión Solr
Puede clonar esta muestra de aplicaciones Java "nombres de directorio" de GitHub.
Este es el paso más importante en la aplicación Java "Dockerizing". Con el fin de aprovechar las variables de entorno que puede pasar cuando se ejecuta contenedores, tendrá que asegurarse de que su aplicación se configura de una manera que le permitirá cambiar ciertas propiedades durante la petición - como:
- El puerto Solr URL y que le gustaría usar
- El controlador de base de datos que desea utilizar
- La base de datos de URL
- Las credenciales de base de datos
- Cualquier otro parámetro que desea cambiar en el momento de la solicitud (por ejemplo, el / min tamaño máximo del grupo de conexión, tiempo de espera, etc.)
Para lograr esto, hemos creado varios archivos Java para declarar las variables de entorno que tenemos que utilizar para conectarse a la base de datos y Solr. Los archivos Java se pueden encontrar en el directorio de configuración:
Vamos a primera examine SolrConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/SolrConfig.java
Usted notará que solr_host y solr_port se declaran como variables de entorno que puede pasar cuando se ejecuta el contenedor de servidor de aplicaciones.
Ahora vamos a examine DatabaseConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/DatabaseConfig.java
Usted notará que database_driverClassName , database_url , database_username , y database_password se declaran como variables de entorno que puede pasar cuando se ejecuta el contenedor de servidor de aplicaciones. Estos serán utilizados para conectar las bases de datos MySQL, PostgreSQL y Oracle.
A continuación, vamos examine MongoConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/MongoConfig.java
Usted notará que mongo_url se declara como variables de entorno que puede pasar cuando se ejecuta el contenedor de servidor de aplicaciones.
Sin embargo, el MongoConfig.java también se utiliza para rellenar la base de datos con el esquema de la derecha y mesa en el arranque - si este cuadro no está ya encontró.
Por último, vamos a examine CassandraConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/CassandraConfig.java
Usted notará que cassandra_url se declara como variables de entorno que puede pasar cuando se ejecuta el contenedor de servidor de aplicaciones.
El uso de la haba Liquibase para inicializar los Conectado MySQL, PostgreSQL y bases de datos Oracle
Normalmente, recomendamos inicializar el esquema de base de datos como parte de la implementación de aplicaciones de Java en sí. De esta manera, usted no tiene que preocuparse por el mantenimiento de los archivos de SQL separados que deben ser ejecutadas en la base de datos por separado.
Sin embargo si ya tiene esos archivos SQL y todavía ellos prefieren que se ejecuta en la base de datos por separado - a continuación, DCHQ puede ayudar a automatizar este proceso a través de su marco plug-in. Se puede hacer referencia a esta sección para obtener más información.
La inicialización de las bases de datos de Mongo y Cassandra se cubre en los archivos MongoConfig.java y CassandraConfig.java.
Para MySQL, PostgreSQL y Oracle, el Liquibase frijol se utiliza en el archivo DatabaseConfig.java para comprobar el origen de datos y ejecutar sentencias SQL de Upgrade.sql. Pistas Liquibase qué estados de cambios se han topado contra cada base de datos.
Aquí está el archivo Upgrade.sql real con las sentencias SQL para inicializar el esquema en la base de datos MySQL, PostgreSQL u Oracle conectados.
La construcción de las plantillas de aplicación YAML-base que pueden volver a utilizarse en cualquier sistema Linux se ejecuta en cualquier lugar
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 un nuevo acoplable Componer plantilla.
Hemos creado 24 plantillas de aplicaciones que utilizan las imágenes oficiales de estibador de concentradores para la misma aplicación Java "nombres de directorio" - pero por diferentes servidores de aplicaciones y bases de datos.
Las plantillas incluyen ejemplos de las siguientes pilas de aplicaciones (por la misma aplicación Java):
- Apache HTTP Server (httpd) y Nginx - para equilibrar la carga
- Solr - para la búsqueda de texto completo
- Tomcat, Espolón, y JBoss - para los servidores de aplicaciones
- Mongo, Cassandra, MySQL y Oracle XE - para las bases de datos
Plug-ins para configurar los servidores Web y servidores de aplicaciones a petición del tiempo y de post-Disposición
A través de todas estas plantillas de aplicación, se dará cuenta de que algunos de los contenedores están invocando escritura del golpe plug-ins durante la petición con el fin de configurar el contenedor. Estos plug-ins se pueden ejecutar después de la prestación así.
Estos plug-ins se pueden crear mediante la navegación a Plug-ins . Una vez que se proporciona la escritura del golpe, el agente DCHQ ejecutará esta secuencia de comandos en el interior del recipiente . Un usuario puede especificar argumentos que se pueden sustituir durante la petición y después de la prestación. Cualquier cosa precedido por el $ signo se considera un argumento - por ejemplo, $ file_url puede ser un argumento que permite a los desarrolladores especificar la URL de descarga de un archivo WAR. Esto se puede anular durante la petición y después de la provisión cuando un usuario desea actualizar el archivo Java WAR en un contenedor de funcionamiento.
debe ser proporcionada al definir la plantilla de aplicación basada en YAML el plug-in de identificación. Por ejemplo, para invocar un script BASH plug-in para Nginx, queremos hacer referencia al plug-in ID de la siguiente manera:
En las plantillas de ejemplo, estamos invocando 4 de script BASH plug-ins.
Nginx está invocando un plug-in de escritura del golpe que inyecta contenedor IP de los servidores de aplicaciones en el archivo default.conf dinámicamente (o en el momento de la solicitud). El plug-in de identificación es 0H1Nk .
Apache HTTP Server (httpd) está invocando un script BASH plug-in que inyecta contenedor IP de los servidores de aplicaciones en el archivo httpd.conf de forma dinámica (o en el momento de la solicitud). El plug-in de identificación es uazUi .
La belleza de las Nginx y Apache HTTP Server (httpd) plug-ins es que pueden ser ejecutadas después de la prestación como parte de la escala de clúster de servidores de aplicaciones en u horizontal. Esto hace que sea posible definir políticas de auto-escala que se actualizan automáticamente el servidor web (o equilibrador de carga). Esto es parte de DCHQ de descubrimiento de servicios de marco.
Descubrimiento de Servicio Con el complemento en las etapas del ciclo de vida
El ciclo de vida de parámetros de plug-ins permite especificar la etapa exacta o evento para ejecutar el plug-in. Si no se especifica el ciclo de vida, de forma predeterminada, el plug-in se ejecuta on_create . Aquí están las etapas del ciclo de vida compatibles:
- on_create - ejecuta el plug-in cuando se crea el contenedor
- on_start - ejecuta el plug-in después de un envase de aperturas
- on_stop - ejecuta el plug-in antes de unas paradas de contenedores
- on_destroy - ejecuta el plug-in antes de destruir un contenedor
- post_create - ejecuta el plug-in después de crear y ejecutar el envase
- post_start [: Nodo] - ejecuta el plug-in después de otro contenedor se inicia
- post_stop [: Nodo] - ejecuta el plug-in después de otras paradas de contenedores
- post_destroy [: Nodo] - ejecuta el plug-in después de otro contenedor se destruye
- post_scale_out [: Nodo] - ejecuta el plug-in después de otro grupo de contenedores se escala a cabo
- post_scale_in [: Nodo] - ejecuta el plug-in después de otro grupo de contenedores se escala en
Para conseguir el acceso al servidor Nginx y Apache HTTP (httpd) de los complementos bajo la licencia EULA, asegúrese de que sea:
Los servidores de aplicaciones (Tomcat, Jetty, y JBoss) también están invocando un plug-in script bash para implementar el archivo WAR de Java desde la URL GitHub accesible.
Tomcat, JBoss y el embarcadero están invocando la secuencia de comandos BASH mismo plug-in exacta (plug-in ID: oncXN ) - excepto el archivo WAR se está implementado en diferentes directorios:
- Tomcat - dir = / usr / local / tomcat / webapps / ROOT.war
- Embarcadero - dir = / var / lib / embarcadero / webapps / ROOT.war
- JBoss - dir = / opt / jboss / JBoss / independiente / los despliegues / ROOT.war
Solr está invocando un plug-in diferente escritura del golpe (plug-in ID: doX8s ) que hará que el archivo names.zip y descomprimirlo en / opt / Solr / servidor / Solr /
CLUSTER_SIZE y anfitrión parámetros para la implementación de HA en hosts múltiples
Usted notará que el CLUSTER_SIZE parámetro le permite especificar el número de contenedores para poner en marcha (con las mismas dependencias de la aplicación).
El anfitrión parámetro le permite especificar el host que desea utilizar para las implementaciones de contenedores. Esto es posible si se ha seleccionado la armadura como la capa de red al crear los grupos. 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 las direcciones IP reales de usar para los despliegues 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 comodines para el uso dentro de un nombre de host
Asociaciones de variables medioambientales en todas las Imágenes
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 - incluyendo database_url = jdbc: mysql: // {{MySQL | container_hostname}}: 3306 / {{MySQL | MYSQL_DATABASE}} - en la que el nombre del contenedor de base de datos 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 el nombre 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 | container_private_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.
He aquí cuatro ejemplos. Usted puede encontrar personalizar y ejecutar todas las 24 plantillas de sí mismo.
Multi-Nivel de Java (Nginx-Tomcat-Solr-Mongo)
Multi-Nivel de Java (Nginx-JBoss-Solr-Oracle-XE)
Multi-Nivel de Java (ApacheLB-Tomcat-Solr-Cassandra)
Multi-Nivel de Java (ApacheLB-embarcadero-Solr-Mongo)
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 VMware vSphere, OpenStack, CloudStack, Servicios Web de Amazon, Rackspace, Microsoft Azure, digitalocean, 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 Clusters página 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. La política de auto-escala , por ejemplo, puede establecer el número máximo de VM (o Servidores Cloud) a 10.
Un usuario puede ahora suministrar un número de Servidores Cloud en el clúster recién creado ya sea a través del flujo de trabajo basado en la interfaz de usuario o mediante la definición de una plantilla de máquina de composición basada en YAML simple que puede ser solicitada a la Biblioteca de autoservicio.
Flujo de trabajo basado en la interfaz de usuario - Un usuario puede solicitar servidores de la nube de Rackspace navegando 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 se abren de forma predeterminada en los servidores de la nube de Rackspace para dar cabida a algunos de los requisitos de puerto (por ejemplo, 32000-59000 para Docker, 6783 para la armadura, y 5672 para RabbitMQ). Un racimo Luego se activa y el número de Servidores Cloud se puede especificar.
Plantilla Componer máquina basada en YAML - Un primer usuario puede crear una plantilla de máquina de componer para Rackspace navegando a Máquinas y luego seleccionar la máquina de composición .
Aquí está la plantilla para la solicitud de un servidor de la nube de 4 GB.
Los parámetros admitidos para la plantilla de la máquina de composición se resumen a continuación:
- Descripción : Descripción del modelo / plantilla
- instanceType : Nube proveedor de valor específico (por ejemplo general1-4)
- región : Nube proveedor de valor específico (por ejemplo IAD)
- Imagen : Obligatorio - completo la imagen ID / nombre (por ejemplo IAD / 5ed162cc-b4eb-4371-b24a-a0ae73376c73 o vSphere VM Template nombre)
- nombre de usuario : Opcional - sólo para vSphere VM Template nombre de usuario
- contraseña : Opcional - sólo para vSphere VM Template contraseña cifrada. Puede cifrar la contraseña utilizando el punto final https://www.dchq.io/#/encrypt
- la red : Opcional - Nube proveedor de valor específico (por ejemplo, por defecto)
- SecurityGroup : Nube proveedor de valor específico (por ejemplo DCHQ-seguridad-grupo)
- KEYPAIR : Nube proveedor de valor específico (por ejemplo, clave privada)
- OpenPorts : Opcional - valores de los puertos separados por comas
- cuentan : Nº total de VM, por defecto es 1.
Una vez que se guarda la plantilla de la máquina de composición, un usuario puede solicitar esta máquina desde el autoservicio Biblioteca . Un usuario puede hacer clic en Personalizar y, a continuación, seleccione el proveedor de la nube y el clúster de usar para el aprovisionamiento de estos servidores de Rackspace Cloud.
Despliegue de la aplicación 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 Creación de máquinas .
En el acceso a la Terminal-Browser para los contenedores para correr
Un icono de símbolo del sistema debe estar disponible junto a los nombres de los recipientes en la página de aplicaciones en vivo. Esto permite a los usuarios introducir el recipiente usando un protocolo de comunicación segura a través de la cola de mensajes del agente. Una lista blanca de comandos se puede definir por el inquilino de administración para garantizar que los usuarios no hacen ningún cambio perjudicial en los contenedores de funcionamiento.
Para el despliegue de Tomcat por ejemplo, se utilizó el símbolo del sistema para asegurarse de que el archivo WAR de Java se desplegó bajo el / tomcat / webapps / directorio / usr / local.
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 Acciones menú de la aplicación en ejecución y después de Monitoreo . 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 Acciones menú 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 El Tomcat Application Server Cluster y aprovechar el descubrimiento marco de servicios para actualizar el equilibrador de carga
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 desde 1 hasta 2, un usuario puede hacer clic en el Acciones menú 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 medida que se ejecuta la escala a cabo, el marco de descubrimiento de servicio se utiliza para actualizar el equilibrador de carga. Un plug-in automáticamente se ejecuta en Apache HTTP Server para actualizar el archivo httpd.conf de Apache HTTP Server para que esté al tanto del nuevo servidor de aplicaciones añadido. Esto se debe a que hemos especificado post_scale_out: AppServer como el evento del ciclo de vida para este plugin.
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. En este caso, el marco de descubrimiento de servicios ejecuta el plug-in del servidor HTTP Apache automáticamente justo después de la agrupación de servidores de aplicaciones se escaló a cabo.
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.
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