CI/CD

Owned by Robin Rönnberg (Unlicensed)
Last updated: Jan 11, 2023 by Joakim Schürer (Unlicensed)
3 min read

Denna sida är under uppbyggnad och inte aktuell förrän denna text är borttagen!

Denna sida beskriver utvecklingsfabriken uppsättning av CI/CD för deployment av mikrotjänster i OpenShift kluster.

Verktyg

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.

Översiktlig beskrivning av implementation

Utvecklingsfabriken har valt att implementera en gemensam pipeline för merparten av de mikrotjänster som skapas i fabriken. Pipelinen ä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, vilka sedan används för att generera de slutgiltiga kubernetes objekten.

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 repo

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

Deployment av pipeline och mikrotjänst

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, vilket 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 repositoryt. Se Skapa pipline för mikrotjänst för detaljer hur en tjänst ska sättas upp i Argo CD. När mikrotjänstens pipeline är deployad i klustret triggas pipelinen via en webhook som är definierad på github.com där tjänstens källkod ligger lagrad.

När pipelinen har kört klart pushas en uppdatering till gitlab på en ny branch. Uppdateringen innehåller vilken image som ska vara deployad i klustret. När denna mergas till den branch som Argo CD är uppsatt att övervaka, synkas uppdateringen och klustret kan deploya den nya imagen.

Pipelinen skapar en merge request mot test-branchen som default. För att deploya i produktion görs en cherry pick av en commit från test branch och appliceras på prod branch. Se Deployment i olika miljöer.

Branch-strategi

Pipelinen är utformad för att bygga en image per commit mot main branch. Varje image kan sedan promotas till varje miljö (test/prod). Det finns alltså inte en branch som bygger för test och en annan som bygger för produktion. Den image som har verifierats i test är samma image som sedan ska deployas i produktion.

Om man vill minimera antalet merge request och image byggen kan man nyttja en development branch där man kan hantera kod som ligger under utveckling.

Har man behov att göra akuta rättningar i produktion och har släpande releaser (saker som ligger på main som inte kan deployas i produktion) kan man göra ett branch bygge där man checkar ut en branch från valfri commit.

Tanken med denna strategi är att uppnå continuous deployment. Att ha så korta release cykler som möjligt och kontinuerligt deploya den nya koden i alla miljöer. Har man behov att köra två major versioner samtidigt kan en temporär branch brytas ut, vilken innehåller den äldre versionen och i Argo CD lägga upp en separat applikation. Behövs rättningar göras i den kan man nyttja branch byggen. När alla klienter gått över till ny version kan branchen tas bort.