Preliminary version. The functionality may change, but the basic features will be preserved. Compatibility with future versions is ensured, but may require additional migration actions.
Migration from Omnibus to Code
-
If GitLab uses local file storage for Docker Registry, you need to migrate the data to an S3 bucket that connects to Code, according to this guide:
aws --endpoint-url <https://your-object-storage-backend.com> s3 sync registry s3://mybucket
-
If you are using the
s3cmd
utility, run the commands3cmd --configure
to set up the connection configuration for S3. Then, use the following command to transfer data to the S3 bucket that is connected to Code:s3cmd sync registry s3://mybucket
where
registry
is the path to the Docker Registry storage folder in the file system.
-
Blob objects that use S3 Object Storage for data storage should be migrated to S3 buckets connected to the Code Operator, according to this guide:
- Configure two connections in
rclone
: old and new, where:old
is the connection to the S3 Storage linked to GitLab.new
is the connection to the S3 Storage bucket in the Code Operator.
- Run the command:
rclone sync -P old:BUCKET_NAME new:BUCKET_NAME
- Configure two connections in
-
Create a backup archive according to this guide. Add the
SKIP
option for objects migrated in step 2. If Object Storage is not used at all, theSKIP
option can be omitted. -
Upload the created backup archive to the administrator’s computer, then upload it to the S3 storage for backups specified in the
ModuleConfig
for Code, under thebucketName
field:backup: enabled: true restoreFromBackupMode: true s3: bucketName: d8-code-backup
The S3 bucket
d8-code-backup
should contain the backup archive, for example:1742909494_2025_03_25_17.8.1_gitlab_backup.tar
. -
Create secrets in the
d8-code
namespace:Place the corresponding values into these secrets.
-
Generate the
ModuleConfig
manifest and configure thebackup
block:backup: enabled: true restoreFromBackupMode: true s3: bucketName: code-backup external: accessKey: S3AccessKey provider: YCloud | Generic | AWS | AzureRM secretKey: S3SecretKey mode: External
-
Connect to the
toolbox
pod on the master host of the Deckhouse cluster. Example:/opt/deckhouse/bin/kubectl -n d8-code exec -it -c toolbox toolbox-64d4fb84cf-b7dwb -- bash
-
Inside the
toolbox
, run:backup-utility --restore -t <backup_timestamp>
For example:
backup-utility --restore -t 1742909494_2025_03_25_17.8.1
-
Disable the restore mode in the
ModuleConfig
for Code:- Run the command:
/opt/deckhouse/bin/kubectl edit mc code
- Change the value of
restoreFromBackupMode
tofalse
.
- Run the command:
-
Wait for the operator to restart the pods.
Migration from Code to Omnibus
-
Switch Code to backup mode by setting the
backup.restoreFromBackupMode
parameter totrue
in theModuleConfig
. This will temporarily disable all Code consumer components during the restore process. -
Use the
toolbox
pod and the built-inbackup-utility
tool to create a backup archive:kubectl -n d8-code exec <Toolbox pod name> -it -- backup-utility --restore -t <timestamp|URL>
For example:
/opt/deckhouse/bin/kubectl -n d8-code exec -it -c toolbox toolbox-64d4fb84cf-b7dwb -- backup-utility
-
Wait for the backup creation process to complete. Upon completion, the backup will be saved in the S3 storage specified in the
ModuleConfig
under thebackup
section:backup: enabled: true restoreFromBackupMode: true s3: bucketName: code-backup external: accessKey: S3AccessKey provider: YCloud | Generic | AWS | AzureRM secretKey: S3SecretKey mode: External
The name of the created archive will follow the format
<timestamp>_gitlab_backup.tar
. Example:1742909494_2025_03_25_17.8.1_gitlab_backup.tar
. -
Stop the
puma
andsidekiq
services:gitlab-ctl stop puma gitlab-ctl stop sidekiq
If GitLab is deployed in Docker, run these commands inside the container.
-
Download and transfer the backup archive to the directory where GitLab backups are stored:
- By default, this is
/var/opt/gitlab/backups
. - If a different directory is used, move the backup there.
- If S3 Object Storage is used for storing backups, upload the archive there.
- By default, this is
-
Restore the
gitlab-secrets.json
file:-
Create a copy of the current
gitlab-secrets.json
file from your Linux/Docker installation. To do this, copy the file/etc/gitlab/gitlab-secrets.json
to the administrator’s host. -
Retrieve
rails-secrets.json
from Code. Run the following command on the host where thekubectl
command is executed for the Deckhouse cluster:kubectl -n d8-code get secret rails-secret-v1 -ojsonpath='{.data.secrets\.yml}' | yq '@base64d | from_yaml | .production' -o json > rails-secrets.json
-
Move the created
rails-secrets.json
file to the same directory as thegitlab-secrets.json
file, and run the command:yq eval-all 'select(filename == "gitlab-secrets.json").gitlab_rails = select(filename == "rails-secrets.json") | select(filename == "gitlab-secrets.json")' -ojson gitlab-secrets.json rails-secrets.json > gitlab-secrets-updated.json
-
Replace the current
gitlab-secrets.json
file with the generatedgitlab-secrets-updated.json
. To do this, copygitlab-secrets-updated.json
to the host/container where GitLab is running, into the/etc/gitlab/gitlab-secrets.json
directory:cp gitlab-secrets-updated.json /etc/gitlab/gitlab-secrets.json
-
-
Restore the SSH host keys:
-
On the host where the
kubectl
command is executed for the Deckhouse cluster, run the following commands:kubectl -n d8-code get secrets shell-host-keys -ojsonpath='{.data.ssh_host_ecdsa_key}' | base64 -d > ssh_host_ecdsa_key kubectl -n d8-code get secrets shell-host-keys -ojsonpath='{.data.ssh_host_ecdsa_key.pub}' | base64 -d > ssh_host_ecdsa_key.pub kubectl -n d8-code get secrets shell-host-keys -ojsonpath='{.data.ssh_host_ed25519_key}' | base64 -d > ssh_host_ed25519_key kubectl -n d8-code get secrets shell-host-keys -ojsonpath='{.data.ssh_host_ed25519_key.pub}' | base64 -d > ssh_host_ed25519_key.pub kubectl -n d8-code get secrets shell-host-keys -ojsonpath='{.data.ssh_host_rsa_key}' | base64 -d > ssh_host_rsa_key kubectl -n d8-code get secrets shell-host-keys -ojsonpath='{.data.ssh_host_rsa_key.pub}' | base64 -d > ssh_host_rsa_key.pub
-
Copy the generated files to the host with your Linux/Docker installation into the
/etc/gitlab
directory:cp ssh_host_* /etc/gitlab/
-
-
After replacing the
gitlab-secrets.json
file, run the command:gitlab-ctl reconfigure
-
Once the command completes, start the restore process:
gitlab-backup restore BACKUP=<timestamp>
For example:
gitlab-backup restore BACKUP=1742909494_2025_03_25_17.8.1
-
After restoring, restart GitLab and check its status:
gitlab-ctl restart gitlab-rake gitlab:check SANITIZE=true