Strategier för migration av klassiska servermiljöer till containermiljöer

Strategier för migration av

klassiska servermiljöer till

containermiljöer

Författare:_​ Albin Wejros

Handledare:_​ Jesper Andersson

Sammanfattning

Företag som är intresserade av att gå över från ett traditionellt tillvägagångssätt att driftsätta sin applikationsmiljö i en mer modern containerbaserad miljö saknas ofta den kunskap och erfarenhet som behövs. Det här arbetet syftar till att ge förslag till företag kring hur de bör gå tillväga för att flytta sin nuvarande traditionella infrastrukturella lösning, vare sig det är fysiska eller virtuella servrar, till en containerbaserad lösning. Projektet syftar också till att ge företag som är intresserade av en sådan migration en teoretisk grund att stå på för att undvika att gå i de fällor som är vanliga att gå i. Resultatet baseras på en litteraturstudie som i sin tur resulterade i en sammanfattning över vad som bör ingå i en migrationsstrategi samt ett antal praktiskt tillämpningsbara beslutsträd.

Nyckelord:_{​ docker, containers, kluster, Kubernetes, infrastruktur, images,}

repository, VMWare, Swarm, roadmap, pipelines, virtualisering, databaser, strategi

Förord

Innehåll

2.1.1 Problemidentifiering och motivering 12

2.1.2 Beskrivning av målbilden 12

2.1.3 Design och utveckling 13

2.1.4 Demonstration 13

2.1.5 Utvärdering 13

2.1.6 Kommunikation 13

2.2 Arbetets implementering av Design Science 13

2.3 Tillförlitlighet och validitet 14

2.4 Etiska överväganden 15

3 Relaterad Teknik 16

3.1 Continuous Delivery & Continuous Integration 16 3.2 Containrar och “container orchestration” 18

4.4.4 Containrars livscyklar 27 4.4.5 Orkestrering 27 4.5 Säkerhet 27 4.6 Monitorering 31 4.7 Containers livscykel 37 4.8 Container Orchestration 39 5 Beslutsträd 41 5.1 Beslutsträd 41 5.1.1 Infrastuktur 42 5.1.2 Tillvägagångssätt för drift 43 5.1.3 Container Orchestration 45 5.1.4 Livscykelhantering 46 5.2 Scenario - Startup 46

5.2.1 ExCom42s affärsområde och nuvarande infrastruktur 47

5.2.3 ExCom42s krav på sitt system 48

5.2.3 ExCom42s applicering av beslutsträden 49

6 Analys 54

6.1 Slutresultat 54

6.1.1 Strategikomponenter 54

6.1.2 Beslutsträd 54

6.1.3 Synergi mellan dessa 54

6.2 Mål 54

6.3 Utvärdering 55

7 Diskussion 57

7.1 Modellernas och strategikomponenternas kvalitet 57

7.2 Relaterade arbeten 57

7.3 Slutsatser och tillförlitlighet 58

8 Sammanfattning och framtida arbete 59

1

Introduktion

Detta är en kandidatuppsats om 15 hp vid Linneuniversitetet i ämnet datavetenskap. Arbetet syftar till att ge industrin inom mjukvaruutveckling en teoretisk överblick kring en servermiljö driftsatt med container- och klusterteknologi. Dessa teknologier används för att göra mjukvara isolerad från yttre beroenden och för att göra den portabel, dvs att den exekveras på samma sätt på olika maskiner. Arbetet syftar även till att skapa en strategistruktur för migrationsstrategier från klassiska infrastrukturer. Modellen innehåller komponenter och aspekter för de beslut som skall fattas. Även s.k. “beslutsträd” tillhandahålls för en praktisk tillämpning av dessa strategier.

1.1

Bakgrund

Företag använder i dagsläget olika infrastrukturella lösningar för att driftsätta applikationer i en on-premise kontext. Ett klassiskt exempel i en sådan kontext är att köra servrar på fysiska maskiner med dedikerad hårdvara, s.k. “bare-metal servers”. Ett modernare alternativ är att använda sig utav en virtualiserad miljö. En enda fysisk maskin kan då, med hjälp av en s.k. “hypervisor”, emulera hårdvara och på så sätt köra ett flertal servrar [1].

En ännu modernare teknik, containerization, går steget längre än virtualisering med en hypervisor. En vanlig virtuell maskin kräver, precis som en vanlig maskin, bland annat dedikerad hårdvara och ett

operativsystem. En container däremot innehåller inte mer eller mindre än det som behövs för att köra applikationen, dvs artefakter som källkod, bibliotek och verktyg etc. Det går att uttrycka det som att en container isolerar

applikationen från dess miljö. Detta betyder att en container blir

Projektet utförs i samarbete med företaget NTM i Norrköping som är en av Sveriges största mediebyråer med ca 2000 anställda.

De senaste 4 åren har NTM genomgått en digital transformation. Detta innebär att de bland annat har utvecklat nya redaktionella system som är drivna av AI/ML, e-handelssystem, prenumerationssystem, CRM,

self-service möjligheter för deras kunder (både B2C och B2B), hela 22 nya nyhetssajter och appar, och mycket mer. För att utveckla, förvalta och drifta allt detta så har NTM en utvecklingsavdelning med ca. 25 personer, och en IT avdelning på 6 personer.

NTM:s IT-infrastruktur består både av fysiska servrar och en virtuell miljö som driftas on-premise, vilket betyder att man som företag står för sina egna servrar i till exempel en serverhall istället för att använda sig utav en molntjänst. Det mesta av miljön finns i Norrköping, men NTM har även en del av miljön i Linköping. NTM har investerat 9 miljoner på 5 år i sin servermiljö. IT-avdelningen använder VMWare för att drifta allt detta. VMWare är ett företag som tillhandahåller lösningar för bland annat driftsättning och virtualisering.

För närvarande har företaget ett kontrakt på deras hårdvara som sträcker sig till 2023, vilket betyder att hela miljön kommer att vara on-site. Efter 2023 finns det eventuella planer på att lyfta miljön till molnet. Det behövs därför en plan för detta i framtiden, men detta är något som inte behandlas i det här arbetet.

1.2

Relaterade arbeten

År 2018 så undersökte Christian Abdelmassih hur en organisation kan uppnå sina höga säkerhetskrav vid en migration till en arkitektur som består av containrar [6]. Abdelmassih utredde i detta arbete hur det går att nå separation av applikationer så att organisationens, i hans fall den svenska polismyndighetens, höga krav på säkerhet kan uppnås. Abdelmassihs arbete relaterar till detta då båda organisationer har samhällskritiska uppgifter samt att de båda har mycket höga krav på integriteten och säkerheten av deras data. Resultatet av hans arbete innefattar tre olika förslag på arkitekturer, något som bör vara högst relevant till det här arbetet.

I rapporten “Virtualization vs Containerization to support PaaS” [34], så undersöks och jämförs virtuella maskiner med containrar utifrån olika aspekter. När detta arbete eventuellt kommer till att välja om företaget bör sätta alla dess applikationer och beroenden i containrar så kommer den rapporten att vara högst relevant. Risken finns att samtliga applikationer och implementeringar inte passar att containerisera, och rapporten kan då ha ett stort inflytande på valet.

1.3

Problemställning

Förutom att det tar mycket tid av personalen att konfigurera upp och förvalta varje enskilt API, så låses också resurser som CPU och minne fast till varje api:s servrar. Det här problemet har uppstått på grund av NTMs nuvarande infrastruktur som består av virtuella servrar. Detta kan bidra till ökade kostnader för drift, trots att en server kanske inte alls används mycket, förutom vid hög trafik.

Det som NTM behöver är automatisk skalbarhet, och ett mycket enklare sätt att konfigurera upp framtida API:er och servrar så personalen kan lägga sin tid på annat. De vill även enkelt kunna köra A/B tester, samt lastbalansering.

Nya tekniker för drift av system möjliggör en högre grad av flexibilitet och portabilitet än vad traditionella tillvägagångssätt erbjuder [4]. Med nya tekniker avses främst Containers och Container Orchestration.

driftsatta med virtualiseringsteknik till att driftsättas i just containrar.

Med strategi menas att ta fram de bästa verktygen för ändamålet och hur dessa ska användas.

Sammanfattningsvis så kan projektet beskrivas som en studie där de mest relevanta teoretiska kunskaperna sammanställs i syfte att ligga som grund till NTM när de utvecklar sin strategi. Projektet ska också redogöra för vad som bör ingå i en bra strategi. Frågorna som det här arbetet och företaget i fråga vill ha svar på kan brytas ner till två stycken; hur sätter de sina applikationer i containers på bästa sätt och vad bör de tänka på när de utformar en strategi för detta.

1.4

Motivation

Arbetet syftar till att hjälpa företaget att lägga upp en strategi för att migrera deras nuvarande system till en containermiljö. En sådan här migration är någonting som förväntas hända mer och mer inom industrin i relation till att den här typen av teknologi blir industristandard och det här arbetet kan då vara till fördel till företag som ämnar att göra samma sak. Arbetet kommer att tillgodose kunskap och modeller till grund för företaget att utveckla en strategi för att uppnå en framgångsrik migration. Kort beskrivet så syftar arbetet till att hjälpa industrin, speciellt då företag med lite erfarenhet av den här typen av teknologi, med att komma igång med driftsättning av applikationer i containermiljö.

Företaget har ingen tidigare erfarenhet av varken containerisering eller container orchestration. Därför behöver olika verktyg att letas upp och jämföras för att ta fram det bästa verktyget för varje syfte. Företaget i fråga är bara ett exempel i mängden men det finns många företag som står inför ungefär samma förändringsprocess som också är i behov av kunskap och stöd för att ta fram en helt ny process.

1.5

Mål

Tabell 1.1 visar de delmål som behöver nås för att kunna svara på

här arbetet sedan ska gå in mer djupgående i. M2 ska sedan utforska dessa egenskaper mer djupgående. Med M3 så menas det att redogöra för de upptäckter som gjorts i M2. M4 ska sedan validera resultatet med personal från NTM. När själva studien är utförd ska beslutsträd utformas med resultatet i beaktning, som M5 anger. M6 och M7 är inte nödvändiga för att svara på frågeställningen men det är önskvärt om dessa hinns med inom tidsramen för att stärka förståelsen för arbetet.

Tabell 1.1 - Mål

1.6

Avgränsningar

Det finns såklart ingen silverkula när det kommer till att migrera ett helt system till en sådan här infrastruktur och därför ämnar inte det här projektet heller till att vara någon definitiv guide till hur en migration ska gå tillväga. Istället syftar det till att ge företag förståelse för hur svårt det kan vara, vilka fördelar- och nackdelar det finns samt hur en lösning skulle kunna se ut m.m. Det är heller inte meningen att ta upp samtliga aspekter med en migration, utan endast de som anses mest relevanta av företaget i fallet.

Med en stor mängd verktyg som kan hjälpa till att göra migrationen smidigare så finns där heller ingen tid eller direkt anledning att konkret jämföra alla verktyg i praktiken, utan det är snarare mer genomförbart att teoretiskt redogöra skillnaderna dessa kan ha. Några exempel av kriterier är pris, användarvänlighet och tillgång till support.

1.7

Målgrupp

Intressenter för detta arbete är personer som är intresserade av fördelar- och nackdelar med att flytta över ett “klassiskt” system med virtuella dedikerade maskiner till ett system där alla, eller iallafall en majoritet av, applikationerna

M1 Teoretisk modell eller grund klargjord.

M2 Utforska relevanta komponenter i en strategi.

M3 Redogör relevanta verktyg och infallsvinklar utifrån varje aspekt i den teoretiska modellen.

M4 Bekräfta jämförelserna med NTM.

M5 Ta fram beslutsträd kring relevanta aspekter.

M6 Utveckla och utvärdera en prototyp av en eller flera containrar.

1.8

Disposition

Resterande innehåll av rapporten är organiserad som följande. Kapitel 2 beskriver modellen som används för att lösa problemet men även tillförlitligheten till arbetet samt eventuella etiska överväganden kommer att presenteras här.

2

Metod

I det här avsnittet så förklaras metoden som ska användas för att ta fram de komponenter som behövs för att utveckla en strategi.

2.1

Design Science

Figur 2.1 - Design Science-modellen

Arbetets metod utgår från DSRP (Design Science Research Process) modellen [8]. Metoden ger en struktur som beskriver hur arbetsprocessen kan organiseras då man studerar problem som innefattar design. I och med att arbetet behandlar design av ett ett flertal komponenter för att ta fram en strategi, så anses metoden passande. Metoden består av sex stycken delsteg o figur 2.1.

2.1.1 Problemidentifiering och motivering

Syftet med aktiviteten är att definiera problemet samt att rättfärdiga värdet av en lösning till detta. Metoden rekommenderar att finfördela problemet på ett begripligt sätt. På det här sättet så kan lösningen fånga problemets

komplexitet.

Att rättfärdiga värdet till en lösning åstadkommer två saker: det motiverar författaren och läsaren att sträva efter lösningen och acceptera resultaten samt att förstå resonemanget som är associerat med forskarens förståelse av problemet. Resurser som krävs för den här komponenten är kunskap om problemets tillstånd och förståelsen för vikten av en lösning.

2.1.2 Beskrivning av målbilden

Detta steg syftar till att beskriva målen som en lösning till problemet som identifierats i den första komponenten har. Målen kan vara kvantitativa, som till exempel egenskaper som en åtråvärd lösning har som inte en nuvarande lösning har. De kan också vara kvalitativa, där en lösning till exempelvis skulle lösa problem som än inte har adresserats.

om problemet samt dess nuvarande lösningar och deras effektivitet.

2.1.3 Design och utveckling

Skapandet av lösningen. Lösningen kan vara konstruktioner, metoder, modeller eller exemplifieringar där var och en av dem är brett definierade. Komponenten inkluderar aktiviteten att utröna lösningens önskade

funktionalitet och arkitektur samt skapandet av själva lösningen.

Resurser som krävs för att gå från den förra komponenten till denna är teorikunskaper som används för att skapa en lösning.

2.1.4 Demonstration

Komponenten syftar till att demonstrera lösningens effektivitet. Aktiviteter för detta kan vara saker som experiment, simuleringar, en fallstudie eller annat som kan tyckas lämpligt för just detta.

Resurser som behövs för detta är kunskap om hur man använder lösningen för att effektivt lösa problemet.

2.1.5 Utvärdering

Den här delen av metoden jämför resultatet från demonstrationen med målen som utmärkts i beskrivningen av målbilden. Detta kräver kunskap om hur man bör gå tillväga för att avgöra att problem har lösts på ett tillfredsställande sätt. Datan för detta kan vara feedback från relevant personal eller kunder, resultat från simuleringar eller experiment etc.

2.1.6 Kommunikation

Den sjätte komponenten (som inte visas i Figur 2.1) är Kommunikation och syftar till att kommunicera ut arbetet till omvärlden. I det här fallet är det denna uppsats.

2.2

Arbetets implementering av Design Science

Hela kapitel ett ägnade sig åt den första komponenten i DSRP-modellen, problemidentifiering och motivering. Den andra komponenten innefattar _​hur

målen skall uppnås_{​ snarare än att beskriva målen i sig, det vill säga att man}

definierar krav.

tillvägagångssätten för ändamålet. Dessa ändamål är olika kontexter, till exempel hur skall det gå till att försätta en applikation i containermiljö där kravet på säkerhet är högt. Ett annat exempel är hur applikationer och

containrars hälsa och status övervakas. Detta redovisas i kapitel 4.2 samt 4.3. Därefter så ska själva lösningen till problemet tas fram. Genom en nära dialog med företaget så kommer frågeställningar att tas fram och svaras på. Frågeställningarna kommer därefter att generaliseras och är sådana som är relevanta för företaget och som kan appliceras på andra applikationer från andra företag. Rent konkret så blir lösningen de jämförelser av olika

lösningar som görs. Även detta redovisas i kapitel 4, efter att aktivitet 2 har gjorts.

Efter detta steg så kommer demonstrationskomponenten och utvärderingen i modellen. När jämförelserna för en aspekt är framtagna så kommer dessa att valideras genom samtal med kunnig personal på företaget i enlighet med “Types of Research Validation” i Mary Shaw’s “What Makes Good Research In Software Engineering” [9] dvs specifikt “Validation by Experience”.

Därefter går steget tillbaka till utvecklingen av en lösning till det specifika fallet, det vill säga att en studie om nästa aspekt inleds. När

frågorna är besvarade och kraven fastställda så kommer ett flertal beslutsträd att utvecklas. Beslutsträden ska ligga som grund för hur företag tar beslut angående sin infrastruktur innan de fortsätter med sin strategi för

containerisering. Beslutsträdens faktorer, dvs titlar, kommer att tas fram tillsammans med företaget.

2.3

Tillförlitlighet och validitet

sälja en produkt. Dessa rekommendationer är ingenting som andra företag behöver ha hänsyn till då deras behov och inhemska kompetens kan vara helt olika från NTMs.

2.4

Etiska överväganden

3

Relaterad Teknik

Kapitlet behandlar och beskriver termerna Continuous

Integration/Continuous Delivery. Det går också in djupare på containerisering och kluster samt begrepp och termer som hör till dessa. Dessa begrepp och tekniker är nödvändiga att förstå för att kunna förstå sig på och genomföra strategin, men det är inte nödvändigt att de används igen under arbetets gång. Kapitlet tar också upp processteknikerna som Change Management innebär och hur det kan appliceras på en strategi

3.1

Continuous Delivery & Continuous Integration

I mitt tidigare arbete [40] diskuterade jag begreppet “kontinuerlig leverans”. Kontinuerlig leverans (som är mer känd under den engelska termen

Continuous delivery) är en mjukvaruutvecklingsmetod som är utformad för att kontinuerligt producera, leverera och distribuera ny och / eller uppdaterad programvara på ett smärtfritt sätt. Metoden för att leverera kod är inspirerad och använder vissa principer för smidig utveckling, men den är inte

begränsad till nya funktioner, utan används också för konfiguration etc. [11]. Historiskt sett distribuerades programvaran i ett skede efter dess utveckling, det vill säga det har betraktats som en separat manuell process i sig. På grund av programvarans komplexitet kan detta orsaka allvarliga problem, beroende på mjukvarans storlek, då processen kommer med många rörliga delar. Genom principerna för kontinuerlig leverans av applikationer (det vill säga att hålla programvaran driftredo hela tiden) kan du eliminera många problem, tid och kostnader i samband med felsökning och frisättning.

En viktig del av kontinuerlig leverans är kontinuerlig integration (mer känt under dess engelska term Continuous Integration). Detta löser problemet med att kombinera flera utvecklares arbete varje dag genom att integrera koden och konfigurationen för dess utvecklare med huvudgrenen (även känd som master branch). Denna princip kommer från "Extreme Programming" och ordspråket "If it’s painful, do it more often". Genom att använda verktyg som är specifika för detta fält för att automatiskt testa alla kodintegrationer är programvaran alltid i ett kvalitativt och funktionellt tillstånd [11] [12].

felsökning och frisättning mycket lägre. Produkten kan också släppas ut på marknaden snabbare och genom att använda en "leveranspipeline" kan den också upprätthålla en generellt högre kvalitet [12].

En leveranspipeline (mer känt som den engelska termen “Delivery Pipeline”) innehåller flera steg, inklusive instruktionerna som koden måste gå igenom, för att öka dess förtroende för att den fungerar som förväntat innan den tas i produktion. Stegen visas visuellt i figur 3.1. Instruktioner kallas också vanligtvis "jobb". En vanlig metod i CI är att när utvecklare integrerar sin kod med huvudgrenen, utlöses en process när koden passerar. Det är denna process som kallas för "leveranspipeline", och stegen inkluderar allt från linttester, enhetstester till sammanställning. Om koden inte går igenom detta steg (även känd som en "gate") under denna process kommer det att vara den högsta prioriteringen att fixa den innan den passerar till

versionshanteringen och produktionsservrar [14].

Figur 3.1 - Diagram över en delivery pipeline.

Kontinuerlig leverans är lätt att missuppfatta som synonymt med kontinuerlig distribution. Kontinuerlig distribution är nivån efter kontinuerlig leverans. Alla förändringar genom denna nivå är automatiska. Detta innebär faktiskt att sätta dem direkt i produktion. Detta skiljer sig från kontinuerlig leverans. Vid kontinuerlig leverans, om ändringarna går igenom distributionspipelinen, kan de Omedelbart i bruk kan du omedelbart använda den automatiskt. Ett

3.2

Containrar och “container orchestration”

För att köra en container behövs bara en så kallad containermotor, också känt som en “container runtime” [2] som visas i figur 3.2.

Figur 3.2 - Skillnaden mellan en traditionell miljö, en virtualiserad miljö och en containermiljö.

För att skapa containrar så används “images” (avbildningar), som fungerar som en slags ritning för containrarna. Dessa avbildningar specificeras i textform i en fil och byggs med hjälp av containermotorn. Flödet kan beskrivas i sekvens. Först specificeras avbildningen på något sätt, oftast genom en textfil. Sedan byggs den till en avbildning som man sedan kan dela mellan olika nätverk och datorer. Denna avbildning används sedan för att köra igång containrar som bygger på avbildningen. Det går att beskriva en container som en instans av en avbildning.

Det finns ett antal olika verktyg för att applicera containerization, men den som är absolut mest populär är Docker som stod för 83 procent av marknaden år 2018 [3]. Avbildningsfiler kallas i Dockers kontext för “Dockerfiler”.

För att hantera containrar i en produktionsmiljö går det att använda sig av system som tillämpar s.k. “Container Orchestration”. Container Orchestration innefattar hanteringen av containrars livscykler i stora dynamiska system.

containeravbildningar finns, hur kommunikation mellan olika containrar ska ske och var loggfiler ska sparas etc [7].

Det är lätt att missta Dockers verktyg “docker-compose” för container orchestration. Den stora skillnaden med det verktyget och till exempel

Kubernetes är att docker-compose har förmågan att styra flera containrar på en enda maskin (en s.k. container host). I “verklig” container orchestration finns det möjlighet att provisionera ut containrar på flera stycken maskiner vilket gör det mycket mer lämpligt för stora system med en komplex infrastruktur.

Det absolut mest populära verktyget för att åstadkomma allt detta är Kubernetes som har blivit industrins de facto standard när det kommer till container orchestration. Terminologin kring Kubernetes arkitektur kan vara komplicerad till en början men kort beskrivet så består av sex komponenter.

En _{​nod ​som beskrivs som en fysisk eller en virtuell maskin.​ ​En s.k.} container host.

Ett _{​kluster ​består av flera olika “noder” där minst en utav dessa är en} “mästarnod” och resten “arbetarnoder”.

En _{​pod​ är en enhet som består av en eller flera containrar. En pod} garanterar att containrarna som den består av befinner sig på samma maskin. Varje pod har en egen unik IP-adress vilket gör att applikationerna kan använda sig av portar utan att riskera konflikt med resten av klustret. En pod beskrivs i en konfigurationsfil.

“_{​Mästarnoden​” eller ​“control-plane node”​ hanterar planering och} driftsättning av applikationer på arbetarnoderna. Den kommunicerar med dessa genom ett API. Den tillsätter noder till poddar beroende på resursen som podden kräver.

Varje nod kör en process som kallas för _{​“kubelet”​. Dessa kubelets} ansvarar för att hantera nodens tillstånd, dvs att starta, stoppa eller

upprätthålla containrar baserat på instruktioner från “mästarnoden”. En _{​deployment ​är ett objekt som definierar poddarna och antalet} containerinstanser (containerkopior) varje pod ska ha. Dessa instanser kallas för _{​replicas ​och definieras via ett ​ReplicaSet​, som är en del av}

3.3

Change Management

Strategin kommer att utgå och ta hjälp av begreppet “Change Management”, vilket konsultbolaget Prosci beskriver som processen, verktygen och

teknikerna som används för att hantera den mänskliga aspekten vid en organisatorisk förändring [15]. Begreppet skiljer sig från “Project

Management” som innefattar kunskap, erfarenhet, verktyg och tekniker för att utföra själva förändringen och använder sig istället av tekniker och resurser för att resultatet av förändringen ska bli så framgångsrik som möjligt. Båda formerna av hantering behövs för att en förändring ska bli framgångsrik.

Prosci nämner att när en förändring introduceras till en organisation så påverkas minst en av följande faktorer: processer, system, organisatoriska strukturer och arbetsroller. Det här arbetet kommer att påverka samtliga faktorer men främst de två förstnämnda på grund av förändringarna till processen att bära ut uppdaterad kod via CI/CD-lösningar till systemen som applikationerna är driftsatta i. Genom att applicera Change Management så kan systemet tas från punkt A till punkt B genom en förändring till

4

Migrationsstrategier

Kapitlet beskriver strategier och vad en bra strategi bör innehålla men även vad hjälpmedlet beslutsträd är och vad dessa är bra för. Det tar också upp frågeställningar från företaget för att sedan generalisera och besvara dem utifrån ett teoretiskt och allmänt perspektiv.

4.1

En bra strategi

Ett bra strategiarbete sker i flertalet steg på olika nivåer. Det första steget innefattar den verifierande strategin och sedan tillförs mer detaljer genom specifika beslut. Men för att utforma en strategi så måste man först ha klart för sig vad en strategi är och hur den definieras. En populärvetenskaplig definition av strategi är ett sätt att beskriva _{​hur​ saker och ting bör utföras} [35]. En strategi skiljer sig från en handlingsplan då den inte är lika specifik i sitt utförande. Den försöker istället att ge ett brett svar på frågan “Hur tar vi oss från punkt A till punkt B?”. En genomarbetad strategi tar också hinder och resurser (som personal, finanser, makt, material osv) i beaktning. Den ska också följa de mål som har satts upp med initiativet. Det är också inte

ovanligt att ett initiativ använder sig av flera mindre delstrategier för att uppnå sitt mål.

Mål å andra sidan kan beskrivas som en kontrast till en strategi. Ett mål beskriver hur ett framgångsrikt tillstånd ser ut medans en strategi föreslår vägar att ta på vägen till framgång. En strategi finns till för att hjälpa till i besluten som man tar på vägen för att realisera den grundläggande visionen och dess mål.

Det finns flera kriterier som en strategi bör möta för att kunna anses vara bra.

4.1.1 Riktning

Ger strategin en övergripande riktning att gå emot? En bra strategi bör kunna ge en god idé om vilken väg som bör tas utan att begränsa tillvägagångssättet allt för mycket.

4.1.2 Resurser

Passar strategin de resurserna och möjligheterna som finns? En strategi bör utnyttja de resurser och tillgångar man har. Den bör också ta hänsyn till de möjligheter som finns, som till exempel viljan hos organisationen att utföra en förändring.

4.1.3 Friktion

4.1.4 Påverkan

Når strategin de människor som initiativet påverkar? För att adressera ett problem så bör strategin sammankoppla med de som påverkas av initiativet. I det här arbetets fall så bör till exempel strategin sammankoppla med

IT-personal som rimligtvis riskerar att bli de som blir mest påverkade av initiativet.

4.1.5 Framsteg

Avancerar strategin initiativet? En strategi finns som tidigare beskrivet till som grund för initiativtagare att ta beslut ifrån. Om målet är att ta företagets applikationer till containrar, så bör strategin ha en påverkan på beslutstagarna kring detta för att kunna anses vara en bra strategi.

4.2

Beslutsträd

När strategin är klarlagd är det en bra idé att ta till hjälpmedel för att få ett mer specifikt stöd kring hur målen ska uppnås. Ett sådant hjälpmedel kan vara olika diagram eller delmål. En av de mer populära tillvägagångssätten är ett beslutsträd. Ett beslutsträd är en annan form av ett flödesschema som används för att visualisera beslutstagarprocessen. Trädet gör detta genom att kartlägga beslutens förlopp och deras potentiella utgångar [39].

Figur 4.1 - Beslutsträd

Figur 4.1 visar ett typiskt beslutsträd. Användaren får ställa fördelar mot nackdelar för var och en av besluten i varje lager. När samtliga beslut är tagna så är vägen till det slutgiltiga målet, roten, klarlagd.

4.3

Frågeställningar

För att kunna utveckla en strategi behöver företaget först besvara ett antal generella frågeställningar och ta beslut utifrån dessa svar. Frågeställningarna identifieras med hjälp av möten och samtal med nyckelpersoner på företaget. De teoretiska aspekterna som sedan presenteras i kommande kapitel ska sedan, tillsammans med anpassningsbara beslutsträd, ligga till grund för företaget då de besvarar sina frågor.

Nedan är frågor från företaget som har kommit upp under möten. Frågorna är väldigt tekniska men det går att utvinna mer generella frågeställningar som företag i allmänhet behöver få besvarade för att kunna utveckla en effektiv strategi, vilket görs längre fram i avsnitt 4.4.

1. Ska en image kompilera källkod eller bara köra redan kompilerad kod?

4. Hur hanterar vi images i våran Continuous Integration-lösning? ○ Hur hanteras “secrets”, dvs hemlig data som till exempelvis

connection strings i en container?

5. Kommer applikationens källkod att behöva ändras för att passa en containermiljö?

6. Kommer en anställd utvecklares vardagliga arbetsflöde att påverkas? 7. Vi har privata NuGet-paket som vi använder i våra applikationer. Hur

får vi in dessa i en image/container?

8. Vi har tre olika miljöer, “Development”, “Staging” och “Production”. Hur hanterar vi detta i en containermiljö?

9. Kommer vi kunna dra ner på våra licenser från VMWare, och isåfall med hur mycket/många licenser?

4.4

Grundmodell

För att projektets resultat skall vara applicerbara på andra företags initiativ till att gå över till en containerbaserad servermiljö, så måste frågeställningarna generaliseras till mindre specifika problem och faktorer.

Konsult- och forskningsföretaget Gartner har identifierat sex stycken faktorer som man bör ha i beaktning i en containeriseringsstrategi, nämligen säkerhet, monitorering, lagring, nätverk, hanteringen av en containers livscykel samt container orchestration [10]. En visualisering för detta finns i figur 4.2. Dessa faktorer bildar tillsammans en generaliserbar modell som får ytterligare stöd av anpassningsbara beslutsträd.

Figur 4.2 - Gartners modell för en containeriseringsstrategi.

4.4.1 Säkerhet

Gartner beskriver säkerhet som någonting som bör vara integrerad i DevOps-processen och poängterar att den containeriserade miljön bör vara säkrad genom hela dess livscykel. För att förhindra saker som illasinnad aktivitet så bör beslutstagare i en strategi investera i produkter som tillförser funktioner som beteendemonitorering och avvikelsedetektering.

4.4.2 Monitorering

Monitorering behöver också ingå i en strategi. Användandet och driftsättningen av cloud-native applikationer (dvs applikationer som är designade för stor skala, snabb förändring och för att kunna återhämta sig snabbt vid fel [43]) har flyttat fokuset på att monitorera tjänster och applikationer snarare än maskinen som de körs på. Därför bör fokuset i en strategi också ligga på applikationer istället för fysiska maskiner.

containrar eller om man syftar till att refaktorera dem till mikrotjänst-baserade applikationer. Om det senare är fallet så behöver det finnas någon form av lagringsplattform som är integrerad med arbetsflödet.

4.4.3 Nätverk

Nätverk behöver hanteras helt annorlunda på grund av containrars kortlivade natur. Gartner beskriver hur företag bör ha en plan för hur de ska automatisera nätverksrelaterade arbetsuppgifter genom den tillgång på verktyg som finns tillgängliga.

4.4.4 Containrars livscyklar

På grund av lättheten med att driftsätta fler containrar så är det också lätt att antalet containrar som belastar infrastrukturen eskalerar. Det behövs en plan för att hantera containrars livscyklar. Företag bör ha en tydlig plan för hur det här hanteras med diverse continuous integration-verktyg och andra automationsverktyg i sin strategi.

4.4.5 Orkestrering

Den sista hörnstenen i Gartners modell i figur 4.1 behandlar orkestreringen, dvs hanteringen av containrar. En god strategi bör ha en robust plan för hur initiativtagaren ska hantera containrar. Den bör innehålla för- och nackdelar med olika konsumtionsmodeller för verktyg som syftar till att hantera containrar.

Ämnena ovan är väldigt breda, speciellt säkerhet och monitorering, men arbetet berör endast ämnena genom perspektivet _{​containrar och}

containerisering_​.

4.5

Säkerhet

De poängterar vikten av att använda sig av så minimalistiska “grundimages” som möjligt, det vill säga de officiella och inofficiella images som man använder sig utav när man ska sätta sin applikation i en container. Ska en applikation använda sig av till exempel en node runtime så används en officiell, redan färdigbyggd, image med node färdiginstallerad som man bygger vidare på. Problemet som Snyk ser med detta är när användare bygger vidare på den officiella imagen “node” utan att specificera en version så kan det tillkomma bibliotek och tillägg som inte behövs vilket i sin tur utökar attackytan. Genom att minska imagen som byggs ut till den version som inte innehåller mer än absolut nödvändigt så minskas därmed även attackytan.

I tabell 4.1 så listas de misstag som oftast är orsaken till varför containern kan ses som osäker och vad som kan göras för att minimera riskerna.

För “uppsvälld”

grundimage (Även känt som “bloat”*)

* “Bloat” betyder att “för mycket” programvara är installerad, det vill säga sådan som inte behövs eller är oönskad/ospecificerad.

Använd en mer minimalistisk version som endast innehåller de paket, bibliotek och funktioner som applikationen kräver alternativt installera de paket som saknas själv i din egen image.

Container har rootaccess_​*

*Containern har potentiellt tillgång till värdmaskinens filsystem och inställningar.

Specificera ‘USER’ i Dockerfilen och ge den skräddarsydda rättigheter för att minska bieffekter.

Användning av

osignerade/overifierade images

Docker har som standardläge att tillåta användning av images utan att verifiera dess validitet. Användningen av dessa kan leda till problem, och inte minst av allt

som är verifierade av Docker själva. Onödiga

grundinställningar i images

När användaren laddar ner en image för att använda som grund så tar användaren också en indirekt risk med de potentiellt dåligt inställda standardinställningar. Detta kan minimeras genom att dels återigen använda sig av en minimalistisk image men också genom att använda sig av mjukvara för att scanna igenom imagen innan den används för att exponera svagheter och sårbarheter. Dels finns det inbyggd funktionalitet för detta i Docker med Docker Bench Security, men det kan även vara en bra idé att använda sig av

tredjepartsalternativ som till exempelvis Snyk. Användning av känslig

information

Det är mycket vanligt att det krävs känslig data vid byggandet av applikationer inuti images som till exempel nycklar eller tokens för att installera privata paket. Om man skulle kopiera in de rakt av i Dockerfilen så kan det medföra en stor säkerhetsrisk, både genom exponering i filen och senare i runtime. Därför bör känslig data hållas utanför Dockerfilen. Docker har inbyggt stöd för “multi-stage builds”, vilket delar upp byggandet av imagen i flera lager. Genom att applicera detta så behöver ingen känslig information komma ut i den slutgiltiga imagen. Utöver detta så ger det även mer anpassade images som kan användas i produktion, vilket medför att attackytan minskas.

Rekursiv kopiering Det är vanligt att använda sig av kommandot ‘COPY . .’ vilket kopierar hela katalogen till imagen, vilket kan medföra att känslig

Tabell 4.1 - De vanligaste säkerhetsmässiga misstagen vid containerisering med Docker och rekommenderad lösning

det här misstaget antingen genom att ta bort den känsliga datan eller använd dockerignore som tillåter Docker att exkludera angivna filer. Versionen av den

grundläggande imagen ändras.

En enda docker image kan ha flera stycken taggar som separeras från namnet med ett kolon. (Till exempel node:3.17) Genom att specificera taggen så kan man på så sätt veta vilken image man bygger vidare på varje gång. Fördelen med detta är att beteendet på imagen blir konsekvent vilket ökar säkerhetsgraden. Använder kommandot

‘ADD’.

ADD, till skillnad från COPY, skapar

destinationen som anges i dess argument och accepterar dessutom lokala och avlägsna URLer som källa.

Anger och använder sig inte utav metadata.

Med kommandot ‘LABEL’ i Dockerfiler så är det möjligt att tillhandahålla metadata till imagen. Det kan vara vad som helst men det är rekommenderat att lägga till metadata som kontaktinformation till den som är ansvarig för imagen och en kvalitetsstatus (om alla tester har gått igenom osv.) Det är dessutom

rekommenderat av standarden RFC5785 [8] att använda sig av en SECURITY.TXT-fil. En referens som till exempel en URL till denna fil kan anges i metadatan.

Använder sig inte utav en linter.

En linter är en form av mjukvara som parsar en Dockerfil och varnar för användning av

4.6

Monitorering

Kubernetes-as-a-Serviceföretaget Rancher räknar upp och jämför sju olika alternativ av verktyg för monitorering av containrar i en artikel [20]. De utvärderar dessa verktyg utifrån sex kriterier:

1. Komplexitet i att driftsätta dem. 2. Nivå av information som produceras.

3. Nivå av sammanklumpning av information från hela systemet. 4. Egenskap att larma utifrån informationen som tillges.

5. Egenskap att monitorera resurser som inte kommer ifrån Docker. 6. Kostnad.

I tabell 4.2 redogörs en kort beskrivning för varje verktyg, Ranchers betyg utifrån kriterierna som listas ovan och en kort slutsats.

VERKTYG BESKRIVNING RANCHERS BETYG / ARBETETS SLUTSATS Docker Stats & Docker Remote API

Dockerklienten har inbyggda verktyg för ändamålet.

Docker Stats är ett verktyg som redan finns inbyggt i klienten och är tillgängligt i ett

gränssnitt via terminal.

Verktyget är väldigt enkelt och körs endast genom kommandot ‘docker stats’ följt av de

containrars namn som är i drift. Docker kommer då i realtid att visa CPU-användning, minnet som används och totalt

tillgängligt minne för varje container. Värt att notera är att om användaren inte har

1. 5/5 2. 5/5 3. Ej existerande 4. Ej existerande 5. Ej existerande 6. Gratis

allokerat en viss mängd minne så kommer värdmaskinens totala minne att visas under den sista parametern.

Genom att använda Docker Remote API så kan användaren få tillgång till mer detaljerad information via HTTP requests som ger tillbaka JSON-objekt. Informationen är densamma som för Docker Stats fast betydligt mer detaljerad.

monitoreringsmjukvar a.

CAdvisor Är det önskvärt att tillgå samma information som Docker Stats tillger i ett mer grafiskt

gränssnitt så behövs ett verktyg som CAdvisor. Verktyget producerar samma information som Dockers egna verktyg med hjälp av grafer och tabeller. Det är också open-source och gratis. Dess kapabilitet att övervaka resurser sträcker sig dock bara till en enda värdmaskin, den maskin som den körs på, vilket leder till problem i

klustermiljöer. Datan som produceras är dessutom en rörlig graf som visar den senaste minuten, vilket betyder att det är omöjligt att se

långsiktiga händelser och kurvor. Det finns heller ingen funktionalitet att larma om resursanvändningen hamnar på 1. 5/5 2. 2/5 3. 1/5 4. Ej existerande 5. Ej existerande 6. Gratis

CAdvisor är ett väldigt bra verktyg när

användaren precis har kommit igång med containrar. Vid mer kritisk drift som till exempelvis i

produktion så krävs mer robusta verktyg. Eftersom det är gratis och resurssnålt så skadar det hursomhelst inte att ha det driftsatt på alla värdmaskiner, även de som är

för höga nivåer.

Scout Scout adresserar de problem som finns med CAdvisor. Verktyget är agentbaserat (det vill säga att det tar data från egna värdmaskiner, men att är driftsatt på en dedikerad server) och har funktionalitet att samla information från flera värdar, den kan se och presentera mer långsiktig data och den kan dessutom skapa larm som är baserad på sagd data. Scout konfigureras genom det välkända formatet YAML och det är möjligt att driftsätta verktyget genom ett plugin till Docker vilket skapar upp ett gränssnitt som är tillgängligt via en webbläsare. Själva servicen är dock driftsatt på deras egna server som

agenterna/värdmaskinerna sedan skickar sin data till. Genom att skapa någonting som Scout kallar för “triggers” så kan användaren konfigurera Scout att larma om något värde går över eller under ett angivet värde. Dessa värden hämtas från den angivna containerns värdmaskin, vilket betyder att det är omöjligt att larma för maskiner som har flera

containrar av olika slag. Detta

1. 4/5 2. 2/5 3. 3/5 4. 3/5 5. Fullt stöd 6. $10/ Övervakad värd Scout är ett bra

alternativ om man inte driftsätter flera olika containrar på samma maskiner. Finns där ett stort antal

gör också att information inte är lika detaljerad som till

exempelvis CAdvisor, som bevakar varje container individuellt.

Data Dog DataDog fungerar på ett liknande sätt som Scout, men försöker att lösa de problem som Scout och CAdvisor har. Det är, precis som Scout, en service som är driftsatt på dedikerade servrar. Verktyget erbjuder en betydligt flexiblare och mer detaljerat system för att larma användare. Det är möjligt att definiera på en djupare nivå vilka kriterier som krävs för att till exempel skicka ett email till systemadministratör. DataDogs larmsystem gör det också möjligt att felsöka i stora system med många maskiner.

1. 5/5 2. 5/5 3. 5/5 4. Fullt stöd 5. 5/5 6. $15/Övervakad värd

Ett mindre system hade dragit mest fördelar med Data Dog då det slår Scout på de flesta punkterna. För ett större system så rekommenderas något annat verktyg på grund av kostnaden.

Sensu Monitoring Framework

Både Scout och DataDog bygger på en centraliserad arkitektur på dedikerade servrar. Om man däremot behöver ett verktyg som man själv kan konfigurerar och installera på sin egna server så är Sensu Monitoring Framework (SMF) ett bra alternativ. SMF stödjer dock inte Docker och containrar direkt, utan verktyget behöver ett plugin för att lösa detta.

1. 1/5 2. 4/5 3. 4/5 4. Fullt stöd men begränsad förmåga att monitorera resurser som inte har med containrar att göra.

Genom att injektera mjukvara (scripts) in i containrarna så kan SMF konfigureras upp och fånga i princip vilken data och information som helst. Det är också möjligt att konfigurera larm på vilket sätt man kan tänka sig. Problemet med detta är den höga komplexiteten. Verktyget använder sig av ett antal olika mjukvaror för att klara sin uppgift och kräver därmed kunskap om samtliga, bland annat Redis och uchiwa.

6. Gratis

Verktyget har i princip inga begränsningar men kommer till kostnad av en väldigt hög komplexitet. För att ett företag ska implementera SMF så behövs

systemadministratörer och IT-personal med hög kompetens inom de olika verktyg som SMF använder sig utav. Söker man någonting enkelt bör man däremot använda sig av andra verktyg. Prometheus Till skillnad från resterande

verktyg så är Prometheus en uppsättning av flera verktyg snarare en ett samlat. Tillsammans så förser de användaren och systemet med information, sammanställning utav den, visualisering samt ett varningssystem. Den stora skillnaden ligger dock i sättet som Prometheus samlar in data. De andra verktygen är så kallade “push-baserade”, det vill säga att de består av “agenter” på de monitorerade servrarna som pratar med en

central enhet. Prometheus är “pull-baserad” vilket betyder att verktyget förväntar sig att de monitorerade servrarna har någon form av gränssnitt som det kan dra information ifrån. Det finns en stor mängd av så kallade “exporters” tillgängliga med syfte att göra information tillgängliga för Prometheus ur olika kontexter. En sådan kontext kan vara en applikation, en databas, hårdvara som diskar eller vad som helst som

producerar någon form av data. Detta gör Prometheus till ett mycket mångsidigt verktyg som kan övervaka i princip allting.

komponenter

integrerar direkt med Prometheus, vilket ökar komplexiteten och kan dessutom vara direkt omöjligt att hantera i vissa kontexter.

Sysdig Cloud Sysdig Cloud är en service som det går att ansluta sig till som förser användaren med

information, sammanställning av information, visualisering och har möjlighet att varna. För att använda verktyget behöver Sysdig installera vissa

definitioner för att kompilera kod, s.k. “Kernel Headers” på värdmaskinen. Det här går emot filosofin med containerteknik där meningen är att ha

möjlighet att köra containrar oavsett miljö men är ändå en relativt liten avvikelse då det inte handlar om beroende till

Tabell 4.2 - Sju rekommenderade verktyg för monitorering av containrar samt beskrivning och betyg av dem.

Gartner skriver om att användaren bör fokusera på att monitorera containrar på en servicenivå, det vill säga att fokuset bör ligga på att monitorera och övervaka applikationer snarare än de fysiska eller virtuella värdmaskiner som dessa applikationer ligger på. Detta är något som är värt att ha i åtanke vid val av monitoreringsmjukvara då det är att föredra en så djup nivå av monitorering som möjligt.

4.7

Containers livscykel

Gartner skriver att potentialen för “sprawl”, det vill säga fenomenet som uppstår när det är väldigt lätt att starta upp en ny container vilket gör att antalet växer och blir mer och mer svårkontrollerat, är ännu högre än vad den är inom klassiska virtuella maskiner [10]. Detta är på grund av containrars oföränderliga natur där för varje förändring som görs så måste en ny image och en ny container skapas [22].

Ett stort misstag som företag gör när de adapterar containerteknologi till sin infrastruktur är att de hanterar containrar på samma sätt som de skulle hanterat virtuella maskiner [21] eller en applikations arbetsbörda (workload).

För att råda bot på dessa problem så behövs någon form av Continuous Delivery-lösning med till exempel pipelines. Genom att

automatisera konfigurationen och byggandet av images så hålls “sprawlen” till ett minimum. För att åstadkomma detta så behöver man ha kunskap och uppfattning om de olika faserna i en containers livslängd. Vice President på IBM “Cloud Platform”-avdelning Jason McGee skriver om dessa faser i en artikel [23]. Det är dessa steg som utvecklare på IBM följer.

1. Acquire - Anskaffningsfasen

En av de största fördelarna med Docker och containrar i allmänhet är deras förmåga att byggas i lager. Oftast bygger man inte en container från grunden utan man använder någon form av basimage. Imagen som byggs av denna kan sedan användas som basimage till en annan. Genom att identifiera vilket innehåll man vill ha i sin container med den här kapabiliteten i åtanke så kan

livslängden på varje container förlängas och därmed så hålls även container sprawl till ett minimum.

2. Build - Byggfasen

Efter den första fasen kommer byggfasen. I den här fasen bör utvecklaren fråga sig själv hur innehållet som identifierats i den första fasen ska utvecklas till en applikation och hur den ska byggas i en pipeline. I den här fasen är containern färdigbyggd och bör nu testas. Blir några säkerhetshål eller sårbarheter exponerade så bör livscykeln avbrytas och faskedjan bör startas om.

3. Deliver - Leveransfasen

I leveransfasen så levereras containern till systemen där applikationen driftsätts i produktion. Ytterligare tester såsom integrationstester sker i den här fasen.

4. Deploy - Distribueringsfasen

I den fjärde fasen distribueras och driftsätts containern i en skarp miljö. I en continuous delivery-miljö så bör här containern “canary”-testas, det vill säga att det bör vara fastslaget att containern och applikationen beter sig som förväntat innan all trafik delegeras från den gamla containern till den nya.

5. Run - Exekveringsfasen

I den här fasen så är applikationen och containern driftsatta och är redo att användas. Inför fasen så bör det vara bestämt vad som händer om något fel inträffar, det vill säga att en plan bör vara fastställd som behandlar hur man rullar tillbaka en applikation till dess föregående version. Även

tillvägagångssättet som beskriver hur applikationen ska sammankoppla med sina beroenden måste vara definierat och klart. Om nödvändigt så ska även skalningsmöjligheter vara fastställda.

6. Maintain - Underhållsfasen

Genom en gedigen kunskap om containerns livslängd, om dess natur och genom en vetskap om när faser bör inledas och avslutas så kan de vanligaste problemen kring continuous integration och containrar undvikas.

4.8

Container Orchestration

Gartner beskriver att nyckelfunktionaliteten kring en miljö baserad på containrar ligger hos orkestreringen utav dem [10]. Det är på detta lager som containrar hålls i ett önskvärt läge och därmed uppehåller olika service-level agreements (SLA). Det är också på detta lager som ett gränssnitt mellan utvecklare och applikation erhålls.

Kubernetes är den plattform som har blivit de facto standard inom industrin för denna uppgift. Plattformen har industriella ledare som kunder och ett livfullt community. Problemet som uppstår när man vill adaptera Kubernetes är när man ska välja konsumtionsmodell för den. Det är viktigt att försiktigt utvärdera fördelar gentemot nackdelar mellan olika lösningar som till exempel CaaS (Container-as-a-Service) eller PaaS (Platform-as-a-Service). CaaS innebär en molntjänst som tillåter användaren att ladda upp, organisera, starta, stoppa och skala upp/ner containrar med ett användarvänligt gränssnitt [36]. I en Kubernetes-kontext innebär en stor abstraktion av komplexiteten med att installera och hantera klustret själv när man väljer en sådan modell. En PaaS är en hel miljö i molnet där man utvecklar och distribuerar allt själv. Man köper således bara resurser från PaaS-leverantören [37].

Beroende på kompetens och kunskap så bör man välja vilken nivå man vill lägga sig på och hur mycket komplexitet som man vill abstrahera bort. Oavsett vilket tillvägagångssätt som man väljer så finns det ett antal verktyg som man bör bekanta sig med som syftar till att förenklar installationsprocessen. Är meningen att installera Kubernetes på bare-metal servrar så finns verktyget KRIB (Kubernetes Rebar Integrated Bootstrap) [24]. Väljer man att installera Kubernetes i molnet så finns där Kubespray [25] eller kops [26] som är särskilt avsett för AWS (Amazon Web Services).

5

Beslutsträd

Kapitlet beskriver och motiverar de beslutsträd som arbetet har kommit fram till genom ett samarbete med NTM. Vi inleder med att beskriva den här implementationen av beslutsträden. Därefter presenteras ett exempel på hur träden bör kan användas i ett verkligt scenario.

Kapitlet implementerar beslutsträden som beskrivs i kapitel 4.2. Beslutsträden illustreras grafiskt med ljusblåa rektanglar som “rot”, dvs målet eller syftet. Grenarna illustreras som “gafflar” och fortsätter till ytterligare alternativ som raka linjer. “Löven” (alternativen) består av rundade rektanglar. Det löv som fastställs markeras genom att det färgläggs grönt. Eventuella alternativ som finns för att implementera lövet

representeras av ovaler. På samma sätt som löven så dras det linjer till dessa samt att de implementationsalternativ som beslutats markeras som gröna. Genom att väga för- och nackdelar gentemot varandra för varje löv så kommer en väg att stakas ut och ett beslut som oftast är sammansatt, blir därmed betydligt lättare att ta.

5.1

Beslutsträd

Modellen består av fyra stycken beslutsträd. Dessa träd kommer först att presenteras i ett grundutförande. Ett praktiskt exempel kommer senare att visa hur träden kan manipuleras och expanderas utefter en organisations egna krav och behov. Eftersom två av träden har samma rubrik som komponenter i Gartners modell och uteslutande handlar om dessa, så kommer var och en utav dem bara att diskutera säkerhet och monitorering utifrån trädets kontext. Vidare kommer det beslut som har tagits i fallet NTM att presenteras och motiveras.

5.1.1 Infrastuktur

Det första valet företaget behöver göra är att välja plats för sin infrastruktur. Det här valet görs oftast baserat på företags redan existerande resurser. Har man redan hårdvaran som krävs för en On Premise-lösning så finns det förmodligen högre benägenhet att fortsätta med det. Ett startupföretag föredrar snarare en prenumerationsmodell i molnet för att slippa de höga initiala kostnaderna. Det finns en mängd alternativ när det kommer till molnleverantör. Några som är populära är Amazon Web Services (AWS), Google Cloud och Microsoft Azure. AWS har ett stort fokus på publika moln och passar bäst för den som vill ha all sin infrastruktur i molnet. Microsoft Azure är snarare för den kund som redan har befintlig infrastruktur och vill integrera den med molnet, ett så kallat “hybridmoln”. Google är en

uppstickare bland dessa tre då de kom in på marknaden senare. Värdet i Googles tjäns är deras innovativa lösningar med bland annat artificiell intelligens och maskininlärning [38].

Fördelar med en on premise-lösning angående säkerhet och

monitorering är den kontroll som finns. Företaget får friheten att välja själv mellan de verktyg och lösningar som finns tillgängliga. Vid användning av en molnleverantörs lösning så får man helt enkelt acceptera och använda de som finns tillgängliga. Fördelen med det är dock att de oftast är lättare att

integrera och att de är väl beprövade verktyg.

En nackdel med att välja en on premise-lösning är att säkerheten och nivån av monitorering bara är så robust som den ansvariga personalens kompetens. Genom att välja en molnlösning så innebär det också att för över ansvaret på säkerhet till molnleverantören i fråga, någonting som kan öka tillförlitligheten till sitt systems robusthet. Notera att de tre molnleverantörer i figur 5.2 inte är de enda som finns, utan de är de tre största aktörerna på marknaden för närvarande [30]. Då NTM redan nu driftsätter sina

Figur 5.2 - Beslutsträd för val av drift för applikation(er)

5.1.2 Tillvägagångssätt för drift

Det andra valet som ett företag behöver göra är vilken typ av hårdvara som deras applikationer ska driftas på. Det mest klassiska exemplet är att driftsätta applikationer på så kallade “bare-metal servers”. Detta innebär att man

form av kritisk data som till exempelvis databaser så gör man bäst i att använda sig av en virtuell maskin. Den främsta anledningen till detta är att tekniken fortfarande är relativt ung och har skapat problem med förluster av värdefull data förr. Detta kan, och kommer förhoppningsvis, komma att ändras i framtiden då tekniken har mognat ytterligare.

När det kommer till säkerhet och monitorering så råder det olika meningar om det. Marvin Waschke, en skribent för InfoWorld, hävdar i en artikel [32] att virtuella maskiner är säkrare eftersom de går ett extra steg angående isolering. Virtuella maskiner separerar sig från den fysiska

maskinen hela vägen ner till hårdvaran medans containrar delar på hårdvara på samma värdmaskin, vilket i teorin äventyrar den.

Angående monitorering så är det ingen skillnad i den data som är möjlig att samla in, även fast uppsamlingen av den kan ske på lite annorlunda sätt i containrar gentemot virtuella maskiner.

I den tidigare nämnda rapporten “Virtualization vs Containerization to support PaaS” [34] så stärker författarna påståendet om isolering, vilket är någonting som NTM och många andra företag är måna om när det kommer till just databaser som kan innehålla känslig information.

Just på grund av dessa anledningar, samt Simon Vestmans rekommendationer i hans arbete [5], så har NTM valt att försätta sina applikationer och sina APIer i containrar men att behålla sin nuvarande databaslösning direkt på virtuella maskiner.

5.1.3 Container Orchestration

När ett företag väl har valt att adaptera och använda containrar så behöver de besluta hur de ska gå tillväga för hanteringen och skalningen av dessa

containrar. Väljer man att sätta sin infrastruktur i molnet så använder man förmodligen också deras integrerade alternativ för Container Orchestration så det här beslutsträdet blir oftast endast relevant om man väljer en on

premise-lösning. Här finns det i regel två val som är relevanta, även fast de i praktiken kan korsas och användas parallellt med varandra. Det första alternativet är att själv installera ett Container Orchestration-verktyg. Nackdelen med detta är komplexiteten och kompetensen som behövs. Fördelen är att det är väldigt billigt eller till och med gratis om rätt verktyg väljs då många verktyg är open source.

Det andra alternativet är att istället använda sig av en kommersiell plattform som abstraherar bort installationen av verktyg för användaren. Några exempel på dessa plattformar finns i figur 5.4 (VMWare Tanzu, RedHat Openshift och Rancher) men det finns ett stort antal andra aktörer på marknaden. Fördelarna med detta blir det betydligt mindre komplexa

gränssnitt som medföljer. Uppstartssträckan för att komma igång med containrar blir mycket mindre då ansvarig personal inte behöver lära sig om verktyg som Kubernetes och dylikt. En annan fördel är också att säkerhet och monitorering är polerat vid val av en bra plattform vilket minskar oron för detta vid en migration till containrar. Nackdelen är allt som oftast priset. Dessa plattformar kan vara mycket dyra. Det torde dock vara värt priset om kompetensen inte redan finns.

NTM har valt att först införskaffa sig kompetens och experimentera med ett kluster som är konfigurerat på egen hand för att sedan revidera möjligheterna hos en plattform. Motivationen är att det finns en risk att det behövs en eller flera heltidstjänster med det enda syftet att se efter

Figur 5.4 - Beslutsträd för val av livscykelhantering

5.1.4 Livscykelhantering

Det sista beslutsträdet är egentligen inte nödvändigt för att migrera en drift av applikationer till containrar, men komponenterna i det är så pass vanliga och förtjänar därför att vara med i det här kapitlet.

Ur ett säkerhetsperspektiv så är det viktigt att i sina pipelines hantera vem som får göra vad. I Microsofts Azure är det möjligt att gruppera

användare i olika säkerhetsgrupper. Det är därefter möjligt att bevilja eller avslå vad de olika grupperna får göra [33].

Genom att använda sig av olika notifieringssystem som de flesta CI-verktyg erbjuder så ökar kontrollen över containerns livslängd.

Administratören kan få notifieringar via SMS eller mail om i princip vilken data som helst och på så sätt hålla systemet och byggservrarna i ett optimalt tillstånd.

5.2

Scenario - Startup

5.2.1 ExCom42s affärsområde och nuvarande infrastruktur

Figur 5.5 - ExCom42s nuvarande infrastruktur

ExCom42s applikationer behandlar privatpersoners ekonomi och låter

större kontroll och en mer automatisk process vid driftsättning av applikationerna och har därför kollat på Docker och Kubernetes som en lösning på deras problem. Då de inte har någon tidigare erfarenhet av sådana lösningar så anser de att de måste etablera en robust strategi innan en

migration av det här slaget kan genomföras. Genom att använda sig av det här arbetets beslutträd som grund så förenklas och förtydligas uppgiften. Träden expanderas med företagets specifika problem som grund.

5.2.3 ExCom42s krav på sitt system

För att ha en grund att gå på så kommer företaget fram till ett antal krav som de har för att hjälpa dem att ta beslut. Kraven visas i tabell 5.1. När kraven är klarlagda så är företaget redo att börja använda sig av beslutsträden för att förenkla sin strategi.

Krav Beskrivning

1

Systemet ska vara “on prem”.

Systemet ska vara helt och hållet i våra egna system, dvs att

molntjänster inte är ett gott alternativ. Möjligtvis så kan vi överväga att ha mindre tjänster i molnet men ingen data av våra användare får lämna våran egen miljö.

2

Systemet ska hålla en hög standard för säkerhet.

På grund av våran datas känsliga natur så ska åtgärder tagas för att hålla den säker. Våra kunders information är det viktigaste vi har, så det får prioriteras framför

exempelvis kostnader. 3

Systemet ska vara användarvänligt för vår IT-personal och utvecklare

Då vi har begränsad erfarenhet av den här typen av system så ser vi gärna att inlärningskurvan är så liten som möjligt för att kunna utföra lättare administrationsuppgifter.

Tabell 5.1 - Företagets krav på systemet

5.2.3 ExCom42s applicering av beslutsträden

Det första trädet utgår från beslutet av infrastrukturens lokalisering. Då företaget redan har en robust serverhall så bestämmer de sig för att förvalta sin egen infrastruktur och väljer därför alternativet “On Premise”. Dessutom har de ett högt säkerhetskrav och vill i den mån möjligt slippa externa tjänster som till exempelvis molntjänster.

Figur 5.5 - Företagets expansion av beslutsträd för infrastrukturens placering Figur 5.5 visar hur företaget har tagit det första beslutträdet och expanderat och använt det utifrån sina egna preferenser och behov. Efter beslutet att använda sig av den infrastrukturen de redan har så valde de att använda sig av virtuella maskiner att ha sin containermiljö på i och med deras redan

befintliga vana med denna teknik. Istället för att hantera var och en av dessa Systemet ska integrera med vårt

befintliga arbetssätt.

verktyg i vår dagliga arbete. Ett exempel är GitLab för

versionshantering av vår kod. Vi ser gärna att detta utnyttjas så mycket som möjligt i integrationen med kluster.

5

Systemet ska vara robust.

maskiner själva så valde de att använda sig av en plattform som gör den här uppgiften lättare. De kollade på olika alternativ och kom fram till att de mest intressanta är Citrix eller VSphere. Valet föll till slut på VSphere efter interna diskussioner där de kom fram till att det verktyget passar deras budget och miljö bäst.

Figur 5.6 - Företagets expansion av beslutsträd för tillvägagångssätt för drift

Träd nummer två innefattar beslutet om vilket sätt de ska drifta samtliga av företagets applikationer. Figur 5.6 visar hur företaget använder sig av en blandning av trädets olika grenar. Då de inte har en gedigen vana med teknik som innefattar containrar och därmed inte ett fullt förtroende för dess

stabilitet så väljer de att behålla deras nuvarande lösning för databasdrift, nämligen “Bare Metal” dvs fysiska maskiner. I deras fall är det

Figur 5.7 - Företagets expansion av beslutsträd som angår “Container Orchestration”

Det tredje trädet innefattar de beslut som behöver tas angående hur Container Orchestration ska hanteras. De väljer här att markera grenarna med etiketter utifrån deras egen uppfattning från litteraturstudien i syfte att hjälpa dem ytterligare att ta ett beslut. Då de som bekant inte har någon tidigare

erfarenhet av dessa system så väljer de det alternativ där de köper in en tjänst från en annan aktör som gör konfigureringen lättare. De inser också att de behöver välja mellan att ha en “mästarnod” gentemot flera. Fördelarna med att ha flera är att klustret blir mer robust och motståndskraftig då klustret står och faller med kontrollplanet, dvs “mästarnod(erna)”. Nackdelen är

Figur 5.8 - Företagets expansion av beslutsträd som angår en containers livslängd

Till slut så beslutar sig företaget på deras lösning på hantering av containrars livslängd. De två första löven behöver nödvändigtvis inte vara exklusiva gentemot varandra utan kan med fördel kombineras, vilket inte är ovanligt. På grund av omfattningen på förändringar som Infrastructure as Code skulle innebära så väljer dock företaget att inte implementera något sådant i ett initialt skede. Då de redan versionshanterar med GitLab så väljer de att också implementera en pipeline i deras system. Valet som återstår med det här trädet är “Image Repository” dvs där lagringen av containrar sker. Även här har GitLab en lösning för ändamålet men på grund av de stora

säkerhetskraven så väljer ExCom42 att hantera lagringen själva. I regel finns egentligen bara två lösningar som passar företaget, nämligen Dockers egna sätt Docker Registry, vilket är en applikation som utvecklats av Docker själva och som är mycket anpassningsbar men kräver en hel del arbete för att

skräddarsy den till sina egna behov. Harbor däremot är en open

source-applikation som är mer robust direkt efter installation. Applikationen stödjer ett gediget webbläsargränssnitt och rollbaserad behörighet [41]. På grund av den medgörliga inlärningskurvan så väljer ExCom42 att

Figur 5.9 - Företagets preliminära skiss på en slutgiltig infrastruktur När ExCom42 har klarlagt beslutsträden så ritar de upp en skiss för hur en slutgiltig infrastruktur skulle kunna se ut (visas i figur 5.9). De fundamentala grunderna för deras strategi är nu klarlagda och det blir lättare att utforma detaljerna kring arbetet för migrationen.