Zum Inhalt springen
Odinex Cloud
GitLab CE
DevOps

GitLab CE

Ihr eigenes Git-Hosting mit CI/CD und Container-Registry.

GitLab Community Edition auf Ubuntu 24.04 mit fertig eingerichtetem HTTPS: Git-Hosting, Merge Requests, Issues und CI/CD-Pipelines auf Ihrem eigenen Server in Deutschland.

Öffnet die Odinex Console mit GitLab CE vorausgewählt. Keine Lizenzgebühr: Sie zahlen nur den Server.

Basis-Image
Ubuntu 24.04 LTS
Minimum
4 GB RAM · 40 GB Speicherplatz
Empfohlener Tarif
S4 (4 vCPU · 8 GB RAM · 120 GB NVMe)
Bereit nach dem Start
10 bis 15 Minuten (GitLab konfiguriert sich beim ersten Start)
Image-Slug
gitlab

Über GitLab CE

GitLab CE ist die Open-Source-Edition von GitLab: Git-Repositorys, Merge Requests und Code-Review, Issues und Boards, ein Wiki, CI/CD-Pipelines und eine Container-Registry in einer Anwendung. Selbst gehostet bleibt Ihr Quellcode auf einem Server unter Ihrer Kontrolle.

In diesem Image ist das offizielle Omnibus-Paket von GitLab CE installiert. Beim ersten Start konfiguriert es GitLab für die HTTPS-Adresse dieses Servers mit einem Let's-Encrypt-Zertifikat, setzt das Root-Passwort und optimiert GitLab für einen kleineren Server (weniger Puma-Worker und Sidekiq-Threads, integriertes Prometheus-Monitoring aus).

Was enthalten ist

Die im Image installierte Software und die verwendeten Ports.

Software
KomponenteVersion
Ubuntu24.04 LTS
GitLab CE (Omnibus-Paket)Neueste Version zum Zeitpunkt der Image-Erstellung
Enthaltene DiensteNGINX, PostgreSQL, Redis, Puma, Sidekiq, Gitaly
Let's EncryptIntegrierte Anbindung von GitLab, wird wiederholt, bis sie erfolgreich ist
Ports
PortProtokollVerwendung
22TCPSSH und Git über SSH (git@your-host)
80TCPHTTP (Weiterleitung auf HTTPS, Zertifikatsprüfung)
443TCPHTTPS: Weboberfläche, API und Git über HTTPS
5050TCPContainer-Registry (wenn GitLab sie mit Let's Encrypt aktiviert)

Für wen

  • Teams, die privates Git-Hosting mit Code-Review brauchen
  • Unternehmen, die Quellcode auf eigener Infrastruktur in der EU halten müssen
  • DevOps-Engineers, die CI/CD nah an ihren Servern wollen

Anwendungsfälle

  • Privates Git-Hosting für ein Team

    Repositorys, Merge Requests, geschützte Branches und Code-Review ohne Gebühren pro Nutzer.

  • CI/CD-Pipelines

    Definieren Sie Pipelines in .gitlab-ci.yml und führen Sie sie auf GitLab Runnern aus, die Sie registrieren, z. B. auf Docker-CE-Servern.

  • Container-Registry

    Bauen Sie Images in CI und pushen Sie sie in die Registry direkt neben Ihrem Code.

Ressourcen

GitLab CE braucht mindestens 4 GB RAM und 40 GB Speicherplatz. Jeder Tarif enthält NVMe-Speicher und 20 TB Traffic.

Kleinster Tarif

S2

  • 2 vCPU (geteilt)
  • 4 GB RAM
  • 60 GB NVMe-Speicher

Der kleinste Tarif, der die Mindestanforderungen erfüllt.

Empfohlen

S4

  • 4 vCPU (geteilt)
  • 8 GB RAM
  • 120 GB NVMe-Speicher

Eine komfortable Größe für den regulären Betrieb.

GitLab benötigt mindestens 4 GB RAM. S2 funktioniert für wenige Nutzer; S4 (4 vCPU, 8 GB) ist spürbar schneller und passt zu einem Team. Führen Sie CI-Jobs auf separaten Runner-Servern aus, nicht auf dem GitLab-Server. Sie können den Server später skalieren. Siehe aktuelle Preise.

Erste Schritte nach der Bereitstellung

  1. Ersten Start abschließen lassen

    GitLab konfiguriert sich beim ersten Start selbst, was einige Minuten dauert. Bis dahin antwortet die Adresse nicht oder zeigt eine 502-Seite. Das Log liegt in /var/log/nexoran-gitlab-reconfigure.log.

  2. Adresse und Passwort finden

    Adresse, Benutzername und Passwort stehen in /root/APP-INFO.txt und werden angezeigt, wenn Sie sich per SSH als root anmelden. Wenn Sie den Server mit einem Root-Passwort erstellt haben und es die Vorgaben von GitLab (mindestens 8 Zeichen) erfüllt, verwendet die App dasselbe Passwort – Sie melden sich also mit dem Passwort an, das die Console beim Erstellen angezeigt hat. Haben Sie einen SSH-Schlüssel verwendet (oder erfüllt das Passwort die Vorgaben nicht), wird für diesen Server ein starkes Passwort erzeugt und in /root/APP-INFO.txt gespeichert.

    ssh [email protected]
    cat /root/APP-INFO.txt
  3. Als root anmelden

    Öffnen Sie die Adresse und melden Sie sich als root an. Bis Sie eine eigene Domain hinzufügen, ist die App unter https://<your-ip-with-dashes>.sslip.io erreichbar (z. B. https://203-0-113-10.sslip.io), einem öffentlichen Wildcard-DNS-Namen, der auf Ihren Server zeigt, mit automatisch bezogenem Let's-Encrypt-Zertifikat. Der Aufruf der reinen IP-Adresse leitet dorthin weiter. Ist Let's Encrypt anfangs nicht erreichbar, liefert GitLab ein selbst signiertes Zertifikat aus und versucht es alle 15 Minuten erneut, bis ein gültiges ausgestellt ist.

  4. Registrierung absichern

    Deaktivieren Sie im „Admin-Bereich“ unter „Einstellungen → Allgemein → Registrierungsbeschränkungen“ die Registrierung oder verlangen Sie eine Freigabe, und legen Sie Konten für Ihr Team an.

  5. Eigene Domain verwenden

    Legen Sie für Ihre Domain einen A-Record an, der auf die IPv4-Adresse des Servers zeigt, und warten Sie, bis er auflöst. Führen Sie dann als root das Domain-Hilfsprogramm aus: Es stellt die App auf den neuen Namen um und bezieht ein neues Zertifikat. Bei GitLab aktualisiert es external_url und führt gitlab-ctl reconfigure aus.

    nexoran-app-domain app.example.com
  6. E-Mail konfigurieren

    Es ist kein Mailserver installiert, daher kann GitLab noch keine Benachrichtigungen oder Passwort-Resets versenden. Tragen Sie Ihren SMTP-Anbieter in /etc/gitlab/gitlab.rb ein und führen Sie dann gitlab-ctl reconfigure aus.

  7. Runner hinzufügen

    Pipelines brauchen mindestens einen GitLab Runner. Installieren Sie ihn auf einem separaten Server (ein Docker-CE-Server eignet sich gut) und registrieren Sie ihn in Ihrem Projekt oder im Admin-Bereich.

Hinweise zur Sicherheit

  • Die Secrets aus dem Build werden aus dem Image entfernt; jeder Server erzeugt beim ersten Start seine eigene gitlab-secrets.json. Sichern Sie diese zusammen mit Ihren Daten: Ohne sie lassen sich Backups nicht wiederherstellen.
  • Ein Server ohne Firewall nimmt jeden eingehenden Traffic an. Erstellen Sie eine Odinex-Firewall, die nur SSH (22), HTTP (80), HTTPS (443) und, falls Sie die Registry nutzen, 5050 zulässt, und wenden Sie sie auf den Server an. Odinex-Firewalls filtern den Traffic, bevor er den Server erreicht – Dockers eigene iptables-Regeln können sie daher nicht umgehen.
  • Erzwingen Sie im Admin-Bereich die Zwei-Faktor-Authentifizierung für alle Nutzer.
  • Halten Sie GitLab mit apt update && apt install gitlab-ce aktuell; das Paket-Repository von GitLab ist bereits eingerichtet. Erstellen Sie vor jedem Upgrade einen Snapshot.
  • Nutzen Sie gitlab-backup create für Anwendungs-Backups und Odinex-Backups oder -Snapshots für den gesamten Server.

Fragen zu GitLab CE

Klare Antworten zu Standort, Infrastruktur und Abrechnung.

Ist GitLab Runner enthalten?
Nein. Das Image enthält nur GitLab selbst. Installieren Sie GitLab Runner auf einem anderen Server und registrieren Sie ihn, damit CI-Jobs GitLab nicht ausbremsen.
Können sich Git über SSH und Server-SSH Port 22 teilen?
Ja. Git nutzt den Benutzer git auf Port 22 (git@your-host), und Sie melden sich auf demselben Port als root am Server an.
Wo liegt die Konfiguration?
In /etc/gitlab/gitlab.rb. Übernehmen Sie Änderungen anschließend mit gitlab-ctl reconfigure.
Ist das GitLab Enterprise Edition?
Nein, es ist GitLab Community Edition, die kostenlose Open-Source-Edition.

Dokumentation

Mehr aus dem Marketplace

GitLab CE in Frankfurt bereitstellen

Ihr eigener Server mit vollem Root-Zugriff, NVMe-Speicher und 20 TB Traffic, stündlich abgerechnet.