Versions 3.16 and 3.18 support GitLab versions that lag behind the official versions. Upgrading GitLab to the latest official version requires more than 10 upgrades to complete. After upgrading to 4.0, the product does not provide automatic upgrades to 17.8.z. This solution addresses how to upgrade from 14.0.12 to 17.8.z.
Considering the large version gap, we adopt a data migration approach for the upgrade.The time required for the upgrade varies significantly depending on the size of the GitLab data. It may take several days to complete the upgrade, so it's necessary to evaluate the maintenance window in advance.
Test data: Includes 3 projects (one large project of 666MB, 2 empty projects), backup file size of 668MB, upgrade time of 8 hours.
Data migration Path According to the official upgrade path documentation, the data migration path is as follows:
Finally, back up the data from 17.8.1 and import it into the platform-deployed 17.8.z instance to complete the data migration.
Backup the platform-deployed GitLab and restore it to an all-in-one image deployed GitLab, then upgrade to 17.8.1 using the all-in-one image, and finally restore the data backup to the platform-deployed 17.8.z instance.
For the latest GitLab instance and operator versions, please refer to the Release Note.
Install kubectl, yq, base64, and other tools on the execution host.
Configure environment variables (Note: at this point, the gitlab-operator version has not been upgraded and corresponds to the operator version for GitLab 14.0.12)
Prepare PVCs for the upgrade, which need to be created in the namespace of the old GitLab deployment
Prepare the images needed for the upgrade. Download each version of the image from the attachments and push them to an image repository that the GitLab deployment cluster can pull from. Image download links:
Enable the task-runner on GitLab 14 to execute backup commands
Set the gitlab 14 to read-only mode
Set the backup PVC for gitlab 14 task-runner, the PVC name is backup-pvc (the PVC needs to be created in advance, the size needs to be evaluated based on the gitlab data volume)
Backup gitlab 14 data
Use the all-in-one image to deploy 14.0.12 gitlab.
Apply the following yaml to the gitlab deployment namespace, the yaml has already mounted the backup pvc (backup-pvc) to the backup directory (if you need to access the gitlab instance during the upgrade process, you need to replace the IP and nodeport port in the yaml).
Restore the backup data to the 14.0.12 gitlab deployed with all-in-one.
There will be database-related errors during the recovery process, and must be owner
and does not exist
are expected behaviors, see (https://gitlab.com/gitlab-org/gitlab/-/issues/266988) for details.
Use the all-in-one mode to upgrade gitlab to 17.8.1. You need to replace the gitlab image in the upgrade path one by one until you upgrade to 17.8.1.
Upgrade path: 14.0.12 → 14.3.6 → 14.9.5 → 14.10.5 → 15.0.5 → 15.4.6 → 15.11.13 → 16.3.8 → 16.7.9 → 16.11.10 → 17.3.6 → 17.5.5 → 17.8.1
Upgrade 14.0.12 to 14.3.6
Upgrade 14.3.6 to 14.9.5: Replace the image tag with 14.9.5-ce.0, other operations are the same as "14.0.12 to 14.3.6".
Upgrade 14.9.5 to 14.10.5: Replace the image tag with 14.10.5-ce.0, other operations are the same as "14.0.12 to 14.3.6".
Upgrade 14.10.5 to 15.0.5: Replace the image tag with 15.0.5-ce.0, other operations are the same as "14.0.12 to 14.3.6".
Upgrade 15.0.5 to 15.4.6: Replace the image tag with 15.4.6-ce.0, other operations are the same as "14.0.12 to 14.3.6".
Upgrade 15.4.6 to 15.11.13: Replace the image tag with 15.11.13-ce.0, other operations are the same as "14.0.12 to 14.3.6".
Upgrade 15.11.13 to 16.3.8: Replace the image tag with 16.3.8-ce.0, other operations are the same as "14.0.12 to 14.3.6".
Upgrade 16.3.8 to 16.7.9: Replace the image tag with 16.7.9-ce.0, other operations are the same as "14.0.12 to 14.3.6".
Upgrade 16.7.9 to 16.11.10: Replace the image tag with 16.11.10-ce.0, other operations are the same as "14.0.12 to 14.3.6".
Upgrade 16.11.10 to 17.3.6: Replace the image tag with 17.3.6-ce.0, other operations are the same as "14.0.12 to 14.3.6".
Upgrade 17.3.6 to 17.5.5: Replace the image tag with 17.5.5-ce.0, other operations are the same as "14.0.12 to 14.3.6".
Upgrade 17.5.5 to 17.8.1: Replace the image tag with 17.8.1-ce.0, other operations are the same as "14.0.12 to 14.3.6".
In the 17.8.1 deployment pod, execute the backup.
Deploy gitlab 17.8.z on the platform using the operator and enable the toolbox (note that it needs to be in the same namespace as the old instance), then restore the data to the gitlab 17.8.z deployed by the operator (set the name of the gitlab deployed on the platform to the environment variable NEW_GITLAB_NAME).
In the gitlab 17.8.z, add the following values to enable the gitlab 17.8.z toolbox:
During the recovery process, database-related errors may occur, where must be owner and does not exist are expected behavior, details can be found at (https://gitlab.com/gitlab-org/gitlab/-/issues/266988)
Verify that the data after the upgrade is different from the data before the upgrade.
After the data verification is complete, manually clean up the old instance.
When executing the backup data, the task-runner container is killed, and the request and limit resources need to be added to the task-runner container (at least 2c4g), then restart the task-runner and perform the backup again.
When restoring the backup to the 17.8.z deployed by the platform, the toolbox container is killed, and the request and limit resources need to be added to the toolbox container (at least 2c4g).
The upgrade backup does not include external attachment images and avatars, so the page cannot display attachment images and uploaded avatars after the upgrade. You can replace the 17.8.z PVC with the 14.0.12 image storage PVC.