Denna sida är under uppbyggnad och inte aktuell förens denna text är borttagen!
Denna sida beskriver utvecklingsfabriken uppsättning av CI/CD för deployment av mikrotjänster i OpenShift kluster.
Verktyg
OpenShift Pipelines som använder Tekton
Openshift Gitops som använder Argo CD (https://www.youtube.com/watch?v=MeU5_k9ssrs )
Koncept att känna till
För att kunna ta till sig all dokumentation bör man ha förståelse för följande saker:
Tekton
Task
ClusterTask
Pipeline
PipelineRun
Eventlistener
Trigger
TriggerTemplate
Argo CD
Grundförståelse för vad Argo CD används till
Sync/out of sync
Helm
Chart file
values file
templates files
subchart
Helm dependencies
Information hittar man enklast via de länkar som finns under rubriken verktyg.
Implementation
Utvecklingsfabriken har valt att implementera en gemensam pipline för så många mikrotjänster som möjligt, som är versionshanterad och uppdateras centralt. Det finns både för och nackdelar med en sådant val. Men fördelarna anses överväga nackdelarna. Man kan se det som vilken gemensam kod som helst där man bygger en modul som kan återanvändas av många tjänster om så önskas. När den vidareutvecklas bör man ha detta i åtanke och se till att möjligheten till att göra overrides och anpassningar är möjliga för de som använder modulen.
Pipeline Chart
För att åstadkomma en gemensam pipeline i Tekton används en Helm Chart (spring-boot-pipeline) som subchart för att generera varje tjänsts pipeline. Varje tjänst anger den gemensamma Charten som ett dependency och behöver inte (om så inte önskas) ha några egna template filer.
Charten spring-boot-pipeline är inte tänkt att användas separat utan endast som ett dependency. De parametrar som finns i spring-boot-pipeline:s value-fil blir alltså default värden för de objekt som genereras. Vissa nödvändiga parametrar saknas och förväntas tillhandahållas av service charten. Användaren av charten tvingas då att fylla i de parametrar som saknas och kan, om man vill och har behov, göra override på alla parametrar som ligger i spring-boot-pipeline:s value-fil.
Varje tjänst behöver ange ett minimalt antal parametrar och sedan genereras de slutgiltiga objekten som kompletta kubernetes objekt.
spring-boot-pipeline: https://gitlab.sundsvall.se/argocd/helm/spring-boot-pipeline
Service Chart
För deployment av en tjänst används Helm på samma sätt som för pipelines. Ett gemensamt Helm chart (spring-boot-chart) som innehåller defaults som till slut genererar kompletta kubernetes objekt.
spring-boot-chart: https://gitlab.sundsvall.se/argocd/helm/spring-boot-chart
Common pipeline
Den Tekton pipeline som genereras med hjälp av spring-boot-pipeline chart har referenser till ytterliggare objekt som behövs för att pipelinen ska kunna köras. Dessa objekt hanteras i ett separat git repository som heter common-pipeline. Här återfinns gemensamma secrets, tasks och en eventListener. Man kan tänka sig uppdelningen mellan common-pipeline och spring-boot-pipeline som att de objekt som skapas av common-pipeline delas av alla tjänster medan spring-boot-pipeline genererar unika objekt för varje tjänst.
common-pipeline: https://gitlab.sundsvall.se/argocd/common-pipeline
Rubrik
För att deploya varje mikrotjänsts pipeline och själva mikrotjänsten används Argo CD. Varje mikrotjänst har ett privat repository på https://gitlab.sundsvall.se/argocd/api-services som innehåller manifesten som ska appliceras i klustret, dels för pipelinen och dels för själva mikrotjänsten. Argo CD sätts upp att synka klustret mot det som återfinns i repot. Se “lägg till länk” för detaljer hur en tjänst ska sättas upp i Argo CD. När mikrotjänsten pipeline är deployad i klustret triggas pipelinen via en webhook som är definierad på github.com där tjänstens källkod ligger lagrad.