I have been assigned the task of migrating a gitlab-7.5.0.rc1 on Centos 6 instance to a new machine running Centos 8.3 and gitlab-ee-14.4.0. There appears to be no documentation for 7.5.0 on the site and the gitlab.com archives do not go that far back. I am aware of the upgrade process that allows one to upgrade without downtime, the trouble is it only goes back to 8.3.14 I believe. What I would like to know is whether or not I can:
install new instance of gitlab-ee-14.4.0 on Centos 8.3 machine
bring over the gitlab.rb file from 7.5.0.rc1
backup databases from 7.5.0.rc1 system (how is this done?)
restore databases in 14.4.0
upgrade database(s) from 7.5.0.rc1 => 14.4.0
I’ve found some documentation on migration and all cases indicate machine to machine migration can only be done when both machines are the same version of gitlab. Is there really no other way to perform the migration?
What about upgrade path? I see in the upgrade documentation that there are at least 15 upgrades to perform to get from 8.1.X to 14.4.0. Is that the only way to upgrade regardless of whether or not I want to incur downtime?
Finally, the initial site seems to be compiled. I would like to get on a distribution based release. Is that even possible or is it the case that once you start on a compiled version of gitlab you stay on the source build path?
Well, that will be a bit problematic for a number of reasons. You can find old documentation here: Docs archives | GitLab | GitLab but from a post already on this forum, I couldn’t find anywhere in those archive docs how to check background migrations, since the command in the current docs is for a particular version and higher (not even sure what version).
Your next problem - you will not be able to backup/restore your existing install to a different version. You mention you are on a compiled, so source version. That means you cannot restore it to Omnibus or even the docker one. Restores can only be done on the same type/version. So source can be restored to source, omnibus can be restored to omnibus, docker restored to docker.
In all honesty, your best bet would be:
Install a new server with latest Gitlab using omnibus version.
Export repositories from your old Gitlab install - providing of course there is an export option in the Gitlab web interface (hopefully there is).
Import repositories on your new Gitlab install using the web interface.
Would save you the headaches of trying to find everything in the archive documentation, which requires you to run a local docker instance to view it, and having to do this multiple times for all the versions between yours, and the oldest available on the Gitlab website. It also gives you the ability to switch to a distro release, which you cannot do with your existing install.
After posting I continued to investigate the upgrade path. I discovered that as of gitlab-12.1 only postgresql db is supported and as luck would have it, the original site is running mysql so I’m going to have to do a db conversion as well. Fortunately this seems to be well understood and possible with pgloader.
Looking at export/import documentation I think I’m still forced into multiple upgrades as the export/import option is only supported between narrow ranges of gitlab releases. Again, anything before 8.9.0 is going to be a crap shoot.
I’m not quite understanding what you’re saying about the documentation. If I understand the offline archives correctly, I can only get documentation back to gitlab-10.3 and that would require a docker instance to even access it. Are you saying that if I do download and install that archive I may find documentation extending back to older versions of gitlab? Perhaps something for 7.5?
Hi, yes by looking at the older archive docs, for example at gitlab-10.3 there is probably going to be info in it going back as far as 7.x - for example the upgrade paths for one.
Some people have had problems with the mysql → postgres migration, and that was also only available up until a certain point, and I’m not entirely sure what version of Gitlab actually had it, and when it later disappeared. So, that also adds another to the list of potential problems during the upgrade.
I stick by what I recommended before, export the repositories and import into a new install. I spent two days upgrading from 12.9.x going through every single point release to get to 14.0 to ensure that it was 100% successful (I could skip releases via an upgrade path but without knowing then whether I could incur problems, better safe than sorry). And that was on an omnibus installation which is far more straightforward. Therefore, assuming that an upgrade path isn’t possible to find for you, your safest way also is to upgrade via every single point release from your existing install - which let’s assume if mine was 80+ upgrades, yours could be a few hundred, so looking at approx a week - not including the time to compile.
I think the path outlined by @iwalker is the way forward.
GitLab 7.5.0 is quite a lot older than what I have administrated, I’ve only ever touch omnibus installs, and installs using PostgreSQL and I’ve never touched a CentOS (privately I’ve use Debian since December 1999, at work we use Ubuntu). In short: In almost all areas of the task ahead of you, there are gaps in my knowledge, but I see so many challenges just from what I do know that I can’t imagine the rest makes it easy.
I don’t know how backups worked with 7.5.0, but for the several last years You’ve only been able to restore a backup on the exact same version, and has to do all the upgrades.
You write that you are aware of the procedure for upgrading without downtime (the procedure is badly named as it incurs downtime, it only reduces it). My advice would be to drop that idea, from the documentation on zero-downtime upgrades: “You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to 9.3”, going all the way back to 7.5 (I don’t know if that limitation was accurate back then), you’ll be looking at way beyond 100 steps, just there.
Thought I’d post an update on how this is going. The primary user has a small team of developers and is willing to re-create users. After a scratch setup and configuring LDAP authentication I turned it over to him. He pushed a small project from the current server to the new server and it seems to have worked. He did mention that tags seemed to be missing. He’s currently pushing a larger project with more tags to see how it looks but if this is successful (enough) then that’s how the entire migration will be accomplished.
Again, anything before 8.9.0 is going to be a crap shoot.