Instalación de GitLab autohosp

Configuración

El archivo de configuración principal para GitLab Omnibus es /etc/gitlab/gitlab.rb. Después de cualquier cambio en este archivo, es necesario ejecutar sudo gitlab-ctl reconfigure para aplicarlos.

1. Configuración básica de GitLab (/etc/gitlab/gitlab.rb)

Abra el archivo gitlab.rb para editarlo:

sudo nano /etc/gitlab/gitlab.rb

Encuentre y descomente/modifique las siguientes líneas:

# URL externa de su instancia de GitLab. Esto debería configurarse durante la instalación, pero verifique.
external_url 'https://gitlab.yourdomain.com'

# Desactivar NGINX integrado si usa un proxy externo (no es nuestro caso)
# nginx['enable'] = true # Habilitado por defecto

# Configuración de correo electrónico para notificaciones (obligatorio para funcionar)
# Reemplace con los datos de su servidor SMTP
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.your-email-provider.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "[email protected]"
gitlab_rails['smtp_password'] = "SU_CONTRASEÑA_DE_CORREO"
gitlab_rails['smtp_domain'] = "yourdomain.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false # Establezca en true si su proveedor requiere TLS

gitlab_rails['gitlab_email_from'] = '[email protected]'
gitlab_rails['gitlab_email_display_name'] = 'GitLab'

# Configuración de la copia de seguridad (se tratará con más detalle en la sección de copias de seguridad)
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
gitlab_rails['backup_keep_time'] = 604800 # 7 días en segundos

Después de realizar los cambios, guarde el archivo y ejecute la reconfiguración:

sudo gitlab-ctl reconfigure

2. Configuración de TLS/HTTPS con Certbot (Let's Encrypt)

Para asegurar una conexión HTTPS, utilizaremos Certbot para obtener certificados SSL/TLS gratuitos de Let's Encrypt. GitLab Omnibus tiene soporte integrado para Let's Encrypt, lo que simplifica significativamente el proceso.

En el archivo /etc/gitlab/gitlab.rb, encuentre las siguientes líneas y asegúrese de que estén configuradas:

# Habilitar la gestión automática de certificados de Let's Encrypt
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['[email protected]'] # Asegúrese de especificar su correo electrónico
letsencrypt['auto_renew_hour'] = 12 # Hora para el intento de renovación diaria
letsencrypt['auto_renew_minute'] = 30 # Minuto para el intento de renovación diaria
letsencrypt['auto_renew_day_of_month'] = "*/7" # Una vez cada 7 días

# Habilitar la redirección de HTTP a HTTPS (recomendado)
nginx['redirect_http_to_https'] = true

Guarde el archivo y ejecute la reconfiguración de nuevo:

sudo gitlab-ctl reconfigure

GitLab intentará automáticamente obtener e instalar el certificado. Si encuentra problemas, asegúrese de que:

• Su dominio (gitlab.yourdomain.com) apunte correctamente a la dirección IP de su VPS.
• Los puertos 80 (HTTP) y 443 (HTTPS) estén abiertos en su firewall (UFW).

3. Verificación de la operatividad

Después de la configuración y reconfiguración, asegúrese de que GitLab funciona correctamente:

• Acceso a través de la interfaz web: Abra https://gitlab.yourdomain.com en su navegador. Debería ver la página de inicio de sesión de GitLab. Verifique que la conexión sea segura (el candado verde en la barra de direcciones).
• Verificación de la redirección HTTP: Intente acceder a http://gitlab.yourdomain.com. Debería ser redirigido automáticamente a la versión HTTPS.
• Verificación del estado de GitLab:

  
  # Verificación de los servicios principales de GitLab
  sudo gitlab-ctl status
  
  # Ejecución de la verificación de salud integrada de GitLab
  sudo gitlab-rake gitlab:check SANITIZE=true
              

  El comando gitlab-rake gitlab:check ejecutará una serie de verificaciones que mostrarán posibles problemas con la configuración, los permisos o la base de datos. Si hay errores, léalos atentamente y siga las recomendaciones.

• Verificación de puertos:

  
  # Verificación de que NGINX escucha en los puertos 80 y 443
  sudo netstat -tulnp | grep -E ':(80|443)'
              

En este punto, su GitLab autoalojado debería estar completamente funcional y accesible a través de una conexión segura.

Copias de seguridad y mantenimiento

La copia de seguridad es una parte fundamental de cualquier sistema de producción. GitLab cuenta con mecanismos integrados para crear copias de seguridad que permiten guardar todos los datos: repositorios Git, bases de datos, archivos subidos, configuración y secretos.

1. Qué respaldar

GitLab Omnibus incluye todo lo necesario. El comando de copia de seguridad de GitLab guarda por defecto:

• Base de datos PostgreSQL
• Repositorios Git
• Archivos subidos (avatares, adjuntos)
• Archivos de configuración (no todos, pero los principales)
• Secretos (claves de cifrado)

Importante: el archivo /etc/gitlab/gitlab.rb y el directorio /etc/gitlab/ssl/ (si utiliza certificados personalizados) no se incluyen en la copia de seguridad estándar de GitLab. Deben ser respaldados por separado.

2. Script sencillo de copia de seguridad automática

GitLab proporciona un comando conveniente para crear copias de seguridad. Puede configurar su ejecución a través de cron.

Paso 1: Creación manual de la copia de seguridad

# Creación de una copia de seguridad completa de GitLab
sudo gitlab-rake gitlab:backup:create

Las copias de seguridad se guardan por defecto en /var/opt/gitlab/backups/. Los archivos tienen el formato [TIMESTAMP]_gitlab_backup.tar.

Paso 2: Configuración de la copia de seguridad automática con Cron

Abra la tabla cron para editarla:

sudo crontab -e

Añada la siguiente línea para que GitLab cree una copia de seguridad todos los días a las 02:00 de la madrugada:

# Copia de seguridad diaria de GitLab a las 02:00
0 2 * * * sudo gitlab-rake gitlab:backup:create CRON=1

La opción CRON=1 suprime las solicitudes interactivas y hace que la salida sea más concisa, lo que es útil para tareas automatizadas.

Paso 3: Copia de seguridad de los archivos de configuración

Cree un script separado para la copia de seguridad de gitlab.rb y otros archivos importantes:

sudo mkdir -p /var/opt/gitlab/config_backups
sudo nano /usr/local/bin/gitlab_config_backup.sh

Añada el siguiente contenido al archivo:

#!/bin/bash
TIMESTAMP=$(date +%F_%H-%M-%S)
BACKUP_DIR="/var/opt/gitlab/config_backups"
CONFIG_FILES="/etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /etc/gitlab/ssl" # Añada otros archivos/carpetas importantes

# Creación de un archivo con los ficheros de configuración
sudo tar -czf "$BACKUP_DIR/${TIMESTAMP}_gitlab_config.tar.gz" $CONFIG_FILES

# Eliminación de copias de seguridad antiguas (por ejemplo, de más de 7 días)
find "$BACKUP_DIR" -type f -name "*.tar.gz" -mtime +7 -delete

echo "Copia de seguridad de la configuración de GitLab creada: $BACKUP_DIR/${TIMESTAMP}_gitlab_config.tar.gz"

Haga el script ejecutable:

sudo chmod +x /usr/local/bin/gitlab_config_backup.sh

Añádalo a crontab (por ejemplo, a las 02:30):

# Copia de seguridad diaria de la configuración de GitLab a las 02:30
30 2 * * * sudo /usr/local/bin/gitlab_config_backup.sh

3. Dónde almacenar las copias de seguridad

Almacenar las copias de seguridad en el mismo servidor que la instancia principal de GitLab es extremadamente arriesgado. Si pierde el servidor, también perderá las copias de seguridad. Se recomienda utilizar un almacenamiento externo:

• Almacenamiento en la nube compatible con S3: AWS S3, DigitalOcean Spaces, Backblaze B2. GitLab Omnibus soporta la carga directa de copias de seguridad a S3. Para ello, edite /etc/gitlab/gitlab.rb:

  
  # Habilitar la carga de copias de seguridad a S3
  gitlab_rails['backup_upload_connection'] = {
    'provider' => 'AWS',
    'region' => 'us-east-1', # Reemplace con su región S3
    'aws_access_key_id' => 'ВАШ_AWS_ACCESS_KEY_ID',
    'aws_secret_access_key' => 'ВАШ_AWS_SECRET_ACCESS_KEY'
  }
  gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups' # Nombre de su bucket S3
              

  Después de los cambios, ejecute sudo gitlab-ctl reconfigure.

• VPS separado: Puede configurar un segundo VPS pequeño y usar rsync o scp para transferir regularmente las copias de seguridad del servidor principal a este.
• NAS/servidor local: Si tiene su propio hardware, puede configurar un almacenamiento en red.

Importante: utilice credenciales separadas (usuario IAM) para S3 con permisos mínimos (solo escritura en el bucket especificado).

4. Actualizaciones: rolling vs maintenance window

Las actualizaciones regulares de GitLab son críticas para la seguridad y para obtener nuevas funciones. GitLab lanza nuevas versiones mensualmente (major.minor.patch).

• Rolling updates (no recomendado para GitLab): Este es un enfoque en el que las actualizaciones se aplican inmediatamente a medida que se lanzan. Para GitLab, esto es peligroso, ya que cada actualización puede contener cambios en la base de datos o la configuración que requieren atención.
• Maintenance window: Enfoque recomendado. Planifique una ventana de mantenimiento regular (por ejemplo, una vez al mes) para actualizar GitLab. Esto le permite prepararse, hacer una copia de seguridad y, en caso de problemas, revertir rápidamente.

  
  # Detener GitLab antes de la actualización
  sudo gitlab-ctl stop
  
  # Actualizar el sistema y GitLab
  sudo apt update
  sudo apt upgrade -y gitlab-ce
  
  # Iniciar GitLab después de la actualización
  sudo gitlab-ctl start
  
  # Reconfiguración (a veces necesaria después de actualizaciones mayores)
  sudo gitlab-ctl reconfigure
  
  # Comprobar el estado
  sudo gitlab-ctl status
  sudo gitlab-rake gitlab:check
              

Lea siempre las instrucciones oficiales de actualización de GitLab para su versión específica, ya que puede haber pasos específicos entre versiones mayores.

Solución de problemas + Preguntas frecuentes

¿Qué hacer si GitLab no se inicia después de un reinicio?

Primero, revise los registros. Los registros principales de GitLab se encuentran en /var/log/gitlab/. Empiece por gitlab-rails/production.log, nginx/gitlab_access.log, nginx/gitlab_error.log y gitlab-shell/gitlab-shell.log. También ejecute sudo gitlab-ctl status para ver qué servicios no están iniciados. A menudo, el problema está relacionado con la falta de memoria o una configuración incorrecta en /etc/gitlab/gitlab.rb. Intente ejecutar sudo gitlab-ctl reconfigure y sudo gitlab-ctl restart.

No se puede obtener un certificado SSL de Let's Encrypt. ¿Cuál es el problema?

Las causas más comunes: 1) El registro DNS de su dominio está configurado incorrectamente — asegúrese de que el registro A apunte a la dirección IP de su VPS. 2) El puerto 80 o 443 está bloqueado por el firewall (UFW o el firewall del proveedor del VPS). Asegúrese de que sudo ufw status muestre allow 80/tcp y allow 443/tcp. 3) Otro proceso ya está escuchando en el puerto 80 o 443. Compruebe sudo netstat -tulnp | grep -E ':(80|443)'. 4) Errores en /etc/gitlab/gitlab.rb, por ejemplo, un external_url incorrecto o la falta de contact_emails para Let's Encrypt.

¿Qué configuración mínima de VPS es adecuada?

Para un solo usuario o un equipo muy pequeño (hasta 3-5 personas) con un mínimo de actividad y sin CI/CD intensivo, un VPS mínimamente aceptable debe tener 2 núcleos de CPU, 4 GB de RAM y 50 GB de SSD. Sin embargo, para un funcionamiento más cómodo y estable, especialmente si se planea usar CI/CD, se recomienda encarecidamente 4 núcleos de CPU, 8 GB de RAM y 100 GB de NVMe SSD. Parámetros menores provocarán ralentizaciones y fallos constantes debido a la falta de recursos.

¿Qué elegir — VPS o dedicado para esta tarea?

La elección entre un VPS y un servidor dedicado depende de la escala de su equipo y la intensidad del uso de GitLab. Para la mayoría de los equipos pequeños y medianos (hasta 50-70 personas) con CI/CD moderado, un VPS bien configurado (por ejemplo, 8-16 GB de RAM, 8 vCPU, 200+ GB NVMe SSD) será más que suficiente y económicamente ventajoso. Un servidor dedicado es preferible para equipos muy grandes (cientos de usuarios), pipelines de CI/CD de alta carga, requisitos específicos de rendimiento de E/S o aislamiento físico completo de los recursos. En cualquier caso, empiece con un VPS y escale a un dedicado si surgen problemas de rendimiento.

¿Cómo cambiar el tamaño máximo de archivo para subir?

El tamaño máximo de archivo para subir en GitLab está limitado por defecto. Para cambiarlo, edite /etc/gitlab/gitlab.rb. Busque o añada las siguientes líneas:

# Aumentar el límite de subida de NGINX a 2048MB (2GB)
nginx['client_max_body_size'] = '2048m'

# Aumentar el límite de Git (para archivos LFS grandes)
gitlab_rails['gitlab_shell_git_max_size'] = 2048000 # En KB, 2GB

Después de guardar el archivo, ejecute sudo gitlab-ctl reconfigure.

¿Cómo actualizar GitLab a una nueva versión?

El proceso de actualización incluye varios pasos. Primero, realice una copia de seguridad completa de GitLab. Luego, detenga los servicios de GitLab: sudo gitlab-ctl stop. Actualice los paquetes del sistema y GitLab: sudo apt update && sudo apt upgrade -y gitlab-ce. Después de la actualización, inicie GitLab: sudo gitlab-ctl start y realice la reconfiguración: sudo gitlab-ctl reconfigure. Siempre consulte la documentación oficial de GitLab sobre actualizaciones para su versión específica, ya que puede haber pasos adicionales entre versiones mayores.

Conclusiones y próximos pasos

¡Felicidades! Ha instalado y configurado con éxito GitLab autoalojado en su VPS, asegurándolo con SSL/TLS e implementando una estrategia de copia de seguridad. Ahora tiene una plataforma potente y flexible para gestionar sus proyectos de desarrollo, control de versiones y automatización de procesos CI/CD, completamente bajo su control.

Aquí hay algunos pasos a seguir:

• Configuración de GitLab CI/CD: Explore las capacidades de GitLab CI/CD para automatizar la compilación, prueba y despliegue de sus aplicaciones. Configure GitLab Runner en un servidor separado o en un contenedor Docker para el aislamiento y la escalabilidad de las tareas de CI/CD.
• Integración con servicios externos: Conecte GitLab a sus herramientas existentes, como sistemas de seguimiento de tareas (Jira), almacenamientos de artefactos externos o sistemas de monitoreo.
• Monitoreo del rendimiento: Implemente herramientas de monitoreo (por ejemplo, Prometheus y Grafana) para rastrear la salud y el rendimiento de su instancia de GitLab, a fin de responder a tiempo a posibles problemas y planificar la escalabilidad.