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 <project>/local-environment, en la que escribimos nuestro docker-compose.

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 <project>/docker-images/Jenkins. En ella ubicamos nuestro Dockerfile

  • 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.

 

Deja un comentario

Menú de cierre