Jak wdrożyć samodzielnie zarządzanego GitLab na platformach chmurowych?

GitLab można zainstalować w usługach Amazon Web Services, Google Cloud Platform, Microsoft Azure oraz innych systemach wspierających Linux.

W tym artykule przedstawimy różne metody instalacji GitLab na konkretnych platformach chmurowych. Dodatkowo przekażemy instrukcje, jak łatwo zainstalować GitLab dla firm liczących do 500 użytkowników, biorąc pod uwagę ich potrzeby i wymagania. Aby zrozumieć podstawy platformy przed wdrożeniem, możesz przeczytać nasz przegląd na temat tego, czym jest GitLab.

Zacznijmy od tego, jakie metody instalacji istnieją w ogóle:

Oficjalny pakiet Linux

GitLab zaleca korzystanie z pakietu Linux o nazwie Omnibus w celu sprawnego wdrożenia samodzielnej wersji GitLab na różnych platformach chmurowych, takich jak GCP, AWS, Azure i inne. Ta metoda jest odpowiednia dla maksymalnie 1000 użytkowników. Podejście to zapewnia szybką i wysokiej jakości implementację pełnoprawnej platformy DevSecOps w celu udoskonalenia najlepszych praktyk w cyklu życia oprogramowania (SDLC). Pakiet Omnibus zawiera wszystkie niezbędne usługi i narzędzia zapewniające nieprzerwaną pracę, łatwą administrację i, co najważniejsze, stałe aktualizacje.

Architektury referencyjne

GitLab opracował i przetestował unikalne architektury referencyjne, które są zoptymalizowane pod kątem zalecanych wdrożeń na dużą skalę. Pakiety architektury referencyjnej GitLab mogą z powodzeniem obsługiwać wielu użytkowników – od 1 000 do 50 000. Jeśli jednak Twoim celem jest stworzenie środowiska dla mniejszej liczby użytkowników (do 3 000), zalecamy skorzystanie z alternatywnej metody, ponieważ architektura referencyjna wymaga wysokiego balansu dostępności, aby każdy komponent systemu GitLab mógł efektywnie pracować podczas awarii przy użyciu różnych mechanizmów. Osiągnięcie tego poziomu jest trudne; tworzenie niezbędnego środowiska może być czasochłonne i pracochłonne. W przypadku tak złożonych konfiguracji zarządzanie niestandardowymi rolami GitLab staje się kluczowym elementem utrzymania bezpiecznej kontroli dostępu.

GitLab Helm chart (Kubernetes)

Helm Chart zawiera wszystkie niezbędne komponenty do szybkiego startu i może być skalowany do dużych wdrożeń. Jeśli planujesz zainstalować GitLab na platformie OpenShift, zaleca się użycie GitLab Operator. W innych scenariuszach musisz samodzielnie skonfigurować ograniczenia kontekstu bezpieczeństwa. GitLab nie zaleca jednak tego podejścia dla środowisk produkcyjnych, ponieważ wdraża ono wszystkie usługi GitLab wewnątrz klastra. Komponenty takie jak PostgreSQL czy Gitaly powinny działać poza klastrem, aby zapewnić idealną i niezawodną pracę GitLab. Taka konfiguracja zapewnia skalowalność i niezawodną obsługę obciążeń w środowisku GitLab. Jeśli korzystasz z Kubernetes, GitLab zaleca wdrożenie architektury referencyjnej dla Kubernetes o nazwie Cloud Native Hybrid.

Cloud Native Hybrid

To podejście wykorzystuje architekturę referencyjną z jedną istotną różnicą: nie wszystkie usługi są umieszczone w tym samym klastrze, aby zapewnić optymalną wydajność procesów roboczych. Wszystkie komponenty przechowywania danych muszą działać poza klastrem. GitLab aktywnie rozwija Infrastructure as a Code (IaC), co pozwala na dostosowanie kombinacji Helm Chart z dodatkową infrastrukturą chmurową, taką jak Google Kubernetes Engine (GKE) lub Amazon Elastic Kubernetes Service (EKS), zapewniając skalowalność i elastyczność wdrożenia.

Jak zainstalować GitLab i dokonać minimalnych ustawień, aby go uruchomić?

Skupimy się na najłatwiejszej i najpopularniejszej metodzie – oficjalnym pakiecie dla systemu Linux.

Samodzielnie zarządzany GitLab występuje w dwóch rodzajach:

• GitLab CE (Community Edition).
• GitLab EE (Enterprise Edition).

Oba typy mają niewielkie różnice i są bezpłatne do momentu zakupu licencji. Główna różnica polega jednak na tym, że GitLab CE to wersja darmowa, której nie można licencjonować. Dlatego też, jeśli firma planuje korzystać z płatnych funkcji, zaleca się natychmiastową instalację GitLab EE, aby uniknąć dodatkowych kosztów przyszłej migracji.

Najpierw musimy wybrać serwer WWW, na którym zostanie wdrożony nasz GitLab. Oto rekomendacje GitLab dotyczące wyboru serwera na platformach AWS, GCP i Azure:

Biorąc pod uwagę zalecane przez GitLab specyfikacje dla maszyny roboczej oraz ich sugestię dodania 2 GB przestrzeni SWAP, sugerujemy wybór urządzenia z co najmniej 8 GB pamięci RAM i dodanie 4 GB przestrzeni SWAP, aby zapewnić płynną administrację. Podczas konfiguracji systemu i aktualizacji może wystąpić znaczne obciążenie, które może zatrzymać proces. Czas poświęcony na rozwiązywanie ewentualnych problemów jest wart różnicy w cenie maszyny. Po utworzeniu niezbędnej maszyny z wybranym systemem operacyjnym, na przykład Ubuntu 22.04, rozpoczynamy instalację i konfigurację wymaganych zależności.

Zaczynamy od instalacji i konfiguracji odpowiednich zależności.

sudo apt-get update

sudo apt-get upgrade

sudo apt-get install -y curl openssh-server ca-certificates tzdata perl

Zgodnie z zaleceniami GitLab, kolejnym krokiem jest instalacja Postfix w celu wysyłania powiadomień e-mail. Jeśli jednak chcesz skorzystać z alternatywnego narzędzia, możesz pominąć ten krok i skonfigurować zewnętrzny serwer SMTP po zainstalowaniu GitLab. Szczegółowe instrukcje dotyczące konfiguracji tej opcji znajdziesz w dokumentacji GitLab.

sudo apt-get install -y postfix

Następnie Postfix otworzy ekran konfiguracji, na którym musimy wybrać typ strony:

Następnie podajemy domenę naszego GitLab <gitlab.example.com>:

Na wszystkie inne pytania odpowiedz klikając przycisk „OK”, aby zaakceptować wszystkie wartości domyślne.

Dodaj i zainstaluj repozytorium pakietów GitLab.

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

Następnie zainstaluj GitLab.

sudo apt-get install gitlab-ee

Po instalacji hasło dla użytkownika root zostanie wygenerowane automatycznie i będzie przechowywane przez 24 godziny w /etc/gitlab/initial_root_password.

Uwaga! Zdecydowanie zaleca się natychmiastową zmianę hasła po instalacji.

Na tym etapie skonfigurujemy i aktywujemy firewall w Twoim systemie operacyjnym, zakładając, że używany jest Ubuntu 22.04. Jeśli masz już dostęp do serwera, możesz pominąć ten krok.

Najpierw musimy przyznać uprawnienia dostępu do serwera:

1|  sudo ufw allow http

2|  sudo ufw allow https

3|  sudo ufw allow OpenSSH

Włącz firewall:

sudo ufw enable

Teraz otwieramy plik konfiguracyjny GitLab do edycji. Plik konfiguracyjny gitlab.rb znajduje się w /etc/gitlab/gitlab.rb:

sudo vim /etc/gitlab/gitlab.rb

lub

sudo nano /etc/gitlab/gitlab.rb

Musisz podać swój adres IP w następnej linii:

external_url  <‘http://51.120.241.152’>

sudo gitlab-ctl reconfigure

Następnie należy poczekać na kolejny komunikat, co może zająć trochę czasu:

Po zakończeniu procedury rekonfiguracji przejdź pod swój adres IP i sprawdź, czy GitLab jest zainstalowany i działa poprawnie:

Następnie wróć do pliku konfiguracyjnego gitlab.rb i wprowadź następujące zmiany, odkomentowując odpowiednie linie:

sudo vim /etc/gitlab/gitlab.rb

or

sudo nano /etc/gitlab/gitlab.rb

external_url — domena serwera, na którym zainstalowany jest GitLab, sprawdź dokładnie, czy wskazuje na https://

• letsencrypt[‘enable’]= true – użycie certyfikatu Let’s Encrypt
• letsencrypt[‘contact_emails’] – podaję e-mail do rejestracji
• Letsencrypt[‘auto_renew’]= true – automatyczne odnawianie certyfikatu Let’s Encrypt
• Letsencrypt[‘auto_renew_hour’]= “12” podaję godzinę odnowienia
• letsencrypt[‘auto_renew_minute’]= “30” podaję minuty aktualizacji

Upewnij się, że zmiany w pliku gitlab.rb wyglądają w ten sposób i zauważ, że plik gitlab.rb jest dość obszerny, więc poszczególne zmiany mogą być od siebie oddalone.

external_url ‘https://gitlab.example.com’

letsencrypt[‘enable’] = true

letsencrypt[‘contact_emails’] = [‘example@com’]

letsencrypt[‘auto_renew’] = true

letsencrypt[‘auto_renew_hour’] = “12”

letsencrypt[‘auto_renew_minute’] = “30”

letsencrypt[‘auto_renew_day_of_month’] = “*/7”

Zapisujemy zmiany i wprowadzamy je w życie:

sudo gitlab-ctl reconfigure

Po otrzymaniu tego komunikatu, co może wymagać chwili oczekiwania, zwłaszcza w przypadku błędu 502, możesz pomyślnie zalogować się do GitLab.

Wygenerowane hasło można znaleźć w odpowiednim pliku GitLab.

sudo cat /etc/gitlab/initial_root_password

Otrzymujemy następujący wynik:

W polu „Username or email” wpisz użytkownika „root”, a w polu „Password” hasło znajdujące się w pliku „/etc/gitlab/initial_root_password”. Po pomyślnej autoryzacji możemy zalogować się na nasze konto GitLab.

Konieczna jest natychmiastowa zmiana hasła! Aby to zrobić, przejdź do swojego profilu, klikając awatar w prawym górnym rogu ekranu.

Kliknij <Edit profile -> Password>.

W poprzednim kroku zakończyliśmy etapy instalacji GitLab. Teraz przejdziemy do dodatkowych ustawień. Jak widać na przykładzie, GitLab oferuje opcję wyłączenia rejestracji nowych kont dla każdego, kto zna naszą domenę. Każdy, kto zna naszą domenę, może utworzyć konto (ale administrator nadal będzie musiał zatwierdzić rejestrację).

Odznacz pole:

Możesz również od razu skonfigurować autoryzację rejestracji w swojej organizacji:

Kliknij <Save changes>.

Pusty GitLab zużywa następującą moc:

Teraz możesz bez problemu korzystać z wygodnych funkcjonalności GitLab; musisz jeszcze skonfigurować SMTP, aby poprawnie otrzymywać powiadomienia, i jesteś gotowy do budowania swojego obszaru roboczego. W ten sposób instalacja została zakończona i zasadniczo spełnia potrzeby większości firm.

Podsumowanie

Wybierając między wdrożeniem samodzielnie zarządzanego GitLab na platformach chmurowych, takich jak GCP, AWS i Azure, a korzystaniem z wersji SaaS, decyzja zależy od firmy klienta, ponieważ brane są pod uwagę wymogi prawne niektórych krajów dotyczące przechowywania projektów w środowiskach chmurowych. Jeśli jednak ograniczenia prawne nie stanowią przeszkody, korzystamy z wersji SaaS GitLab.

Podejście to ma kilka niezaprzeczalnych zalet:

• Zmniejszenie kosztów utrzymania infrastruktury chmurowej.
• Oszczędność czasu i wysiłku zwykle wymaganych do administrowania systemem.
• Brak potrzeby skomplikowanych ustawień, które często są czasochłonne i kosztowne.
• Automatyczna konfiguracja SMTP dla powiadomień.
• Otrzymywanie aktualizacji i inne korzyści dla użytkownika podczas użytkowania.

Istnieją jednak bardziej opłacalne opcje niż samodzielnie zarządzany GitLab. Wymaga on po prostu więcej uwagi, wysiłku i zasobów, aby był skuteczny. Samodzielnie zarządzany GitLab może przynieść korzyści firmom o specyficznych wymaganiach, wysokich standardach bezpieczeństwa lub potrzebie pełnej kontroli nad swoimi danymi.

GitLab i Cloudfresh

Cloudfresh jest certyfikowanym partnerem GitLab w zakresie konsultingu, wsparcia i wdrożeń. Pomagamy organizacjom w pełni wykorzystać rozwiązania GitLab. Z naszą pomocą setki zespołów ulepszają swoje cykle SDLC dzięki naszej wiedzy specjalistycznej. Zapoznaj się z naszymi profesjonalnymi usługami GitLab.

Nasi eksperci GitLab doradzą, pokierują i wdrożą wysokiej jakości usługi wdrożeniowe GitLab oraz zapewnią wsparcie techniczne dla usług migracji GitLab.

Użyj tego linku, aby uzyskać 30-dniowy bezpłatny okres próbny dla licencji GitLab self-managed, profesjonalny onboarding, konsultacje, wiedzę specjalistyczą i wsparcie techniczne od Cloudfresh.

Przyspieszmy wspólnie Twoją transformację DevSecOps!