Hallo lieber Blogleser und Gitlab Server Admin! Gitlab brachte positive News zu den Nutzern des Gitlab Servers. Ein neues Update auf die Version 10.1.3 war erschienen und dokumentiert wurde es unter https://about.gitlab.com/2017/11/10/gitlab-10-dot-1-dot-3-released/.
Gitlab Server kann auf verschiedenen Betriebssystemen wie auch meinerseits unter Centos 7.4 installiert werden. Meine eigene Instanz ist unter https://gitlab.liebrechts-portfolio.de aufgesetzt. Nur noch mit SSL von Let’s Encrypt klappt es nicht, weil ich die maximale Anzahl an Erneuerungen des SSL-Zertifikats bereits überschritten habe. Ich muss mich noch mehrere Tage gedulden, bis es wieder funktioniert. Aber an sich ist meine Instanz bereits aufrufbar.
Gitlab Server 10.1.3 kam mit Regressions-Fixes und Bugfixes daher
Das kannst du hinter dem oben gesetzten Linkverweis gerne vorfinden. Fehlerbehebungen seitens der Entwickler-Front sind immer wieder herzlich willkommen und das macht die Software ein Stück besser sowie funktionsfähiger. An Issues, so genannten Tickets, für Gitlab CE(Community Edition) und Gitlab EE(Enterprise Edition, was ich habe) mangelt es nicht. Die global ansässige Gitlab Community macht das Beste draus und hilft bei allen Belange und Problemen, was sehr schätzenswert ist.
Upgrade auf Gitlab Server 10.1.3 – wie geht das?
Das Upgrade konnte ich heute zum allerersten Mal erfolgreich vollbringen, wofür mir die Konsole und ein paar Befehle wie diese dienten.
yum update
„yum“ >> gilt immer für RedHat/Centos OS.
Ich gehe davon aus, dass du Gitlab Server bereits aufsetztest und müsstest nur noch das Upgrade hinter dich bringen. Das geht dann mit oben gezeigtem Befehl. Falls du in Linux im Verzeichnis /etc/yum.repos.d kein Gitlab EE Repository hast, kannst du es mit diesem SSH-Befehl hinzufügen.
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
Meine Empfehlung, erfahrungsbedingt
Lösche bitte das Gitlab EE/CE Repo aus diesem Verzeichnis, denn Plesk und Centos aktualisieren sich oft von selbst, sodass es passieren kann, dass deine Instanz nicht mehr korrekt funktioniert. Lade die Datei mit dem Repo in einen Windows-Ordner herunter, bewahre sie dort auf und lade sie bei Bedarf und nach dem du Release Notes checktest wieder hoch. Damit sorgst für ein einwandfreies Funktionieren deiner Gitlab Server Instanz.
Mit „yum update“ wird Gitlab EE/CE Repo aufgerufen, Aktualisierungen werden mittels SSH installiert und so wird deine Gitlab Instanz in der Kommandozeile neu gestartet. Das heisst, dass alle Prozesse und Ports, die für Gitlab gelten, inkl. der PostgreSQL-Datenbank werden neu gestartet. Ich zeige dir mal einen solchen Update-Ausschnitt von heute aus meinem Kommandozeilen-Update des Gitlab Server EE.
Resolving Dependencies --> Running transaction check ---> Package gitlab-ee.x86_64 0:10.1.1-ee.0.el7 will be updated ---> Package gitlab-ee.x86_64 0:10.1.3-ee.0.el7 will be an update --> Finished Dependency Resolution Dependencies Resolved ==================================================================================================== Package Arch Version Repository Size ==================================================================================================== Updating: gitlab-ee x86_64 10.1.3-ee.0.el7 gitlab_gitlab-ee 399 M Transaction Summary ==================================================================================================== Upgrade 1 Package Total download size: 399 M Is this ok [y/d/N]: y Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. gitlab-ee-10.1.3-ee.0.el7.x86_64.rpm | 399 MB 00:00:10 Running transaction check Running transaction test Transaction test succeeded Running transaction gitlab preinstall: Automatically backing up only the GitLab SQL database (excluding everything else!) Dumping database ... Dumping PostgreSQL database gitlabhq_production ... [DONE] done Dumping repositories ... [SKIPPED] Dumping uploads ... [SKIPPED] Dumping builds ... [SKIPPED] Dumping artifacts ... [SKIPPED] Dumping pages ... [SKIPPED] Dumping lfs objects ... [SKIPPED] Dumping container registry images ... [DISABLED] Creating backup archive: 1510739190_2017_11_15_10.1.1-ee_gitlab_backup.tar ... done Uploading backup archive to remote storage ... skipped Deleting tmp directories ... done done Deleting old backups ... skipping Updating : gitlab-ee-10.1.3-ee.0.el7.x86_64 1/2 Cleanup : gitlab-ee-10.1.1-ee.0.el7.x86_64 2/2 Checking PostgreSQL executables: OK Shutting down all GitLab services except those needed for migrations ok: down: gitaly: 0s, normally up ok: down: gitlab-monitor: 1s, normally up ok: down: gitlab-workhorse: 0s, normally up ok: down: logrotate: 1s, normally up ok: down: node-exporter: 0s, normally up ok: down: postgres-exporter: 1s, normally up ok: down: postgresql: 0s, normally up ok: down: prometheus: 0s, normally up ok: down: redis: 1s, normally up ok: down: redis-exporter: 0s, normally up ok: down: sidekiq: 0s, normally up ok: down: unicorn: 0s, normally up ok: run: postgresql: (pid 23116) 1s ok: run: redis: (pid 23119) 0s run: postgresql: (pid 23116) 1s; run: log: (pid 13356) 644846s run: redis: (pid 23119) 0s; run: log: (pid 13334) 644847s Reconfiguring GitLab to apply migrations * Moving existing certificates found in /opt/gitlab/embedded/ssl/certs * Symlinking existing certificates found in /etc/gitlab/trusted-certs gitlab Reconfigured! Checking for an omnibus managed postgresql: OK Checking for a newer version of PostgreSQL to install No new version of PostgreSQL installed, nothing to upgrade to Ensuring PostgreSQL is updated: OK Restarting previously running GitLab services ok: run: gitaly: (pid 23719) 0s ok: run: gitlab-monitor: (pid 23739) 1s ok: run: gitlab-workhorse: (pid 23698) 2s ok: run: logrotate: (pid 23786) 0s ok: run: node-exporter: (pid 23792) 1s ok: run: postgres-exporter: (pid 23798) 0s ok: run: postgresql: (pid 23116) 26s ok: run: prometheus: (pid 23807) 0s ok: run: redis: (pid 23119) 25s ok: run: redis-exporter: (pid 23822) 1s ok: run: sidekiq: (pid 23830) 0s ok: run: unicorn: (pid 23839) 1s _______ __ __ __ / ____(_) /_/ / ____ _/ /_ / / __/ / __/ / / __ \`/ __ \ / /_/ / / /_/ /___/ /_/ / /_/ / \____/_/\__/_____/\__,_/_.___/ Upgrade complete! If your GitLab server is misbehaving try running sudo gitlab-ctl restart before anything else. If you need to roll back to the previous version you can use the database backup made during the upgrade (scroll up for the filename). Verifying : gitlab-ee-10.1.3-ee.0.el7.x86_64 1/2 Verifying : gitlab-ee-10.1.1-ee.0.el7.x86_64 2/2 Updated: gitlab-ee.x86_64 0:10.1.3-ee.0.el7
So sollte es in etwa bei dir aussehen, je nachdem, welche Centos-Version du auf dem Linux-Server hast. Wenn es Centos 6 ist, musst du auch dementsprechend ein anderes Repo installieren. Zur Installation des Gitlab Servers in Centos OS kann ich dir diese Anleitung unter https://about.gitlab.com/installation/#centos-7 gerne empfehlen.
Das ist im Grossen und Ganzen die Upgrade-Prozedur. Es ist empfehlenswert, mal von Zeit zu Zeit in Google mit dem Begriff „gitlab release notes“ zu suchen, um an neue Updates zu gelangen. Ich checke mittlerweile alle Atlassian Apps, OpenProject, Phabricator, Gitlab Server mit „release notes“ in Google. So hast du immer, was du brauchst.
Falls du Fragen zum Upgrade hast, bemühe bitte darunter die Kommentare.
[note note_color=“#ee4821″ radius=“10″]Auch wäre es höchst erfreulich, falls du auch ein Gitlab Admin bist. Was war das Schwierigste für dich bei der Installation und was ging schnell von der Hand?[/note]
Meinerseits musste geklärt werden, an welchem Port nun Unicorn laufen soll. OpenProject ist am Port 3000, sodass der Unicorn Port schon mal am Port 6000 sein könnte. Das macht möglich, dass du OpenProject App und Gitlab Server auf einem und demselben Rootserver laufen lassen kannst. Das gilt es zu beachten.
by Alexander Liebrecht