1. Objetivo del proyecto
El objetivo es instalar un servidor GitLab Self-Managed sobre una máquina con Ubuntu Server.
Este servidor permitirá:
- Guardar proyectos de programación.
- Centralizar scripts personales.
- Mantener archivos de configuración.
- Trabajar desde diferentes ordenadores.
- Controlar las versiones de los archivos.
- Recuperar versiones anteriores.
- Desplegar proyectos en otros servidores.
- Automatizar despliegues mediante GitLab CI/CD.
- Mantener copias de seguridad de todos los repositorios.
Aunque muchas veces se utiliza la expresión “instalar un GitHub”, realmente instalaremos GitLab, que ofrece un servicio similar a GitHub, pero alojado en nuestro propio servidor.
La arquitectura inicial será:
Ordenador personal
│
│ Git mediante SSH o HTTPS
▼
https://gitlab.tudominio.es
│
▼
Router de Internet
│
│ Puertos 80, 443 y 2222
▼
Ubuntu Server
│
▼
Docker Compose
│
▼
GitLab Community Edition
Fase 0. Planificación y requisitos
0.1. Requisitos recomendados
Para una instalación personal se recomienda:
- Ubuntu Server 22.04 LTS o 24.04 LTS.
- Procesador de 64 bits.
- 4 núcleos de CPU recomendados.
- 8 GB de RAM recomendados.
- 50 GB de almacenamiento como mínimo.
- Dirección IP local fija.
- Dominio propio.
- Acceso a la configuración del router.
- Conexión a Internet sin CG-NAT, o con posibilidad de abrir puertos.
- Usuario de Ubuntu con permisos
sudo.
GitLab consume bastantes más recursos que un servidor Git básico. Con 4 GB de RAM puede funcionar para pruebas, pero para un uso continuado es preferible disponer de 8 GB o más.
0.2. Datos utilizados en los ejemplos
Durante la documentación utilizaremos estos datos:
Dominio: gitlab.tudominio.es
IP local del servidor: 192.168.1.50
Puerto web HTTP: 80
Puerto web HTTPS: 443
Puerto SSH de GitLab: 2222
Directorio de instalación: /srv/gitlab
El puerto SSH externo será el 2222 porque el puerto 22 normalmente ya está siendo utilizado por el servicio SSH de Ubuntu Server.
0.3. Comprobar la versión de Ubuntu
lsb_release -a
También podemos utilizar:
cat /etc/os-release
0.4. Comprobar procesador, memoria y almacenamiento
Procesador:
lscpu
Memoria:
free -h
Espacio en disco:
df -h
0.5. Actualizar Ubuntu Server
sudo apt update
sudo apt upgrade -y
Reiniciamos si se ha actualizado el kernel:
sudo reboot
Fase 1. Configuración de red y dominio
1.1. Asignar una IP fija al servidor
El servidor debe mantener siempre la misma dirección IP dentro de la red local.
Tenemos dos posibilidades:
- Crear una reserva DHCP en el router.
- Configurar una IP estática en Ubuntu Server.
La opción más sencilla suele ser crear una reserva DHCP en el router asociando la dirección MAC del servidor con una IP, por ejemplo:
192.168.1.50
Para consultar la dirección IP actual:
ip address
Versión abreviada:
ip -br address
Para conocer la puerta de enlace:
ip route
1.2. Comprobar la IP pública
Desde el servidor podemos ejecutar:
curl https://ifconfig.me
También podemos consultar la IP pública desde el panel del router.
1.3. Crear el registro DNS
En el proveedor del dominio debemos crear un registro de tipo A.
Ejemplo:
Tipo: A
Nombre: gitlab
Destino: IP_PUBLICA
TTL: Automático
El resultado será:
gitlab.tudominio.es → IP pública del router
Si la conexión utiliza una IP pública dinámica, será necesario configurar un servicio de DNS dinámico o actualizar automáticamente el registro DNS.
El dominio debe resolver públicamente hacia el servidor para que GitLab pueda solicitar automáticamente el certificado HTTPS de Let’s Encrypt.
1.4. Comprobar la resolución DNS
Desde otro ordenador:
nslookup gitlab.tudominio.es
En Linux o macOS también podemos utilizar:
dig gitlab.tudominio.es
El resultado debe mostrar nuestra IP pública.
1.5. Configurar la redirección de puertos
En el router debemos crear estas reglas NAT o Port Forwarding:
| Puerto externo | IP interna | Puerto interno | Protocolo |
|---|---|---|---|
| 80 | 192.168.1.50 | 80 | TCP |
| 443 | 192.168.1.50 | 443 | TCP |
| 2222 | 192.168.1.50 | 2222 | TCP |
Los puertos 80 y 443 deben ser accesibles desde Internet para la validación y renovación automática del certificado de Let’s Encrypt.
1.6. Comprobar si existe CG-NAT
Compara:
- La IP pública mostrada por el router.
- La IP obtenida con
curl https://ifconfig.me.
Si son diferentes, es posible que la conexión esté detrás de CG-NAT.
En ese caso, las redirecciones de puertos no funcionarán directamente. Las alternativas serían:
- Solicitar una IP pública al proveedor.
- Utilizar una VPN como WireGuard o Tailscale.
- Utilizar un túnel inverso.
- Alojar GitLab en un VPS.
Fase 2. Instalación de Docker y Docker Compose
2.1. Eliminar paquetes incompatibles
Antes de instalar Docker desde su repositorio oficial eliminamos posibles versiones anteriores:
sudo apt remove -y \
docker.io \
docker-compose \
docker-compose-v2 \
docker-doc \
podman-docker \
containerd \
runc
No ocurre nada si algunos de estos paquetes no estaban instalados.
Docker recomienda utilizar su repositorio oficial de APT e instalar el complemento moderno docker compose, en lugar del antiguo ejecutable independiente docker-compose.
2.2. Instalar las dependencias
sudo apt update
sudo apt install -y ca-certificates curl
2.3. Añadir la clave oficial de Docker
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL \
https://download.docker.com/linux/ubuntu/gpg \
-o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
2.4. Añadir el repositorio
sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOFActualizamos la información de paquetes:
sudo apt update
2.5. Instalar Docker
sudo apt install -y \
docker-ce \
docker-ce-cli \
containerd.io \
docker-buildx-plugin \
docker-compose-plugin
2.6. Comprobar el servicio
sudo systemctl status docker
Debe aparecer:
active (running)
Para salir de la pantalla de estado pulsamos:
q
2.7. Activar Docker durante el arranque
sudo systemctl enable docker
2.8. Probar Docker
sudo docker run --rm hello-world
2.9. Comprobar Docker Compose
sudo docker compose version
Debe aparecer una versión de Docker Compose.
2.10. Permitir utilizar Docker sin sudo
Añadimos nuestro usuario al grupo docker:
sudo usermod -aG docker "$USER"
Cerramos la sesión cambiado de usuario o reiniciando.
Volvemos a conectarnos por SSH y comprobamos:
docker ps
Pertenecer al grupo
dockerproporciona privilegios elevados sobre el sistema. Solamente deben añadirse usuarios de confianza.
Fase 3. Preparación del servidor GitLab
3.1. Crear la estructura de directorios
sudo mkdir -p /srv/gitlab
Creamos los directorios persistentes:
sudo mkdir -p /srv/gitlab/config
sudo mkdir -p /srv/gitlab/logs
sudo mkdir -p /srv/gitlab/data
sudo mkdir -p /srv/gitlab/backups
Asignamos los directorios al usuario actual:
sudo chown -R "$USER":"$USER" /srv/gitlab
Entramos en el directorio:
cd /srv/gitlab
3.2. Función de los directorios
| Directorio del servidor | Directorio del contenedor | Contenido |
|---|---|---|
/srv/gitlab/config | /etc/gitlab | Configuración y secretos |
/srv/gitlab/logs | /var/log/gitlab | Registros |
/srv/gitlab/data | /var/opt/gitlab | Repositorios y datos |
/srv/gitlab/backups | — | Copias adicionales |
La imagen oficial de GitLab utiliza precisamente /etc/gitlab, /var/log/gitlab y /var/opt/gitlab para conservar la configuración, los registros y los datos.
Fase 4. Instalación de GitLab con Docker Compose
4.1. Elegir una versión
GitLab ofrece:
- GitLab Community Edition:
gitlab/gitlab-ce - GitLab Enterprise Edition:
gitlab/gitlab-ee
Para este proyecto personal utilizaremos Community Edition.
Para una primera prueba se puede utilizar:
gitlab/gitlab-ce:latest
Sin embargo, cuando el servidor esté funcionando conviene fijar una versión concreta:
gitlab/gitlab-ce:19.x.x-ce.0
GitLab recomienda fijar una versión específica en entornos estables y utilizar latest principalmente para pruebas.
4.2. Crear el archivo .env
nano /srv/gitlab/.env
Contenido:
GITLAB_HOSTNAME=gitlab.tudominio.es
GITLAB_IMAGE=gitlab/gitlab-ce:latest
Guardamos con:
Ctrl + O
Enter
Ctrl + X
4.3. Crear compose.yaml
nano /srv/gitlab/compose.yaml
Contenido:
services:
gitlab:
image: gitlab/gitlab-ce:latest
container_name: gitlab
hostname: 192.168.1.14
restart: unless-stopped
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url 'http://192.168.1.14:8929'
nginx['listen_port'] = 80
nginx['listen_https'] = false
letsencrypt['enable'] = false
gitlab_rails['gitlab_shell_ssh_port'] = 2222
ports:
- "8929:80"
- "2222:22"
volumes:
- ./config:/etc/gitlab
- ./logs:/var/log/gitlab
- ./data:/var/opt/gitlab
shm_size: "256m"
La configuración utiliza:
Puerto 80 del servidor → puerto 80 de GitLab
Puerto 443 del servidor → puerto 443 de GitLab
Puerto 2222 del servidor → puerto 22 del contenedor
El valor:
gitlab_rails['gitlab_shell_ssh_port'] = 2222
indica a GitLab que debe mostrar el puerto 2222 en las direcciones de clonación SSH. La documentación oficial contempla configurar un puerto SSH externo diferente cuando el puerto 22 del servidor está ocupado.
4.4. Validar el archivo
cd /srv/gitlab
docker compose config
Si no aparecen errores, la sintaxis es correcta.
4.5. Descargar la imagen
docker compose pull
4.6. Iniciar GitLab
docker compose up -d
4.7. Consultar el estado
docker compose ps
4.8. Consultar los registros
docker compose logs -f gitlab
Para dejar de visualizar los registros:
Ctrl + CLa primera inicialización es más lenta que los siguientes arranques porque GitLab debe configurar PostgreSQL, Redis, NGINX, Gitaly y el resto de sus componentes internos.
4.9. Comprobar el estado interno
docker exec -it gitlab gitlab-ctl status
También podemos comprobar el endpoint de estado:
curl -I https://gitlab.tudominio.es
Fase 5. Primer acceso y configuración inicial
5.1. Obtener la contraseña inicial
docker exec -it gitlab \
grep 'Password:' /etc/gitlab/initial_root_password
El usuario inicial es:
root
El archivo con la contraseña inicial se elimina automáticamente después del primer reinicio transcurridas aproximadamente 24 horas, por lo que conviene obtenerla y cambiarla cuanto antes.
5.2. Entrar en GitLab
Revisa la configuración persistente
Como /srv/gitlab/config es persistente, puede conservarse la dirección anterior.
Ejecuta:
grep -n "external_url" /srv/gitlab/config/gitlab.rbSi aparece:
external_url 'https://gitlab.tudominio.es'edita el archivo:
sudo nano /srv/gitlab/config/gitlab.rbCámbialo por:
external_url 'http://192.168.1.14:8929'Introducimos:
Usuario: root
Contraseña: la obtenida anteriormente
5.3. Cambiar la contraseña de root
Dentro de GitLab:
Avatar
→ Edit profile
→ Password
Debemos utilizar una contraseña larga y exclusiva.
5.4. Crear un usuario personal
Es preferible no trabajar diariamente con root.
Entramos en:
Admin
→ Overview
→ Users
→ New user
Ejemplo:
Nombre: Antonio Otero
Usuario: antonio
Correo: correo@tudominio.es
Podemos marcar el usuario como administrador si realmente necesitamos administrar GitLab desde esa cuenta.
5.5. Desactivar el registro público
Como el servidor está expuesto a Internet y será de uso personal, debemos impedir que cualquier visitante pueda crear una cuenta.
Ruta:
Admin
→ Settings
→ General
→ New user account restrictions
Desmarcamos:
Allow new user accounts
GitLab recomienda plantearse la desactivación del registro en instancias públicas donde no se espera que usuarios externos creen cuentas.
5.6. Limitar la visibilidad predeterminada
En:
Admin
→ Settings
→ General
→ Visibility and access controls
Configuramos:
Default project visibility: Private
Default snippet visibility: Private
Default group visibility: Private
5.7. Activar autenticación de dos factores
En la cuenta personal:
Avatar
→ Edit profile
→ Account
→ Two-factor authentication
Guardamos los códigos de recuperación en un lugar seguro.
Fase 6. Configuración de Git y claves SSH
GitLab permite trabajar mediante HTTPS o SSH. Para trabajar habitualmente desde varios equipos utilizaremos SSH, que GitLab recomienda como método de autenticación para clonar repositorios.
6.1. Instalar Git en Ubuntu o Debian
sudo apt update
sudo apt install -y git
6.2. Instalar Git en Windows
Puede instalarse Git for Windows y utilizar:
- Git Bash.
- PowerShell.
- Visual Studio Code.
- Un IDE compatible con Git.
6.3. Comprobar la instalación
git --version
6.4. Configurar el nombre y el correo
En cada ordenador:
git config --global user.name "Antonio Otero"
git config --global user.email "correo@tudominio.es"
Comprobamos:
git config --global --list
6.5. Crear una clave SSH
En Linux, macOS, PowerShell o Git Bash:
ssh-keygen -t ed25519 -C "portatil-personal"
Cuando pregunte dónde guardar la clave, pulsamos Enter.
Ruta habitual:
Linux/macOS:
~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub
Windows:
C:\Users\USUARIO\.ssh\id_ed25519
C:\Users\USUARIO\.ssh\id_ed25519.pub
Es recomendable establecer una contraseña para proteger la clave privada.
6.6. Mostrar la clave pública
Linux o macOS:
cat ~/.ssh/id_ed25519.pub
Windows PowerShell:
Get-Content $HOME\.ssh\id_ed25519.pub
Copiamos el contenido completo.
6.7. Añadir la clave a GitLab
En GitLab:
Avatar
→ Edit profile
→ Access
→ SSH keys
→ Add new key
Indicamos un nombre identificativo:
MacBook Pro
PC principal
Portátil Windows
Equipo del trabajo
Cada ordenador debe tener su propia clave. No es recomendable copiar la misma clave privada entre todos los equipos.
6.8. Configurar el puerto SSH personalizado
Creamos o editamos:
nano ~/.ssh/config
Contenido:
Host gitlab-personal
HostName gitlab.tudominio.es
User git
Port 2222
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
Protegemos el archivo:
chmod 600 ~/.ssh/config
6.9. Probar la conexión
ssh -T gitlab-personal
La primera vez aparecerá una pregunta sobre la huella del servidor.
Después de comprobar que el nombre del servidor es correcto, respondemos:
yes
El resultado esperado será parecido a:
Welcome to GitLab, @antonio!
También podemos probar directamente:
ssh -T -p 2222 git@gitlab.tudominio.es
Fase 7. Crear y utilizar el primer repositorio
7.1. Crear un proyecto en GitLab
Entramos en:
New project
→ Create blank project
Ejemplo:
Project name: scripts-linux
Project slug: scripts-linux
Visibility level: Private
Podemos marcar:
Initialize repository with a README
7.2. Clonar el repositorio
Utilizando el alias SSH:
git clone gitlab-personal:antonio/scripts-linux.git
Entramos en el proyecto:
cd scripts-linux
7.3. Crear un archivo
nano informacion-sistema.sh
Contenido:
#!/bin/bash
echo "Nombre del equipo:"
hostname
echo
echo "Sistema operativo:"
cat /etc/os-release
echo
echo "Memoria:"
free -h
echo
echo "Almacenamiento:"
df -h
Guardamos y damos permisos:
chmod +x informacion-sistema.sh
7.4. Consultar el estado
git status
7.5. Añadir los cambios
git add informacion-sistema.sh
También podríamos añadir todos los archivos:
git add .
7.6. Crear un commit
git commit -m "Añadido script de información del sistema"
7.7. Subir los cambios
git push
7.8. Flujo de trabajo habitual
Cada vez que comencemos a trabajar:
git pull
Después modificamos los archivos y ejecutamos:
git status
git add .
git commit -m "Descripción clara de los cambios"
git push
Fase 8. Trabajar desde varios ordenadores
8.1. Primer ordenador
En el primer equipo:
git clone gitlab-personal:antonio/scripts-linux.git
cd scripts-linux
Modificamos y subimos cambios:
git add .
git commit -m "Cambios realizados desde el PC principal"
git push
8.2. Segundo ordenador
Configuramos su propia clave SSH y la añadimos a GitLab.
Después:
git clone gitlab-personal:antonio/scripts-linux.git
cd scripts-linux
Antes de trabajar:
git pull
Realizamos los cambios:
git add .
git commit -m "Cambios realizados desde el portátil"
git push
8.3. Regla fundamental
Antes de empezar una sesión de trabajo:
git pull
Después de terminar:
git add .
git commit -m "Explicación de los cambios"
git push
8.4. Evitar conflictos
No conviene modificar simultáneamente las mismas líneas del mismo archivo desde dos equipos sin haber sincronizado antes.
Flujo recomendado:
git pull
Trabajamos.
git add .
git commit -m "Cambios"
git push
8.5. Resolver un conflicto sencillo
Si git pull detecta un conflicto, el archivo mostrará algo parecido a:
<<<<<<< HEAD
Contenido local
=======
Contenido procedente del servidor
>>>>>>> origin/main
Debemos editar el archivo y dejar solamente el contenido definitivo.
Después:
git add archivo-conflictivo
git commit -m "Resuelto conflicto de sincronización"
git push
Fase 9. Organización de los repositorios personales
Para mantener el servidor ordenado podemos crear un grupo llamado:
personal
Dentro del grupo podemos crear repositorios como:
personal/scripts-linux
personal/scripts-windows
personal/docker-compose
personal/configuraciones
personal/wordpress
personal/php
personal/java
personal/python
personal/documentacion
personal/proyectos-clase
9.1. Qué debe guardarse
Ejemplos adecuados:
- Código fuente.
- Scripts Bash.
- Scripts PowerShell.
- Archivos Docker Compose.
- Plantillas HTML y CSS.
- Documentación Markdown.
- Configuraciones sin credenciales.
- Proyectos Java, PHP, Python o JavaScript.
- Consultas SQL.
- Diagramas.
- Archivos pequeños relacionados con el proyecto.
9.2. Qué no debe guardarse directamente
No deben subirse:
- Contraseñas.
- Claves privadas SSH.
- Tokens de acceso.
- Archivos
.envcon credenciales. - Copias completas de bases de datos con datos sensibles.
- Directorios de dependencias regenerables.
- Imágenes de máquinas virtuales.
- Archivos temporales.
- Copias de seguridad grandes.
- Certificados privados.
9.3. Utilizar .gitignore
Ejemplo para un proyecto PHP:
.env
vendor/
node_modules/
*.log
.DS_Store
.vscode/
.idea/
Ejemplo para Java:
target/
bin/
.classpath
.project
.settings/
*.class
*.jar
.idea/
Ejemplo para Python:
__pycache__/
*.pyc
.venv/
venv/
.env
Fase 10. Importar un proyecto existente
Supongamos que tenemos un proyecto en:
/home/antonio/proyectos/mi-web
Entramos en él:
cd /home/antonio/proyectos/mi-web
Inicializamos Git:
git init
Creamos la rama principal:
git branch -M main
Añadimos los archivos:
git add .
Creamos el primer commit:
git commit -m "Importación inicial del proyecto"
Creamos un proyecto vacío en GitLab y añadimos el remoto:
git remote add origin \
ssh://git@gitlab.tudominio.es:2222/antonio/mi-web.git
Subimos el proyecto:
git push -u origin main
Para consultar el remoto:
git remote -v
Fase 11. Despliegue manual en otro ordenador
GitLab almacenará el proyecto, pero también queremos desplegarlo en otros servidores.
Supongamos que tenemos un servidor web con Ubuntu en:
192.168.1.80
11.1. Instalar Git en el servidor destino
sudo apt update
sudo apt install -y git
11.2. Crear una clave exclusiva de despliegue
En el servidor destino:
ssh-keygen -t ed25519 -C "despliegue-servidor-web"
Mostramos la clave pública:
cat ~/.ssh/id_ed25519.pub
11.3. Añadir una Deploy Key
En el proyecto de GitLab:
Settings
→ Repository
→ Deploy keys
→ Add new key
Introducimos:
Title: Servidor web
Key: contenido de id_ed25519.pub
Para un despliegue que solamente descarga archivos, no activamos permisos de escritura.
Las Deploy Keys están pensadas precisamente para permitir que servidores externos accedan a repositorios sin asociar el acceso a la clave personal de un usuario.
11.4. Configurar SSH en el servidor destino
nano ~/.ssh/config
Contenido:
Host gitlab-personal
HostName gitlab.tudominio.es
User git
Port 2222
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
Permisos:
chmod 600 ~/.ssh/config
11.5. Clonar el proyecto
sudo mkdir -p /var/www
sudo chown "$USER":"$USER" /var/www
cd /var/www
git clone gitlab-personal:antonio/mi-web.git
11.6. Actualizar el despliegue
Cuando subamos cambios a GitLab:
cd /var/www/mi-web
git pull origin main
Este sería el despliegue manual más sencillo.
Fase 12. Crear un script de despliegue
En el servidor destino:
sudo nano /usr/local/bin/desplegar-mi-web.sh
Contenido:
#!/bin/bash
set -e
PROYECTO="/var/www/mi-web"
RAMA="main"
echo "Iniciando despliegue..."
cd "$PROYECTO"
echo "Descargando cambios..."
git fetch origin
echo "Actualizando la rama $RAMA..."
git reset --hard "origin/$RAMA"
echo "Corrigiendo permisos..."
sudo chown -R www-data:www-data "$PROYECTO"
echo "Despliegue terminado correctamente."
Damos permisos:
sudo chmod +x /usr/local/bin/desplegar-mi-web.sh
Ejecutamos:
sudo /usr/local/bin/desplegar-mi-web.sh
El uso de:
git reset --hard origin/main
garantiza que el directorio desplegado coincida exactamente con el contenido del repositorio remoto.
Debe utilizarse solamente en un directorio de despliegue donde no se hagan cambios manuales que queramos conservar.
Fase 13. Introducción al despliegue automático con GitLab Runner
En una fase posterior podemos automatizar el despliegue mediante GitLab CI/CD.
El flujo será:
Ordenador
│
│ git push
▼
GitLab
│
│ Ejecuta pipeline
▼
GitLab Runner
│
│ Conecta por SSH
▼
Servidor de despliegue
GitLab Runner puede ejecutarse dentro de un contenedor Docker y ejecutar los trabajos definidos en .gitlab-ci.yml.
13.1. Ejemplo conceptual de .gitlab-ci.yml
stages:
- comprobar
- desplegar
comprobar:
stage: comprobar
script:
- echo "Comprobando el proyecto"
- test -f index.html
desplegar:
stage: desplegar
script:
- echo "Desplegando proyecto"
- ssh usuario@servidor-destino "/usr/local/bin/desplegar-mi-web.sh"
only:
- main
Las claves privadas utilizadas por CI/CD no deben ser las claves personales del usuario. GitLab recomienda utilizar claves específicas para la automatización y almacenarlas de forma protegida.
La instalación y configuración completa de Runner debe realizarse como una fase independiente después de dominar:
- Repositorios.
- Clonado.
- Commits.
- Push y pull.
- Claves SSH.
- Deploy Keys.
- Despliegue manual.
Fase 14. Copias de seguridad
Un repositorio Git distribuido ya proporciona copias parciales en los equipos donde se ha clonado, pero eso no sustituye una copia completa de GitLab.
La copia de GitLab debe incluir:
- Base de datos.
- Repositorios.
- Archivos subidos.
- Configuración.
- Secretos.
- Certificados.
- Archivo
compose.yaml. - Archivo
.env.
GitLab advierte de que debe conservarse también gitlab-secrets.json, porque contiene secretos necesarios para descifrar determinados datos durante una recuperación.
14.1. Crear una copia desde el contenedor
docker exec -t gitlab gitlab-backup create
La copia se guardará normalmente dentro de:
/srv/gitlab/data/backups
Consultamos:
sudo ls -lh /srv/gitlab/data/backups
14.2. Copiar la configuración
Creamos una carpeta con la fecha:
FECHA=$(date +%Y-%m-%d_%H-%M)
mkdir -p "/srv/gitlab/backups/$FECHA"
Copiamos la configuración:
sudo cp -a \
/srv/gitlab/config \
"/srv/gitlab/backups/$FECHA/"
Copiamos Compose y las variables:
cp /srv/gitlab/compose.yaml \
"/srv/gitlab/backups/$FECHA/"
cp /srv/gitlab/.env \
"/srv/gitlab/backups/$FECHA/"
14.3. Crear un archivo comprimido
cd /srv/gitlab/backups
sudo tar -czf "gitlab-config-$FECHA.tar.gz" "$FECHA"
14.4. Copia externa
La copia debe trasladarse a otro equipo o almacenamiento:
rsync -avh \
/srv/gitlab/backups/ \
usuario@servidor-copias:/copias/gitlab/
También se puede utilizar:
- NAS.
- Disco USB.
- Otro servidor.
- Almacenamiento cifrado en la nube.
rclone.- Copia mediante
scp.
Una copia guardada únicamente en el mismo disco que GitLab no protege frente a una avería física de ese disco.
Fase 15. Automatizar las copias
15.1. Crear un script
sudo nano /usr/local/sbin/copiar-gitlab.sh
Contenido:
#!/bin/bash
set -euo pipefail
FECHA=$(date +%Y-%m-%d_%H-%M-%S)
ORIGEN="/srv/gitlab"
DESTINO="/srv/gitlab/backups/$FECHA"
echo "Creando copia interna de GitLab..."
docker exec -t gitlab gitlab-backup create
echo "Copiando configuración..."
mkdir -p "$DESTINO"
cp -a "$ORIGEN/config" "$DESTINO/"
cp "$ORIGEN/compose.yaml" "$DESTINO/"
cp "$ORIGEN/.env" "$DESTINO/"
echo "Comprimiendo configuración..."
tar -czf "/srv/gitlab/backups/gitlab-config-$FECHA.tar.gz" \
-C "/srv/gitlab/backups" "$FECHA"
rm -rf "$DESTINO"
echo "Eliminando copias de configuración antiguas..."
find /srv/gitlab/backups \
-type f \
-name "gitlab-config-*.tar.gz" \
-mtime +14 \
-delete
echo "Copia terminada: $FECHA"
Damos permisos:
sudo chmod 700 /usr/local/sbin/copiar-gitlab.sh
15.2. Probar el script
sudo /usr/local/sbin/copiar-gitlab.sh
15.3. Programarlo con cron
sudo crontab -e
Añadimos:
0 3 * * * /usr/local/sbin/copiar-gitlab.sh >> /var/log/copiar-gitlab.log 2>&1
Esto ejecutará la copia todos los días a las 03:00.
Fase 16. Restauración básica
La restauración debe probarse antes de depender de ella.
GitLab exige que la instalación utilizada para restaurar tenga la misma versión y edición que la instalación que creó la copia.
16.1. Consultar la versión instalada
docker exec -it gitlab gitlab-rake gitlab:env:info
También podemos consultar la imagen:
docker inspect gitlab \
--format='{{.Config.Image}}'
Debemos anotar el resultado.
Ejemplo:
gitlab/gitlab-ce:19.x.x-ce.0
16.2. Detener los servicios que escriben en la base de datos
docker exec -it gitlab gitlab-ctl stop puma
docker exec -it gitlab gitlab-ctl stop sidekiq
16.3. Consultar las copias disponibles
ls -lh /srv/gitlab/data/backups
Supongamos que existe:
1750000000_2026_07_20_19.x.x_gitlab_backup.tar
El identificador de la copia sería:
1750000000_2026_07_20_19.x.x
16.4. Ejecutar la restauración
docker exec -it gitlab \
gitlab-backup restore \
BACKUP=1750000000_2026_07_20_19.x.x
16.5. Reiniciar GitLab
docker restart gitlab
16.6. Comprobar la instalación
docker exec -it gitlab gitlab-rake gitlab:check SANITIZE=true
Fase 17. Actualización de GitLab
No debemos actualizar una instalación estable utilizando latest sin revisar previamente los cambios.
17.1. Consultar la imagen actual
docker inspect gitlab \
--format='{{.Config.Image}}'
17.2. Crear una copia
sudo /usr/local/sbin/copiar-gitlab.sh
17.3. Cambiar la versión
Editamos:
nano /srv/gitlab/.env
Cambiamos:
GITLAB_IMAGE=gitlab/gitlab-ce:VERSION-ce.0
17.4. Descargar y recrear el contenedor
cd /srv/gitlab
docker compose pull
docker compose up -d
17.5. Consultar los registros
docker compose logs -f gitlab
17.6. Comprobar el estado
docker exec -it gitlab gitlab-rake gitlab:check SANITIZE=true
GitLab recomienda crear una copia antes de actualizar. Para saltos grandes también puede exigir versiones intermedias obligatorias, por lo que no debe pasarse directamente de una versión muy antigua a la última sin revisar la ruta de actualización.
Fase 18. Firewall básico
18.1. Instalar UFW
sudo apt install -y ufw
18.2. Permitir SSH del servidor
Antes de activar el firewall:
sudo ufw allow OpenSSH
18.3. Permitir GitLab
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 2222/tcp
18.4. Activar el firewall
sudo ufw enable
18.5. Consultar las reglas
sudo ufw status numbered
Resultado esperado:
22/tcp ALLOW
80/tcp ALLOW
443/tcp ALLOW
2222/tcp ALLOW
Fase 19. Mantenimiento habitual
19.1. Consultar contenedores
docker ps
19.2. Consultar el espacio ocupado
docker system df
sudo du -sh /srv/gitlab/*
19.3. Consultar los registros recientes
docker compose logs --tail=100 gitlab
19.4. Reiniciar GitLab
cd /srv/gitlab
docker compose restart gitlab
19.5. Detener GitLab
docker compose stop
19.6. Iniciar GitLab
docker compose start
19.7. Recrear el contenedor
docker compose up -d
19.8. Comprobar internamente GitLab
docker exec -it gitlab gitlab-rake gitlab:check SANITIZE=true
19.9. Consultar el estado de sus componentes
docker exec -it gitlab gitlab-ctl status
Fase 20. Comprobaciones finales
Al terminar el proyecto deben cumplirse los siguientes puntos:
- El servidor tiene una IP local fija.
- El dominio apunta a la IP pública.
- Los puertos 80, 443 y 2222 están redirigidos.
- GitLab se abre mediante HTTPS.
- El certificado es válido.
- El registro público de usuarios está desactivado.
- Los proyectos nuevos son privados.
- Se ha creado un usuario personal.
- La cuenta tiene autenticación de dos factores.
- Cada ordenador dispone de su propia clave SSH.
- Se puede clonar un repositorio.
- Se pueden realizar
pull,commitypush. - Un servidor externo puede clonar mediante una Deploy Key.
- Existe un procedimiento de despliegue.
- Se realizan copias automáticas.
- Las copias se guardan fuera del disco principal.
- Se conoce la versión exacta de GitLab.
- Se ha probado al menos una restauración.
Resultado final
Al completar todas las fases tendremos una infraestructura personal parecida a esta:
INTERNET
│
gitlab.tudominio.es
│
HTTPS / SSH
│
ROUTER
│
┌──────────┴──────────┐
│ │
80/443 2222
│ │
└──────────┬──────────┘
│
UBUNTU SERVER
│
DOCKER COMPOSE
│
GITLAB CE
│
┌─────────────────────┼─────────────────────┐
│ │ │
Repositorios Copias CI/CD futuro
│
┌─────┼─────────┬───────────────┐
│ │ │ │
PC MacBook Portátil Servidor web
El servidor GitLab será el punto central de trabajo, pero cada equipo conservará también una copia local de los repositorios que utilice.
El flujo diario será:
git pull
Trabajar sobre el proyecto.
git add .
git commit -m "Descripción de los cambios"
git push
Y el flujo de despliegue inicial será:
cd /var/www/proyecto
git pull origin main
Posteriormente podrá sustituirse por un pipeline automático de GitLab CI/CD.
![[Reto] – Infraestructura virtualizada con Ubuntu Server](https://laaventuradeaprender.com/wp-content/uploads/2026/03/9dc81aff-d57d-45b1-83e9-c70955561713.png)