Zum Inhalt

Gogs Git-Server: Schnell, schön, leicht.

Der Gogs Git-Server ist ein zentrales Repository für eure Git-Projekte. Git-Server setzt man üblicherweise gar nicht oder mit GitLab auf. Da GitLab aber aufwendig ist, habe ich mir nach einer Alternative umgeschaut. Andere bekannte Vertreter sind etwa Atlassian Bitbucket, Gitblit und GitList.

Aber von all diesen hat Gogs als einziger die Eigenschaft, frei und schnell zu sein. Kein Wunder: Gogs ist in der Programmiersprache Google Go geschrieben und daher sehr schnell.

Wahl des Git-Servers: Kriterien

Wichtigstes Kriterium war die Wahl der Laufzeitumgebung, also der benötigten Infrastruktur. Dort spielen Kriterien wie Softwarestack, Speicherbedarf etc. mit hinein.

Web-Infrastruktur für GitLab

GitLab ist sicherlich das komplexe Monster unter den genannten Lösungen: Ohne grundlegende Kenntnisse zu Rubys Paketmanager kommt man nicht weit. GitList ist eine PHP-Variante, von der ich mir nicht viel Performance versprach — außerdem wollte ich nicht zwingend einen Webserver aufsetzen, zumal mit PHP noch weiterer Konfigurations- und Wartungsaufwand anfällt.

Java-Standalone und Perl für Bitbucket

Die kommerzielle Lösung heißt Bitbucket und ist nicht kostenlos zu haben. Der Stack ist zwar einfach, aber auch nicht zwingend schnell installiert: Ein Java 1.8 und ein Perl 5.8.8 sind doch recht moderne Anforderungen, die — vor allem im Corporate-Umfeld — nicht immer verfügbar sind.

Java-Web-Applikationsserver Gitblit

Gitblit ist eine Java-Webanwendung und wird als .war -Datei oder kombiniert mit einem integrierten Java-Webapplikationsserver (hier: Jetty) bereitgestellt. Java-Webapplikationsserver können (müssen aber nicht) schwergewichte sein und sind eine potentiell eigene Fehlerquelle und verbraucht weitere Ressourcen. Da ich mich mit Tomcat, Jetty und dergleichen gut auskenne, wäre es sicher (bei ausreichend RAM/Speicher) eine gute Lösung gewesen. Wäre da nicht das eher unschöne Webinterface.

Gogs Git-Server (Go Git Service)

Der Go Git Service (kurzform: Gogs) ist ein Git-Server, der — wie der Name schon sagt — komplett in Go geschrieben ist und daher sehr ressourcenschonend ist. Gogs startet seinen eigenen, integrierten und optimierten Webserver. Da statische Resourcen in einem eigenen Verzeichnis liegen, lässt sich dennoch ein beliebiger Webserver vorschalten — entweder Apache mit mod_proxy, oder nginx mit try_files. Zudem hat es ein schönes Webinterface — GitHub lässt grüßen. Es ist zwar noch nicht vollständig, aber bereits sehr funktional. Man kann gogs sogar ohne Datenbank nutzen – eine SQLite-Unterstützung ist vorhanden.

Daher habe ich mich bei meinem aktuellen Fall für Gogs entschieden.

gogs auf Uberspace

Für mich interessant war auch die Frage, ob sich gogs auf Uberspace installieren lässt.

Apache als für statische Resourcen und als Proxy für Gogs nutzen

Die meisten Serverkonfigurationen, die ich gesehen habe, leiten alle Anfragen direkt an Gogs weiter. Dabei ist Apache für statische Resourcen die bessere Wahl, da sich nur so Komprimierung und Expire-Kopfzeilen nutzen lassen. In dem Beispiel bei Geeklabor und in diesem Blog wird leider einfach direkt auf den anderen Port umgeleitet, was ich für unschön halte.

Schöner ist da sicherlich eine Proxy-Anweisung, da so der Apache etwa das SSL-Zertifikat liefern kann, die statischen Resourcen direkt bedient, Daten komprimiert und Expire-Header setzt. Eine komplette Konfiguration (ohne Rücksicht auf Uberspace) sieht wie folgt aus:

Weiterhin sollten noch Direktiven für z.B. Caching eingefügt werden. Beispiele finden sich bei h5bp. Für Uberspace müssten natürlich noch die passenden Direktiven in die .htacces -Datei gelegt werden. Die Alias- und Directory-Anweisung werden entsprechend relativ umgeschrieben.

Uberspace: Port reservieren

Da bei shared hosting ein Port ein teures Gemeingut ist, sollte man den Port vorher mit den Jungs von Uberspace absprechen. Generell sollte die Verwendung eines High-Ports kein Problem sein. Vorteil ist, dass dieser nicht nach außen sichtbar ist, und die Besucher über den Apache zugreifen müssen.

gogs unter Windows

Gogs bringt seine eigene SSH-Keyverwaltung mit, genauso wie bei GitHub. Unter Windows muss lediglich eine Bash nachinstalliert werden, etwa per cygwin. Damit ist Gogs als eine der wenigen Lösungen, die auch unter Windows lauffähig sind: GitLab als wohl beliebteste Lösung ist es nicht. Bei Gitblit ist es zwar offiziell supported, aber dürfte durch die Java-Laufzeitumgebung gerade unter Windows die Performance leiden (Stichwörter: Dateisystem, Multithreading, fehlende CGroups, Speicherverwaltung, etc.).

Gogs (Go Git-Server) unter Windows.
Gogs (Go Git-Server) unter Windows.

In der englischen Installationsanleitung für Windows ist sogar beschrieben, wie ein Windows-Dienst mit nssm (non-sucking service manager) eingerichtet werden kann. Im Beispielbildschirmfoto oben ist zu sehen, wie der Dienst mit nssm gestartet und gestoppt wird, und mit einem Apache-httpd-Proxy und MySQL über XAMPP getestet wird.

Fazit

Gogs ist ein toller, schneller Server. Er ist noch jung, erfüllt aber schon mehr als die wichtigsten Wünsche und sollte für die allermeisten Belange ausreichen.

Das Projekt ist in Google Go verfasst und daher ungeheuer schnell und Resourcensparsam.

Veröffentlicht inSoftware vorgestellt

12 Kommentare

  1. „GitLab ist sicherlich das komplexe Monster unter den genannten Lösungen: Ohne grundlegende Kenntnisse zu Rubys Paketmanager kommt man nicht weit.“

    Das stimmt so nicht, hat es vielleicht früher mal – das weiß ich nicht… Heutzutage stellt Gitlab deb und rpm bereit die alles fertig konfiguriert mitbringen. Klar kann man auch manuell installieren, muss man aber eben nicht.

    • Benjamin Marwell Benjamin Marwell

      In dem konkreten Beispiel hatte ich keine RPM- oder DEB-Distri zur Verfügung. Und dann ist GitLab halt doch ein komplexes Monster. Aber das ist es auch als rpm, denn die Komplexität wird ja nicht weniger, nur versteckt. Es hat auch mehr Abhängigkeiten, als mir lieb ist.

      In dem Fall habe ich auch auch eine Lösung gesucht, die OS-unabhängig ist.

      Aber Du hast recht; in den meisten Fällen ist GitLab eine gute Wahl, weil man von der Komplexität nichts mitbekommt.
      Danke für den Hinweis!

  2. Hallo Benjamin,
    das Problem ist schlichtweg, dass man bei Uberspace keinen Einfluss auf die Apache Konfiguration hat. Es besteht also gar keine andere Möglichkeit als ein .htaccess redirect. Warum der jetzt schlechter sein soll als eine Proxy Konfiguration weiß ich nicht, aber bei einer Weiterleitung der Requests an localhost wird zumindest die SSL Konfiguration weiterhin vom Apache erledigt:
    RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
    RewriteRule (.*) http://localhost:PORTNUMMER/$1 [P]

      • Benjamin Marwell Benjamin Marwell

        Stimmt, das habe ich übersehen. Tatsächlich wollte ich aber erreichen, dass statische Resourcen nicht den Weg des Proxies gehen.

    • Benjamin Marwell Benjamin Marwell

      Hi, in der .htaccess kann man doch recht viel einstellen. Mime-Types, Komprimierung, Expires, Rewrites.
      Man kann auch einfach vier negative rewrite-Conditions hinzufügen, das hätte den gleichen Effekt:
      RewriteCond %{REQUEST_URI} !^/img/
      Darauf wollte ich hinaus. Soviel Einfluss hat man dann doch nicht. Entschuldige, wenn das nicht richtig herübergekommen ist. Das war eine „Kleinigkeit“, die mich an dem kurzen (aber natürlich auch gut funktionierenden) Rewrite gestört hat.

      • Hi, das sollte auch keine Kritik sein sonder rein invormativ. Jetzt interessiert es mich aber doch? Warum bevorzugst du denn den Weg ohne Proxy, was ist denn das genaue Problem bei statischen Ressourcen? Eventuell sollte man noch darauf hinweisen, dass XAMPP keinesfalls für den produktiven Einstatz (Portfreigaben aus dem eigenen Nezt heraus) geeignet ist.
        Viele Grüße

      • Benjamin Marwell Benjamin Marwell

        No offense taken. 😉

        Wenn du andere Blogartikel liest, dann wirst du merken, dass ich sonst recht Linux-Affin bin. Der XAMPP war nur ein Notnagel, damit ich im Artikel überhaupt ein Beispiel habe. Zu Hause setze ich auf nginx. Klar kann man auf XAMPP und Testbetrieb hinweisen, aber ich möchte meine Leser nicht entmündigen. 😉

        Den Weg ohne Proxy bevorzuge ich, weil — wie eingangs erwähnt — somit konfigurierte Header im Apache erhalten bleiben, etwa Expires, Mime-Types, usw.. Außerdem werden sie dann gzip-Komprimiert bei korrekter Konfiguration ausgeliefert — siehe h5bp, ist im Artikel verlinkt.
        Da der Go-Webserver eingebaut ist, möchte ich daran nichts ändern. Und den Apache hat man doch meist eh installiert. 😉

        Ich denke, alle Argumente zusammen sollten ein halbwegs klares Bild geben.

  3. Anderes Thema: Kann es sein, dass auf deinem Blog keine CSS Formatierungen angewendet werden? Zumindestens sieht er bei mir komplett unformatiert aus.

    • Benjamin Marwell Benjamin Marwell

      Einmal hart neuladen… ich kämpfe oft mit den entsprechenden Cache-Plugins. Derzeit nutze ich bwp minify und cachify. Aber das Zusammenspiel klappt oft nicht. Aufm Desktop gehts, unter Android klappt es irgendwie nie. Warum weiß ich bis heute noch nicht.

      Und das Kommentarformular… Bin schon am überlegen, ob ich bwp minify entferne.

  4. „…aber ich möchte meine Leser nicht entmündigen.“ Naja ich finde man hat auch eine gewisse Verantwortung gegenüber seiner Leser. Dafür gehört für mich auch, dass ich nicht so bewanderte Leser darauf hinweise, dass bestimmten Sachen mit Vorsicht zu genießen sind, bzw. dass man manche Sachen einfach nicht machen sollte sondern nur zur Demonstration dienen.

    • Benjamin Marwell Benjamin Marwell

      Nun ja, es ist einfach mein Schreibstil. Nur das wirklich wichtigste, ein PoC als Starthilfe bzw Hinweis. Ich lasse das weg, was ich persönlich auch in anderen Blogs weglassen würde. Gerade Xampp sollte hinreichend bekannt sein, und es ist letztlich ja auch nur auf dem Bildschirmfoto zu sehen.

      Ich könnte irgendwo eine Apache-Console fotografieren. Dann müsste ich aber nach deiner Logik auch die restliche Config Posten. Aber irgendwo muss man halt den Schlussstrich ziehen. Das tue ich sehr früh. Nicht aus Böswilligkeit, sondern um den Artikel nicht künstlich aufzublähen und bei einem Thema zu bleiben. Das ist hier Gogs, nicht Apache.

      Aber im Endeffekt: Schreibstil. 😉

      Aber ich werde einen dezenten Hinweis einfügen, okay. Macht ja nicht viel Arbeit und stört nicht. 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.