Heute gehen wir zusammen mal durch, was ich alles unternommen habe um mein GitLab 7.14.3 auf ein GitLab 8.0.5 zu aktualisieren. Nebenbei habe ich MySQL verlassen und auf PostgreSQL migriert (empfohlen durch GitLab selbst). Zusätzlich läuft mein neuer GitLab dann in einer Docker-Umgebung. Aber erstmal von Anfang an.
GitLab – Ich liebe Quellcodes
Als Entwickler arbeite ich mit Quellcodes. Und das mache ich sehr sorgfältig. Ich kenne derzeit keinen Web-Entwickler der so vorgeht wie ich #selbstlobstinkt 😉
Und ein wichtiger Teil meiner Strategie ist GitLab und GitLab CI. Was genau diese beiden Tools sind, werde ich in einem anderen Artikel behandeln.
Backups – Nichts ist sicher
Wichtig ist den gesamten Prozess über immer ein Backup parat zu haben. Denn nichts ist sicher!
|
|
cd /home/git/gitlab sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production |
Aktuelle GitLab-Instanz aktualisieren
Da Backups nur in „passende“ GitLab-Systeme integriert werden können, hat man zwei Möglichkeiten:
- Erst auf GitLab 7.14.3 in einem Docker-Container umsteigen und dann diesen aktualisieren
- Erst auf GitLab 8.0.5 aktualisieren und dann auf den Docker-Container umsteigen
Da ich keinen funktionierenden Docker-Container für GitLab 7.14.3 gefunden habe, habe ich Variante 2 genommen. Dazu gibt es eine Update-Anleitung, diese hat bei mir funktioniert. Was danach nicht mehr ging waren Push oder Pull-Anfragen. Das habe ich aber ignoriert. Ich war schließlich eh dabei, diese GitLab-Instanz zu löschen.
Ich habe also nochmal ein Backup durchgeführt, jetzt nämlich für GitLab 8.0.5.
Auf PostgreSQL migrieren
In den GitLab-Backups ist ein Dump-File der Datenbank hinterlegt. Also in unserem Fall aktuell ein MySQL-Export. Dieser muss migriert werden.
Es gibt dafür ein Tool, welches MySQL-Dumps nach PostgreSQL migriert, das wusste ich bereits. Allerdings hat es nicht geklappt als ich es händisch gemacht habe. Praktischerweise hat GitLab selbst dieses Tool weiter modifiziert sodass es derzeit gut möglich ist, die Migration durchzuführen. Hier lest ihr wie ein GitLab Backup mit MySQL zu einem GitLab Backup mit PostgreSQL migriert wird.
GitLab Docker-Instanzen starten
Ich habe nicht das offizielle GitLab-Docker-Image genommen, sondern die Images von sameersbn. In dem Repository gibt es viele Images, hier kommt ihr zu den Docker GitLab Images.
Der Quick-Start dort ist sehr gut dokumentiert. Ich habe nur Step 3 Launch the GitLab Container angepasst:
|
|
docker run --name gitlab -d \ --link gitlab-postgresql:postgresql \ --link gitlab-redis:redisio \ --publish 10022:22 --publish 10080:80 \ --env 'GITLAB_PORT=10080' \ --env 'GITLAB_SSH_PORT=10022' \ --env 'GITLAB_SECRETS_DB_KEY_BASE=long-and-random-alpha-numeric-string' \ --env 'GITLAB_HOST=lw-scm.de' \ --env 'GITLAB_TIMEZONE=Berlin' \ --volume /srv/docker/gitlab/gitlab:/home/git/data \ quay.io/sameersbn/gitlab:8.0.5 |
Daten wiederherstellen
Nun bleibt nur noch das migrierte Backup in das Backup-Verzeichnis vom Docker-Container zu schieben (bei mir halt /srv/docker/gitlab/gitlab/backups/) und schon kann der Restore beginnen.
Ich bin dazu in die Shell des Docker-Container gewechselt, das geht über
|
|
docker exec -it gitlab bash |
Und dort habe ich gitlab dann angewisen das Backup wiederherzustellen
|
|
sudo -u git -H bundle exec rake gitlab:backup:restore BACKUP=ts RAILS_ENV=production |
Das ‚ts‘ bei „BACKUP=ts“ müsst ihr durch den Timestamp ersetzten, der als Prefix im Backup-Dateinamen gesetzt wurde.
GitLab 8.0.5 läuft jetzt im Docker-Container
Und schon haben wir es geschafft. Unser GitLab läuft jetzt in dem Docker-Container. Die Daten wurden vollständig migriert. Ich konnte mich einloggen.
Ein sau gutes Gefühl endlich ein vom restlichen System abgekapseltes GitLab zu haben welches sauber installiert ist. Keine großen Schwierigkeiten mehr. Echt der Hammer 🙂
