Hello there,
I have a GitLab (v 11.10.4) installed on a RedHat Linux 7 server. This version is a very old version of the GitLab community.
I would like to know what the route would be to update to the new version of GitLab, and how advisable is it to update the version of the operating system?
I appreciate the support.
Your route would look like this from the Gitlab upgrade tool: Upgrade Path
Since there was only 11.9.12 or 11.10.8 to choose from, I chose the version prior to the version you mentioned which was 11.10.4. As you can see, from 11.10.4 you need to go to 11.11.8 from the first step on the upgrade path. More details related to the upgrade can be found in the docs: Upgrade GitLab | GitLab
16.9.1 exists for RHEL7, so you don’t need to look at upgrading the operating system just yet. I would go to 16.9.1, and then think about perhaps going to RHEL9 and then doing a backup/restore to move from the old RHEL7 server. RHEL7 goes end of life in June 2024, so you have a few months yet before it gets critical.
Whilst RHEL has a tool for upgrading the OS, I would recommend a clean install and backup/restore of Gitlab. The extra bonus of doing the backup/restore is that you learn how to recover your Gitlab instance in the event of server failure. Better to do that now, than when things go really wrong, and you’ve not had a chance to check/test your recovery procedures are complete.
Don’t forget the backup/restore does require the /etc/gitlab/gitlab.rb and /etc/gitlab/gitlab-secrets.json files as well as the backup file created under /var/opt/gitlab/backups.
Before updating make sure the you have to make the beckup of all the gitlab data.
I saw that the migration would have to be done in the background, but I would like to know what the recommendation is, and if there are other ways to perform the migration.
I ask this to know if I would have to pause the gitlab service, or can it be running while the updates run.
If you ask that because downtime critical you can look into the recommendation for so called “zero downtime” upgrades (unless you have multiple servers in a load-balancing configuration, it will still involve downtime, so I think it’s badly named). That will make more migrations run in the background, but the method for checking that they are done is basically the same as what you have to do anyway before continuing.
Yes, I would like to know how long it would take approximately to run 11 updates.
If I understood correctly, any type of update has downtime?
I really appreciate the time and your responses.
How long is a piece of string? It varies. Physically downloading and applying the update package takes a few minutes. The background migrations, depending on how many there are can take minutes or they can take hours. There is no real way to determine this since it varies. If you were doing updates regularly when they were released, then you could expect the migrations to take a few minutes. When following an upgrade path like you have to do here, a lot of background migrations will accumulate some releases on the upgrade path will have more and require longer to finish.
The downtime on a single instance when the services are restarted are usually around 2 - 3 minutes max. You can still use the system, even when waiting for the background migrations are being completed. You cannot however start the next upgrade until they have finished.
That also depends on your internet connection. Just like everything about how long it takes depend on your hardware. If you have really slow disks migrations will take longer than if you have the newest and fastest SSD’s (Given that we’re talking about an old server here, the reality is probably somewhere in between - so an unprecise estimate between unprecise bounds).
It also depends on how many repositories/issues/… you have, and probably also on how those issues are distributed on projects.
So it’s not just a piece of string, it’s a piece of elastic band that we haven’t seen, you asking us how long is.
Thank you very much for the time and responses, I have more left.
Excellent day community.
Muchas gracias @moisesarrona, fue de bastante ayuda para migrar exactamente como tu tenias tu problema, saludos desde Chiapas