Wer häufiger programmiert, in Teams zusammen an einer Software arbeitet oder einfach nur Revisionssicherheit haben möchte, der kommt um ein GIT oder SVN (im Allgemeinen ein Version Control System) nicht herum. Beide VCS bieten die Möglichkeit in frei definierbaren Abständen den aktuellen Stand der Dinge zu sichern und auf einem zugehörigen Server sicher zu verwahren. Wir können ergo zu jedem beliebigen Zeitpunkt eine Momentaufnahme machen und anschließend frei Schnauze auf diese zurückkehren. Gleichwohl ist es möglich mehrere Momentaufnahmen (Commits) von unterschiedlichen "Zeitlinien" (Branches) unterschiedlicher Programmierer:innen zu einer Zeitlinie zusammenfassen (Merge). Wobei mehr oder minder alle bereits lokal benutzten Zeitlinien (Checkout) auf allen Rechnern und Servern als "physische" Kopien zur Verfügung stehen. Zugegebenermaßen war diese Beschreibung stark vereinfacht und mit viel künstlerischer Freiheit geschrieben, ABER: Durch diese zugrundeliegenden Prinzipien ist es mehreren Entwickler:innen gleichzeitig möglich auf einfachste Weise an einem selben Softwareprodukt zu arbeiten, ohne dabei an jeder Ecke und Kante Änderungen der Kolleg:innen zu entfernen/überschreiben.
Das Ganz dient im Grund nur einem höheren Zweck: einfache Zusammenarbeit durch dezentrale Sicherungskopien
SVN oder Git?
Diese Frage muss man sich persönlich selber stellen und ich will und kann dazu aktuell auch gar nichts sagen. Ich habe damals Git für mich entdeckt und bin dabei geblieben. Aus diesem Grund schreibe ich auch aus der Sicht von Git. Wer hier lieber SVN einsetzen möchte ist mit diesem Artikel allerdings auch schlecht bedient, da Gitlab eine ausschließliche Softwarelösung für das VCS Git ist.
Was macht Gitlab so besonders?
Das ist wieder so ein Ding. Sollte man lediglich die Vorteile von Git nutzen wollen, so reicht es eigentlich aus auf der heimischen NAS das bereits fertig eingerichtete Package Git Server herunterzuladen und zu starten. Im Unterschied zum reinen Git Server bietet Gitlab jedoch deutlich mehr Vorteile wie beispielsweise das Erstellen von Branches über die Web-Oberfläche, das Konfigurieren von automatischen Deployments, die Integration von Tickets, erweiterte Zugriffsrechte, Kommentare, Code-Reviews, Statistiken, ...
Was ich sagen will: Mit Gitlab hat man eine Komplettlösung in der Hand, die sowohl von Privatleuten als auch Firmen mit mehreren tausend Mitarbeitern genutzt werden kann. Das Schöne ist, dass Gitlab zwar generell kostenpflichtig ist, jedoch für den Privatanwender und kleine Teams auch in der kostenlosen und etwas abgespeckten Community-Edition (CE) durchaus sehr gut nutzbar ist. In der Regel werden Funktionen der kostenpflichtigen Version alle x Monate oder Jahre auch kostenlos auf die CE übertragen. Weiterhin kann man sich nach Belieben dafür entscheiden Gitlab entweder kostenlos von Gitlab hosten zu lassen oder aber auch auf der heimischen Synology NAS zu installieren und damit die Hoheit über die eigenen Daten zu behalten.
Gitlab per Docker vs Gitlab per Package
Gitlab kann auf ausgewählten NAS Systemen auf einfachste Weise direkt über den "App Store" von Synology installiert und gestartet werden. Das sind wenige Klicks und es geht los. Leider hinkt die Version des hauseigenen App Stores von Synology etwas der frei verfügbaren CE Version nach. Wer also Up-To-Date bleiben möchte und gleichzeitig vielleicht den einen oder anderen Sicherheitspatch direkt zum Release mitnehmen möchte der/die muss sich an Docker wenden und einen Gitlab Container aufsetzen. - Genau darum soll es heute gehen. Was für eine lange Einleitung. :P
Kurz vorweg: Hier findet ihr eine Liste aller Synology NAS, die Docker unterstützen.
Gitlab per Docker installieren
Wer man Blut geleckt hat, der sollte sich schleunigst bei DSM als Administrator einloggen und den App Store (Paket-Manager) öffnen. Hier findet ihr ein Paket mit dem Namen Docker. Dieses könnt ihr auf den oben genannten Geräten installieren. Der Prozess ist recht einfach und straight forward gestaltet. Ich denke ich brauche hier keine genauere Erklärung zu geben. Nach der Installation können wir das Paket öffnen und finden folgende Übersicht vor:
Auf der linken Seite finden wir verschiedene Menüs. Unter dem Menüpunkt "Registrierung" wiederum haben wir die Möglichkeit vorgefertigte Images (ein noch nicht instanziierter/gestarteter Container nennt sich "Image") zu suchen und zu installieren. Da wir die CE von Gitlab installieren wollen können wir über das obere Suchfeld nach "gitlab" oder "gitlab-ce" suchen. Das im Bild markierte Image solltet ihr doppelt anklicken können und nach kurzer Zeit ploppt euch ein Fenster entgegen in dem ihr die herunterzuladende Version von Gitlab/dem Image auswählen könnt. Es ist ratsam hier direkt auf die neueste Version "latest" zu setzen. Bestätigt die Auswahl mit "Auswählen".
Der nachfolgende Prozess läuft im Hintergrund ab. Da das Image pi mal Daumen 2 GB misst könnte der Vorgang ein paar Minuten in Anspruch nehmen. Zeit für einen neuen Kaffee :) .
Nach abgeschlossenem Download findet ihr das heruntergeladene Image unter dem Menüpunkt "Image". Das blaue Logo auf der rechten Seite ist vollständig blau gefüllt und nicht mehr animiert. Well Done! Wir können damit beginnen aus dem Image einen Container zu erstellen.
Für das Erstellen eines laufenden Containers müssen wir unser heruntergeladenes Image aus der Liste auswählen und auf den Knopf "Starten" klicken. Es sollte sich nach einer kurzen Denkpause von DSM ein Wizard öffnen, über den wir einige zusätzliche Einstellungen tätigen können und in unserem Fall sogar müssen.
Innerhalb des ersten Fensters können wir den Container einen Namen geben (kleiner Hinweis: aus einem Image können wir nach Belieben 2, 20 oder 2.000 laufende Container machen, die unabhängig voneinander sind).
Zusätzlich empfehle ich dem Container eine maximale Grenze an genutzten Ressourcen zuzuweisen. Meine NAS ist aktuell mit 8 GB Arbeitsspeicher bestückt und ich möchte einfach nicht, dass die komplett von Gitlab "vereinnahmt" werden.
Im Anschluss MÜSSEN wir noch zwei wichtige Anpassung tätigen.
- Der Container muss nach "Außen" per HTTPS und wahlweise zusätzlich SSH erreichbar sein.
- Der Container muss einen Speicherplatz AUßERHALB des Containers bekommen, da ALLE Daten nach einem Update des Containers sonst gelöscht wären!!!
Vor allem der zweite Punkt ist wichtig! Um diese beiden Anpassungen machen zu können klicken wir unterhalb der Ressourcenbeschränkung auf: "Erweiterte Einstellungen"
Dieser Bereich wird nun besonders relevant. Aus den eben genannten Gründen werden wir als Erstes eine neue Konfiguration der Ports vornehmen. Standardgemäß hört der Docker Container, nämlich auf die Ports 80, 443 und 22. Diese Ports sind auf unserer Synology NAS jedoch bereits in Gebrauch. Wir werden diese Ports dann beispielsweise auf die Ports 3080, 3443 und 3022 mappen. Durch dieses Mapping können wir im Anschluss (optional) eine öffentliche Domain nehmen und diese auf die entsprechenden Ports umleiten. Sollten wir also unser Gitlab aus dem öffentlichen Netz zur Verfügung stellen wollen, so werden die Clients auf die Domain examplegitlab.com zugreifen, die NAS wird diese Domain auf localhost:3443 oder localhost:3080 durchreichen und der Docker Container wiederum an das Gitlab in dem internen Port 80 oder 443. Klingt etwas konfus wird aber klar, wenn wir das erste Mal auf Gitlab zugreifen. Ich würde bei Bedarf hierzu noch einmal eine kleine Anleitung über die Konfiguration des Reverse Proxy vornehmen, sofern gewünscht.
Vorerst stellen wir ein, dass der Container beim Start der NAS ebenfalls hochfahren soll:
Anschließend wechseln wir in den Tab "Volume" und weisen den Docker Container dazu an außerhalb des Containers liegende Ordner so zu behandeln, als wären diese die Ordner innerhalb des Containers. Damit speichert Gitlab unsere in Gitlab gepflegten Daten außerhalb des Containers und wir können den Container immer wieder nach Belieben neu erstellen ohne Daten zu verlieren. Ich hatte in meinem Beispiel einen "Gemeinsamen Ordner" mit dem Namen "gitlab" erstellt und dort die drei Unterordner "logs", "config" und "data" angelegt. Docker legt auf der Synology NAS automatisch einen gemeinsamen Ordner "docker" an. Hier könnte man natürlich auch einfach drei Unterordner anlegen und würde dann im Wizard "docker/logs", "docker/gitlab/logs", "docker/toller_ordner_5000/logs" oder ... angeben.
Zu guter Letzt wird noch das angesprochene Port-Mapping vorgenommen:
Sind alle Einstellungen vorgenommen können wir auf "Übernehmen" und "Weiter" klicken, damit der Container gestartet wird.
Es wird nun ein Container mit den entsprechenden Einstellungen aus dem Image erzeugt und gestartet. Gitlab wird nun innerhalb des Containers eine erste "Installation" durchführen. Dies kann je nach zugrundeliegenden Metall SEHR lange dauern. Zeit für den zweiten Kaffee.
Wir können prüfen, ob die "Installation" abgeschlossen ist, wenn die Web-Oberfläche von Gitlab über die Domain http://[IP-DER-NAS]:3080 oder https://[IP-DER-NAS]:3443 erreichbar ist und uns mit der Bitte nach einem ersten Nutzer begrüßt. Zusätzlich sollte Gitlab auf unserer NAS in dem vorher konfigurierten /gitlab/config Ordner ein paar Dateien angelegt haben, gleiches sollte in den anderen beiden Ordner passiert sein. Ist dies nicht der Fall, so würde ich dringlichst um eine Prüfung der Konfiguration oder mehr Wartezeit bitten.
Hi Marvin,
danke dir für den klasse Artikel. Angenehm geschrieben und einfach nachzuvollziehen. Ich habe seit längerem Gitlab auf meinem NAS laufen und bin einer ganz ähnlichen Vorgehensweise gefolgt. Wo es aber seit einiger Zeit hängt sind 1. der SSH Zugang der wohl irgendwie nicht richtig will und 2. Das ausführen von CI/CD Pipelines. Immer wieder werden hier (meine Vermutung) die falschen Ports gewählt. Was dann zum Fehler "fatal: unable to update url base from redirection:" führt, da Gitlab in der Pipeline auf die DSM Oberfläche weitergeleitet wird. Sehr..wirr. Funktionieren bei dir SSH und CI/CD Pipeline? Freue mich über Rückmeldung! Grüße