One of my more recent small projects has been upgrading an old Gitlab server to the latest version and migrating it to a new server. Now as much as we preach trying to keep systems up to date; unfortunately, sometimes internal servers slip through the cracks, and as a result they end up outdated. Sometimes they are outdated to a point where it makes more sense to just build a new server and migrate the data - this is one of those stories.
The Background
We start our story with an internal Gitlab server being used to house code for various projects. For those of you not familiar with Gitlab, it is a website platform similar to Github, with the exception that you can host it on your own servers - which is great if you prefer to keep your code confidential. This particular instance of Gitlab existed on an Ubuntu 14.04 server that had been many months without updates. This particular instance of Gitlab was also version 9.2.2.
The Problem
I had attempted to perform updates, and as a result, upgrade the instance of Gitlab on a couple separate occasions; however, they had not went as planned. For whatever reason, some library or package was corrupt and kept causing updates to fail, one time it was bad enough that the server wouldn’t even boot and I had to restore a previous backup to bring it back to life. Now, I know as geeks/nerds/hackers/techies a lot of us like to break things down and try to figure out what exactly is happening and how to fix it. While this is great (I often do this myself, if nothing else as a learning experience) there is not always the time to do such a thing. This happened to be one of these times. I needed to get this platform upgraded and migrated to a new server, and I didn’t have all the time in the world to mess with it.
One of the nice features of Gitlab, is the ability to export a project (including issues, labels, wiki, etc) and then import it into a different server. This was my first solution to this problem, but ultimately it led to yet another problem. Evidently the versions of exports/imports are not necessarily backwards compatible. As a side note, the new server is running Ubuntu 18.04 and the latest Gitlab instance is 11.2.
While I do not have screenshots of the actual error, essentially it told me that it was an incompatible project file, and could not be imported. While at this point I could have just created a project on the new server and then pushed the code there; however, I wanted to maintain the issues and other project settings from the production Gitlab instance.
The Solution
Enter Docker as the solution. For those of you not familiar with Docker, it is a tool to create containers (similar to virtual machines) that can house necessary requirements for a variety of different types of servers and applications. With Docker, you can spin up a variety of versions of a type of an application, such as in this case, Gitlab. What I ended up having to do was spin up an old version of Gitlab (9.2.2) while mapping the data directories to local folders on my system. Example code below:
docker container run --detach --hostname gitlab.example.com --publish 80:80 --name gitlab --volume /srv/gitlab/config:/etc/gitlab --volume /srv/gitlab/logs:/var/log/gitlab --volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:9.2.2-ce.0
After I had the container up, I was able to import the project from the production server and gain access to it within the Docker container. At this point I was able to dismantle the container while maintaining data persistence (courtesy of mapping to local system folders) and then spin up a new container with the latest version of Gitlab. Fortunately, to update a Docker container all you usually have to do is spin up the latest version and as it builds it updates the directories along with it. This is exactly what happened with Gitlab. I performed the same mappings, and used the latest release of Gitlab and created a new Docker container. Example code below:
docker container run --detach --hostname gitlab.example.com --publish 80:80 --name gitlab --volume /srv/gitlab/config:/etc/gitlab --volume /srv/gitlab/logs:/var/log/gitlab --volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latest
After the new container was up and running, I had access to the upgraded project. From there I was able to export it, and then import it to the new production server.
While this was not an ideal process, it was very effective, and is something to keep in mind for any upgrading issues in the future.
More documentation on this process for Gitlab and Docker can be found here. https://docs.gitlab.com/omnibus/docker/
~Mike