CI/CD pipeline z użyciem Kubernetesa, AWS, Azure i .NET Core – Dodawanie klastra w Octopus Deploy

Hej, ze względu na sporo wydarzeń w moim życiu prywatnym nie jestem w stanie pisać regularnie. Jednak na ten moment jest trochę luźniej, także lecimy. Ten wpis jest kolejnym z serii CI/CD pipeline z użyciem Kubernetesa. Dziś zajmiemy się narzędziem o nazwie Octopus Deploy.
Seria CI/CD pipeline z użyciem Kubernetesa, AWS, Azure i .NET Core:
- Stawianie klastra na AWS
- Helm 3.0 i ACR
- Dodawanie klastra w Octopus Deploy
- Deploy na klaster testowy
- Stawianie klastra na Azure oraz deploy
Przegląd architektury
Wprowadzenie
Octopus Deploy jest narzędziem pozwalającym na zarządzanie wdrożeniami na wielu środowiskach w jednym miejscu. Nie będę tutaj opisywał całego narzędzia, jednak co warto powiedzieć to, że jest darmowe do 10 deployment targetów. Oznacza to, że za darmo możemy deployować na 10 klastrów k8s. Octopus jest dostępny w zarządzalnym środowisku jak i on- premise. Na stronie https://octopus.com/ możemy postawić octopusa w chmurze, dostając publiczny dostęp od ręki lub pobrać plik instalacyjny dla środowiska on-premise. Ja wybrałem opcję w chmurze.
Tworzenie środowiska i deployment targetu
Pierwsze co musimy zrobić to stworzyć środowisko w Octopusie.
Tworzymy środowisko testowe.
Klikamy Save, a następnie Add Deployment Target.
Z dostępnych targetów wybieramy oczywiście Kubernetesa.
Wpisujemy nazwę, przypisujemy klaster do wcześniej przypisanego środowiska oraz dodajemy target rolę np “`aws-k8s-test“`.
Przechodząc niżej, musimy wypełnić zakładkę dotyczącą uwierzytelniania.
Uwierzytelnianie Octopusa w klastrze
Aby zdeployować aplikacje w k8s, Octopus musi się uwierzytelnić w klastrze. Mamy do wyboru kilka metod uwierzytelniania dla różnych klastrów. Ja opiszę tutaj metodę “`Token“`. Dobrą praktyką jest, aby stworzyć użytkownika klastra, który ma ograniczony dostęp do zasobów. Poniżej przejdziemy przez proces stworzenia takiego użytkownika, który będzie adminem tylko w danym namespace kubernetesa.
Pierwszym co zrobimy, będzie stworzenie “`namespace“`:
kubectl create namespace itdepends
Następnie tworzymy “`ServiceAccount“` w powyższym “`namespace“`
kubectl -n itdepends create serviceaccount itdepends-admin-service-account
Tworzymy rolę admina, dla powyższego “`namespace“`.
kubectl create -f itdepends-deployment-role.yml
“`itdepends-deployment-role.yml“`
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: itdepends name: itdepends-admin-role rules: - apiGroups: ["", "extensions", "apps"] resources: ["*"] verbs: ["*"]
Wiążemy stworzoną rolę ze stworzonym “`ServiceAccount“` z użyciem “`RoleBinding“`.
kubectl create -f itdepends-deployment-role-binding.yml
“`itdepends-deployment-role-binding.yml“`
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: itdepends-deployment-role-binding namespace: itdepends subjects: - kind: ServiceAccount name: itdepends-admin-service-account apiGroup: "" roleRef: kind: Role name: itdepends-admin-role apiGroup: ""
Pobieramy secrety ze stworzonego namespace:
kubectl get secrets --namespace=itdepends
Wyświetlą się nam dwie opcje:
Otwieramy tą, która ma nasz “`ServiceAccount“` w nazwie:
kubectl get secrets itdepends-admin-service-account-token-fq5mx --namespace=itdepends -o yaml
Kopiujemy certyfikat oraz token. Potrzebne będą nam w Octopusie. Obie wartości są zakodowane w “`base64“`, jednak tylko token musimy odkodować.
Musimy teraz dodać powyższe konto w Octopusie. Aby to zrobić, klikamy plus zaznaczony na czerwono.
Przenosimy odkodowany z base64 token oraz wypełniamy nazwę, oraz środowisko.
Wracamy do zakładki z deployment targetem. Po odświeżeniu listy kont możemy wybrać wcześniej dodane konto.
Następnie dodajemy certyfikat.
Wklejamy wcześniej skopiowany certyfikat oraz wypełniamy nazwę i środowisko.
Po dodaniu certyfikatu wracamy do naszego deployment targetu. Dodajemy URL api serwera naszego klastra. Jest on dostępny w widoku konfiguracji “`kubectl“`.
kubectl config view
Wybieramy wcześniej dodany certyfikat i wpisujemy namespace, w którym stworzyliśmy konto w k8s.
Po zapisaniu deployment targetu sprawdźmy, czy się udało. Wybieramy zakładkę Connectivity i klikamy Health Check.
Rezpozytorium Helm w Octopusie
Dodajmy jeszcze nasze repozytorium paczek helmowych w Octopusie, które stworzyliśmy w poprzednim wpisie. Będzie nam ono potrzebne do automatycznych wdrożeń aplikacji. Do pobierania paczek potrzebujemy “`ServicePrincipala“` z uprawnieniem “`Reader“` na naszym repozytorium. Jak go stworzyć pisałem już tutaj. Dodatkowo potrzebujemy URL naszego repo, najprawdopodobniej ma następujący format: “`https://nazwaRepozytorium.azurecr.io/helm/v1/repo/“`. Dla upewnienia się możemy lokalnie dodać nasze repozytorium lokalnie następującą komendą:
az acr helm repo add --name itdepends
I następnie listujemy repozytoria:
helm repo list
Przechodzimy do zakładki Library i wybieramy External feed -> Add feed.
Wybieramy Helm feed. Wpisujemy nazwę, powyższy URL, a w credentiale wpisujemy “`
Bardzo ważne aby na koniec URL repozytorium dodać forward slash. Czyli https://nazwaRepozytorium.azurecr.io/helm/v1/repo/. W innym wypadku Octopus ignoruje tą część i feed nie będzie działał.
Klikamy Save and test. Dla testu wyszukajmy paczkę z poprzedniego wpisu:
Podsumowanie
Octopus Deploy to świetne narzędzie do zarządzania deploymentami na wielu środowiskach. W następnym wpisie zepniemy AzureDevops i Octopusa i automatycznie opublikujemy aplikacje na testowym klastrze.