Service containers en Azure Pipelines

Es habitual (y deseable) que nuestros pipelines ejecuten tests, que suelen habitualmente ser unitarios o de integración. 

En el segundo caso podemos requerir de servicios externos como bases de datos, servicios de cache, colas u otros.

 

Puede que esos servicios se encuentren ya disponibles en nuestro agente de pipelines, como es el caso de Sql Server LocalDB en los agentes hosteados de Azure DevOps, lo que sin duda simplifica las cosas, pero en otros casos esos servicios no estarán disponibles. 

 

¿Qué opciones tenemos?

 

• Podemos utilizar un servicio externo al agente. 
  

 

Por ejemplo, si necesitásemos acceso a un Redis, podríamos desplegarlo en Azure u otro Cloud, y desde nuestros tests usarlo. Es una solución sencilla, pero presenta varios inconvenientes que hacen que no sea la más optima.

 

Uno de los problemas es el económico: tener provisionado un Redis 24/7 cuando solo lo necesitaremos al ejecutar nuestras pipelines no parece lo más optimo.

 

Por otro lado disponer de un solo Redis nos impediría ejecutar varias pipelines en paralelo, ya que si dos se ejecutasen a la vez, nuestros tests podrían colisionar, arrojando resultados erráticos.

 

• Podemos instalar Redis en nuestros agentes.

 

Sí, es una opción, pero descarta los agentes hosteados y nos obliga a usar agentes self-hosted, es decir que nosotros deberemos proporcionar máquinas virtuales o contenedores donde se ejecutarán nuestras pipelines.

 

Es un escenario muy común, pero aun así el hecho de tener que instalar software en nuestros agentes complica su gestión y nos impide usar Hosted agents a futuro en caso de necesidad.

 

Por otro lado, ¿imagináis que no tenemos una dependencia sino varias? Las cosas sin duda se complican.

 

• Podemos usar redis como servicio en nuestra pipeline.

 

Si, podemos hacer que nuestro agente, hosted o self-hosted, ejecute una imagen docker de nuestro servicio, de modo que nuestros tests puedan hacer uso de la misma.

 

Vamos a explorar esta última opción.

 

Pipeline yaml

 

Volvamos al caso del Redis y pensemos en una pipeline que necesite usarlo al ejecutar tests de integración.

 

Podemos definir que nuestro agente ejecute un contenedor con la última versión de redis. Para ello solo necesitaremos definir un elemento container como se ve a continuación:

 

Con lo anterior, definimos un servicio llamado redis basado en dicho contenedor, que podremos usar en nuestra pipeline.

 

Como veis, instalamos redis-cli para después usarlo lanzando un ping a nuestro Redis, al que como es habitual en docker, podremos acceder a través del localhost y el puerto mapeado.

 

La pipeline completa queda así:

 

No es complejo: igual que hemos mandado un ping a Redis,  nuestros tests podrían acceder al mismo utilizando localhost:6379. 

 

A partir de aquí las posibilidades son ingentes: ¿necesitas usar nginx, Postgres o RabbitMq? Busca su imagen docker y adelante!

 

¿Quieres ver lo anterior funcionando?

 

Te dejo un breve video de mi canal con un ejemplo un poco más elaborado: 

 

 

 

 

En la siguiente entrada profundizaremos un poco más sobre estos Services Containers e introduciremos un nuevo concepto: los container jobs.

 

Otros recursos:

 

Documentación oficial: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/service-containers?view=azure-devops&tabs=yaml