introduccion - jenkins pdf español

Uso de docker, títeres y jenkins para entrega continua y despliegue de PROD

Question

Necesidad de configurar la infraestructura para un nuevo proyecto. Anteriormente he utilizado títeres independientes con jenkins, pero ahora estoy pensando en incorporar construcciones de docker, para poder pasar de la fase de desarrollo a la fase de producción sin desencadenar una compilación, pero simplemente obteniendo las imágenes acoplables existentes de Docker que ya han sido procesadas. construido.

La aplicación:

• Aplicación web Java con API de reposo respaldada por postgresql, neo4j, elasticsearch
• Aplicación del lado del cliente escrita con angular que habla con java a través de repos api
• Código almacenado en repositorios git

Envs:

• Servidor Dev (construcción, entornos de prueba + desarrollo) - máquina linux 32GB
• Servidor de prueba (AWS)
• Producción (AWS)

Preparar:

Básicamente, estaba pensando algo así:

• Imágenes separadas de Docker para aplicaciones laterales Java + cient, postgresql, elasticsearch, neo4j que se comunican entre sí y tienen sus datos almacenados en hosts a través de volúmenes Docker, o mediante el uso de contenedores de datos Docker (todavía no se han decidido sobre el enfoque)
• Jenkins construye todo el código y crea imágenes de Docker que serían enviadas al repositorio interno privado
• Las pruebas de integración se ejecutan con el módulo de la ventana temporal de Puppet en el servidor DEV
• Empuje hacia la producción con jenkins a través de la marioneta usando Docker

¿Por qué debería usar Docker?

• Big Dev Machine: podría ejecutar fácilmente múltiples instancias de mi aplicación sin la necesidad de virtualización (podría tener un dev inestable, un desarrollador estable, un sitio, etc.)
• Facilidad de implementación (use el módulo acoplable y el acoplador de marionetas) y restauración (simplemente recupere la versión anterior del repositorio Docker)
• Migración rápida y capacidad de generar nuevas instancias
• Preparación para escalar fácilmente diferentes partes del sistema (por ej., Agrupamiento de elasticsearch)

Preguntas

• ¿Esto se ve razonable?
• Estoy pensando en utilizar este módulo de marionetas https://github.com/garethr/garethr-docker . ¿Cómo actualizaría mis entornos a través de él? Debo de alguna manera detener el contenedor Docker, hacer una docker rm, y luego Docker ejecutar?
• Estamos utilizando liquibase para la administración de actualizaciones de bases de datos. ¿Adivina que esto debería ir por separado de Docker para actualizaciones / retrocesos?

Cualquier sugerencia bienvenida, gracias.

Answer 1

Estás construyendo un contenedor orquestado por PAAS . Mi consejo es buscar sistemas similares para las mejores prácticas que valen la pena emular.

El primer lugar para comenzar es el sitio de la aplicación de 12 factores , escrito por uno de los cofundadores de Heroku . El sitio es increíblemente útil, ya que describe algunas de las características operativas deseables de una aplicación de escala de nube moderna. La próxima parada sería Heroku para obtener una idea de lo que un entorno "moderno" de desarrollo e implementación puede / debe ser.

También recomendaría ver algunas de las plataformas emergentes de código abierto PAAS. Los grandes sistemas soportados por proveedores como Cloud Foundry y Openshift están de moda por el momento, pero también están surgiendo soluciones más simples (basadas en el docker ). Uno de estos, Deis , utiliza un Chef de tecnología relacionado, por lo que podría dar una idea de cómo se puede usar el títere para administrar los contenedores de portadores en tiempo de ejecución. ( Deis moderno ya no usa Chef)

Respuestas

• Sí, esto es bastante razonable.
• En lugar de administrar "entornos", hágalo como Heroku y simplemente cree una nueva aplicación para cada versión de su aplicación. Este es el patrón " Build, Release, Run ". En su caso, Jenkins es activado por el nuevo código, crea las imágenes Docker, que pueden guardarse en un repositorio y utilizarse para implementar instancias de su versión de la aplicación.
• La base de datos sería un ejemplo de un " servicio de respaldo " que puede conectar a su aplicación en el momento de la creación de la aplicación. Una actualización equivaldría a detener una versión de la aplicación y comenzar otra conectada a la misma base de datos.