Concrete Logo
Hamburger button

Conozca GITLAB CI

  • Blog
  • 18 de Junho de 2019
Share



UNA PODEROSA PLATAFORMA DE CÓDIGOS, AHORA CON CONTINUOUS INTEGRATION & DEPLOYMENT

¡Hola! El objetivo de este post es mostrar un poco de lo que es el Gitlab CI y montar un lab, usando Docker, para que usted vea lo buena que es esa plataforma y lo que la diferencia de los otros servicios.

¿QUÉ ES EL GITLAB CI / CD?

Todos nosotros de la comunidad de desarrolladores conocemos varias plataformas de repositorios y Continuous Integration, y cada una de ellas tiene sus debidos destaques. Una buena parte del mercado acaba seleccionando una plataforma para cada uno de ellos (repositorio, CI y CD, etc.), haciendo que haya un trabajo más para que la integración entre estos dos (o hasta tres) esté completa y bien refinada para poder ser utilizado por sus equipos.

Pero ¿por qué no usar una plataforma que posea todos estos servicios en un solo entorno? Esta es la propuesta de gitlab integración continua e implementación . Una plataforma como servicio (PaaS) que puede comprometer su código, control de versiones y hacer revisiones de código , pruebas de integración, construye y despliegues .

¿CÓMO FUNCIONA?

Es idéntico al que ya sabemos gitlab una  aplicación web con una API en el que se puede almacenar y gestionar su proyecto con una interfaz de demonios, “digasse de paso” con todas las funciones disponibles para el servicio. Y para que el servicio de CI / CD funcione sólo es necesario agregar el Gitlab Runner a su arquitectura.

El corredor es una aplicación que se ejecuta por separado y funciona con el gitlab CI / CD, corriendo  a construir  y  desplegar  las aplicaciones identificadas. Se pueden ejecutar en cualquier sistema operativo (Windows, MacOS, Linux) y también a través de Docker! Es decir, para que pueda realizar la totalidad del flujo de trabajo de CI / CD se requiere al menos un caso de gitlab CI / CD y 1 gitlab Runner se ejecuta en un servidor, el ordenador o incluso  dockerizado .

Con la plataforma montada y los servicios rodando, el código se ejecuta, el Runner es accionado y busca, dentro del repo, por un archivo conocido como .gitlab-ci.ym , para un archivo llamado  .gitlab-ci.yml. En este fichero encontramos todos los trabajos a ejecutar por Gitlab (Pipeline as a Code), que puede variar de acuerdo con la rama en la que se ejecutará.

A continuación un modelo muy simple de la estructura de ese .yml

MONTANDO SU PROPIO GITLAB CI CON DOCKER

Para crear nuestro lab vamos a utilizar la última versión disponible, la v10.1. Si quieres ver más páginas de información para otras versiones de gitlab, visite el  repositorio oficial  en DockerHub.

Ahora abra su terminal y descargue la imagen de Gitlab CE (Community Edition):

La descarga es un poco larga. Cuando termine, inicie la descarga del runner de GitlabCI con el siguiente comando. En el caso de que se trate de una versión diferente del Gitlab CE que bajamos, hay grandes posibilidades de incompatibilidades.

Hecho las descargas vamos a iniciar el proceso de creación de los contenedores. Crear una carpeta en un directorio con el nombre GitlabCI y dentro de ella crear el archivo  docker-compose.yml, añadiendo la información a continuación. Guarde el archivo. Esta es la receta que va a subir los contenedores, dar un hostname al Gitlab CI y configurar la red de ellos y la persistencia en los volúmenes.

Si no lo ha acoplable-Componer en su máquina, su instalación y uso están disponibles  aquí , en la documentación oficial de estibador. Y más información acerca de cómo “Bao” es compone se puede leer  este post .

En el compiso arriba él va a subir la instancia del Gitlab_CI, con una LAN dedicada a él, configurando para ser iniciado siempre que la máquina también se inicie. Además, va a dar un nombre de host al contenedor, liberar el puerto 80 para acceder y crear la persistencia en el volumen. 
Después de eso, finalizará el proceso iniciando el Gitlab Runner, enlazando el contenedor en la LAN de Gitlab_CI, usar el mismo método de arranque y crear la persistencia en el volumen.

Ahora que tenemos nuestro  docker-compose.yml conjunto, todavía en el tipo de carpeta del proyecto  docker-compose up -d y se obtiene el retorno de componer como OK, que indica que se crearon los contenedores. Entras  docker container ls y verá que el corredor gitlab del contenedor ya se está ejecutando y el IC gitlab está empezando  (health: starting), como en la imagen de abajo:

Este proceso de inicialización del contenedor del Gitlab CI / CD tarda alrededor de 10 minutos. Entonces, mientras el servicio se inicia, vamos a agregar el host de Gitlab en nuestros hosts conocidos para facilitar el acceso. Abra el terminal y escriba el comando Dock para recoger el IP del contenedor Gitlab_CI:

Devuelve el IP del contenedor. Grabe y luego escriba:

En este archivo agregue la dirección IP y el host  gitlab.docker, como se muestra a continuación:

Guarde el archivo. Ahora esperamos a que el contenedor llegar  healthy a acceder a él. Introducir  docker container ls y realizar un seguimiento del cambio de estatus. Cuando  healthy, abra su navegador y escriba gitlab.docker/

PRIMER ACCESO AL GITLAB CE

En el primer acceso se le pedirá la nueva contraseña para el usuario “root”. Escriba una de su preferencia. Enseguida te va a redirigir la página de inicio de sesión de la plataforma, ahí tecleas el usuario “root” y la contraseña que has definido en la página anterior.

Ahora que ya accedemos a nuestro Gitlab, necesitamos configurar el Gitlab Runner para empezar a subir los proyectos y jugar con lab. En la parte superior del Gitlab, haga clic en el icono de configuración (ejemplo en la siguiente imagen):

Al acceder a la página ver que no tenemos ningún Runner configurado, entonces vamos a configurar, también utilizando los comandos vía Docker 🙂

Abra el terminal y escriba:

Se mostrará el mensaje siguiente, dando inicio a la configuración del Runner. El primer paso es informar la URL de Gitlab, a continuación, escriba el nombre de host del servicio como se describe en el ejemplo siguiente y pulse Enter:

El siguiente paso es informar a Registration Token. Para copiarlo, ve a la página de los Runners en Gitlab y copia la clave disponible en la pantalla (ejemplo abajo). Pegue en el terminal y presione enter:

Después de informar a Token, se le pedirá la descripción del Runner. Introduzca su preferencia, según la imagen muestra:

Después le solicitará la etiqueta para ese Runner. Es un paso muy importante porque es esa etiqueta que vas a utilizar en los trabajos de sus pipelines para que funcionen correctamente. Puede utilizar la opción para que funcionen sin ella, pero vamos a utilizarla, ya que es un proceso más detallado y es muy bueno conocer. Describa una etiqueta fácil de identificarse, como en el ejemplo:

Después de “taggear” el Runner, tenemos que indicar si puede ejecutar trabajos no “taggeados” y si vamos a bloquear el Runner sólo en 1 proyecto. Vamos a configurar para que los trabajos sin etiquetas no se ejecuten y dejar el runner compartido, así que todos los proyectos que tengan con la etiqueta runner01 configurada serán ejecutados.


Una vez agregada esta información, el registro devolverá un mensaje que indica que el registro se ha realizado correctamente y se ha creado el ID de Runner:

Para completar el registro, vamos a indicar qué ejecutor del Runner vamos a usar y la imagen predeterminada a ser utilizada. En este caso vamos a usar el ejecutor Docker y una imagen del alpine: 3.5. Esta imagen predeterminada se utilizará si no se especifica ninguna en la ejecución del trabajo en la canalización.

El ejecutor Docker le permite ejecutar cada trabajo en un contenedor separado y aislado con una imagen predefinida en su bandeja .gitlab-ci.yml

Para obtener más información acerca de otros artistas gitlab CI,  haga clic aquí.

Ahora vuelve a Gitlab y ve que tu nuevo Runner está activo.

Antes de finalizar, sin embargo, tenemos que hacer algunos ajustes adicionales dentro del Runner para que pueda identificar el Gitlab y hacer el pull de los proyectos. Acceda al contenedor de Gitlab Runner con el comando del contenedor docker container exec -t -i Gitlab_Runner /bin/bash y vaya a la carpeta  /etc/gitlab-runner. Tendrá el archivo  config.toml, editarlo mediante la adición del campo  extra_hosts como se muestra a continuación, en la que el lado izquierdo es el nombre de host informado de nuestras  docker-compose.yml ya la derecha de la IP de la máquina o cualquier otra máquina que acoplable es el anfitrión:

Tenemos que establecer este  extra_hosts, si no en el momento en que el Runner ejecuta el trabajo no va a encontrar el CI gitlab contenedor informado.

Ahora que tenemos nuestro Gitlab CI “de pie” y el Runner está activo y configurado, subir un proyecto en él y crear nuestra pipeline.

Para facilitar el proceso, hice una copia de un proyecto muy utilizado en Github y redujo algunos archivos de él. El acceso  haciendo clic aquí  y hacer el clon.

Ahora ve a la carpeta del proyecto y quitar la carpeta .git, usando el comando  rm -r .git.

Perfecto, pero antes de subir el proyecto vamos a crear el repositorio remoto en nuestro Gitlab CI en Docker. Acceda a la url creada y, en la barra superior en la esquina derecha, haga clic en el icono de +, según la siguiente imagen:

La selección que se abre, haga clic en  New Project. Nombre del proyecto (si podemos utilizar el mismo nombre, primavera-petclinic), y haga clic en el botón  Create project. Listo! Ahora vamos a volver a la carpeta del proyecto Petclinic para conectarnos al repo remoto y construir nuestra pipeline como código.

En el repo, conecte la carpeta con el repositorio utilizando estos comandos:

Listo! Tenemos nuestro proyecto conectado y ya con el primer commit hecho.

Vamos ahora a nuestra pipeline.

Crear un archivo llamado  .gitlab-ci.yml y dentro de ella copiar la información a continuación. Vea que he comentado cada etapa del proceso para que usted entienda mejor.

Después de que agregar y guardar esta información,  Commite  el archivo en el repositorio del proyecto.

Ahora acceda al gitlab.docker y vaya al área de CI / CD (según la imagen abajo) y vea que nuestra pipeline ya está siendo ejecutada.

Si desea mantener el terminal en funcionamiento, haga clic en el botón  Running y luego la etapa de construcción del botón, y se puede realizar el seguimiento del resultado de la ejecución del trabajo.

Las estaciones de Gitlab se ejecutan en Pipeline

Terminal de salida del trabajo en el Gitlab CI / CD

¡Y es eso! En  .gitlab-ci.yml todavía se puede agregar muchas otras etapas y funciones. El gitlab tiene una documentación muy detallada con todos los recursos que se pueden utilizar en .yml y si desea ver sólo el acceso  este enlace .

También voy a dejar aquí algunas de las documentaciones que me ayudaron bastante durante el descubrimiento de esa plataforma y también en la evolución de este post. 😀

Cualquier duda, es sólo dejar aquí en el campo de comentarios que respondo. ¡Hasta la próxima!

¿Quieres trabajar con el mejor equipo de DevOps de Latino América?
trabajeconnosotros@concrete.com.br