Tecnología de contenedorización ha avanzado enormemente en el espacio tecnológico del desarrollo de software como el método más aceptado para empaquetar y desplegar aplicaciones en entornos de nube. Esto ha sido necesario debido a la necesidad de integración continua (CI) y despliegue continuo (CD), que son aspectos definitorios de DevOps. Los desarrolladores e ingenieros de software utilizan contenedores para lograr el aspecto de CI/CD de la arquitectura de software. Un contenedor es esencialmente una plataforma informática portátil, totalmente empaquetada y autodependiente. Aunque existen varias plataformas de contenedores en la web, Docker resulta ser la más común.
Docker es una plataforma de contenedores de código abierto que hace que el desarrollo sea eficiente y predecible. Docker ofrece un repositorio público de imágenes de Docker disponible en Docker Hub. Contiene muchas imágenes de Docker de código abierto para las implementaciones más comunes que puedes descargar y usar. Dado que es un repositorio público, también eres libre de agregar tus propias imágenes de Docker para compartirlas con el público. Sin embargo, si tienes código privado/propietario, es posible que tengas que pagar por un repositorio de imágenes privado o crear tu propio servicio de repositorio de imágenes. Aquí es donde entra en juego GitLab.
GitLab es un repositorio basado en la web de Git que es más que una simple herramienta de control de versiones. Proporciona herramientas de DevOps para la integración y el despliegue continuos, el seguimiento de problemas, registros de imágenes de Docker y más. Ofrece tres opciones: GitLab Community Edition (CE), GitLab Enterprise Edition (EE) y GitLab SaaS. GitLab CE y GitLab EE son soluciones autogestionadas que te permiten descargar, instalar y administrar la instancia de GitLab por ti mismo. GitLab SaaS está alojado por GitLab Inc., y no tienes que preocuparte por instalar nada para usarlo.
En un tutorial anterior, te mostramos cómo configurar una instancia de GitLab en un servidor de CloudSigma y alojar tu propio repositorio de Git. También te mostramos cómo implementar pipelines de integración continua con GitLab runner para compilar y ejecutar automáticamente tus pruebas cada vez que haya un nuevo commit. Si no has realizado los tutoriales mencionados, hazlo, ya que son la base de este tutorial.
En este tutorial, demostraremos cómo compilar una imagen de Docker simple y alojarla con una instancia autohospedada de GitLab (ya sea que estés utilizando la Community Edition o la Enterprise Edition – el flujo de pasos es el mismo).
Requisitos previos
Para seguir cada paso de este tutorial, asegúrate de tener un GitLab CI runner y un servidor de GitLab autohospedado como se explica a continuación.
1. Un servidor de GitLab seguro
Utilizaremos esto para almacenar el código fuente, ejecutar tareas de CI/CD y alojar el registro de imágenes de Docker. Deberías tener un servidor con al menos 2 CPU núcleos y 4GB de RAM como lo recomienda GitLab para instalar una instancia de GitLab autogestionada. También necesitarás un nombre de dominio registrado para apuntar al servidor, ya que lo utilizaremos para obtener un certificado SSL de Let’s Encrypt para proteger el servidor. A continuación, se presentan algunos enlaces que puedes seguir para configurar una instancia autohospedada de GitLab.
- Registra un nombre de dominio con cualquier registrador de nombres de dominio de tu elección y apúntalo a CloudSigma.
- Sigue este tutorial para la configuración inicial del servidor Ubuntu, agregar un usuario no root, y habilitar el firewall UFW de Ubuntu.
- Finalmente, sigue este tutorial para instalar y configurar una instancia autohospedada de GitLab.
2. Un GitLab CI runner
Un GitLab CI runner es necesario para ejecutar trabajos automatizados en tus casos de prueba. El tutorial sobre cómo configurar pipelines de integración continua de GitLab en Ubuntu 20.04 te ofrece una visión general del servidor GitLab CI y te muestra cómo activar trabajos. Sigue los pasos del tutorial para configurar el servicio GitLab CI runner si aún no lo has hecho. El tutorial tiene una aplicación de demostración de Node.js con casos de prueba – la utilizaremos en este tutorial.
¡Ahora, comencemos!
Paso 1: Configuración de un GitLab CI Runner con privilegios
En el tutorial sobre cómo configurar un GitLab CI Runner, configuramos un runner de GitLab utilizando el comando sudo gitlab-runner register comando que nos permitió agregar de forma interactiva los parámetros requeridos. Aunque esto funcionó para nuestro caso de uso anterior, que consistía en ejecutar compilaciones y pruebas en contenedores Docker aislados, es posible que no sirva para compilar imágenes de Docker. Compilar imágenes de Docker requiere que el runner tenga acceso completo al servicio Docker. Puede lograr esta configuración utilizando la imagen oficial docker-in-docker para ejecutar los trabajos. Dicha configuración implica otorgar al runner un modo privilegiado de ejecución.
Aunque otorgar el modo privilegiado de ejecución es necesario para compilar imágenes de Docker, conlleva problemas de seguridad. Esto se debe a que implica prescindir de las ventajas de seguridad de los contenedores. Puede pensar que los otros runners de Docker son seguros, pero resulta que tienen los mismos problemas explicados en la documentación oficial de Docker.
Crearemos otro runner con el modo de ejecución privilegiado. Este será un runner específico del proyecto debido a las implicaciones de seguridad mencionadas anteriormente. Aceptará trabajos del proyecto Node Pipeline que creamos en el tutorial sobre cómo configurar canalizaciones de CI continuas con GitLab.
Lo primero que debe hacer es verificar que los Runners compartidos estén desactivados en el proyecto. Desde la página del proyecto Node Pipeline, haga clic en Settings en el menú inferior izquierdo y seleccione CI/CD en el submenú:
Busque el botón Expand en la sección Runners y haga clic en él para revelar detalles sobre los runners disponibles:
Haga clic en el interruptor para desactivar los Runners compartidos para este proyecto. Si había agregado un runner específico del proyecto en la sección anterior, también desactívelo. Agregaremos un runner específico del proyecto privilegiado para ejecutar trabajos para este proyecto. Esto garantiza que no terminemos con errores de compilación en caso de que GitLab asigne trabajos aleatoriamente a runners que no fueron registrados con un modo de ejecución privilegiado. En la captura de pantalla anterior, en la pestaña Specific runners, debería ver el token de registro de su proyecto. Tome nota de él, ya que lo usará a continuación.
| Nota: Un runner específico del proyecto también se puede asignar a otros proyectos desde la sección Admin panel > Runners. Cuando selecciona un runner de la lista de runners, llega a la página de configuración del runner. Desplácese hacia abajo para ver la sección Restrict projects for this runner: |
Es hora de abrir su terminal. Si no ha realizado los pasos del tutorial sobre cómo configurar canalizaciones de integración continua de GitLab en Ubuntu 20.04, tómese un descanso de este tutorial y siga los pasos para poder tener un servidor con el servicio de runner de GitLab CI. De lo contrario, acceda por SSH al servidor del runner de GitLab CI con su usuario sudo para los siguientes pasos.
Para configurar el runner específico del proyecto privilegiado, ingrese el siguiente comando en su terminal, reemplazando su nombre de dominio y el token de registro copiados anteriormente:
|
1 2 3 4 5 6 7 |
sudo gitlab-runner register -n \ --url https://your-gitlab-instance-domain.com/ \ --registration-token your-project-specifc-registration-token \ --executor docker \ --description "docker-privileged-builder" \ --docker-image "docker:latest" \ --docker-privilegedh |
Esta salida muestra un registro exitoso:
Para verificar que su instancia de GitLab detectó el runner, vuelva al navegador y actualice la página Settings > CI/CD. Expanda la sección Runners y debería ver su runner en Specific Runners:
Opcionalmente, si va al Admin Panel (haciendo clic en el botón Menu en la barra superior y seleccionando Admin), luego seleccione Runners en las opciones del menú:
Debería llegar a esta página que muestra todos los runners disponibles conectados a su instancia de GitLab, tanto los runners compartidos como los específicos del proyecto:
Hasta este punto, ha configurado con éxito un runner que puede compilar imágenes de Docker.
Paso 2: Configuración del registro de Docker de GitLab
Algunos flujos de trabajo cruciales requieren independencia de los servicios externos. Ahí es donde entra el autogestionado de GitLab Docker Registry. No solo es seguro, sino que garantiza que tengas la flexibilidad de adaptar tus trabajos y pipelines según tus necesidades. Para configurar el Docker Registry, modificarás el archivo de configuración de GitLab. Primero, accede por SSH a la instancia de GitLab y luego abre el archivo con el siguiente comando:
|
1 |
sudo nano /etc/gitlab/gitlab.rb |
Desplázate hacia abajo hasta que veas Container Registry Settings:
Descomenta la línea con registry_external_url y establécela con el nombre de dominio de tu instancia de GitLab, especificando el puerto 8888 al final:
|
1 |
registry_external_url 'https://your-gitlab-domain.com:8888' |
A continuación, debemos especificar dónde encontrará el registro los certificados de Let’s Encrypt agregando las siguientes líneas. Recuerda editarlo con el nombre de dominio real de tu instancia de GitLab:
|
1 2 |
registry_nginx['ssl_certificate'] = "/etc/letsencrypt/live/your-gitlab-domain.com/fullchain.pem" registry_nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/your-gitlab-domain.com/privkey.pem" |
Una vez que hayas terminado, guarda y cierra el archivo. Introduce el siguiente comando en tu terminal para reconfigurar GitLab:
|
1 |
sudo gitlab-ctl reconfigure |
A continuación, espera unos segundos a que el comando termine de ejecutarse. Deberías ver la siguiente salida si tiene éxito:
A continuación, debemos asegurarnos de que el cortafuegos (ufw) permita el tráfico al puerto del registro que asignamos usando el comando:
|
1 |
sudo ufw allow 8888 |
Luego, debes probar que el Docker Registry esté funcionando iniciando sesión en él desde otra máquina que tenga Docker instalado utilizando el comando docker login con el comando. Si no habías configurado Docker en tu entorno local, puedes acceder por SSH al servidor del runner de GitLab CI, ya que este ya tiene Docker instalado. A continuación, ejecuta el siguiente comando, especificando, por supuesto, el nombre de dominio de tu instancia de GitLab:
|
1 |
docker login your-gitlab-domain.com:8888 |
Tu salida mostrará el mensaje Login Succeeded de esta manera:
Esto significa que el registro se ha configurado correctamente y está funcionando. Cuando crees imágenes, se almacenarán localmente en el sistema de archivos del servidor de GitLab. Esto está bien para un registro de empresa privado. Sin embargo, si planeas dejar tu registro abierto al público, es posible que necesites un almacenamiento más grande. Afortunadamente, GitLab ofrece opciones para conectarse a buckets de almacenamiento. Puedes leer más en la documentación oficial del registro de contenedores de GitLab para ver cómo puedes configurar un bucket de almacenamiento para tu instancia de GitLab.
Paso 3: Modificar el archivo gitlab-ci.yml y compilar una imagen de Docker
Para continuar con este paso, debes tener el proyecto Node Pipeline en tu instancia de GitLab. Aquí está la vista del proyecto en GitLab:
Hablamos de gitlab-ci.yml como el archivo que lee el runner de GitLab CI cuando se activa para saber cómo compilar tu aplicación y realizar pruebas automatizadas. Necesitamos modificar este archivo para agregar instrucciones para compilar imágenes de Docker. Puedes optar por editar este archivo directamente dentro de la interfaz de GitLab. También puedes clonarlo en tu máquina local y editarlo con tu editor favorito, luego hacer un commit y un git push de vuelta a GitLab. Para abreviar, utilizaremos la interfaz de GitLab.
Haz clic en el archivo para abrirlo, luego haz clic en el botón Editar:
Esto abre el archivo listo para editar. Elimina todo del archivo y agrega el siguiente código:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
image: docker:20-dind services: - name: docker:20-dind alias: docker command: ["--tls=false"] stages: - build - test - release variables: TEST_IMAGE: gitlab-domain.com:8888/hackins/node_pipeline:$CI_COMMIT_REF_NAME RELEASE_IMAGE: gitlab-domain.com:8888/hackins/node_pipeline:latest DOCKER_HOST: tcp://docker:2375 DOCKER_DRIVER: overlay2 DOCKER_TLS_CERTDIR: "" before_script: - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN gitlab-domain.com:8888 build: stage: build script: - docker build --pull -t $TEST_IMAGE . - docker push $TEST_IMAGE test: stage: test script: - docker pull $TEST_IMAGE - docker run $TEST_IMAGE npm test release: stage: release script: - docker pull $TEST_IMAGE - docker tag $TEST_IMAGE $RELEASE_IMAGE - docker push $RELEASE_IMAGE only: - master |
Mientras agregas el fragmento de código anterior, recuerda actualizar la parte resaltada con tus datos reales. Cuando hayas terminado, guarda los cambios presionando el botón Commit changes . Si has estado trabajando fuera de GitLab, haz commit y push de tus cambios.
Comprendamos qué hace el código que hemos agregado al archivo .gitlab-ci.yml. La primera línea le indica a GitLab que use la imagen oficial de Docker-in-Docker y la asocia al servicio docker-in-docker (docker:dind). Luego definimos las etapas para build, test y release. La etapa build construye la imagen utilizando las instrucciones del Dockerfile y luego la sube al Docker Registry que configuramos en un paso anterior.
Cuando la etapa build tiene éxito, la etapa test descarga la imagen, la ejecuta como un contenedor y ejecuta el comando npm test para realizar pruebas automatizadas dentro de él. Si la etapa test tiene éxito, la etapa release toma el control. En la etapa de release, la imagen se descarga y se etiqueta como node_pipeline:latest. Luego se vuelve a subir al registro.
Esta es solo una configuración básica para un proyecto de demostración. Para tus proyectos del mundo real, podrías tener otras etapas, por ejemplo staging, production, etc. Cuando guardas el archivo después de editarlo, se activa un pipeline. Luego comienza a ejecutar los trabajos. Regresa a la página Node Pipeline. Deberías ver que el trabajo se está ejecutando actualmente:
Haz clic en el icono indicador CI para ver las distintas etapas del trabajo:
Como puedes ver en la captura de pantalla anterior, todas las etapas fueron exitosas según los iconos de marca de verificación verdes. Puedes hacer clic en cada etapa para ver la salida del trabajo:
En el menú de la izquierda, haz clic en Packages & Registries y selecciona Container Registry:
Esto abre una página que enumera las imágenes de Docker disponibles para el proyecto seleccionado. La imagen que construimos y lanzamos debería aparecer en la lista con la etiqueta asignada:
Haz clic para revelar las distintas etiquetas de la imagen:
Si tienes Docker instalado en tu entorno local, puedes descargar la imagen y probar que se ejecute como se espera. Haz clic en el icono Copiar al lado del nombre de la etiqueta de la imagen. Copiará en tu portapapeles el nombre completo de la imagen que puedes usar con el comando docker pull:
|
1 2 |
docker pull feetspark.com:8888/hackins/node_pipeline:latest docker run -it --rm -p 8090:8090 feetspark.com:8888/hackins/node_pipeline:latest |
Los comandos anteriores descargarán la imagen y la ejecutarán dentro de un contenedor:
La aplicación ahora se está sirviendo en el puerto 8090. Si abres tu navegador y navegas a tu-direccion-IP:8090 deberías ver la página mostrada:
Si puedes ver una página así en tu navegador, entonces has construido con éxito una imagen de Docker y la has compartido en un Docker Registry privado. En el futuro, si realizas algún cambio en la rama master, las etapas definidas en el archivo .gitlab-ci.yml se ejecutarán, y si tienen éxito, se reconstruirá una nueva imagen de Docker con la etiqueta latest y se enviará al registro.
Conclusión
En este proyecto, aprendiste cómo agregar un runner de GitLab privilegiado a tu instancia autogestionada de GitLab para que puedas construir imágenes de Docker. También configuraste un registro privado de imágenes de Docker para alojar tus imágenes. Usando el proyecto Node pipeline, pudiste probar cada componente de la configuración y asegurarte de que se conectaran y comunicaran como se esperaba. Una vez que tu imagen estuvo disponible en el registro, pudiste descargarla y confirmar que se ejecutaba dentro de un contenedor.
Este es un tutorial introductorio que te brinda los conceptos básicos sobre los cuales construir. Por favor, sigue la documentación oficial de GitLab para obtener más información sobre GitLab. Este enlace puede proporcionar información sobre GitLab Container Registry.
Para obtener más recursos sobre el uso de Docker, es posible que desees consultar más tutoriales en nuestro blog:
- Compartir datos entre contenedores de Docker
- Configuración de un registro privado de Docker en Ubuntu 18.04
- Cómo compartir datos entre un contenedor Docker y un host
- Limpieza de recursos de Docker: imágenes, contenedores y volúmenes
¡Feliz computación!
Comentarios
Aún no hay comentarios. Sea el primero.