With the update to DSM7, Synology does not provide a GitLab package anymore. The best way to keep GitLab running is to run it in a Docker container.
Also, the latest GitLab version provided by Synology is 13.12.2. In order to keep the data the same, the "old" version has to be installed in the container first and then updated to a recent version.
In order to test the export of the GitLab data from the Synology NAS before upgrading to DSM7, the GitLab container is first installed and run on another Arch Linux PC.
ssh access to the Synology NAS is enabled.
Log in via SSH to your NAS. Run the following command to create a backup:
sudo docker exec -u git -i synology_gitlab /home/git/gitlab/bin/rake gitlab:backup:create --trace
The backup file is in the directory /volume1/docker/gitlab/gitlab/backups. Copy the backup file to your PC or to a folder on your volume on your NAS where you can access it later.
Hint: It might be necessary to grant read permissions on the file for other users.
sudo chmod o+r volume1/docker/gitlab/gitlab/backups/?????_13.12.2_gitlab_backup.tar
Copy the environment keys; they will be needed to restore the backup.
GITLAB_SECRETS_OTP_KEY_BASE
GITLAB_SECRETS_DB_KEY_BASE
GITLAB_SECRETS_SECRET_KEY_BASE
Hint: You can get the environment variables via the terminal.
sudo docker ps
# CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
# xxxxxxxxxxx synology/gitlab:13.12.2-saml-patched "/sbin/entrypoint.sh…" 15 months ago Up 16 minutes 22/tcp, 0.0.0.0:30000->80/tcp, 0.0.0.0:30001->443/tcp synology_gitlab
sudo docker exec xxxxxxxxxxx cat /proc/1/environ | tr '\0' '\n'
Install docker
pacman -S docker
Install docker-compose
pacman -S docker-compose
Start docker deamon
sudo systemctl start docker.service
For xxxxxxxxxxxxxxxxxxxxxxxx insert the corresponding key from the Synology GitLab docker environment.
docker-compose.yml
services:
gitlab:
image: gitlab/gitlab-ce:13.12.2-ce.0
container_name: gitlab
restart: always
hostname: 'gitlab.example.com'
environment:
GITLAB_SECRETS_SECRET_KEY_BASE: "xxxxxxxxxxxxxxxxxxxxxxxx"
GITLAB_SECRETS_DB_KEY_BASE: "xxxxxxxxxxxxxxxxxxxxxxxx"
GITLAB_SECRETS_OTP_KEY_BASE: "xxxxxxxxxxxxxxxxxxxxxxxx"
GITLAB_OMNIBUS_CONFIG: |
external_url 'http://gitlab.example.com:8929'
gitlab_rails['gitlab_shell_ssh_port'] = 2424
ports:
- '8929:8929'
- '443:443'
- '2424:22'
volumes:
- '/srv/gitlab/config:/etc/gitlab'
- '/srv/gitlab/logs:/var/log/gitlab'
- '/srv/gitlab/data:/var/opt/gitlab'
shm_size: '256m'
Ensure that you do not overwrite existing data!
The folders must be created according to the folders defined in the docker-compose file.
sudo mkdir /srv/gitlab/config
sudo mkdir /srv/gitlab/logs
sudo mkdir /srv/gitlab/data
sudo mkdir /srv/gitlab/data/backups
# Run in the folder where the docker-compose.yml file was created.
sudo docker compose up -d
Verify that the container is running by opening GitLab's web interface (http://127.0.0.1:8929).
Copy the backup ?????_13.12.2_gitlab_backup.tar to folder /srv/gitlab/backups.
Enter into bash mode on the gitlab docker
sudo docker exec -ti <container_id> bash
Restore the backup
NOTE: The backup file name will look like this: 1770492387_2022_06_11_13.12.2_gitlab_backup.tar. For the restore command, the ending _gitlab_backup.tar has to be removed.
gitlab-backup restore 1770492387_2026_02_07_13.12.2
Note: There are several questions that have to be answered with yes. Also, for me, several errors have been displayed; all content was available after the restore.
In order to update GitLab to a recent version, a stepwise update procedure is suggested.
The update can be performed by stopping the Docker container, adjusting the version of the GitLab image in the docker-compose.yml file, and then starting the container again.
Please ensure to verify that the update was successful after every step. To be safe, further backups of the data can be done in between.
# change in docker-compose.yml
# image: gitlab/gitlab-ce:13.12.2-ce.0 -> image: gitlab/gitlab-ce:14.0.2-ce.0
# stop docker
sudo docker stop <container-id>
# start docker
sudo docker compose up -d
Here is a suggested upgrade pattern:
-> 13.12.2 -> 14.0.2 > 14.1.0 -> 14.1.3 -> 14.2.1 -> 14.2.2 -> 14.2.4 -> 14.3.1 -> 14.4.0 -> 14.5.0 -> 14.6.0-1 -> 14.7.0 -> 14.8.0 -> 14.9.0 -> 14.9.3 -> 14.10.0 -> 14.10.3 -> 15.0.0 -> 15.1.0 -> 15.2.2 -> 15.2.4 -> 15.3.3 -> 15.4.0
Ensure to update/upgrade the container until the version is reached that will be running under DSM7.
//TODO