GitLab es una plataforma líder para alojar repositorios Git, canalizaciones de CI y flujos de trabajo de DevOps. Está disponible como oferta SaaS en GitLab.com o como distribución autogestionada para uso privado en su propio hardware.
GitLab es un sistema complejo formado a partir de una red de distintos componentes y dependencias. La instalación de paquetes de GitLab directamente en su sistema operativo agregará importantes servicios nuevos a su máquina, incluidos PostgreSQL, Redis, Gitaly y la principal aplicación web de GitLab basada en Rails.
Implementar GitLab como un contenedor de Docker es una forma de evitar contaminar su entorno con todos estos componentes. Todo lo relacionado con GitLab vivirá dentro del contenedor, por separado del sistema de archivos de su host.
En esta guía, usaremos Docker para implementar una instancia de GitLab lista para producción que puede usar para alojar su código fuente y colaborar en proyectos. Una cosa a considerar antes de continuar es que Docker no elimina los requisitos básicos de hardware de GitLab: necesitará al menos 4 GB de RAM libre y alrededor de 10 GB de almacenamiento sin usar.
La imagen oficial de Docker
GitLab ofrece una imagen de Docker preconstruida que viene con todo lo que necesita para implementar el software. Nos estamos centrando en esta imagen en este tutorial, pero vale la pena prestar atención a sus limitaciones.
La imagen es de naturaleza monolítica y agrupa todos los componentes de GitLab para que se ejecuten en un solo contenedor. Esto simplifica la configuración, pero dificulta escalar su instalación en el futuro. Va en contra de las mejores prácticas de contenedorización al ejecutar múltiples componentes distintos en el contenedor.
Esto significa que la imagen de stock podría no ser ideal para instalaciones ocupadas. Como alternativa, puede usar el gráfico Helm de GitLab para implementar en un clúster de Kubernetes. Esto lanza cada servicio como su propio Pod en contenedor para que pueda escalar los componentes individualmente.
Implementación de GitLab con Docker
Instale Docker y configure un registro DNS A para su nombre de dominio de GitLab antes de continuar. Debe apuntar el registro DNS a la dirección IP de su host Docker. usaremos gitlab.example.com como dominio en el resto de esta guía.
Puede iniciar GitLab ejecutando el siguiente comando:
docker run -d -p 22:22 -p 80:80 -p 443:443
--name gitlab
--hostname gitlab.example.com
--restart unless-stopped
--shm-size 256m
-v gitlab_config:/etc/gitlab
-v gitlab_logs:/var/log/gitlab
-v gitlab_data:/var/opt/gitlab
gitlab/gitlab-ce:14.7.0-ce.0
Docker descargará la imagen GitLab Community Edition (CE) e iniciará un nuevo contenedor usándola. Es una buena práctica anclar a una versión específica de GitLab seleccionando su etiqueta de imagen correspondiente, 14.7.0-ce.0 en este caso. Aquí hay una explicación de las banderas utilizadas en el comando:
-d- Separe la terminal del contenedor para que se ejecute en segundo plano.-p- Enlace los puertos 22, 80 y 443 en el contenedor a los puertos correspondientes en su host; esto permite que GitLab reciba tráfico Git y web a través de SSH y HTTP/S cuando se dirige a su host.--name- Asigne al contenedor un nombre descriptivo para que pueda hacer referencia a él de manera conveniente cuando ejecute los comandos de la CLI de Docker en el futuro.--hostname- Establecer el nombre de host del contenedor; esto debe coincidir con el dominio que está utilizando para acceder a GitLab.--restart- Asigne al contenedor una política de reinicio para que se reinicie automáticamente cuando salga debido a una falla o un reinicio del host.--shm-size- Esto se explica en la siguiente sección.-v- Configure los volúmenes de Docker para almacenar de forma persistente los archivos de configuración, los registros y los datos de usuario generados de GitLab fuera del contenedor. ¡Esto es vital para que no pierda sus datos cuando el contenedor se detiene!
Espere varios minutos para que se complete la configuración de la primera ejecución de GitLab. Eventualmente deberías poder visitar gitlab.example.com para ver la página de inicio de sesión. Iniciar sesión como root; la contraseña de la cuenta se genera automáticamente y se puede recuperar ejecutando el siguiente comando:
docker exec -it <gitlab-container-name> grep 'Password:' /etc/gitlab/initial_root_password
Sustituir <gitlab-container-name> con el nombre que le asignaste al crear tu contenedor. Esto era gitlab en el ejemplo anterior.
Investigación de problemas de implementación
Es normal que los scripts de instalación tarden mucho tiempo en completarse. GitLab tiene muchos componentes para configurar antes de que el servicio pueda comenzar a funcionar. Puede monitorear el progreso al ver los registros del contenedor:
docker logs gitlab --follow
El mejor curso de acción si la interfaz de usuario web de GitLab no está disponible es simplemente esperar un poco más y dejar que el procedimiento de configuración se complete. Si algo salió mal, ve 500 errores en su navegador y los registros del contenedor no muestran actividad nueva, reinicie el contenedor con docker restart gitlab a veces puede ayudar.
Un mensaje de error común que puede ver en los registros es similar a este:
writing value to /dev/shm/gitlab/... failed with unmapped file
Esto ocurre porque los servicios incluidos con GitLab escriben cantidades significativas de datos en el archivo temporal. /dev/shm sistema de archivos Docker solo asigna contenedores a /dev/shm espacio de 64 MB por defecto. Esto rara vez es suficiente para mantener la recopilación de métricas de GitLab a través de Prometheus, responsable de la mayoría de las escrituras en el sistema de archivos.
la capacidad de /dev/shm se puede aumentar usando el --shm-size marca cuando creas tu contenedor con docker run. Esto se muestra en el ejemplo de implementación anterior donde se asignan 256 MB, el mínimo recomendado por GitLab. Es posible que las instalaciones muy activas necesiten utilizar un tamaño mayor.
Otro problema se relaciona con los archivos de registro de GitLab: estos rápidamente se vuelven expansivos, lo que puede causar buffer overflow detected errores al iniciar Docker. Esto se puede evitar borrando periódicamente los archivos antiguos del /var/log/gitlab directorio desde dentro de su contenedor GitLab:
docker exec -it gitlab rm /var/log/gitlab/*
Los archivos de registro que Docker recopila de los flujos de salida del contenedor y retiene en su host también crecerán rápidamente a tamaños grandes. Docker por defecto json-file El controlador de almacenamiento de registro no es adecuado para su uso con una instancia de producción de GitLab. Los archivos JSON que crea son pesados, detallados y nunca se comprimen ni giran. Cambie a otro controlador de almacenamiento como local o journald para garantizar que los registros se rotan regularmente.
Configuración de GitLab
Puede proporcionar fragmentos del archivo de configuración de GitLab cuando crea su contenedor configurando el GITLAB_OMNIBUS_CONFIG Variable ambiental. Esta debe ser una cadena Ruby válida que se agregará al /etc/gitlab/gitlab.rb archivo dentro del contenedor:
docker run -e GITLAB_OMNIBUS_CONFIG="gitlab_rails['allowed_hosts'] = ['gitlab.example.com]; nginx['redirect_http_to_https'] = true;"
También puedes editar /etc/gitlab/gitlab.rb desde dentro del contenedor una vez que se está ejecutando. Cuando haya terminado de hacer cambios, debe reiniciar el contenedor para aplicarlos:
docker restart gitlab
La imagen de Docker de GitLab ejecuta automáticamente el script de reconfiguración de Omnibus cada vez que se inicia. Esto toma la configuración actual de su gitlab.rb y lo aplica a su instalación. Es normal que no se pueda acceder a GitLab durante unos segundos después de que su contenedor se reinicia mientras se completa este proceso.
Aplicar actualizaciones de GitLab
Las actualizaciones de GitLab se aplican fácilmente deteniendo su contenedor e iniciando uno nuevo con la misma configuración.
Tire de la nueva imagen correspondiente a su versión de GitLab elegida:
docker pull gitlab/gitlab-ce:14.7.1-ce.0
Retire su contenedor existente:
docker rm gitlab
Finalmente, inicie un nuevo contenedor, repitiendo sus banderas originales pero modificando la referencia de la imagen:
docker run -d -p 22:22 -p 80:80 -p 443:443
--name gitlab
...
gitlab/gitlab-ce:14.7.1-ce.0
Sus datos permanecerán intactos ya que los volúmenes del antiguo contenedor se volverán a conectar al nuevo.
Puede evitar la repetición de su docker run banderas encapsulando su configuración en un docker-compose.yml expediente:
version: "3" services: gitlab: image: gitlab/gitlab-ce:14.7.0-ce-0 hostname: gitlab.example.com ports: - 22:22 - 80:80 - 443:443 volumes: gitlab_config:/etc/gitlab gitlab_logs:/var/log/gitlab gitlab_data:/var/opt/gitlab restart: unless-stopped volumes: gitlab_config: gitlab_logs: gitlab_data:
Cuando usa Docker Compose, puede abrir su instancia de GitLab ejecutando docker-compose up -d. Para actualizar a una nueva versión, cambie el image campo en consecuencia y repita el comando. Docker Compose automatizará el proceso de reemplazo de contenedores.
Independientemente del mecanismo que utilice, es importante asegurarse de que sus rutas de actualización se alineen con las rutas compatibles de GitLab. Ocasionalmente, es posible que deba realizar acciones manuales posteriores a la actualización para completar la migración.
Copia de seguridad de su instalación
Las copias de seguridad regulares son críticas para una implementación exitosa de GitLab. El papel típico de GitLab como la única fuente de verdad de su organización significa que, en el peor de los casos, todo su trabajo podría perderse para siempre a menos que se realicen copias de seguridad.
GitLab tiene una utilidad de copia de seguridad integrada que se puede utilizar para crear un archivo completo de su instalación. Esto es accesible en la imagen de Docker a través de la gitlab-backup mando:
docker exec -t gitlab gitlab-backup create
Las copias de seguridad se guardan en el /var/opt/gitlab/backups directorio por defecto. Esto significa que se almacenarán fuera del contenedor, dentro de uno de sus volúmenes Docker montados. Para mayor seguridad, debe configurar GitLab para cargar copias de seguridad en un proveedor de almacenamiento de objetos remoto agregando estas líneas a su archivo de configuración:
gitlab_rails['backup_upload_connection'] = { "provider" => "AWS", "region" => "eu-west-1", "aws_access_key_id" => "access_key", "aws_secret_access_key" => "secret_key", # "endpoint" => "https://..." }
Ahora el gitlab-backup create El comando cargará automáticamente los archivos de almacenamiento que genera, manteniéndolos separados de su contenedor GitLab y Docker host. Su último paso debe ser agregar un cron tarea en su sistema que ejecuta periódicamente el script de copia de seguridad:
0 * * * * docker exec -t gitlab gitlab-backup create
Resumen
GitLab es una pieza compleja de software que se implementa fácilmente con Docker. los docker run El ejemplo que se muestra en esta guía es adecuado para uso en producción cuando se combina con los cambios de configuración de mejores prácticas explicados anteriormente. También debe auditar la seguridad del demonio Docker y su host para asegurarse de que sus datos estén adecuadamente protegidos.
Una implementación de Dockerized GitLab es una buena manera de probar rápidamente la plataforma. También es una estrategia efectiva para lanzar y mantener un servidor GitLab más pequeño para uso a largo plazo. Otras opciones, como GitLab Omnibus en un servidor dedicado o una instalación de Kubernetes nativa de la nube, generalmente se adaptan mejor a los requisitos más grandes y la adopción empresarial sostenida.