Integración continua. Jenkins, GIT y contenedores DOCKER
Las siglas CI/CD están de moda, casi podría decirse que ponerlas en la literatura de una propuesta o de un articulo técnico es éxito asegurado.
Sin embargo a la hora de implementar la automatización de un proceso que a partir de una “Merge Request”(MR) en GIT, ejecutara un procedimiento de compilación en Jenkins de la rama en cuestión, y en función de los resultados permitiera o no al usuario revisor poder Aprobar la MR, no me resultó nada fácil encontrar todos los detalles necesarios.
Por este motivo, en este artículo voy a intentar detallar con un ejemplo simple, un proceso de integración continua con Jenkins y GIT basado en contenedores.
Inicialización del entorno
Creamos un proyecto en nuestro workspace, y tras ello una carpeta
En él tenemos dos entradas:
- el contenedor local-jenkins, que se construye en una imagen custom que generamos nosotros, basada en la imagen pública de un servidor Jenkins pero con la diferencia que al arrancar el contenedor:
- nos conectamos al servidor GIT y nos descargamos el proyecto en un volumen docker prefijado (líneas 9-18)
- copiamos el/los jobs y usuarios que tengamos, para que cada vez que arranquemos el contenedor tengamos nuestras pipelines y usuarios prefijados (líneas 20 – 23)
- instalamos plugins (líneas 24 – 38)
Para generar la imagen custom creamos la carpeta
- el contenedor local-gitlab, que está basado en una imagen pública de un servidor GIT. Con la peculiaridad que para poder implementar el proceso de manera completa necesitamos la imagen “Enterprise”, ya que el módulo que realizará la comunicación de retorno entre ambos servidores sólo está disponible en la edición de pago.
Una vez definido nuestro entorno podemos arrancarlo:
y tendremos corriendo en local un servidor Jenkins (http://localhost:18080) y un servidor Gitlab(https://localhost).
Integración Continua
GitLab
Empezamos creando un usuario en GitLab para la comunicación entre los dos productos y generando una pareja de claves SSH. Una vez hecho esto, accedemos a Gitlab con el usuario creado y vamos a Settings/SSH Keys y guardamos la clave pública (id_rsa.pub).
Después accedemos a Acces Tokens y creamos un token con scope api + read_user+read_repository. Atención a la advertencia de guardárselo, pq aunque el sistema lo almacena no es posible consultar el valor del token por seguridad.
Por último hay que acceder con un usuario con permisos (root/admin) al “Admin Area” y activar el modulo Jenkins CI.
Jenkins
Al igual que con GitLab, empezamos configurando la clave SSH, en este caso la clave privada. Accedemos a Credentials/System y añadimos una credencial
También tenemos que añadir el token de gitLab como credencial
Una vez configuradas las credenciales de acceso a la API, podemos configurar la conexión entre Jenkins y GitLab: menú Administrar Jenkins/Configurar el Sistema
Ahora la comunicación entre ambos servidores ya esta configurada, queda crear una pipeline: menú Nueva Tarea/Pipeline
Pipeline groovy
Y ya por último nos queda capturar el evento que queremos que depierte el proceso de CI. Para ello configuraremos un webhook en Gitlab, debemos conectarnos como el usuario dado de alta al inicio del proceso, Settings/Integracitions, seleccionar el/los eventos que queremos que desencadenen el proceso de CI y realizar una de esas acciones.
Veremos entonces com Gitlab nos informa del estado de nuestro proceso y si ha finalizado con o sin éxito.
