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

Opublikowane przez admin w dniu

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:

 

Następnie tworzymy ServiceAccount w powyższym namespace

 

Tworzymy rolę admina, dla powyższego namespace.

itdepends-deployment-role.yml

 

Wiążemy stworzoną rolę ze stworzonym ServiceAccount z użyciem RoleBinding.

itdepends-deployment-role-binding.yml

 

Pobieramy secrety ze stworzonego namespace:

Wyświetlą się nam dwie opcje:

Otwieramy tą, która ma nasz ServiceAccount w nazwie:

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.

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ą:

I następnie listujemy repozytoria:

Przechodzimy do zakładki Library i wybieramy External feed -> Add feed.

Wybieramy Helm feed. Wpisujemy nazwę, powyższy URL, a w credentiale wpisujemy 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.