Tekton Cloud Native CI/CD

CZYM JEST TEKTON

Tekton to narzędzie do automatyzacji procesu CI/CD natywnie zintegrowane z klastrem Kuberntes i dopasowane do specyfiki procesów DevOps w obszarze Cloud (Cloud Native CI/CD).

Projekt Tekton został zainicjowany przez Google i jest projektem open-source. Z racji swojej uniwersalności i otwartej architektury coraz bardziej zyskuje na popularności i jest wykorzystywany m.in na platformach IBM Cloud, Open Shift oraz WMware Tanzu platforms.

Z wykorzystaniem Tektona możemy automatyzować procesy CI/CD w obszarze budowania, testowania i wdrażania mikrousług na klastrze Kubernetes. Skonfigurowane w Tektonie procesy bedą uruchamiane na klastrze K8S, a konfiguracja tego procesu będzie przechowywana w obiektach Kubernetes. Pliki źródłowe takiej konfiguracje będą miały postać plików yaml i mogą być wersjonowane w repozytorium kodu.

TEKTON PIPELINES

Tekton podzielony został na moduły. Każdy obszarów funkcjonalnych wymaga instalacji na klastrze K8S komponentów z odpowiedniego modułu.

Tekton wykorzystuje Kubernetes Custom Resource Definitions rozszerzając dostępne API Kubernetes o nowe obiekty po zainstalowaniu Tektona na klastrze K8S. Obiekty opisujemy i parametryzujemy w plikach yaml a następnie komendą kubectl tworzymy ich reprezentację poprzez API na Klastrze w kontekście wybranego kontekstu (namespace).

null

Fundamentem Tektona jest moduł Pipelines definiujący obiekty do budowy procesu CI/CD. Definiując procesy mamy do dyspozycji kilka typów obiektów strukturalnych. Poniżej w artykule opisane zostaną podstawowe z nich w celu zaprezentowania w jaki sposób budowany jest proces CI/CD w Tekton.

Tekton podzielony został na moduły. Każdy obszarów funkcjonalnych wymaga instalacji na klastrze K8S komponentów z odpowiedniego modułu.

Tekton wykorzystuje Kubernetes Custom Resource Definitions rozszerzając dostępne API Kubernetes o nowe obiekty po zainstalowaniu Tektona na klastrze K8S. Obiekty opisujemy i parametryzujemy w plikach yaml a następnie komendą kubectl tworzymy ich reprezentację poprzez API na Klastrze w kontekście wybranego kontekstu (namespace).

Task

Obiekt tego typu opisuje definicję pojedynczego zadania w procesie.

Przykładem takiego zadania może być np. operacja zbudowania obrazu.

null

Podstawowymi atrybutami opisującymi ten typ obiektu go są:

  • params - parametry z jakim wykonujemy zadanie np. ścieżka do pliku
  • inputs - zasoby wejściowe na których będziemy operować określone nazwą i typem zasobu np. repozytrum git
  • outputs - zasoby wyjściowe generowane przez zadanie określone nazwą i typem np. typu obraz jeżeli produktem naszego zadania będzie obraz doker
  • steps - definicja jednego lub więcej sekwencyjnych zadań ( kroków) do wykonania. Kroki są opisane poprzez wskazanie obrazu oraz określenie z jakimi parametrami uruchomieniowymi należy uruchomić obraz w celu wykonania kroku

Komendy i narzędzia z których będziemy korzystać w krokach muszą być skonteneryzowane. Dzięki takiemu podejściu wszystkie kroki zadania mogą być wykonywane jako sekwencja zależnych od siebie procesów uruchamianych na klastrze Kubernetes.

null

Podstawowymi atrybutami opisującymi ten typ obiektu go są:

  • params - parametry z jakim wykonujemy zadanie np. ścieżka do pliku
  • inputs - zasoby wejściowe na których będziemy operować określone nazwą i typem zasobu np. repozytrum git
  • outputs - zasoby wyjściowe generowane przez zadanie określone nazwą i typem np. typu obraz jeżeli produktem naszego zadania będzie obraz doker
  • steps - definicja jednego lub więcej sekwencyjnych zadań ( kroków) do wykonania. Kroki są opisane poprzez wskazanie obrazu oraz określenie z jakimi parametrami uruchomieniowymi należy uruchomić obraz w celu wykonania kroku

Komendy i narzędzia z których będziemy korzystać w krokach muszą być skonteneryzowane. Dzięki takiemu podejściu wszystkie kroki zadania mogą być wykonywane jako sekwencja zależnych od siebie procesów uruchamianych na klastrze Kubernetes.

Kroki mogą dodatkowo mieć zdefiniowane inne zasoby np. volume mount wskazujący na volumen do zamontowania do kontenera podczas uruchomienia zadania.

Pipelne

Kolejnym bazowym typem obiektu opisującym procesy w Tekton niezbędnym do zrozumienia zasady jego działania jest Pipeline.

Definiuje on powiązanie sekwencji zadań w złożony proces wielozadaniowy proces (np. tagowanie , budowanie wersji, zapis obrazu w repozytorium, testy).

null

Zadania w ramach jednego Pipeline możemy od siebie uzależniać i wykonywać sekwencyjnie lub równolegle. Możemy wykorzystywać dane wyjściowe z jednego zadania jako dane wejściowe w innym. Mamy możliwość używana warunków Conditions pod jakim dane zadanie ma zostać wykonane.

Runs

W celu utworzenia procesu wykonawczego Tasku lub Pipeline musimy stworzyć jeden z obiektów typu Runs. Tekton daje nam do dyspozycji następujące obiekty:

TaskRuns - zawierający konfigurację uruchomieniową wcześniej zdefiniowanego zadania typu Task ( obiekt Task może być także zdefiniowany bezpośrednio w TaskRun) z określonymi parametrami takimi jak: wejście, wyście oraz definicją pełnego kontekstu i skutkującego uruchomieniem zadania w tak opisanym kontekście na klastrze.

PipelineRun - Analogicznie do TaskRun zawierający opis parametrów uruchomienia zdefiniowanego wcześniej Pipleline w określonym kontekście w tym także kontekście konta serwisowego z określonym kontekstem uprawnień (parametr Service Account).

null

Do tworzenia definicji procesów wykorzystywane są dodatkowo obiekty wspomagające definiowanie wspólnych kontekstów działania zadania jak Workspace czy PipelineResource. ( nie będziemy ich tutaj szczegółowo opisywać)

Implementując deklaratywny opis procesu oprócz obiektów Tektona mamy do dyspozycji także standardowe obiekty K8S przydatne do parametryzacji takie jak ConfigMaps czy Secrets. Definiując procesy możemy także określać w jaki sposób ma być on uruchamiane w kontekście konfiguracji obiektów K8S naszym klastrze np. jaki typ poda ma być wykorzystany do wykonania danego Task lub Pipeline.

INICJOWANIE PROCESÓW ZDARZENIAMI

null

Do automatycznego (inicjowanego zajściem konkretnego zdarzenia) uruchamiania procesów zdefiniowanych w Tektonie służą obiekty z obszaru Triggers tj.

  • EventListener
  • TriggerTemplate
  • TriggerBinding

EventListener definiuje obiekt na podstawie którego Tekton utworzy usługę umożliwiająca przekazywanie do niego (protokołem HTTP i obiektami JSON) zdarzeń. Opis takiej definicji będzie zawierał odniesienie do dwóch wcześniej zdefiniowanych obiektów. Obiektu typu TrigerBinding opisującego w jaki sposób komunikat wejściowy ma zostać przetworzony na zbiór parametrów Tekton z obiektu JSON (TrigerBinding) aby Tekton mógł przekazać je dalej do TaskRuns i PipelineRuns. Definiując mapowanie mamy do dyspozycji JSON Path i możemy mapować parametry z obiektów JSON.

Drugim odniesieniem jest wskazanie na wcześniej stworzony obiekt typu TempateTrigger opisujący w jaki sposób Tekton ma zareagować na dostarczenie komunikatu ze zdarzeniem. Umożliwia to powiązanie odebrania zdarzenia z powołaniem instancji obiektu PiplineRun lub lub TaskRun skutkującego uruchomieniem konkretnego procesu w Tektonie.

Efektem utworzenia w obiektu EventListener będzie deployment przez Tekoton na klastrze usługi umożliwiającej odebranie komunikatów Http JSON oraz inicjowanie procesów. Parametryzacja obiektu Event Listener umożliwia także zabezpieczenie dostępu usługi oraz wpływanie na specyfikę deploymentu na klastrze. Dodatkowo mamy do dyspozycji standardowe interceptory do komunikacji typu WebHook oraz komunikacji ze źródłami komunikatów takimi jak GitHub, GitLab, BitBucket.

Usługi uruchomione po stworzeniu obiektu Event Listener są udostępniane jako obiekty Kubernetes Service. W celu umożliwienia dostępu do nich z usług poza klastrem (np. jeżeli chcielibyśmy zasubskrybować się na zdarzenia z GitHub typu commit) muszą być one wcześniej udostępnione za pośrednictwem Ingressa.

KONSOLA

Aby zarządzać obiektami z poziomu konsoli webowej Tekton udostępnia komponent Tekton Dashboard.

null

Możemy w niej tworzyć obiekty Teknona definiując proces oraz uruchamiać Task oraz Pipelines poprzez obiekty Runs. W konsoli widoczne są logi z procesu oraz status poszczególnych etapów wykonania. Konsola jest niezależnym komponentem, który także należy wcześniej zainstalować na klastrze.

PODSUMOWANIE

Tekton to bardzo uniwersalne narzędzie do automatyzacji procesów Cloud Native CI/CD na klastrach Kubernetes. Możemy budować i wdrażać usługi na wiele niezależnych środowisk w Cloud i Multi-Cloud z zachowaniem mechanizmów bezpieczeństwa i izolacji środowisk. Proces tworzony w Tektonie jest skompontentyzowany. Tekton to platforma elastyczna i może być zintegrowany z innymi narzędziami CI/CD które już posiadamy takimi jak np. Jenkins.