amazon-web-services - codepipeline - integracion continua devops
Cómo se adaptan Docker y Ansible para implementar Entrega Continua/Despliegue Continuo (3)
Soy nuevo en las herramientas de administración y despliegue de configuración. Tengo que implementar una herramienta de Distribución continua / Implementación continua para uno de los proyectos más interesantes que he tenido en mis manos.
En primer lugar, de forma individual, me siento cómodo con AWS , sé lo que es Ansible , la lógica detrás de él y su propósito. No tengo el mismo nivel de comprensión de Docker pero entendí la idea. Revisé muchos recursos de Internet, pero no puedo ver el panorama completo.
Lo que he estado luchando es cómo encajan. Usando Ansible , puedo administrar mi infraestructura como código; construyendo instancias de EC2 , instalando paquetes ... Incluso puedo implementar una aplicación completa al tirar de su código, modificar los archivos de configuración e iniciar el servidor web. Docker es, en sí mismo, una herramienta que empaqueta una aplicación y asegura que se puede ejecutar donde sea que la implemente.
Mis problemas son:
¿Cómo extiende Docker (o Ansible and Docker) el proceso de Integración Continua?
Supongamos que tenemos un repositorio de código fuente, los miembros del equipo terminan de trabajar en una función e impulsan su trabajo. Jenkins detecta esto, ejecuta todas las suites de prueba de aceptación / unidad / integración y, si todas pasan, lo declara como una compilación estable. ¿Cómo se ajusta Docker aquí? Me refiero a cuando el equipo empuja su trabajo, ¿Jenkins tiene que extraer el código fuente de Docker codificado dentro de la aplicación, construir la imagen de la aplicación, iniciar el contenedor y ejecutar todas las pruebas en su contra o ejecutar las pruebas de la manera clásica y si Todo está bien, entonces construye la imagen Docker del archivo Docker y la guarda en un lugar privado. ¿Debería Jenkins etiquetar la imagen final usando xyz, por ejemplo?
Configuración de contenedores Docker:
Supongamos que tenemos una imagen creada por Jenkins almacenada en algún lugar, cómo manejar la implementación de la misma imagen en diferentes entornos e incluso diferentes parámetros de configuración (configuración de Vhosts, hosts de bases de datos, URLs de colas, puntos finales S3, etc.). ¿Cuál es el una forma flexible de lidiar con este problema sin romper los principios de Docker ? ¿Están respaldadas estas configuraciones en la imagen cuando se genera o cuando se inicia el contenedor basado en ella, de ser así, cómo se inyectan?
Ansible y Docker :
Ansible proporciona un módulo Docker para administrar los contenedores Docker . Asumiendo que resolví los problemas mencionados anteriormente, cuando quiero implementar una nueva versión xtz de mi aplicación, le digo a Ansible que saque esa imagen de donde estaba almacenada, inicie el contenedor de la aplicación, entonces ¿cómo inyectar la configuración? ¿Tiene Ansible que iniciar sesión en la imagen Docker, antes de que se ejecute (esto suena loco para mí) y utilizar sus plantillas Jinja2 de la misma manera con un host clásico? Si no, ¿cómo se maneja esto?
Disculpe si fue una pregunta larga o si escribí mal algo, pero esto es lo que pienso en voz alta. Estoy bloqueado durante las últimas dos semanas y no puedo entender el flujo de trabajo correcto. Quiero que esto sea una referencia para los lectores futuros.
Por favor, sería muy útil leer sus experiencias y soluciones porque esto parece un flujo de trabajo común. Gracias de antemano. Cualquier ayuda es muy apreciada.
Aunque no es una solución completa, tengo sugerencias para dos de sus problemas. Aunque pueden no ser perfectos, estas son las prácticas que estamos utilizando en nuestro flujo de trabajo, y demuestran que son muy lentos.
Al definir entornos diferentes, supongamos que ha escrito una función Ansible diferente para cada entorno que inicia, definimos una variable de entorno que establece el entorno al que deseamos que pertenezca el contenedor. A continuación, descargamos el archivo de configuración adecuado de un depósito S3 usando la variable env establecida anteriormente en el contenedor (que debería ser posible si suministra creditos AWS o le damos a su servidor un rol IAM) e inyectamos estos parámetros en el código cuando lo construimos.
Ansible no necesita iniciar sesión en la aplicación acoplable, pero la solución es un poco complicada. He intentado dos formas de abordar este problema, y ambos no son ideales. El primero es descargar el archivo de configuración como parte de la línea de comandos de la imagen de la ventana acoplable y compilar la aplicación al iniciar el contenedor. Si bien esta solución funciona, infringe la filosofía de Docker y hace que la imagen sea muy propensa a generar errores. Otra solución es empujar varias imágenes a su repositorio de docker hub, y luego tirar de la imagen adecuada de acuerdo con el entorno en cuestión.
En un trazo más amplio, he intentado lanzar nuestra aplicación completamente con Ansible y fue un infierno, muchos pasos de configuración son complicados y se vuelven más complicados cuando intentas implementarlos como un libro de jugadas. Cuando cambié a mantener los servidores solo con Ansible, y al implementar la aplicación con Docker, las cosas se volvieron mucho más fáciles.
Me gustaría responder en partes
¿Cómo extiende Docker (o Ansible and Docker) el proceso de Integración Continua?
Como las imágenes del acoplador son las mismas en todas partes, usa las imágenes del acoplador como si fueran imágenes de producción. Por lo tanto, cuando alguien cometió un código, usted construye su imagen del acoplador. Ejecutas pruebas en su contra. Cuando pasan todas las pruebas, etiqueta esa imagen en consecuencia. Como Docker es rápido, este es un flujo de trabajo factible. Además, los cambios del acoplador son incrementales; por lo tanto, sus imágenes tendrán un impacto mínimo en el almacenamiento. Además, cuando sus pruebas fallan, también puede optar por guardar esa imagen también. De esta forma, el desarrollador obtendrá esa imagen e investigará fácilmente por qué fallaron sus pruebas. El desarrollador también puede optar por ejecutar pruebas en su máquina, ya que las imágenes del acoplador en jenkins y su máquina no son diferentes.
Lo que esto significa es que todos los desarrolladores tendrán el mismo entorno, la misma versión de todo el software, ya que usted decide cuál se usará en las imágenes del acoplador. Me he encontrado con errores que se deben a las diferencias entre las máquinas de desarrollador. Por ejemplo, en el mismo sistema operativo, la configuración de unicode puede afectar su código. Pero en las imágenes acoplables, todos los desarrolladores probarán con la misma configuración, el mismo software de versión.
Configuración de contenedores Docker:
Si está utilizando un repositorio privado y debe usar uno, los cambios en la configuración no afectarán demasiado el espacio del disco duro. Por lo tanto, a excepción de las configuraciones de seguridad, como las contraseñas db, puede aplicar cambios de configuración a las imágenes del acoplador ( horneado de la configuración en el contenedor ). Luego puede usar ansible para aplicar configuraciones no almacenadas a las imágenes desplegadas antes / después del inicio utilizando variables de entorno o volúmenes de Docker.
¿Tiene Ansible que iniciar sesión en la imagen Docker, antes de que se ejecute (esto suena loco para mí) y utilizar sus plantillas Jinja2 de la misma manera con un host clásico? Si no, ¿cómo se maneja esto?
No, ansible no iniciará sesión en la imagen Docker, pero se puede usar ansible con las plantillas Jinja2 para cambiar el archivo docker. Puede cambiar el archivo docker con plantillas y puede inyectar su configuración a diferentes archivos. Etiquete sus archivos en consecuencia y haya configurado las imágenes para que giren.
En cuanto a su pregunta sobre el manejo de múltiples configuraciones de entorno con la misma imagen de Docker, he estado planeando utilizar una herramienta de detección de servicios como Cónsul como una herramienta de administración de configuración / propiedad centralizada. Entonces, cuando comienzas tu contenedor, configuras una ENV var que le dice qué aplicación es (id. De aplicación) y qué configuración de entorno debe usar (por ejemplo: MiAplicación: Dev) y extraerá su configuración de Cónsul al inicio. Todavía tengo que investigar la seguridad alrededor del Cónsul (como si estuviéramos almacenando credenciales de conexión de BD, por ejemplo, cómo restringimos quién puede consultar / actualizar esos valores). No quiero usar esto solo para contenedores, sino para todas las aplicaciones en general. Otra buena función es cambiar el valor de configuración en Consul y volver a conectarlo a tu aplicación para aplicar los cambios inmediatamente (tal vez como un punto final REST en tu aplicación para aplicar cambios y aplicarlo dinámicamente). ¡Por supuesto, tu aplicación debe estar escrita para apoyar esto!
Puede que le interese consultar los artículos de blog de Martin Fowler sobre infraestructura inmutable y servidores de Phoenix .