|
Azure se está poniendo de moda entre las empresas que quieren dar el salto al cloud pero tienen una fuerte dependencia con productos de Microsoft y su Active Directory. Juntas lo anterior con el mal soporte de Azure Pipelines que Microsoft da a Kubernetes/OpenShift y tienes un montón de horas de diversión asegurada intentando integrar Azure Pipelines con Kubernetes. En este post voy a intentar ahorrarte tiempo dándote un Dockerfile mejor que el que proveen y un chart para Kubernetes que permita desplegar agentes fácilmente en Kubernetes/OpenShift. |
|
La meta
Poder instalar el agente con un helm install.
Para ello el agente se debe:
- ejecutar en un statefullset para poder usar un volumen diferente por pod
- poderse ejecutar detrás de un proxy
Análisis para Kubernetes/OpenShift
Otros sistemas necesitan que el servidor se conecte con sus agentes pero el agente de Azure funciona al revés. El agente de Azure, al igual que el de Gitlab o el de Github Actions, puede estar en una red privada y mientras tenga acceso a internet, aunque sea a través de un proxy, va a funcionar correctamente.
Buceando entre las imágenes que provee Microsoft, vemos que Microsoft provee este agente.
En ese enlace, abajo en "Support", hace referencia a un repositorio de github que está congelado.
En ese otro enlace, abajo hace referencia a la página de documentación de Azure.
En ella pone que uses un agente para Docker en Windows o que te lo montes tu mismo a partir de un Dockerfile que empieza por "FROM ubuntu:16.04" cuando la 18.04 tiene más de 2 años de antiguedad y la 20.04 ya salió hace unos meses.
Esto huele un poco mal. ¿no?
Además nos faltan cosas básicas como poder pasarle el nombre del agente o la configuración del proxy como variables de entorno.
Por supuesto, de tener un chart que permita su despliegue en Kubernetes/OpenShift ni hablamos.
Este agente parece estar más orientado a su uso sobre máquinas virtuales Windows y su integración con Kubernetes es nula así que vamos a tener que trabajar un poco para adaptarlo.
Imagen de Docker
Por lo que pone en la documentación, parece pensada como para ser usada de forma interactiva desde una línea de comandos así que hay que hacerle algunas adaptaciones para automatizarla.
CMD
Ejecuta al inicio un start.sh que descarga el agente en tiempo de ejecución y lo lanza pasándole parámetros.
No permite esa descarga del agente detrás de un proxy y no contempla el caso de configurar el nombre del agente dentro de un statefulset.
Dockerfile
No tiene configurado un CMD y no tiene en cuenta que va a ser usado dentro de Kubernetes así que le he agregado start.sh como CMD e instalado los clientes de kubectl y helm.
Volúmenes
Lo correcto sería definir como el directorio donde se ubicará el workspace del agente. Sin embargo el workspace /azp/_work se crea directamente en el contenedor.
Esto no lo he tocado porque permito pasar como variable de entorno el directorio donde se ubicará el workspace (azp_work) pero en Kubernetes no tiene sentido así que cualquier día de estos lo arreglo. ;-)
Chart de Helm
El chart de helm ha sido probado en OpenShift 3.11 y Kubernetes 1.16.
Lo he subido también aquí: https://hub.helm.sh/charts/fermosit
No tienes más que instalarlo ejecutando algo como:
helm repo add fermosit https://harbor.fermosit.es
helm repo update
helm upgrade --install --namespace azp-namespace azp \
--set azp.url=https://dev.azure.com/yourazuregroup \
--set azp.token=aksjdfjkhadfsjkhkjsdgfjkhagsdf \
fermosit/azure-pipelines-agent
Es un chart bastante sencillo así que no necesita mucha más descripción.
En la siguiente entrada ...
... uso de Kaniko para con Azure Pipelines o como hacer un build de una imagen de docker sin hacer "docker build" con todos los problemas de seguridad que eso soluciona.