Dedykowane serwery dla GitLab™

Samodzielnie zarządzany GitLab oraz runnerzy CI/CD na serwerach bare metal

Uruchom GitLab Self-Managed na dedykowanym serwerze z pamięcią masową NVMe i przenieś zadania CI/CD na oddzielne serwery runnerów połączone przez prywatną sieć VLAN. Te same serwery runnerów działają zarówno z GitLab Runner, jak i z self-hosted runners GitHub Actions.
GITLAB jest znakiem towarowym GitLab Inc. w Stanach Zjednoczonych oraz innych krajach i regionach.

Pamięć masowa NVMe dla repozytoriów
Wysoko taktowane CPU do CI
Prywatna sieć VLAN przy 10–25 Gbit/s
Dostęp root i IP-KVM

Utwórz konto Wybierz serwer dla GitLab

AMD Zen 5 do 5,7 GHz

Nielimitowany transfer danych

Dyski NVMe klasy enterprise

Pamięć DDR5 ECC

Wymagania sprzętowe GitLab i GitLab Runner

Instancja: CPU i RAM

Minimalna konfiguracja dla pojedynczej instancji GitLab to 8 vCPU i 16 GB pamięci – procesor 4–6-rdzeniowy z 8–12 wątkami na dedykowanym serwerze. Swap pod obciążeniem spowalnia GitLab, więc 32 GB daje miejsce na zadania w tle i rozwój.

Przypadek: magazynowanie

Przeznacz 40 GB na system i PostgreSQL oraz pełny rozmiar wszystkich repozytoriów. Gitaly, usługa repozytoriów, intensywnie wykorzystuje operacje I/O i wymaga pamięci masowej SSD zamiast sieciowych systemów plików, dlatego standardowym układem są dwa dyski NVMe w RAID 1.

Instancja: stabilna wydajność

Instancje i dyski chmurowe typu burstable to słabe rozwiązanie dla GitLaba: ich wydajność spada po wyczerpaniu limitu użycia. Serwer dedykowany nie ma limitów ani „sąsiadów” na tym samym sprzęcie, więc jego rdzenie i dyski NVMe nigdy nie są ograniczane przez dostawcę.

Biegacze na oddzielnych serwerach

Zadania CI/CD najlepiej uruchamiać na oddzielnym serwerze, a nie na instancji GitLab. Ciężkie kompilacje nie spowolnią wówczas Git, interfejsu WWW ani przeglądania kodu, a kod potoku nigdy nie uruchamia się obok Twoich repozytoriów.

Biegacze: taktowanie zegara, rdzenie i NVMe

Kompilacje, testy i budowanie obrazów opierają się na szybkości pojedynczego rdzenia, więc wysoki zegar skraca każde zadanie, a liczba rdzeni określa, ile zadań może działać równolegle. Każde zadanie potrzebuje własnej pamięci, a warstwy Dockera i pamięci podręczne znajdują się na NVMe runnera.

Prywatna sieć VLAN między instancją a runnerami

Runnery pobierają kod, obrazy i artefakty z instancji przez prywatny VLAN z prędkością do 25 Gbit/s – pełny obraz Dockera dociera w kilka sekund, a nie minut. Publiczny port pozostaje wolny dla Twojego zespołu: wypchnięcia do Git, merge requesty i interfejs WWW nigdy nie czekają za pipeline’em.

Cennik serwerów dedykowanych dla GitLab i runnerów

Zobacz wszystkie konfiguracje

Do 1000 użytkowników

Od 60,40 €/miesiąc

Instancja zespołu 4–8 rdzeni, 8–16 wątków 16–64 GB pamięci RAM ECC 2× NVMe w RAID 1 VLAN do 25 Gbit/s

- Repozytoria, rejestr i web
- Runnerzy na oddzielnych serwerach

Wybierz konfigurację

Szybkie zadania CI

Od 166 €/miesiąc

Serwer Runner 8 rdzeni, do 5,3 GHz 32–192 GB RAM DDR5 ECC Cache kompilacji NVMe VLAN do 25 Gbit/s

- GitLab Runner lub GitHub Actions
- Kompilacje dla małego zespołu

Wybierz konfigurację

Równoległe potoki

Od 179 €/miesiąc

Runner pipeline'ów 12–16 rdzeni, do 5,7 GHz 64–256 GB RAM DDR5 ECC 2–4× NVMe build cache VLAN do 25 Gbit/s

- Kilka pipeline’ów jednocześnie
- Monorepo i długie testy

Wybierz konfigurację

Farma kompilacji

Od 250 €/miesiąc

Węzeł kompilacji 32 rdzenie i więcej 128 GB – 1,5 TB RAM ECC 4 - 10× NVMe VLAN do 25 Gbit/s

- Kompilacje C++, Rust, Android
- Wiele runnerów na jednym hoście

Wybierz konfigurację

Wynajmij dedykowany serwer dla GitLab
od INTROSERV

Jak zamówić serwer dedykowany

Wybierz konfigurację, dodaj dyski NVMe, wybierz system operacyjny, poczekaj, aż serwer będzie gotowy, i zainstaluj GitLab.

Przeczytaj dokumentację

Zainstaluj i zabezpiecz pojedynczą instancję GitLab

Krok po kroku instalacja GitLab Self-Managed z oficjalnego pakietu Linux, z HTTPS i pierwszym logowaniem.

Przeczytaj samouczek

Serwery i infrastruktura dla GitLaba od jednego dostawcy

Wynajmij serwer GitLab, serwery runnerów i kopie zapasowe od jednego dostawcy. Serwery działają w jednym centrum danych w prywatnej sieci VLAN, kopie zapasowe trafiają do własnej przestrzeni dyskowej INTROSERV, a każdy z poniższych kroków można zamówić jako usługę konfiguracji.

1
Zainstaluj GitLab na serwerze instancji

Zainstaluj GitLab Self-Managed z oficjalnego pakietu dla systemu Linux na nośniku NVMe, z dołączonymi PostgreSQL i Redis. Następnie skonfiguruj HTTPS, pocztę wychodzącą oraz rejestr kontenerów.
2
Połącz serwery runnerów przez sieć VLAN

Zamów serwery do obsługi zadań w tym samym centrum danych i dołącz je do prywatnej sieci VLAN z prędkością do 25 Gbit/s. Zadania pobierają kod, obrazy i artefakty przez VLAN, a nie przez publiczny port.
3
Zarejestruj biegaczy

Zainstaluj GitLab Runner z wykonawcą Docker i zarejestruj go w swojej instancji. W przypadku repozytoriów w GitHub te same serwery uruchamiają samodzielnie hostowane operatory GitHub Actions.
4
Twórz kopie zapasowe z usługą INTROSERV Backup Service

Wykonaj kopię zapasową całego serwera instancyjnego za pomocą INTROSERV Backup Service – oprogramowanie NAKIVO i przestrzeń dyskowa w jednej gotowej usłudze. Przywróć cały serwer lub pojedynczy plik, gdy zajdzie taka potrzeba.

Przechodzisz z GitLab.com na własny serwer?

Grupy i projekty (z issues i MR) przenieś do własnej instancji przez GitLab Direct Transfer. Obrazy i pakiety osobno.

Wybierz serwer dla GitLab Przewodnik po migracji

Konfiguracja GitLab przez inżynierów INTROSERV

Instalacja, migracja, obsługa runnerów i kopie zapasowe jako jednorazowe zadanie lub bieżąca opieka nad serwerami w ramach planu zarządzania serwerami.

Ustawienie żądania

Licencjonowanie i wsparcie GitLab

Licencjonowanie

GitLab Enterprise Edition to zalecana instalacja: bez licencji działa w darmowym planie, a Premium lub Ultimate można odblokować później za pomocą kodu aktywacyjnego, bez ponownej instalacji. Community Edition to alternatywa open source na licencji MIT, z tymi samymi bezpłatnymi funkcjami. Subskrypcje są sprzedawane przez GitLab Inc. lub jej partnerów, a nie przez INTROSERV.

Wsparcie

Wsparcie dla samego GitLaba pochodzi z forum i dokumentacji GitLaba albo od GitLab Inc. w ramach płatnej subskrypcji. INTROSERV dba o serwery Linux, na których działa GitLab: monitoring, bezpieczeństwo, aktualizacje systemu operacyjnego oraz naprawy incydentów w ramach planu zarządzania serwerem, a także jednorazowe zadania jako administrowanie systemem rozliczane godzinowo.

GITLAB jest znakiem towarowym GitLab Inc. w Stanach Zjednoczonych oraz innych krajach i regionach. INTROSERV jest niezależnym dostawcą usług hostingowych i nie jest powiązany z GitLab Inc., nie jest przez nią wspierany, sponsorowany ani nie jest jej partnerem. GitLab jest rozwijany, licencjonowany i wspierany przez GitLab Inc.; INTROSERV zapewnia wyłącznie sprzęt serwerowy oraz opcjonalną administrację systemem. Linux, Docker i PostgreSQL są znakami towarowymi lub zastrzeżonymi znakami towarowymi ich odpowiednich właścicieli, używanymi wyłącznie w celach identyfikacyjnych.

FAQ

Jak szybko serwer jest dostarczany?

Konfiguracje natychmiastowe są gotowe w ciągu 3–6 godzin od płatności; niestandardowe konfiguracje zazwyczaj zajmują do 24 godzin. Czas dostawy jest podany przy każdej konfiguracji w katalogu.
Czy można najpierw przetestować serwer?

Tak. Dostępny jest płatny okres testowy do 5 dni, wystarczający do zainstalowania GitLaba, wypchnięcia repozytorium i uruchomienia pierwszego potoku.
Który system operacyjny powinienem wybrać?

Distro Linuksa obsługiwana przez oficjalny pakiet GitLab, taka jak Ubuntu LTS lub Debian. Pakiet zawiera PostgreSQL, Redis oraz serwer WWW, więc na systemie nie trzeba instalować niczego więcej.
Czy mogę użyć własnej domeny i certyfikatu HTTPS?

Tak. Skieruj rekord DNS na serwer, a pakiet GitLab może samodzielnie zażądać i odnawiać certyfikat Let's Encrypt. Zamiast tego można zainstalować certyfikat od innego urzędu certyfikacji.
Czy GitLab Pages może działać na tym samym serwerze?

Tak. Pages działa jako osobna usługa i wymaga rekordu DNS z wildcardem. Dla domen niestandardowych w Pages potrzebny jest również drugi adres IP, który można dodać do serwera.
Co się dzieje, gdy dysk NVMe ulega awarii?

Przy dwóch dyskach w RAID 1 GitLab nadal działa na pozostałym dysku. Otwierasz zgłoszenie do pomocy technicznej, INTROSERV wymienia dysk w centrum danych, a macierz odbudowuje się.
Czy można później dodać więcej serwerów runnerów?

Tak. Zamów kolejny serwer runnera w tym samym centrum danych, dodaj go do istniejącej sieci VLAN i zarejestruj go w swojej instancji. Potoki zaczną z niego korzystać, gdy tylko będzie online.
Czy pamięć można później rozszerzyć?

W konfiguracjach DC1, DC2 i DC3 — tak: dyski do wolnych slotów są dodawane na podstawie zgłoszenia do supportu, a miesięczna cena odpowiednio się zmienia. W przypadku innych konfiguracji najlepiej wybrać układ dysków z pewnym zapasem już na etapie składania zamówienia.