Instalacja GitLab na platformie NSIS Kubernetes
Kontrola źródeł jest niezbędna do tworzenia profesjonalnego oprogramowania. Git stał się synonimem nowoczesnego systemu kontroli źródeł, a GitLab jest jednym z najpopularniejszych narzędzi opartych na Git.
GitLab można wdrożyć jako instancję lokalną, aby zapewnić prywatność przechowywanych artefaktów. Jest to również narzędzie wybierane ze względu na bogate możliwości automatyzacji.
W tym artykule zainstalujemy GitLab na klastrze Kubernetes w chmurze NSIS.
Co będziemy omawiać
Utwórz zmienny adres IP i skojarz rekord A w DNS
Zastosuj wstępną konfigurację
Zainstaluj wykres GitLab Helm
Weryfikacja instalacji
Wymagania wstępne
Nr 1 Konto
Potrzebne jest konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.
Nr 2 Zrozum rozmieszczenie sterów
Aby zainstalować GitLab na klastrze Kubernetes, użyjemy odpowiedniego wykresu Helm. Poniższy artykuł wyjaśnia tę procedurę:
Wdrażanie Helm Charts na klastrach Magnum Kubernetes w chmurze NSIS Cloud
Nr 3 Klaster Kubernetes bez zainstalowanego kontrolera wejściowego
Wykres Helm do instalacji klienta GitHub zainstaluje własny kontroler ingress, więc dla celów tego artykułu powinieneś
albo użyć klastra, który nie ma już zainstalowanego takiego kontrolera wejściowego, albo
utworzyć nowy klaster bez aktywacji opcji Ingress Controller w oknie Network. Opcja ta powinna pozostać taka sama:
Ogólne wyjaśnienie, jak utworzyć klaster Kubernetes, znajduje się tutaj:
Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum
Upewnij się, że używasz szablonu klastra przynajmniej dla wersji 1.25, jak poniżej:
Nr 4 Posiadanie własnej domeny i umiejętność zarządzania nią
Będziesz mógł zarządzać rekordami domeny powiązanej z instancją gitlab u swojego rejestratora domen. Alternatywnie OpenStack na hostingu NSIS pozwala zarządzać DNS jako usługą:
DNS jako usługa na NSIS Cloud Hosting
Nr 5 Dowód koncepcji vs. wersja produkcyjna klienta GitLab
W kroku 3 poniżej utworzysz plik my-values-gitlab.yaml, aby zdefiniować domyślną konfigurację klienta GitLab. Wybrane tam wartości zapewnią solidny szybki start, być może w fazie rozwoju „proof of concept”. Aby dostosować do produkcji, przydatne będzie to odniesienie: https://gitlab.com/gitlab-org/charts/gitlab/-/blob/v7.11.1/values.yaml?ref_type=tags
Krok 1 Utworzenie zmiennego adresu IP i powiązanie rekordu A w DNS
Nasz klient GitLab będzie uruchamiał aplikację webową (GUI) wystawioną jako usługa Kubernetes. Będziemy używać wykresu Helm GitLab, który będzie częścią instalacji GitLab,
wdrożyć ingress (kontroler i zasób), aby ustanowić routing usług i
włączyć szyfrowanie HTTPS (za pomocą CertManager).
Najpierw utworzymy pływający adres IP (FIP) za pomocą interfejsu graficznego Horizon. Ten FIP zostanie później powiązany z kontrolerem wejściowym. Aby kontynuować, przejdź do zakładki Network, następnie Floating IPs i kliknij przycisk Allocate IP to project. Wpisz krótki opis i kliknij przycisk Allocate IP.
Po zamknięciu formularza na liście pojawi się nowy pływający adres IP i powiedzmy, że na potrzeby tego artykułu jego wartość to 64.225.134.173. Następnym krokiem jest utworzenie rekordu A, który skojarzy subdomenę gitlab.<twojadomena> z tym adresem IP. W naszym przypadku może to wyglądać następująco, jeśli korzystamy z DNS jako usługi w OpenStack Horizon UI w chmurze NSIS:
Krok 2 Zastosowanie wstępnej konfiguracji
Warunkiem zapewnienia kompatybilności z konfiguracją Kubernetes na chmurach NSIS jest umożliwienie kontom usługowym udostępnianym przez wykres GitLab Helm wystarczającego dostępu do odczytu metryk skalowania. Można to zrobić poprzez utworzenie odpowiedniego rolebinding.
Najpierw utwórz przestrzeń nazw gitlab, w której wdrożymy wykres Helm:
kubectl create ns gitlab
Następnie utwórz plik gitlab-rolebinding.yaml o następującej zawartości:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: gitlab-rolebinding
namespace: gitlab
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:metrics-server-aggregated-reader
Spowoduje to dodanie rolebinding przestrzeni nazw z odpowiednią rolą klastra odczytu metryk. Zastosuj z:
kubectl apply -f gitlab-rolebinding.yaml
Krok 3 Zainstaluj wykres GitLab Helm
Teraz pobierzmy repozytorium GitLab Helm za pomocą następujących dwóch poleceń:
helm repo add gitlab https://charts.gitlab.io/
helm repo update
Następnie przygotujmy plik konfiguracyjny my-values-gitlab.yaml zawierający nasze specyficzne ustawienia konfiguracyjne. Zastąpią one domyślną konfigurację values.yaml.
my-values-gitlab.yaml
global:
edition: ce
hosts:
domain: mysampledomain.info
externalIP: 64.225.134.173
certmanager-issuer:
email: [email protected]
Oto krótkie wyjaśnienie konkretnych ustawień w tym fragmencie kodu:
- global.edition
ce - używamy darmowej, społecznościowej wersji GitLab.
- global.hosts.domain
Użyj własnej domeny zamiast mysampledomain.info.
- global.hosts.externalIP
Zamiast 64.225.134.173 umieść zmienny adres IP kontrolera wejściowego, który został utworzony w kroku 1.
- global.certmanager-issuer.email
Zamiast XYZ@XXYYZZ.com podaj swój prawdziwy adres e-mail. Zostanie on podany w certyfikatach HTTPS naszego klienta GitLab.
Gdy wszystkie powyższe warunki zostaną spełnione, możemy zainstalować wykres w przestrzeni nazw gitlab za pomocą następującego polecenia:
helm install gitlab gitlab/gitlab --values my-values-gitlab.yaml --namespace gitlab --version 7.11.1
Oto jak może wyglądać wynik udanej instalacji:
Po wykonaniu tego kroku utworzonych zostanie kilka zasobów Kubernetes.
Krok 4 Weryfikacja instalacji
Po krótkiej chwili, gdy wszystkie kapsuły są już uruchomione, możemy uzyskać dostęp do usługi Gitlab, wpisując adres: gitlab.<twojadomena>:
Aby zalogować się do GitLab z początkowym użytkownikiem, użyj root jako nazwy użytkownika i wyodrębnij hasło za pomocą następującego polecenia:
kubectl get secret gitlab-gitlab-initial-root-password -n gitlab -ojsonpath='{.data.password}' | base64 --decode ; echo
Spowoduje to przejście do następującego ekranu. Z tego miejsca możemy korzystać z różnych funkcji GitLab:
Błędy podczas instalacji
W przypadku napotkania błędów podczas instalacji, których nie można odzyskać, warto rozpocząć nową instalację. Poniżej znajduje się polecenie usunięcia wykresu:
helm uninstall gitlab -n gitlab
Następnie można ponownie rozpocząć procedurę od kroku 2.
Co robić dalej
Masz teraz do dyspozycji lokalną instancję GitLab. Kolejne kroki to:
Zwiększenie niezawodności i bezpieczeństwa instalacji, np. poprzez skonfigurowanie pamięci masowej GitLab poza klastrem.
Konfiguracja niestandardowych runnerów
Konfiguracja dodatkowych użytkowników lub federacja uwierzytelniania z zewnętrznym dostawcą tożsamości
Kroki te nie wchodzą w zakres tego artykułu, dalsze wskazówki można znaleźć w dokumentacji GitLab.