Dedizierte Server für GitLab™
Selbstverwaltetes GitLab und CI/CD-Runner auf Bare Metal
Führen Sie GitLab Self-Managed auf einem dedizierten Server mit NVMe-Speicher aus und verschieben Sie CI/CD-Jobs auf separate Runner-Server, die über ein privates VLAN verbunden sind. Dieselben Runner-Server funktionieren sowohl für GitLab Runner als auch für selbst gehostete GitHub-Actions-Runner.
GITLAB ist eine Marke von GitLab Inc. in den Vereinigten Staaten und anderen Ländern und Regionen.
-
NVMe-Speicher für Repositories -
Hochfrequenz-CPUs für CI-Builds -
Private VLAN mit 10–25 Gbit/s -
Root-Zugriff und IP-KVM
AMD Zen 5 bis zu 5,7 GHz
Unbegrenzter Datenverkehr
Enterprise-NVMe-Laufwerke
DDR5-ECC-Speicher
Hardwareanforderungen für GitLab
und GitLab Runner
Die Basis für eine einzelne GitLab-Instanz sind 8 vCPU und 16 GB Arbeitsspeicher – eine CPU mit 4–6 Kernen und 8–12 Threads auf einem dedizierten Server. Swap unter Last verlangsamt GitLab, daher lassen 32 GB Spielraum für Hintergrundaufgaben und Wachstum.
Planen Sie 40 GB für das System und PostgreSQL sowie die vollständige Größe aller Repositories ein. Gitaly, der Repository-Dienst, ist I/O-intensiv und benötigt SSD-Speicher statt Netzwerkdateisystemen, daher sind zwei NVMe-Laufwerke im RAID 1 die Standardkonfiguration.
Burstable Cloud-Instanzen und -Datenträger sind für GitLab wenig geeignet: Ihre Geschwindigkeit sinkt, sobald ein Nutzungskontingent aufgebraucht ist. Ein dedizierter Server hat keine Kontingente und keine Nachbarn auf derselben Hardware, sodass seine Kerne und NVMe-Laufwerke niemals von einem Anbieter gedrosselt werden.
CI/CD-Jobs werden am besten auf einem separaten Server und nicht auf der GitLab-Instanz ausgeführt. Ein aufwendiger Build kann dann weder Git, die Weboberfläche noch Code-Reviews verlangsamen, und Pipeline-Code wird niemals direkt neben Ihren Repositories ausgeführt.
Compiler, Tests und Image-Builds profitieren von Single-Core-Geschwindigkeit, daher verkürzt ein hoher Takt jeden Job, und die Anzahl der Kerne bestimmt, wie viele Jobs parallel laufen. Jeder Job benötigt seinen eigenen Speicher, und Docker-Layer und Caches liegen auf der NVMe des Runners.
Runner ziehen Code, Images und Artefakte über ein privates VLAN von der Instanz mit bis zu 25 Gbit/s – ein vollständiges Docker-Image kommt in Sekunden an, nicht in Minuten. Der öffentliche Port bleibt für Ihr Team frei: Git-Pushes, Merge Requests und die Weboberfläche warten niemals hinter einer Pipeline.
Dedizierte Serverpreise für GitLab und Runner
Alle Konfigurationen anzeigen
Mieten Sie einen dedizierten Server für GitLab
von INTROSERV
Wie man einen dedizierten Server bestellt
Wählen Sie eine Konfiguration aus, fügen Sie NVMe-Laufwerke hinzu, wählen Sie das Betriebssystem aus, warten Sie, bis der Server bereit ist, und installieren Sie GitLab.
Lesen Sie die Dokumentation
Installieren und sichern Sie eine einzelne GitLab-Instanz.
Schritt-für-Schritt-Installation von GitLab Self-Managed aus dem offiziellen Linux-Paket, mit HTTPS und der ersten Anmeldung.
Lies das TutorialServer und Infrastruktur für GitLab aus einer Hand
-
1
GitLab auf dem Instanzserver installieren
Installieren Sie GitLab Self-Managed aus dem offiziellen Linux-Paket auf NVMe-Speicher, mit dem mitgelieferten PostgreSQL und Redis. Richten Sie anschließend HTTPS, ausgehende E-Mails und die Container-Registry ein.
-
2
Verbinde Runner-Server über das VLAN
Bestellen Sie Runner-Server im selben Rechenzentrum und verbinden Sie sie mit einem privaten VLAN mit bis zu 25 Gbit/s. Jobs ziehen Code, Images und Artefakte über das VLAN und nicht über den öffentlichen Port.
-
3
Registrieren Sie die Läufer
Installieren Sie GitLab Runner mit dem Docker-Executor und registrieren Sie ihn bei Ihrer Instanz. Für Repositories auf GitHub betreiben dieselben Server selbst gehostete GitHub-Actions-Runner.
-
4
Sichern Sie mit dem INTROSERV-Backup-Service
Sichern Sie den gesamten Instanzserver mit dem INTROSERV Backup Service – NAKIVO-Software und Speicher in einem fertigen Service. Stellen Sie bei Bedarf den gesamten Server oder eine einzelne Datei wieder her.
Von GitLab.com zu selbst gehostet wechseln?
GitLab-Lizenzierung und Support
Lizenzierung
GitLab Enterprise Edition ist die empfohlene Installation: Ohne Lizenz läuft es im kostenlosen Tarif, und Premium oder Ultimate lassen sich später mit einem Aktivierungscode freischalten, ohne Neuinstallation. Die Community Edition ist die Open-Source-Alternative unter der MIT-Lizenz mit denselben kostenlosen Funktionen. Abonnements werden von GitLab Inc. oder seinen Partnern verkauft, nicht von INTROSERV.
Support
Support für GitLab selbst kommt aus dem GitLab-Forum und der Dokumentation oder von GitLab Inc. mit einem kostenpflichtigen Abonnement. INTROSERV kümmert sich um die Linux-Server, auf denen GitLab läuft: Überwachung, Sicherheit, OS-Updates und Behebung von Vorfällen mit einem Server-Management-Plan sowie einmalige Aufgaben als Systemadministration nach Stunden.
FAQ
-
Wie schnell wird der Server geliefert?
Sofortige Konfigurationen sind innerhalb von 3–6 Stunden nach Zahlung bereit; kundenspezifische Builds dauern in der Regel bis zu 24 Stunden. Die Lieferzeit wird bei jeder Konfiguration im Katalog angezeigt.
-
Kann der Server zuerst getestet werden?
Ja. Es gibt einen kostenpflichtigen Testzeitraum von bis zu 5 Tagen, der ausreicht, um GitLab zu installieren, ein Repository zu pushen und die erste Pipeline auszuführen.
-
Welches Betriebssystem sollte ich wählen?
Eine Linux-Distribution, die vom offiziellen GitLab-Paket unterstützt wird, wie Ubuntu LTS oder Debian. Das Paket bündelt PostgreSQL, Redis und den Webserver, sodass auf dem System nichts Weiteres installiert sein muss.
-
Kann ich meine eigene Domain und mein eigenes HTTPS-Zertifikat verwenden?
Ja. Verweisen Sie einen DNS-Eintrag auf den Server, und das GitLab-Paket kann selbstständig ein Let's-Encrypt-Zertifikat anfordern und erneuern. Stattdessen kann auch ein Zertifikat einer anderen Zertifizierungsstelle installiert werden.
-
Kann GitLab Pages auf demselben Server laufen?
Ja. Pages läuft als separater Dienst und benötigt einen Wildcard-DNS-Eintrag. Für benutzerdefinierte Domains für Pages wird außerdem eine zweite IP-Adresse benötigt, die dem Server hinzugefügt werden kann.
-
Was passiert, wenn ein NVMe-Laufwerk ausfällt?
Mit zwei Laufwerken im RAID 1 läuft GitLab auf dem verbleibenden Laufwerk weiter. Sie eröffnen ein Support-Ticket, INTROSERV ersetzt das Laufwerk im Rechenzentrum, und das Array wird neu aufgebaut.
-
Können später weitere Runner-Server hinzugefügt werden?
Ja. Bestellen Sie einen weiteren Runner-Server im selben Rechenzentrum, fügen Sie ihn dem vorhandenen VLAN hinzu und registrieren Sie ihn bei Ihrer Instanz. Pipelines beginnen ihn zu nutzen, sobald er online ist.
-
Kann der Speicher später erweitert werden?
Bei den Konfigurationen DC1, DC2 und DC3: Ja, Laufwerke für freie Steckplätze werden über ein Support-Ticket hinzugefügt, und der monatliche Preis ändert sich entsprechend. Bei anderen Konfigurationen ist es am besten, beim Bestellzeitpunkt das Laufwerkslayout mit etwas Spielraum zu wählen.
