Service containers en Azure Pipelines, parte 3: comunicando contenedores

Hemos visto en esta entrada como podemos ejecutar contenedores en el ámbito de una pipeline, pero ¿y si levantamos varios contenedores y queremos que se comuniquen entre ellos?

Imagina levantar un contenedor con tu aplicación (un api por ejemplo), otro con un Redis (dependencia de la aplicación), y desde tu pipeline poder lanzar requests para realizar tests.

 

 

 

Podemos hacerlo haciendo uso de Azure Pipelines Service Containers, empecemos por definir nuestros contenedores como recursos de la pipeline

Como veís he mapeado puertos para los dos contenedores, además de indicar en una variable de entorno como la aplicación puede acceder al Redis (aquí tienes el código de la aplicación por si quieres echarle un ojo).

Con estos dos contenedores definidos, podríamos perfectamente lanzar una request a nuestra api, que haría uso del Redis para dar una respuesta. Es importante destacar que los contenedores se ejecutarán dentro de una docker network, mientras que el agente de Azure Pipelines no, lo que tiene implicaciones:

•  Los contentedores se pueden comunicar entre si usando el nombre del servicio, y sin que sea necesario mapear puertos
• El agente de Azure DevOps accede a los contenedores usando localhost y el puerto mapeado.
  

 Con lo anterior podríamos lanzar una request al api (localhost puerto 80) y ver que status code nos responde.

Si la respuestra no es un 200, el step fallará, y por tanto también fallará nuestro pipeline.

Fijaos que como decía el api podrá "hablar" con el Redis a través del nombre del servicio (redis en mi caso). Se hace a traves de la variable de entorno CacheConnection. Si tratásemos de acceder con localhost a redis desde el contenedor del api no llegaríamos.

Os dejo el fichero yaml completo.

Comunicando contendores con "Container jobs"

Veíamos tambien en entradas anteriores como ejecutar un job de nuestra pipeline dentro de un contenedor. Si ese fuese el caso habría que tener en cuenta un detalle:

El job se ejecuta en un contenedor que está en la misma docker network que los otros contenedores, por lo que:

• Puede acceder a ellos usando el nombre del servicio
• No es necesario mapear puertos

En este caso el yaml resultante difiere un poco, aquí os lo dejo:

 

En breve dejaré un video donde podréis ver en vivo todo esto :-)

Espero que os haya resultado de interés. Gracias!

Recursos:

Repositorio con el código: https://dev.azure.com/sergionavarropino/Yaml-docker