Skalowanie i wysoka dostępność GitLab #1

GitLab początkowo był projektem open-source stworzonym przez Dmitriy Zaporozhets i Valery Sizov. Produkt udostępniano całkowicie za darmo i oparto o Licencje MIT. Dzisiaj posiadamy dwie wersje: GitLab CE: Community Edition i GitLab: Enterprise Edition. Jak nie trudno stwierdzić druga z wersji jest płatna, ale posiada znacznie większe możliwości. Samo oprogramowanie to pojedyncza aplikacja, która zapewnia wszystko, czego potrzebujemy do zarządzania, planowania, tworzenia, weryfikacji, konfigurowania, monitorowania czy zabezpieczenia naszych aplikacji. Z GitLab’a korzysta wiele dużych firm technologicznych tj. IBM, SONY, NASA czy nawet SpaceX.

Oprogramowanie jest dostępne w dwóch wariantach jako SaaS gdzie wszystko jest hostowane przez GitLab lub tzw. Self-Managed gdzie posiadamy własną instancję uruchomioną w środowisku on-premises albo w chmurze prywatnej. W przypadku tej drugiej opcji to my musimy troszczyć się o wysoką dostępność, odpowiednie skalowanie i kopie zapasowe naszej instancji. W przypadku instancji self-managed zalecaną metodą instalacji jest użycie paczki Omnibus. Dodatkowo sugeruje się, aby maszyna, na której uruchomiony zostanie GitLab miała  minimum 4GB wolnej pamięci RAM. W przypadku CPU czy też pamięci RAM większa ilość oznacza znaczny wzrost ilości użytkowników obsługiwanych przez instancję GitLab. Przy 4 rdzeniach i 16GB RAM możemy posiadać do 2000 użytkowników w ramach jednej instancji. Nie jest to jedyna metoda, bo np. dzięki zastosowaniu szybszych dysków twardych lub dysków SSD możemy również znacznie przyspieszyć działanie GitLab’a.

W przypadku instalacji z paczki Omnibus wspierane są m.in. Debian (7,8,9), Ubuntu (14.04 LTS, 16.04 LTS, 18.04 LTS), CentOS 6,7 wraz z RHEL, a nawet istnieje możliwość uruchomienia na Raspberry Pi 2. Platforma GitLab wspiera także Docker’a, Kubernetes’a czy Amazon Web Services (AWS). Niestety – przynajmniej dla niektórych osób GitLab’a nie możemy uruchomić na systemach Windows i nie zapowiada się przynajmniej na obecną chwilę, aby to się zmieniło.

Przyjrzyjmy się teraz dokładniej skalowaniu i wysokiej dostępności naszego GitLab’a uruchomionego w infrastrukturze on-premises. To my musimy odpowiednio zaplanować, w jaki sposób będziemy uruchamiać środowisko, aby sprostało naszym wymaganiom. Zakładam, że każdy posiada w swoim środowisku wirtualnym mechanizmy wysokiej dostępności na poziomie hypervisorów… albo przynajmniej powinien posiadać. W takim przypadku sprawa wydaje się prosta. Uruchamiamy wirtualną maszynę w naszym środowisku np. z systemem Ubuntu i instalujemy GitLab’a.

1. Przed właściwą instalacja aktualizujemy system i instalujemy pakiety potrzebne do działania całości.

sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates

2.  Jeżeli chcemy wysyłać powiadomienia z naszego serwera, to musimy zainstalować serwer pocztowy. Jeżeli chcemy wykorzystywać zewnętrzny serwer pocztowy to pomijamy ten krok.

sudo apt-get install -y postfix

3.  Dodajemy repozytorium GitLab I wykonujemy instalacje pamiętając o wpisaniu adresu zewnętrznego, na którym ma być uruchomiony GitLab.

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
sudo EXTERNAL_URL="http://pelna_nazwa_instancji" apt-get install gitlab-ee

4. Po zakończeniu instalacji przechodzimy do przeglądarki i wpisujemy adres podany w poprzednim kroku. Zostaniemy przekierowani do strony, aby zmienić hasło główne. Domyślnym loginem jest root.

W tym momencie posiadamy pojedynczą instancję GitLab’a. Do zapewnienia wysokiej wydajności możemy wykorzystać nasz hypervisior.

Ze względu na możliwość zwiększenia ilości przydzielonych vCPU i pamięci operacyjnej RAM dla instancji GitLab, możemy osiągnąć bardzo dużą ilość obsługiwanych użytkowników jednocześnie. Niejednokrotnie jest to bardzo duży przeskok. Dlatego też wykorzystanie wysokiej dostępności po stronie wirtualizatora dla niewielkich (do 1000 użytkowników) instalacji wydaje się wystarczające. W przypadku awarii serwera czas, przez jaki nie jest dostępny GitLab to czas przełączenia (restart) maszyny wirtualnej na serwerze, który działa poprawnie. Gdy posiadamy ponad 1000 aktywnych użytkowników, należy wtedy zastanowić się nad skalowaniem środowiska GitLab, aby nie było ono zamknięte w obrębie jednej maszyny wirtualnej… ale to już materiał na kolejny wpis!

Część II
Część III