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:

1. Stawianie klastra na AWS
2. Helm 3.0 i ACR
3. Dodawanie klastra w Octopus Deploy
4. Deploy na klaster testowy
5. 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 “`Application (client) ID“` stworzonego “`ServicePrincipal“` oraz secret.

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.