GitLab Inc. oferuje produkt, który jest narzędziem pełnego cyklu DevOps. W witrynie producenta czytamy, że może być on zarówno częścią łańcucha dostarczania oprogramowania, jak i stanowić jego całość. Należy jednak pamiętać, że ma przede wszystkim służyć przechowywaniu kodu źródłowego tworzonych przez nas aplikacji. To w nim zawarta jest ich największa wartość. Czy lokalna instalacja GitLab jest dobrą alternatywą dla GitHub? Jakie są jej zalety i wady oraz jak ją przeprowadzić?
Wprowadzenie do GitLab
Repozytorium kodu GitLab oparte jest obecnie na najbardziej znanym systemie kontroli wersji – Git. Produkt zawiera wszystko to, co powinien posiadać każdy SVN. Wybór pomiędzy nim, a np. GitHub lub BitBucket nie jest związany tylko z użytecznością, ale też tym, co równie ważne: kosztami utrzymania, funkcjonalnościami dodatkowymi oraz bezpieczeństwem. Jeżeli chcemy zwiększyć bezpieczeństwo przechowywanego kodu i rozwijać go w ograniczonym środowisku, to warto rozważyć instalację GitLab we własnej infrastrukturze. Pozwoli to uniknąć modnej aktualnie chmury, ponieważ, jak wszyscy wiemy, to co jest jej zaletą, czasem bywa też wadą.
Licencjonowanie GitLab
Na rynku funkcjonuje kilka alternatywnych platform, takich jak GitHub lub BitBucket, jednak jedynie GitLab w wersji Community Edition pozwala na darmową instalację na własnym serwerze (wersja ta nie jest wersją trial, a pełną funkcjonalną wersją). Zawiera ona w sobie wiele opcji dostępnych w płatnym planie GitLab i oferuje szereg możliwości dla użytkownika.
Warto zwrócić uwagę na to, że korzystanie z wersji darmowej w żaden sposób nas nie ogranicza – w każdym momencie można przejść na plan płatny. Jest to bardzo korzystne dla startupów oraz początkujących przedsiębiorstw, którym trudno na początku przewidzieć, które funkcjonalności będą najbardziej potrzebne.
Poznaj LSB DATA Software House
Instalacja GitLab na własnym serwerze
Firma GitLab Inc. bardzo ułatwiła instalację systemu na własnym serwerze. Pierwszym krokiem jest podjęcie decyzji czy powinna być ona przeprowadzona na dedykowanej maszynie wirtualnej, czy też skorzystamy z rozwiązań chmurowych (AWS, Google Cloud) lub tych w formie kontenerów poprzez Kubernetes albo Docker. Przygotowanych jest wiele gotowych paczek instalacyjnych przeznaczonych m.in. dla Ubuntu Server, Debian, CentOS, OpenSUSE, jak również dla Raspberry Pi (!). Trudno wyobrazić sobie sytuację, w której nasz administrator nie znajdzie odpowiedniego środowiska do instalacji systemu. Z naszej strony polecamy utworzenie maszyny wirtualnej na systemie Debian w wersji 10.
Przygotowanie do instalacji
Przed instalacją należy przygotować środowisko spełniające minimalne wymagania:
- przestrzeń dyskowa: oficjalnie nie jest to podane wprost, ale najbezpieczniej jest przyjąć minimum 50 GB na przechowywanie danych (to zależy oczywiście od pojemności naszych projektów),
- liczba rdzeni: 4 rdzenie. Jest to zalecana liczba rdzeni procesora przypisana do maszyny wirtualnej. Jak podano na oficjalnej stronie, wystarczy to do obsłużenia do 500 użytkowników,
- pamięć RAM: 4 GB. To minimalna ilość pamięci, jaką musimy przeznaczyć do obsłużenia do 500 użytkowników. Jak wiadomo, większa ilość może wpłynąć jedynie pozytywnie na pracę systemu.
W przypadku użycia gotowych instalatorów nie należy martwić się o wersję bazy danych PostgreSQL oraz jej rozszerzenia.
Rozpoczęcie instalacji
Etap 1: instalacja aktualizacji oraz zależności na naszym serwerze.
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates perlEtap 2 (opcjonalny): jeżeli chcemy, możemy zainstalować system pocztowy Postfix na potrzeby wysyłki powiadomień (w przypadku chęci wykorzystania innego istniejącego systemu MTA możemy ten krok pominąć).
sudo apt-get install -y postfixEtap 3: dodanie oficjalnego repozytorium do systemu oraz przygotowanie do instalacji.
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bashEtap 4: konfiguracja hosta oraz rozpoczęcie instalacji. Należy pamiętać, że wybrana domena musi poprawnie wskazywać na nasz serwer, nawet jeżeli jest lokalna. W związku z tym warto sprawdzić przed instalacją poprawność rozwiązywania nazw oraz komunikację z lokalnym serwerem DNS. W przypadku gdy domena będzie domeną zewnętrzną oraz ustawimy protokół HTTPS, GitLab spróbuje automatycznie wygenerować i pobrać certyfikat Let’s Encrypt. W dalszej konfiguracji możliwa jest instalacja własnego certyfikatu – zdecydowanie polecamy tę opcję.
sudo EXTERNAL_URL="https://gitlab.lsbdata.com" apt-get install gitlab-eePierwsze połączenie
Po poprawnej instalacji na serwerze należy połączyć się przez przeglądarkę. Przy pierwszym połączeniu mamy możliwość ustawienia hasła administratora. Jako domyślny login po instalacji używany jest „root”. W kolejnym kroku należy skonfigurować komunikację, mechanizmy autoryzacji czy wygląd.
Wbudowanie CI/CD GitLab
W pełnym łańcuchu dostarczania oprogramowania bardzo ważną funkcją jest Continuous Integration (CI) oraz Continuous Delivery (CD). W systemie GitLab zawarta jest funkcja o nazwie GitLab Runners. Jest to mechanizm komunikacji z systemami, które będą wykonywać konkretne polecenia dla danego repozytorium. Jedną z największych zalet GitLab Runners jest fakt, że konfiguracja działań podejmowanych przez te systemy jest przechowywana bezpośrednio w repozytorium kodu w projekcie. Nietrudno więc sobie wyobrazić, że każda zmiana w krokach do wykonania w ramach CI/CD wprowadzana jest poprzez mechanizm repozytorium GIT. Co dzięki temu zyskujemy? Chociażby historię zmian, możliwość code review itd.
Czym jest GitLab Runners?
GitLab Runners to zewnętrzne systemy – agenci, których zadaniem jest wykonanie wskazanego kodu w ramach wydzielonego obszaru roboczego niezależnie od innych projektów. Każdy GitLab Runner to osobna maszyna wirtualna lub kontener Docker uruchomiony oraz autoryzowany na naszym serwerze GitLab. Autoryzacja wykonywana jest przez administratora GitLab na poziomie serwera, a do danego serwera możemy podłączyć wielu agentów. W przypadku większych projektów lub specyficznych wymagań możliwe jest przypisanie poszczególnego agenta do wybranych projektów.
Instalacja GitLab Runner na kontenerze Docker
Jeżeli nie mamy doświadczenia z przygotowywaniem konfiguracji GitLab Runner, warto wybrać opcję przygotowania kontenera wraz z utworzeniem wolumenu z jego konfiguracją:
docker volume create gitlab-runner-configNastępnie uruchamiamy kontener, korzystając z oficjalnego obrazu i wskazujemy nazwany wolumen:
docker run -d --name gitlab-runner --restart always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v gitlab-runner-config:/etc/gitlab-runner \
gitlab/gitlab-runner:latestKolejnym krokiem jest rejestracja Runnera na naszym serwerze GitLab. W tym celu można użyć komendy:
docker run --rm -it -v gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner:latest registerPo rozpoczęciu rejestracji należy postępować zgodnie z komunikatami. Należy się upewnić, czy nasz kontener ma komunikację z serwerem, zanim zaczniemy jego rejestrację.
Początek z CI/CD w GitLab
Na początku należy utworzyć w repozytorium plik .gitlab-ci.yml – to w nim zawarte będą wszystkie etapy oraz procesy, jakie zajdą w trakcie operacji na GitLab Runner. Poniżej przykładowa zawartość pliku .gitlab-ci.yml:
build-job:
stage: build
before_script:
- echo "Execute this command before any `script:` commands."
script:
- echo "Hello, $GITLAB_USER_LOGIN!"
test-job1:
stage: test
script:
- echo "This job tests something"
test-job2:
stage: test
script:
- echo "This job tests something, but takes more time than test-job1."
- echo "After the echo commands complete, it runs the sleep command for 20 seconds"
- echo "which simulates a test that runs 20 seconds longer than test-job1"
- sleep 20
deploy-prod:
stage: deploy
script:
- echo "This job deploys something from the $CI_COMMIT_BRANCH branch."Jak łatwo zauważyć, jest to standardowy plik zgodny ze standardem plików YAML.
Jego podstawowa składnia to:
- nazwa zadania,
- stage – etap, na którym ma być wykonane dane zadanie,
- script – komendy, jakie mają być wykonane w trakcie danego zadania.
W przypadku naszej instalacji zaszła potrzeba przygotowania agenta przed wykonaniem odpowiednich działań, dlatego ważnym punktem pliku stała się opcja „before_script”. Dzięki niej możemy zdefiniować komendy, które mają zostać wykonane przed poszczególnymi komendami. Co nam to daje?
- Software Developer z poziomu repozytorium może doinstalować niezbędny pakiet oprogramowania na GitLab Runner przed wykonaniem zadań w ramach CI/CD bez posiadania uprawnień do tego.
- Pozwala to przekazać jednorazowo klucz do autoryzacji na serwerze danej aplikacji. Należy pamiętać, że oficjalny GitLab Runner to prosty system zawierający jedynie podstawowe narzędzia, dlatego ta funkcja pozwala dostosować go bez ingerencji administratora.
Zalety lokalnej instalacji GitLab
Podstawową zaletą własnej instalacji GitLab jest zwiększone bezpieczeństwo oraz kontrola nad całym środowiskiem. W przypadku lokalnej instalacji najczęściej wykonuje się ją w sieci lokalnej przedsiębiorstwa. Oto jej zalety:
- połączenie z zewnątrz tylko za pomocą połączenia VPN (dzięki temu mamy już niejako podwójną autoryzację użytkownika),
- blokada połączeń z serwisami/systemami zewnętrznymi, a tym samym ograniczone możliwości wycieku danych,
- zabezpieczenie przechowywania danych – są one przechowywane w naszej infrastrukturze, która nie jest współdzielona i zarządzana przez firmę zewnętrzną,
- dodatkowe metody autoryzacji poprzez wewnętrzne systemy informatyczne, np. Active Directory lub LDAP (bardzo wygodne w przypadku dużych przedsiębiorstw), stosowanie SSO (Single Sign-on), centralne zarządzanie uprawnieniami.
Zaczynasz nowy projekt? Szukasz software house'u?
Wady lokalnej instalacji GitLab
Gdyby własna instalacja miała same zalety, to GitLab nie oferowałby rozwiązań w formie SaaS. Dlatego warto wspomnieć, że własna instalacja, nawet w wersji darmowej, nie jest całkowicie pozbawiona kosztów. Podczas wyboru tej formy instalacji należy wziąć pod uwagę to, że spada na nas odpowiedzialność za:
- dostarczenie infrastruktury,
- tworzenie i testowanie kopii bezpieczeństwa systemu,
- zapewnienie bieżącej konserwacji – czyli m.in. aktualizacje, problem solving,
- świadczenie wsparcia użytkownikom (przynajmniej w pierwszej linii),
- obowiązek naprawy lub odtworzenia środowiska w przypadku awarii.
Powyższe potencjalne wady są oczywiście względne, ponieważ firmy potrzebujące takich systemów jak GitLab często posiadają już odpowiednią infrastrukturę oraz wykwalifikowanych pracowników. Decyzja o wyborze formy korzystania z GitLab zależy od specyficznej sytuacji danej grupy użytkowników.
Masz pomysł? Porozmawiajmy
