Instalacja GitLab na platformie NSIS Kubernetes
Do tworzenia profesjonalnego oprogramowania jest niezbędna kontrola źródeł. 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 danych. Jest to również narzędzie wybierane ze względu na bogate możliwości automatyzacji.
W tym artykule zainstalujemy GitLab w klastrze Kubernetes w chmurze NSIS.
Co zostanie omówione?
Utworzenie adresu floating IP i skojarzenie rekordu A w DNS
Zastosowanie wstępnej konfiguracji
Zainstalowanie wykresu Helm GitLab
Weryfikacja instalacji
Wymagania wstępne
Nr 1 Konto
Jest wymagane konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.
Nr 2 Zrozumienie wdrażania pakietów Helm
Aby zainstalować GitLab w klastrze Kubernetes, użyjemy odpowiedniego wykresu Helm. Procedura jest wyjaśniona w artykule
/kubernetes/Deploying-Helm-Charts-on-Magnum-Kubernetes-Clusters-on-NSIS-Cloud
Nr 3 Klaster Kubernetes bez zainstalowanego kontrolera ingress
Wykres Helm do instalacji klienta GitHub zainstaluje własny kontroler ingress, więc dla celów tego artykułu należy:
albo użyć klastra, który nie ma już zainstalowanego takiego kontrolera ingress, albo
utworzyć nowy klaster bez włączania opcji Ingress Controller w oknie Network. Opcja ta powinna pozostać taka jak poniżej:
Ogólne wyjaśnienie, jak utworzyć klaster Kubernetes, znajduje się w artykule:
Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum
Upewnij się, że używasz szablonu klastra przynajmniej dla wersji 1.30, jak poniżej:
Nr 4 Posiadanie własnej domeny i umiejętność zarządzania nią
Zarządzanie rekordami domeny powiązanej z instancją gitlab jest możliwe u twojego rejestratora domen. Alternatywnie OpenStack w hostingu NSIS pozwala zarządzać DNS jako usługą:
DNS jako usługa na NSIS Cloud Hosting
Nr 5 Model Proof of concept a 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ć wdrożenie do środowiska produkcyjnego, przydatne będzie to odniesienie: https://gitlab.com/gitlab-org/charts/gitlab/-/blob/v7.11.1/values.yaml?ref_type=tags
Krok 1 Utworzenie adresu floating IP i skojarzenie rekordu A w DNS
Nasz klient GitLab będzie uruchamiał aplikację webową (GUI) udostępnioną jako usługa Kubernetes. Będziemy używać wykresu Helm GitLab, który będzie częścią instalacji GitLab, aby:
wdrożyć ingress (kontroler i zasób), aby ustalić routing usług i
włączyć szyfrowanie HTTPS (za pomocą CertManager).
Najpierw utworzymy adres floating IP (FIP) za pomocą interfejsu graficznego Horizon. Ten FIP zostanie później powiązany z kontrolerem ingress. Aby kontynuować, przejdź na kartę 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 adres floating IP i powiedzmy, że na potrzeby tego artykułu jego wartość to 46.60.23.7. Następnym krokiem jest utworzenie rekordu A, który skojarzy subdomenę gitlab.<twojadomena> z tym adresem IP. W naszym przypadku, jeśli korzystamy z DNS jako usługi w OpenStack Horizon UI w chmurze NSIS: może to wyglądać następująco,
Krok 2 Zastosowanie wstępnej konfiguracji
Warunkiem zapewnienia kompatybilności z konfiguracją Kubernetes w chmurach NSIS jest umożliwienie kontom usług udostępnianym przez wykres Helm GitLab 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 odczytującego metryki. Zastosuj zmiany za pomocą polecenia:
kubectl apply -f gitlab-rolebinding.yaml
Krok 3 Instalacja wykresu Helm GitLab
Teraz pobierzmy repozytorium Helm GitLab 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: 46.60.23.7
certmanager-issuer:
email: XYZ@XXYYZZ.com
Poniżej znajduje się krótkie objaśnienie konkretnych ustawień w tym fragmencie kodu:
- global.edition
ce - używamy bezpłatnej, społecznościowej wersji GitLab.
- global.hosts.domain
użyj własnej domeny zamiast mysampledomain.info.
- global.hosts.externalIP
Zamiast 46.60.23.7 wpisz adres floating IP kontrolera ingress, który został utworzony w kroku1.
- 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ć chart 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 pomyślnej instalacji:
Po wykonaniu tego kroku utworzonych zostanie kilka zasobów Kubernetes.
Krok 4 Weryfikacja instalacji
Po krótkiej chwili, gdy wszystkie pody będą już uruchomione, możemy uzyskać dostęp do usługi Gitlab, wpisując adres: gitlab.<twojadomena>:
Aby zalogować się do GitLab jako pierwszy użytkowniki, 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 wystąpienia błędów podczas instalacji, których nie można naprawić, warto rozpocząć nową instalację. Poniżej znajduje się polecenie usunięcia wykresu Helm:
helm uninstall gitlab -n gitlab
Następnie można ponownie rozpocząć procedurę od kroku 2.
Co można zrobić dalej?
Masz teraz do dyspozycji lokalną instancję GitLab. Kolejne kroki to:
zwiększenie niezawodności i bezpieczeństwa instalacji, na przykład poprzez skonfigurowanie pamięci masowej GitLab poza klastrem,
konfiguracja niestandardowych programów uruchamiających
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.