Latest Posts

Categories

Upgrading my GitLab experience

Almost exactly four years after I first installed GitLab, I’ve migrated my instance to a new host, and in the process, finally switched to their “omnibus” install.

When I installed GitLab back on July 20, 2013, there was no package available, but rather one had to follow a lengthy set of instructions to get into place the various pieces that comprise a GitLab instance. In the intervening four years, the number of components has only increased, making the upgrade process more onerous and error-prone.

I recently discovered Packet.net and was considering how I should use the instance I signed up for. Around that time, I went through another manual GitLab upgrade and knew that I’d found a use for the new host. Following a few weeks of tests, I’ve migrated git.ethitter.com to the new host.

If you’ve previously checked out projects from my instance, it’s possible you’ll be warned that the IP and fingerprint have changed. To this end, the new instance displays the following banner:

This instance recently migrated to a new host at 147.75.64.55 / 2604:1380:0:e900::1. The fingerprint for its RSA key is SHA256:vsF6IS2NHLTmvZXUd8DvmMtEkxM8bWXdX/O99PcbzYE; the ECDSA key fingerprint is 85:6d:65:39:21:21:e4:0a:f8:13:aa:ad:90:80:6d:eb.

With GitLab on its own host, I can finally explore features such as its CI and Pages, neither of which I wanted to enable alongside everything else already running on this server. By moving GitLab, I can also dedicate more of this server’s resources to PHP, which should give a bit of a boost to this site’s performance.

One thought on “Upgrading my GitLab experience”

For those wondering about process, it was quite straightforward. First, it’s important that the source and Omnibus installations are at the same version. From there, it’s a matter of making a backup from the source installation and restoring it against the Omnibus instance.