Introducción a IC/DC
Seguimos la temática sobre Infraestructura, en esta ocasión profundizaremos sobre Automatización. Veremos los conceptos relacionados a la Integración Contínua (IC) y Despliegue Contínuo (DC) con una implementación de ejemplo.
La automatización de tareas es un punto clave en cualquier proyecto de software. La sistematización de procesos replicables requiere un conocimiento general del estado de cada aplicación.
En esta publicación nos vamos a enfocar en la preparación de la infraestructura base necesaria para implementar los conceptos de IC y DC. Estos conceptos, se encuentran bien resumidos en la descripción:
La CI/CD incorpora la automatización continua y el control permanente en todo el ciclo de vida de las aplicaciones, desde las etapas de integración y prueba hasta las de distribución e implementación.
Fuente
En este ejemplo de CI/CD utilizaremos el servidor Gitlab y su proceso de pipelines (secuencia de tareas), enfocándonos en la configuración de un runner. Un Runner de Gitlab, es un proceso encargado de ejecutar las instrucciones definidas en archivos de configuración. Puede correr tanto a nivel local como externo, es decir una máquina virtual de terceros.
Instalación y Configuración de un Runner de GitLab:
Para la instalación del runner tenemos varias opciones:
En este caso, instalaremos el runner en nuestras máquinas locales usando Docker.
Comenzamos, iniciando el proceso Gitlab Runner como un contenedor:
docker run -d --name gitlab-runner --restart always \
-v gitlab-runner-config:/etc/gitlab-runner \
-v /var/run/docker.sock:/var/run/docker.sock \
gitlab/gitlab-runner:latestEn este comando, creamos un volumen gitlab-runner-config, donde iremos guardando la información de los nuevos runners. El mapeo de docker.sock, se utiliza generalmente para escuchar la creación y actualización de contenedores dentro de la Máquina Host.
Luego, actualizaremos el contenedor, ejecutando el comando register dentro del mismo:
docker run --rm -it -v gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner:latest register
Este nos pedirá los siguientes datos:
- URL Gitlab:
https://gitlab.com, puede ser la url pública o una instancia auto hosteada. - Token de Acceso:
#12345, este token se genera automáticamente. - Tipo de runner:
docker, generalmente usaremos imágenes docker - Imágen Docker por defecto:
alpine:latest, solo se utilizará cuando no se defina una en el archivogitlab-ci.yaml.
¿Cómo encontrar las variables URL y Token de Acceso?
Una vez actualizado, el runner se conecta con la instancia de Gitlab, esperando a recibir tareas a ejecutar. Deberíamos ver lo siguiente:
Finalmente, para realizar una prueba usaremos la siguiente configuración de CI, es decir las instrucciones que correrá nuestro runner. (Este ejemplo, es tomado de un proyecto node)
# gitlab-ci.yml
image: node:latest
stages:
- build
- validate
cache:
paths:
- node_modules/
install:
stage: build
script:
- npm install
artifacts:
paths:
- node_modules/
lint:
stage: validate
script:
- npm run lint
test:
stage: validate
script:
- npm run testEsta configuración divide el proceso de CI en dos etapas: build y validate, y ejecuta las instrucciones de install(etapa build), lint y test(etapa validate) en cada una de ellas.
Runner en acción:
Logs del Contenedor recibiendo nuevas tareas.
Logs del Contenedor finalizando algunas tareas.
Finalmente el estado de las tareas ejecutadas desde Gitlab
Conclusiones
Últimos comentarios, tener en cuenta que el runner sólamente va a funcionar mientras el proceso(el contenedor en nuestro caso), siga activo. Por lo cuál, se debería pensar al momento de empezar un nuevo proyecto, si es necesario tener una instancia o máquina virtual, que se dedique exclusivamente a correr estas tareas de Gitlab a través de un runner dedicado.
En este ejemplo, vimos cómo crear la infraestructura necesaria para automatizar la ejecución de tareas, en futuras entregas, seguiremos profundizando sobre las diferentes etapas a automatizar, haciendo foco en los procesos de IC y DC con ejemplos más interesantes.
