i

Avkastningsportal i skyen

Bachelorprosjekt ved Institutt for informasjonsteknologi

OsloMet - Storbyuniversitetet

Bachelor i Anvendt datateknologi

Våren 2018

Alexander Kingdon Pål Andreassen Frode Mathiassen Thien Minh Truong

s175295 s305514 s305449 s161922

ii

Studieprogram: Informasjonsteknologi

Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo

Besøksadresse: Holbergs plass, Oslo

Telefon: 22 45 32 00

Telefaks: 22 45 32 05

PROSJEKT NR. 27

TILGJENGELIGHET

BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL

Avkastningsportal i skyen

DATO

22.05.2018

ANTALL SIDER / BILAG

136 med fire vedlegg

PROSJEKTDELTAKERE

Pål Andreassen, s305514 (ANVDATA)

Alexander Kingdon, s175295 (ANVDATA)

Frode Kristian Mathiassen, s305449 (ANVDATA)

Thien Minh Truong, s161922 (ANVDATA)

INTERN VEILEDER

Kirsten Ribu og Andreas Jacobsen

OPPDRAGSGIVER

Kantega AS

KONTAKTPERSON

Hans Ove Ringstad

SAMMENDRAG

Oppgaven gikk ut på å modernisere infrastrukturen til en eksisterende webapplikasjon.

Applikasjonen er utviklet av oppdragsgiver Kantega AS. De ønsket å redusere kostnader

relatert til hosting, drift og vedlikehold ved å tilrettelegge flytting av applikasjonen fra en

virtuell server til en skytjeneste. Vi har løst denne problemstillingen og presentert et

forslag om hvordan dette kan gjennomføres på en moderne og effektiv måte. Dette har

prosjektgruppen fått til med konteinerteknologi og ved å lage et system for kontinuerlig

integrasjon og leveranse av konteinere som effektiviserer utvikling, drift og vedlikehold.

3 STIKKORD

Skytjenester

Konteinerteknologi Kontinuerlig integrasjon og

levering

iii

Forord

Denne rapporten beskriver bachelorprosjektet til gruppe 27 ved Institutt for

informasjonsteknologi, OsloMet - storbyuniversitetet våren 2018. Den dokumenterer

arbeidsprosessen, resultatet, evalueringer og læringsutbyttet prosjektgruppen har kommet

frem til. Oppgaven har gått ut på å tilrettelegge for flytting av en eksisterende applikasjon

over til en skytjeneste.

Arbeidet med bachelorprosjektet har hovedsakelig foregått i perioden fra januar til mai

2018, og har vært en spennende og krevende prosess. Oppgaven ble tildelt av Kantega AS

som gruppen kom i kontakt med ved at et av prosjektlemmene hadde deltidsstilling der.

Vi ønsker å rette en takk til Kantega AS ved avdelingsleder Hans Ove Ringstad og våre

kontaktpersoner Hallbjørn Storruste, Geir Helland og Yngve Skaalerud. Til slutt ønsker vi å

takke våre forelesere ved OsloMet og våre veiledere Kirsten Ribu og Andreas Jacobsen.

iv

Innholdsfortegnelse

1 Innledning ........................................................................................................................... 1

1.1 Bachelorgruppen ......................................................................................................... 1

1.2 Oppdragsgiver.............................................................................................................. 1

1.3 Oppdragsgivers kunde ................................................................................................. 2

1.4 Bakgrunn for prosjektet ............................................................................................... 2

1.5 Generelt om Avkastningsportal ................................................................................... 3

1.6 Tabelloversikt over Avkastningsportals teknologier ................................................... 6

1.7 Mål og strategi ............................................................................................................. 7

1.8 Teknologier i prosjektet ............................................................................................... 8

1.9 Faglig innhold ............................................................................................................. 12

2 Kravspesifikasjon ............................................................................................................... 13

2.1 Hensikt ....................................................................................................................... 13

2.2 Endringer i krav .......................................................................................................... 13

2.3 Funksjonelle krav ....................................................................................................... 14

2.4 Ikke-funksjonelle krav ................................................................................................ 14

2.5 Spesifisering av rammekrav ....................................................................................... 15

2.6 Hosting ....................................................................................................................... 15

2.7 Levetid ....................................................................................................................... 16

3 Prosessdokumentasjon ..................................................................................................... 17

3.1 Arbeidsmetode .......................................................................................................... 17

3.2 Utfordringer med arbeidsmetode ............................................................................. 19

3.3 Planlegging og arbeidsfordeling ................................................................................ 20

3.4 Utviklingsprosessen ................................................................................................... 21

3.5 Virtuelt utviklingsmiljø ............................................................................................... 23

4 Teknologier og vurderinger............................................................................................... 25

v

4.1 DevOps ....................................................................................................................... 25

4.2 Tradisjonell VM-arkitektur og konteinerarkitektur ................................................... 28

4.3 Skytjenester ............................................................................................................... 38

4.4 Vurdering av skytjenesteleverandører ...................................................................... 43

4.5 Diskusjon og valg av skytjeneste ............................................................................... 45

4.6 Databaseløsning ........................................................................................................ 46

4.7 Kontinuerlig integrasjon og leveranse ....................................................................... 46

4.8 Andre hensyn ............................................................................................................. 51

4.9 Oppsummering .......................................................................................................... 52

5 Systemdokumentasjon ..................................................................................................... 53

5.1 Oppsett for testing og utvikling ................................................................................. 55

5.2 Oppsett av utvikling og preprod-miljø ...................................................................... 56

5.3 Oppsett av Avkastningsportal i Rancher ................................................................... 57

5.4 Domenenavn til VM ................................................................................................... 70

5.5 Oppsett av egen Rancher Catalog ............................................................................. 72

5.6 Oppsett av produksjonsmiljø – Amazon AWS ........................................................... 73

5.7 CI/CD-pipeline prosessbeskrivelse ............................................................................ 76

5.8 Testing ....................................................................................................................... 80

5.9 Adresser til løsningene .............................................................................................. 81

6 Evaluering .......................................................................................................................... 83

6.1 Evaluering av planlegging .......................................................................................... 83

6.2 Evaluering av metodikk og arbeidsmetode ............................................................... 83

6.3 Evaluering av prosjektgruppen .................................................................................. 84

6.4 Evaluering av løsningen ............................................................................................. 85

6.5 Forbedring og videreutvikling .................................................................................... 87

7 Konklusjon ......................................................................................................................... 89

vi

7.1 Læringsutbytte ........................................................................................................... 89

7.2 Konklusjon ................................................................................................................. 89

8 Teknisk ordliste ................................................................................................................. 91

9 Referanser ......................................................................................................................... 94

10 Vedlegg 1 - Konfigurasjonsoppsett ............................................................................... 98

10.1 Versjoner brukt i prosjektet ................................................................................... 98

10.2 Oppsett................................................................................................................... 98

11 Vedlegg 2 - Brukerveiledning til oppdragsgiver .......................................................... 124

12 Vedlegg 3 – Testrapport .............................................................................................. 126

12.1 Sammendrag ........................................................................................................ 126

12.2 Avvik i forhold til testplan .................................................................................... 126

12.3 Testens grundighet .............................................................................................. 126

12.4 Avvik i produktet .................................................................................................. 127

12.5 Testplan ................................................................................................................ 127

13 Vedlegg 4 - Oppdragsgivers tilbakemelding ................................................................ 136

1

1 Innledning

1.1 Bachelorgruppen

Bachelorgruppen består av Alexander Kingdon, Pål Andreassen, Thien Minh Truong og Frode

Kristian Mathiassen, som alle studerer siste semester på Anvendt datateknologi ved OsloMet

- Storbyuniversitetet.

Bachelorgruppen har ikke tidligere jobbet sammen som en enhet, og det er først i

forbindelse med bachelorprosjektet at det ble inngått et samarbeid. Alexander er

deltidsansatt hos oppdragsgiver og fikk tildelt prosjektet sammen med Pål mot slutten av

høsten 2017. En utlysning etter flere prosjektdeltakere førte til et samarbeid med Frode og

Thien, og sammen utgjør vi fire prosjektgruppen.

Alexander Kingdon Pål Andreassen Thien Minh Truong Frode Mathiassen

1.2 Oppdragsgiver

Kantega er et ansatteid IT-konsulentselskap i Oslo sentrum, som lager innovative IT-

løsninger, og spesialiserer seg på sikre portaler basert på tjenesteorientert arkitektur.

Bedriften ble stiftet i 2003 og har rundt 120 medarbeidere. I 2016 hadde de driftsinntekter

på nesten 150 millioner kroner. Kantega driver virksomhet i hele Skandinavia, og har

kontorer både i Oslo og Trondheim (Kantega, udatert).

2

Kontaktpersoner og veiledere for bachelorprosjektet er Hans Ove Ringstad (avdelingsleder),

Hallbjørn Storruste (utvikler), Geir Helland (DevOps-konsulent) og Yngve Skaalerud (utvikler).

Figur 1-1 - Kantega AS – logo

1.3 Oppdragsgivers kunde

Norsk Pensjon ble stiftet høsten 2006 av syv livsforsikringsselskaper. I samarbeid med Nav

har de som formål å sammenstille informasjon fra private og offentlige

tjenestepensjonsordninger og sammenlignbare data fra individuelle pensjons- og

spareordninger. Bedriften hadde i 2016 driftsinntekter på nesten 9,5 millioner kroner og har

Storebrand og DNB Livsforsikring som sine største aksjonærer (Norsk Pensjon, udatert).

Figur 1-2 - Norsk Pensjon – logo

1.4 Bakgrunn for prosjektet

Avkastningsportal er en webapplikasjon som tilhører Norsk Pensjon og er utviklet av

prosjektgruppens oppdragsgiver Kantega. Oppgaven med å fornye infrastrukturen og

tilrettelegge for å flytte applikasjonen til en skytjeneste er noe oppdragsgiver har

nedprioritert til fordel for andre essensielle tjenester hos Norsk Pensjon, men var allikevel

ønsket gjennomført.

I dag hostes webapplikasjonen på en virtuell server hos driftsleverandøren Basefarm hvor

oppdragsgiver har flere av sine applikasjoner plassert. På sikt er det ønskelig for

oppdragsgiver å flytte flere av sine tjenester over til skytjenester. Det ble derfor avtalt at

prosjektgruppen skulle utføre denne jobben med Avkastningsportal som et pilotprosjekt.

3

Resultatet vil derfor være et verdifullt vurderingsgrunnlag for oppdragsgiver ved eventuell

migrering av Avkastningsportal, og flere av Norsk Pensjon sine nettjenester, til skyen.

1.5 Generelt om Avkastningsportal

Avkastningsportal er en tjeneste hvor bedrifter kan sende inn data for å se og sammenligne

historisk avkastning på forskjellige pensjonsordninger ut fra kunders porteføljer.

Pensjonsdata innleveres i form av Excel- og XML-filer via en SOAP-tjeneste, som etter

beregninger presenteres i brukergrensesnittet. Beregningene utføres basert på data som

innhentes fra Oslo Børs med FTP og en offentlig webtjeneste for valutakurser.

Applikasjonen finnes på følgende adresse: https://www.norskpensjon.no/rapportering.

Språk og arkitektur

Applikasjonen er skrevet i Java og benytter Spring Boot som er et rammeverk for web-

baserte Java-applikasjoner. I back-end håndterer MySQL lagring av serialiserte java-objekter.

Avkastningsportal er inndelt i fire moduler som prosjektgruppen har jobbet med.

Figur 1-3 - Diagram med oversikt over Avkastningsportal, utlevert av oppdragsgiver

4

Avkastning WS

• Data leveres via webservice (SOAP). Applikasjonen heter avkastning (avkastning-ws).

• Applikasjonen legger dataene i databasetabellen «mottattdata» som et serialisert

java-objekt.

• Det finnes en testklient i prosjektet: «mottakerTestKlient», som tar en xls-fil som

input og leverer dataene til webtjenesten.

Renteimport

• Java-applikasjon henter data fra Oslo børs via FTP og legger dataene i

databasetabellen.

• Applikasjonen er designet for å kunne importere valutakurser fra Norges bank, men

dette er ikke i bruk hverken i vår versjon eller i nåværende Avkastningsportal.

Beregning

• Når java-applikasjonen «Beregning» kjøres, tar den dataene fra mottattdata,

prosesserer dem med rentene (som er hentet med renteimport) og legger så disse i

databasetabellen «avkastningsdata».

Rapportering

• Henter dataene fra databasetabellen «avkastningsdata» og «organisasjon».

• Består av to ting:

o Web GUI, hvor man kan se avkastningsdataene.

o Webtjeneste (SOAP) for uthenting av avkastningsdata. Dette er en åpen

webtjeneste som brukes av Finansportalen.

Brukergrensesnitt for Avkastningsportal

Brukergrensesnittet til Avkastningsportal tillater brukerne å manipulere visning av tabelldata

med filter for sammenligning av avkastningsdata. Nettsiden er beregnet for sluttbrukere som

har et spesifikt informasjonsbehov og vet hva slags informasjon de er ute etter, såkalt

known-item-seeking (Rosenfeld, Morville & Arango, 2015, s. 45-50 og s. 122).

5

Avkastningsportal er basert på en databaseorientert struktur og er organisert etter

forhåndsdefinerte kategorier som representerer innholdet på siden.

Figur 1-4 - Skjermbilde av brukergrensesnittet til Avkastningsportal

Brukergrensesnittet har to filter:

• Et for filtrering av risikoklasser etter kategorier.

• Et for filtrering av avkastningsperiode etter år.

Ved siden av risikoklasse filteret finnes en “Avansert/Enkel” knapp som endrer risikoklassene

mellom numeriske verdier og Lav, Medium, Høy.

Figur 1-5 - Filter for risikoklasse Lav, Medium og Høy

Figur 1-6 - Filter for risikoklasse 1-10

6

Figur 1-7 - Sammenligning av flere pensjonsordninger

1.6 Tabelloversikt over Avkastningsportals teknologier

Java Java er et klassebasert, objektorientert

programmeringsspråk som Avkastningsportal

er skrevet i

Spring boot Spring boot er et rammeverk for å blant

annet lage web-baserte Java-applikasjoner

Maven Verktøy for å forenkle

byggeprosessen av Java-applikasjoner

7

MySQL Relasjonsdatabase for lagring av data

Jetty HTTP-server for å kjøre web-baserte Java-

applikasjoner

HTML Standard markup-språk for å presentere

websider og webdokumenter

JavaScript Programmeringsspråk som brukes for å lage

interaktive effekter og interaksjon med

grensesnitt på websider

CSS Cascading style sheets er et språk for å lage

presentasjoner og stiler på websider

Figur 1-8 - Tabell med teknologier brukt i Avkastningsportal

1.7 Mål og strategi

Prosjektgruppens målsetting

Vi satt oss som mål å bruke moderne teknologi og effektive metoder for å tilrettelegge

flytting av Avkastningsportal til en skyløsning. For å oppnå dette ville vi bruke

konteinerteknologi, som er fremtidsrettet innen virtualisering i moderne infrastrukturer. Vi

ønsket å automatisere løsningen mest mulig med kontinuerlig integrasjon og levering, med

et endelig mål om at Avkastningsportal skulle kjøre problemfritt i skyen.

8

Prosjektgruppens strategi og motivasjon

Prosjektet har en helning mot DevOps, som handler om effektivisering og automatisering i

bindeleddet mellom utvikling og drift. Prosjektet handler således om å modernisere

applikasjonen og dens infrastruktur for å muliggjøre kontinuerlig integrasjon og levering. Vi

hadde som mål å oppnå dette ved å benytte ulike verktøy og fremtidsrettede teknologier

ved hjelp av smidige metoder for å tilpasse Avkastningsportal for flytting til en skyløsning.

Motivasjonen var å tilegne oss ny kunnskap om et fagfelt vi ikke hadde kjennskap til, noe

som gir verdifull erfaring til arbeidslivet og ytterligere faglig tyngde.

1.8 Teknologier i prosjektet

Under prosjektperioden tok vi i bruk mange nye teknologier og verktøy, i tillegg til noen vi

hadde tidligere erfaring med. Disse er oppsummert i tabellene nedenfor.

Teknologier i løsningen

Ubuntu 16.04 Ubuntu er et open source

operativsystem og Linux-distribusjon.

Docker 17.12 Docker er en plattform for å bygge,

pakke og kjøre distribuerte

applikasjoner.

Alpine 6.0 Alpine Linux er en nedstrippet og

lettvekts Linux-distribusjon.

Rancher 1.6 Plattform for håndtering og utplassering

av konteinere.

9

Drone 0.82 Kontinuerlig leveringsplattform for

automatisk bygging og testing av

applikasjoner.

Janitor 1.7.1 Janitor tar seg av automatisk rydding av

ubrukte images på hostene for å spare

diskplass og holde konteinermiljøet

ryddig.

Digital Ocean DigitalOcean er en skyinfrastruktur-

tilbyder.

Amazon Web

Services EC2

AWS EC2 er en skytjeneste som sørger

for enkel og sikker skalering av

skybaserte infrastrukturer.

Amazon RDS Amazon Relational Database Service er

en AWS-tjeneste for relasjonsdatabaser.

Github og Git Github er et versjonskontrollsystem som

benytter Git-teknologien.

Elasticsearch

(ELK stack)

Elasticsearch er en RESTful søkemotor

som indekserer filer og dokumenter.

10

Logstash

(ELK stack)

Logstash er et verktøy for å samle inn og

strukturere datalogger fra ulike kilder.

Kibana

(ELK stack)

Kibana er et verktøy som fremstiller

visualiseringer av data fra Elasticsearch-

indekser.

Logspout Logspout er et tilleggsverktøy som

henter logger fra kjørende konteinere og

videresender dem til ønsket

destinasjon(Logstash).

Figur 1-9 - Tabell med teknologier brukt i vår løsning av Avkastningsportal

Arbeidsverktøy

IntelliJ IDEA IntelliJ er et Java-integrert utviklingsmiljø

for programvareutvikling.

MySQL

Workbench

Workbench er et verktøy for å designe og

håndtere MySQL-baserte

relasjonsdatabaser.

Figur 1-10 - Tabell med arbeidsverktøy brukt i prosjektet

11

Verktøy for styring og kommunikasjon

Trello Prosjektstyringsverktøy for styring av

oppgaver og gjøremål. Ble brukt som

Kanban tavle.

Slack Skybasert kommunikasjonstjeneste for

samarbeid. En privat kanal ble opprettet

slik at gruppen kunne kommunisere med

oppdragsgiver over nettet.

Facebook

messenger

Messenger er chat-tjenesten til

Facebook. En intern gruppechat ble

opprettet slik at prosjektgruppen kunne

kommunisere over nettet.

Google Drive Drive er system for lagring og

synkronisering av filer. Drive ble benyttet

gjennom hele prosjektperioden for å

holde orden på filer og dokumenter, og

editering av tekstdokumenter i sanntid.

Microsoft

Word

Word er et skriveprogram som inngår i

Microsoft Office-pakken. Ble brukt til å

utforme og skrive alle tekstdokumenter.

Draw.io Draw er et nettbasert verktøy som ble

brukt for å designe og utforme

diagrammer og illustrasjoner.

12

Zotero Zotero er et gratis

kildehåndteringsverktøy som ble brukt

for å holde orden på kildereferanser.

Figur 1-11 - Tabell med verktøy for styring og kommunikasjon brukt i prosjektet

1.9 Faglig innhold

I arbeidet med prosjektet måtte vi sette oss inn i ny teknologi og teori vi ikke var kjent med

fra tidligere. Dette har i hovedsak dreid seg om DevOps, konteineriseringsteknologi og

skytjenester. Kontinuerlig integrasjon og leveranse, samt driftstjenester som logging og

overvåkning er andre temaer vi har jobbet med. Utover dette har vi benyttet teori og

praksis fra fag som systemutvikling, operativsystemer, testing av programvare,

informasjonsarkitektur og universell utforming i prosjektet. Det er i tillegg tatt hensyn til

universell utforming og tilgjengelighet ved at rapporten følger WCAG 2.0-standarden.

13

2 Kravspesifikasjon

2.1 Hensikt

Kravspesifikasjon benyttes under planlegging av prosjekter for å identifisere og beskrive

funksjonelle krav om brukerfunksjonalitet og ikke-funksjonelle krav, som ytelse, robusthet

og sikkerhet. I dette prosjektet har oppdragsgiver stilt svært få spesifikke krav og vi har hatt

høy grad av frihet til å løse oppdraget slik vi selv ønsket.

2.2 Endringer i krav

I utgangspunktet var kravspesifikasjonen kort og kun utviklet av oppdragsgiver. Dette gjaldt

krav om at applikasjonen skal kjøre i skyen, håndtering av innloggingsinformasjon og krav

om oppetid. Vi har tilført nye krav underveis i arbeidsprosessen når ny innsikt avdekket

behov for dette. Tilførte krav har hatt som hensikt å sikre kvalitet i løsningen gjennom

reduksjon i kostnader relatert til drift og hosting av applikasjonen, samt forenkle arbeidsflyt

ved bruk av løsningen. Krav av høy viktighet har blitt prioritert.

På grunn av sikkerhetshensyn bestemte oppdragsgiver at et administrasjonsgrensesnitt,

samt dets funksjonalitet, ikke skulle inngå i vår løsning eller kildekoden vi fikk utlevert. Dette

web-baserte administrasjonsgrensesnittet, hvor Excel- og XML-filer kan lastes opp, brukes i

dag av bedrifter for innlevering av avkastningsdata. Applikasjonen sørger for sikkerhet

gjennom integrasjon med ID-porten via egen kildekode. Også ulike SSL-sertifikater ligger i

kildekoden. Oppdragsgiver mente det kunne bli vanskelig å skulle ta hensyn til sikkerheten

rundt dette og få til integrasjon med ID-porten ved flytting av applikasjonen til skyen.

En mulig løsning på problemet, foreslått av oppdragsgiver, var å implementere en

synkroniseringsfunksjon mellom vår applikasjon i skyen og innrapporterte data på kundens

eksisterende webservere. Denne integrasjonen ble forelagt som en mulig ekstraoppgave

dersom det fantes tid etter at andre oppgaver var løst. Mot slutten av arbeidet med

oppgaven fikk vi vite av oppdragsgiver at det allerede fantes funksjonalitet i kildekoden for å

sette opp en SOAP-basert webtjeneste som avkastningsdata kunne leveres inn mot, ved

hjelp av verktøy som SoapUI. Dette ble vi ikke kjent med før vi var ferdig med den tekniske

delen av oppgaven.

14

2.3 Funksjonelle krav

Det har ikke blitt stilt funksjonelle krav fra oppdragsgiver ettersom koden i systemet ikke skal

endres. Det har derfor ikke blitt foretatt analyse av brukervennlighet eller bruk av systemet

generelt, foruten å kontrollere at manuelle systemtester for brukergrensesnittet bestås.

Prosjektgruppen har derfor satt egne funksjonelle krav som vi mener er hensiktsmessige.

Krav Viktighet

Oppgradering av applikasjonen skal skje automatisk ved oppdatering av

kildekode i versjonshåndteringssystemet

Middels

Nyutviklet kode skal automatisk testes for feil ved integrasjon og levering Middels

Figur 2-1 - Tabell over funksjonelle krav

2.4 Ikke-funksjonelle krav

Oppdragsgiver har ikke stilt ikke-funksjonelle krav utover at applikasjonen skal kjøre på en

skybasert løsning og håndtere “secrets”1. Vi har derfor utviklet egne krav underveis som skal

sikre kvalitet i løsningen og legge til rette for videreutvikling.

Krav Viktighetsgrad

Applikasjonen skal kjøre i skyen Høy

Applikasjonen skal oppføre seg som i eksisterende løsning med samme

funksjonalitet

Høy

Secrets skal håndteres på en sikker måte og ikke lagres i kildekoden. Høy

Applikasjonen skal kjøre i et miljø som håndterer sikkerhet Høy

1 “Secrets” omfatter sensitiv informasjon slik som påloggingsinformasjon, databasetilkoblingsinformasjon, SSL-nøkler og andre former for autorisasjon som av sikkerhetsmessige hensyn ikke skal bli kjent for utenforstående.

15

Applikasjonen skal kjøre stabilt med en høy grad av oppetid Høy

Applikasjonen skal kjøre i et konteinerbasert miljø Lav

Applikasjonen skal kjøre i et miljø med lang levetid Middels

Løsningen skal kunne utvides med ytterligere ny funksjonalitet ved å

konfigurere eller legge til nye komponenter for ytterligere grad av

automasjon i leveranseprosessen.

Middels

Figur 2-2 - Tabell over ikke-funksjonelle krav

2.5 Spesifisering av rammekrav

Rammekrav for systemet er krav som gjelder systemet som helhet. Dette innebærer for

eksempel sikring mot tap, ødeleggelse, tyveri og misbruk av data, kapasitet og fremtidig

utvidelse av systemet.

Sikkerhet

Offentlige webtjenester har alltid risiko for å bli utsatt for DDoS-angrep2. Løsningen må

kunne håndtere disse angrepene med minst mulig nedetid. Databasen må ligge i et sikkert

miljø slik at uvedkommende ikke kan få tilgang. Med dataintegritet menes det at

informasjonen som ligger i portalen er korrekt og ikke kan manipuleres.

2.6 Hosting

I forbindelse med skytjeneste-hosting er det fra oppdragsgivers kun krav om høy grad av

oppetid. Stabilitet forutsetter også at hosten støtter de teknologiene som er blitt brukt. Pris

er av mindre betydning på grunnlag av lite trafikk og beskjeden størrelse på applikasjonen.

2 Et DDoS-angrep er når en webtjeneste med vilje blir overbelastet av en gruppe med angripere ofte bestående av et nettverk av infiserte maskiner, såkalt botnet. Resultatet er at tjenesten går ned og ikke lenger kan nås for vanlig bruk

16

2.7 Levetid

Det er ønskelig at systemet skal ha lengst mulig levetid. Dette innebærer at teknologi som

benyttes i løsningen må opprettholdes av utgiver. Ulike versjoner av programvare kan ha ulik

grad av støtte fra utgiver. Teknologi som ikke lenger støttes gir ikke garantier for at de

fungerer som de skal eller at kompatibilitet mot andre teknologier og programvare er

opprettholdt.

17

3 Prosessdokumentasjon

3.1 Arbeidsmetode

Det er forskjellige måter å praktisere smidig utvikling på. I dette prosjektet har vi benyttet

elementer fra Lean metodikk og smidig utvikling som vi har tilpasset etter våre behov med et

overordnet fokus på å levere verdi til kunden. Lean er en helstøpt filosofi og har sitt utspring

fra Toyota Production Systems allerede på 1940-tallet. Lean handler om å forstå hva som er

av verdi for kunden og maksimere verdi så mye som mulig, samtidig som sløsing av ressurser

minimeres. Det handler om å kontinuerlig forbedre for å standardisere arbeid. Lean er

opprinnelig beregnet for industri- og produktutvikling, men passer også for programvare og

utviklingsprosjekter («Hva er Lean?», udatert).

Smidig arbeidsmetodikk vektlegger samspill mellom mennesker ansikt til ansikt, og ønsker

endringer i krav velkommen, selv sent i utviklingsprosessen. Kundens behov er av høyeste

prioritet. Utviklere jobber i selvstyrte team for å løse problemer mer effektivt. Dette blir

gjort gjennom hyppige iterasjoner med kontinuerlig leveranse hvor målet er å lage

fungerende programvare av fremragende kvalitet (“Manifesto for Agile Software

Development,” udatert). Dette bunner ut i 12 prinsipper som fungerer som veiledning og

manifest for smidig utvikling:

1. Vår høyeste prioritet er å tilfredsstille kunden gjennom kontinuerlige leveranser av

verdifull programvare.

2. Ønsk endringer i krav velkommen, selv sent i utviklingsperioden. Smidige prosesser

gjør endringer til konkurransefortrinn for kunden.

3. Lever fungerende programvare ofte, fra noen uker til noen måneder. Helst på kortest

mulig tid.

4. Forretningsfolk og utviklere må jobbe sammen daglig gjennom hele prosjektet.

5. Bygg prosjekter rundt motiverte individer. Gi dem miljøet og støtten de trenger, og

stol på at de får jobben gjort.

18

6. Den mest effektive metoden for å overføre informasjon i et utviklingsteam er å

snakke ansikt til ansikt.

7. Fungerende programvare er hovedmåleenheten for progresjon.

8. Smidige prosesser fremmer bærekraftig utvikling. Sponsorer, utviklere og brukere bør

holde samme tempo.

9. Kontinuerlig fokus på teknisk overlegenhet og god design forbedrer smidighet

10. Simplisitet, kunsten av å minimere arbeidsmengde er essensielt.

11. De beste krav og løsninger kommer fra selvstyrte team.

12. I regelmessige intervall, reflekter på hvordan bli mer effektiv og juster atferd

deretter.

Vi benyttet Kanban for å styre gjøremål og effektivisere kommunikasjon i prosjektet.

Gjennom visuell håndtering av arbeidsoppgaver, optimaliseres arbeidsflyt og sløsing

reduseres i henhold til Lean metodikken. En Kanban-tavle kan være noe så enkelt som et

whiteboard med post-it lapper, som er inndelt i kolonner bestående av arbeidsoppgaver som

viser hva som skal gjøres og når, hva som er under arbeid og hvilke oppgaver som er utført.

Vi har brukt en digital Kanban-tavle i Trello for holde styring på arbeidsoppgaver. Dette ga

oss enkel tilgang til og administrering av oppgavene.

Kanban er basert på fire prinsipper, som underbygger og støtter Lean-metodikken, og som

ifølge LeanKit (2018) hjelper for å redusere sløsing og maksimere verdi.

• Visualisere arbeidsoppgaver

• Begrense arbeid under arbeid

• Fokus på flyt

• Kontinuerlig forbedring

19

Figur 3-1 - Kanban-tavle (LeanKit, 2018)

3.2 Utfordringer med arbeidsmetode

I starten av arbeidet gikk det mye tid på tilegning av kunnskap, noe som gjorde det vanskelig

å planlegge arbeidet etter en bestemt arbeidsmetodikk. Vi hadde under store deler av

prosjektperioden begrenset oversikt over detaljene, og jobbet derfor med større

overordnede arbeidsoppgaver som vi løste i plenum. Selv om vi ikke har fulgt en agil

arbeidsprosess til punkt og prikke har det likevel vært god arbeidsflyt i prosjektet. Det viste

seg utfordrende å jobbe smidig på grunn av manglende erfaring med prosjektets tematikk. Vi

har likevel tilpasset oss situasjonene som oppsto, og håndtert problemstillinger og

kravendringer underveis.

På grunn av vesentlige endringer i krav og arbeidsoppgaver opplevdes det som ekstraarbeid

uten særlig utbytte å opprettholde definerte oppgaver på kanban-tavlen. Vi kom i stedet

frem til at direkte kommunikasjon innad i gruppen fungerte bedre. Vår erfaring med Trello

tilsier at dette og andre arbeidsstyringsverktøy kommer bedre til sin rett i større prosjekter

hvor koordinasjon og kommunikasjon er en større utfordring.

20

3.3 Planlegging og arbeidsfordeling

Under forprosjektet forsøkte vi å kartlegge hvilke arbeidsoppgaver som måtte løses og i

hvilke faser av arbeidet disse skulle utføres. Vi opprettet faser med milepæler som virket

fornuftige på bakgrunn av forarbeidet vi hadde gjort. Ut i fra dette laget vi en overordnet

fremdriftsplan.

Milepæler i prosjektet

1. Valg av arkitektur og tjenestetilbyder

2. Utvikling av fungerende applikasjon i preproduksjon

3. Migrering og testing av eksisterende løsning over til skyløsning

4. Produksjonssetting av applikasjon

5. Ferdigstille sluttrapport

6. Ferdigstille presentasjon

Figur 3-2 - Fremdriftsplan

I tidlig fase av prosjektet trodde vi at løsningen vår skulle tjene reelle brukere av

Avkastningsportal. Vi så derfor for oss en ekstensiv testfase vedrørende tilgjengelighet,

sikkerhet og arbeidsmengde hos tjener. I møte med oppdragsgiver ble det imidlertid avklart

at dette ikke var tilfelle. Testingen i dette prosjektet har i stedet hovedsakelig bestått av

regresjonstesting. Testfasen i fremdriftsplanen fremkommer derfor som mer omfattende

enn den i praksis har vært.

21

Oppdragsgiver anbefalte oss tidlig å løse oppgavene mest mulig i plenum for best mulig

læringsutbytte. God dialog med oppdragsgiver gjorde at vi kunne diskutere og resonnere oss

frem til mulige løsninger, og gjorde det enklere å se helhetlig hvordan problemstillingene

kunne løses. Etterhvert som tekniske oppgaver ble tydeligere definert, delte vi

arbeidsoppgaver som rapportskriving og utvidelser i løsningen som ble løst individuelt.

Det har ikke vært anledning til å arbeide hos oppdragsgiver, med unntak av møter som ble

avholdt hos Kantega. Prosjektgruppen har derfor møttes på universitetet to til tre ganger i

uken gjennom mesteparten av arbeidsprosessen. I tillegg til felles arbeidsøkter har vi jobbet

individuelt. Det individuelle arbeidet har i stor grad bestått av informasjonssøk og forskning

rundt temaer og teknologier som var relevante for vårt arbeid. Resultater av teknisk arbeid

og forskning ble dokumentert underveis. Arbeidet med sluttrapporten ble gjennomført i den

avsluttende fasen av prosjektet, hvor vi møttes oftere for å unngå tidspress under

ferdigstilling av oppgaven.

3.4 Utviklingsprosessen

Før oppdraget var ferdig utformet og kontrakten ble inngått med oppdragsgiver, var det

aktuelt at modernisering av applikasjonen skulle inngå i oppgaven. Dette gjaldt migrasjon av

løsningen over til Java 8 og implementasjon av ny funksjonalitet som lambda-funksjoner og

metodereferanser. Dette er beskrevet i prosjektskissen og forprosjektrapporten som en

mulig oppgave. Denne oppgaven ble imidlertid utført av oppdragsgiver før arbeidet med

prosjektet begynte og har derfor ikke vært aktuelt å jobbe med for prosjektgruppen.

Under det første møtet med oppdragsgiver ble et overblikk av webapplikasjonen og

systemet presentert for oss. På dette tidspunktet var det fremdeles uklart om modernisering

av applikasjonens kildekode skulle være en del av oppgaven. I første omgang fikk vi vite at

brukergrensesnittet ikke skulle oppgraderes. Grunnen til dette var at grensesnittet allerede

var enkelt å bruke, og at brukerne var fornøyde med grensesnittet slik det er i dag. Vi fikk

tidlig vite at det kunne være sikkerhetsmessige utfordringer rundt bruken av ID-porten og

innlogging på websiden for administrasjonsmodulen. Dette viste seg senere å være tilfelle

etter opplysning fra oppdragsgiver, og ble dermed fjernet fra oppdragsbeskrivelsen. Frem til

22

oppdraget var ferdig spesifisert av oppdragsgiver brukte vi tiden på å sette oss inn i

teknologier og verktøy vi ville vurdere å ta i bruk for å løse oppgaven. Skytjenester var et

tema vi måtte sette oss grundig inn i. Her møtte vi store mengder med informasjon. Vi

hadde foreløpig ikke fastsatt rammer for våre krav og behov til skyløsningen vi skulle bruke,

og hadde heller ikke spesifikasjoner fra oppdragsgiver. Denne vurderingen skulle vi ta selv.

Tidlig i utviklingsfasen gjorde oppdragsgiver oss oppmerksomme på fremtidsrettede og

effektive måter å kjøre applikasjoner i skyen på. Slik ble vi introdusert for Docker, noe

oppdragsgiver utfordret oss til å dra nytte av. Vi hadde ikke tilgang til kildekoden før

slutten av januar, og brukte derfor mye tid på å tilegne oss kunnskap om konteinerteknologi

og mikrotjenester frem til vi fikk tilgang til koden. Det gikk også mye tid på å få

Avkastningsportal til å kjøre på våre lokale datamaskiner etter at kildekoden ble utdelt.

I første omgang forsøkte vi å sette opp lokale utviklingsmiljøer på Windows 10 Home som

ikke hadde Hypervisor3 og dermed heller ikke støtte for virtualisering. Fremfor å installere

Windows 10 Pro eller Enterprise som har støtte for dette, bestemte vi oss for å kjøre Docker

på en Linux-distribusjon (Ubuntu 16.04), som også er et krav for å kjøre Rancher.

Vi innså tidlig at det var hensiktsmessig å ha et felles utviklingsmiljø på høgskolens

serverpark. Slik kunne vi eksperimentere fritt uten å være redd for å ødelegge noe eller

risikere unødvendige utgifter. Et ferdigutviklet miljø og oppsett kunne derfor enklere og

raskere gjenskapes på skytjenesten. Siden oppdraget ble noe avgrenset fra oppdragsgivers

side ønsket vi å utvide løsningen ved å tilrettelegge for kontinuerlig integrasjon og levering.

Vi har derfor satt opp og konfigurert automasjonsserveren Drone. I tillegg har vi satt opp

Janitor, som kjører i Rancher og frigjør diskplass ved å slette ubrukte konteiner-images.

Etter at vi hadde en fungerende løsning kjørende med kontinuerlig integrasjon på skolens

VM, opprettet vi konto hos Amazon Web Services og DigitalOcean. Slik hadde vi tre miljøer

med hvert sitt formål å jobbe på:

3 Hypervisor er en teknologi som tillater brukeren å lage virtuelle maskinvareressurser. Dette er ikke tilgjengelig i Home-versjonen av Windows 10.

23

• Utviklingsmiljø (VM hos OsloMet)

• Preprod-miljø4 (VM hos DigitalOcean)

• Produksjonsmiljø (Amazon AWS EC2)

Slik fikk vi testet ut automasjon i kontinuerlig integrasjon og leveranse ved implementasjon.

Vi brukte den resterende tiden i utviklingsfasen på å sette opp utvidelser i Rancher.

Utfordringer med lokale utviklingsmiljøer

Første installasjonsoppsett på lokale maskiner gjorde vi hovedsakelig i felleskap på egne

maskiner. Etter at vi alle hadde fått Avkastningsportal til å kjøre med Windows installert,

fant vi ut at Home versjonen ikke støtter virtualisering. Docker krever Windows Pro eller

Enterprise. Vi installerte derfor Linuxdistribusjonen (Ubuntu 16.04) siden dette er et krav for

å kjøre Rancher. Vi opplevde noen utfordringer med å få applikasjonen til å kjøre i Ubuntu,

men etter flere tapte forsøk, utviklet vi en installasjons- og konfigurasjonsguide for å gjøre

prosessen enklere ved andre anledninger. Denne har senere blitt omskrevet til vedlegget

Konfigurasjonsoppsett.

3.5 Virtuelt utviklingsmiljø

Vi fikk tildelt en virtuell server fra universitet med operativsystemet Ubuntu 16.04 installert.

VM-en har følgende adresse: http://hp5.vlab.cs.hioa.no.

Utfordringer med ressurser og tilgang

Den virtuelle maskinen vi fikk fra universitet viste seg lite egnet til å kjøre Rancher med de

ressursene vi fikk tildelt til å begynne med: én CPU med 2GB minne og 3GB lagringskapasitet.

Serveren var treg og uresponsiv før vi fikk tilgang på ressursene vi trengte for å kunne

eksperimentere med programvaren. Forespørsler om ytterligere ressurser

måtte etterspørres i flere omganger. Vi opplevde problemer med brannmuren på

universitetets nettverk, og ble blokkert når vi å la til host i Rancher. Problemene ble

etterhvert løst, men dette tok mye tid og frustrasjon som forhindret arbeid og fremdrift og

4 “Preprod” er oppdragsgivers navn på et staging-miljø. Dette er et testmiljø laget for å ligne så mye som mulig på et produksjonsmiljø og brukes til testing av løsninger som er antatt produksjonsklare.

24

medførte at vi heller leide en virtuell server fra DigitalOcean vi selv kunne administrere.

Kostnader for leie av VM-en har blitt tilbakebetalt fra oppdragsgiver.

25

4 Teknologier og vurderinger

4.1 DevOps

DevOps-fenomenet dreier seg om en filosofi og et tankesett som har fått mye

oppmerksomhet i IT-verden de senere år hvor skytjenester og effektive metoder er den nye

trenden for å utvikle og levere tjenester over internett. Dette prosjektet trekker inn enkelte

elementer fra DevOps-praksiser, hvor målet er å oppnå effektiv drift og vedlikehold av

Avkastningsportal. Løsningen so mer utviklet i prosjektet legger bedre til rette for

implementasjon av DevOps-praksis hos oppdragsgiver.

Som ordsammensetningen DevOps antyder, (eng: Development and Operations) er samspill

og delt ansvar mellom utvikling (Dev) og drift (Ops) essensen bak tankegangen. Formålet er

å akselerere levering, ved å benytte prosesser og verktøy for å drive effektiv utvikling og

drift. Leveranse til kunde foregår derfor hyppig og kontinuerlig, og misforståelser mellom

teammedlemmer reduseres slik at problemer kan løses raskere og mer effektivt. Med en

DevOps tilnærming når ny funksjonalitet raskere frem til markedet, og kan derfor gi fordeler

for både it-selskaper, kunder og ikke minst brukere (Ebert, Gallardo, Hernantes, & Serrano,

2016).

I følge Jabbari, bin Ali, Petersen, & Tanveer (2016) som har forsket på definisjoner og

praksiser i DevOps, ble det konkludert med følgende definisjon:

“DevOps er en utviklingsmetode som har til formål å tette gapet mellom utvikling og drift,

som vektlegger kommunikasjon og samarbeid, kontinuerlig integrasjon, kvalitetssikring og

levering med automatisert distribusjon og utplassering ved å benytte et sett med

utviklingspraksiser”.

I praksis innebærer DevOps følgende faser:

• Bygging

• Kontinuerlig Integrasjon (CI)

• Utplassering (CD)

• Drift

26

• Logging

• Overvåking

Kulturskifte

For å kunne omfavne DevOps må utviklere ifølge Ebert et al., (2016), ta en full-stack utviklers

tilnærming, hvor de tar ansvar for både testing og utplasseringsmiljøet. Utviklere må mestre

et sett ferdigheter utover kunnskap om kode, som for eksempel databaseadministrasjon,

automasjon og testing. I så måte kan utviklere jobbe sammen med testere, hvor begge

parter kan tilegne seg teknisk kunnskap fra hverandre. Fra et driftsperspektiv påvirker

DevOps i stor grad deres disipliner, som tilsier at driftsteam må samarbeide tett sammen

med utviklere der flytende kommunikasjon essensielt for å kunne lykkes. Videre peker Ebert

et al. (2016) på fire nøkkelpunkter som er nødvendig for å legge til rette for DevOps.

• Det er nødvendig å bryte ned komplekse arkitekturer og funksjonssett til små biter

som blir produsert og utplassert uavhengig av hverandre.

• Det er nødvendig å opprettholde konfigurasjon og bygge miljøer som tilbyr konstant

synlighet av hva som brukes, med versjoner og deres avhengigheter.

• Det er nødvendig å introdusere et spesialtilpasset utviklings og produksjonsmiljø som

stammer fra produktets livssyklushåndteringsmiljøer.

• Det er nødvendig å tette gapet mellom tradisjonelle kulturer innen utvikling og drift.

DevOps, smidig utvikling, lean og kontinuerlig levering

DevOps blir sett på som en utvidelse av smidig utvikling der endringer ønskes velkomne og

responderes på raskt under korte iterasjoner. I følge Lwakatare, Kuvaja, & Oivo (2016) som

har sett på relasjonen mellom DevOps, smidig utvikling, lean metodikk og kontinuerlig

levering, er det indikasjoner på at DevOps stammer fra kontinuerlig levering som en

evolusjon av smidig utvikling med Lean prinsipper som bakgrunn. Dette kommer spesielt av

prinsipper i det agile manifestet som fremmer mål om å tilføye drift de samme verdier, ideer

og praksiser fra agile metoder som utviklere. Det ble også konkludert med at for å få en

vellykket adopsjon av DevOps er det et krav å praktisere smidig utvikling. Forutsetningen er

27

at utviklings- og driftsteam jobber tett sammen og forstår hverandres behov og

prioriteringer, på samme måte som agile metoder krever at utviklere jobber tett sammen

med kunder for å forstå deres forretningsbehov og løser problemene sammen. Lwakatare

et.al (2016) belyser også at det er flere elementer i DevOps. Eksempler på disse er

håndtering av kode-branching, kontinuerlig integrasjon (CI) og levering (CD), samt

automatisert testing som er bakt inn i prosessen.

DevOps er et tema som ofte forbindes med kontinuerlig integrasjon, konteinere og

byggeverktøy som bransjestandard. Dette er nyttige verktøy i DevOps, men det blir også

uttrykt i artikkelen at det beste tilfellet for å oppnå DevOps kan være så enkelt som at en

ansatt fra driftsavdelingen setter seg ned sammen med en utvikler og planlegger

infrastrukturen i fellesskap. Læring, kunnskap og samarbeid trekkes også frem, noe som

bryter ned kunnskapssiloer, forenkler og muliggjør kommunikasjon, og alt i alt øker

organisasjoners kompetanse (Lwakatare, Kuvaja, & Oivo, 2016, side 1-11).

DevOps oppsummert

DevOps bygger på Lean-metodikk og smidige praksiser som påvirker hele IT- og

programvareindustrien. DevOps betyr kort og godt en ende-til-ende automatisering innen

programvareutvikling og levering, og vil være vanskelig å oppnå med en standardoppskrift

og -tilnærming. Utviklere spesielt vil tjene godt på bedre samhandling med driftsteam, noe

som typisk oppnås gjennom delt forståelse for krav i forhold til vedlikehold og

videreutvikling. Slik kan kostnader ifølge Ebert et al. (2016) reduseres med opptil 20 prosent,

men ettersom produkter og livssyklusprosesser varierer i stor grad er det nødvendig for

organisasjoner å tilpasse sin egen kultur med arkitektur og verktøy for å kunne oppnå

DevOps i praksis.

Prosjektoppgaven handler om å effektivisere drift og vedlikehold av Avkastningsportal med

konteineriseringsteknologi. Oppdragsgiver har uttrykt ønske om å gjøre tilsvarende arbeid

med flere av sine systemer, og vi har fått veiledning av deres nyansatte DevOps-konsulent. Vi

antar derfor at DevOps er noe oppdragsgiver ønsker å satse på. Likevel har vi kun en

grunnleggende forståelse av arbeidskulturen hos Kantega og kan vanskelig si hva et slikt

kulturskifte vil måtte innebære for å dra fullt nytte av DevOps.

28

Figur 4-1 - Illustrasjon av DevOps-syklus (Atlassian, udatert)

4.2 Tradisjonell VM-arkitektur og konteinerarkitektur

Skytjenester baserer seg på virtualiseringsteknologi og gir fleksibilitet ved deling av ressurser

i stor skala og utnytter ressursene på en maskin i større grad enn fysiske maskiner.

Virtualiseringsteknologi er en essensiell del av moderne skytjenester og har vært grunnlaget

for arkitekturen som er brukt i skytjenestene. Hovedfokuset til virtuelle maskiner er

administrering og allokering av fysiske maskinressurser og dermed ofte tilbudt som en IaaS-

tjeneste (Infrastructure as a Service). Dagens virtuelle servere/skytjenester kjører på fysiske

maskiner med hjelp av hypervisor, lokalisert på store datasentre omkring i verden.

Hypervisor er et program som kjøres på fysisk maskin for muliggjøring av virtualisering.

I praksis betyr dette at en kraftig maskin kan deles opp i mange mindre virtuelle maskiner

med egne operativsystemer og kan brukes på samme måte som en tradisjonell fysisk maskin.

Teknologien muliggjør en mer effektiv arkitektur, samt isolering av applikasjoner hvor for

eksempel forskjellige deler av applikasjonen kjøres på forskjellige virtuelle maskiner

opprettet på samme fysiske maskin. For eksempel kan webjenesten i en større applikasjon

kjøres fra en virtuell webserver, mens endringer samtidig kan utføres i back-end på en annen

del av applikasjonen som kjører på andre virtuelle maskiner, en såkalt reverse proxy løsning.

29

Fremveksten av virtuelle maskiner har drastisk redusert kostnadene ved IT-drift. Denne

kostnadsreduksjonen gjør det enklere for bedrifter å skille ut egen IT-drift til leverandører

med tilgang til datasentre. I tillegg til kostnadsreduksjon har virtualiseringsteknologi fordeler

som blant annet raskere republisering av maskiner, enklere backup, bedre støtte for testing,

katastrofeløsninger, klyngehåndtering av maskiner og enklere migrering til skyen

(Techrepublic, 2013).

Figur 4-2 - Tradisjonell VM-arkitektur vs. konteinerbasert arkitektur (Pahl, 2015)

Til tross for effektiviteten ved tradisjonell virtualisering er det fremdeles mulig dra bedre

nytte avressursbruk på virtuelle maskinene. Ved bruk av konteinerteknologi er det mulig å

effektivisere ressursbruken på datasentre med ytterligere 10%, og dette er et tall som

fremdeles vokser (M.J Scheepers, 2014). Konteinerteknologi er ikke en erstatning for

tradisjonelle VM-er, men kan heller ses på som en naturlig evolusjon innen virtualisering.

I motsetning til tradisjonell virtualiseringsteknologi med statiske ressurser låst til hver VM, er

konteinerteknologi mer fleksibelt med dynamisk bruk av ressurser. Konteinerteknologi er

laget for å pakke, isolere og sende kildekode med dets avhengigheter uavhengig av andre

konteinere, og benytter kun de fysiske ressursene konteineren har behov for. Låste ressurser

står derfor ikke ubrukt slik som det gjør ved tradisjonell virtualisering.

Dette tillater større fleksibilitet ved utvikling, drift og endringer av IT-systemer. Det finnes i

30

flere typer konteinerteknologier, men Docker er mest utbredt. Tabellen nedenfor viser

hovedforskjellene mellom tradisjonell VM og konteinerteknologi.

Virtuell maskin Docker

Virtuelle maskiner kjører på virtuell

hardware, og gjeste operativsystemet vil bli

lastet inn i sitt eget minne(RAM).

Gjester deler samme operativsystem, som

host OS, som er lastet inn i fysisk minne

(RAM).

Kommunikasjon mellom gjester via

nettverksenheter kan være programvare.

Kommunikasjon mellom gjester er gjennom

pipes, sockets, bridges etc.

Sikkerhet kommer an på type hypervisor. Mangler sikkerhetstiltak?

Mer overhead på grunn av kompleksitet. Mindre overhead på grunn av lettvekts

konteinere.

Tar tid å starte opp (boote). Raskt å starte opp (boote).

Bruker mer minne ettersom hele OS må

lagres for hver gjest.

Mindre minnebruk ettersom konteinere

deler gjeste-OS.

Figur 4-3 - Tabell med hovedforskjeller mellom tradisjonell VM vs. konteinerisering med Docker (Preeth & Mulerickal, 2015)

Både tradisjonell VM med hypervisor og konteinerbasert virtualisering tilbyr portabilitet,

isolering og optimalisering av hardware-ressurser. Hvilken teknologi som er hensiktsmessig å

bruke avhenger av hva slags applikasjon som skal kjøres og hvordan den skal brukes.

Tradisjonelle VM-er egner seg godt dersom ressurser skal deles likt på systemet. Dersom

mange små uavhengige prosesser skal kjøres, er konteineriseringsteknologi et bedre

alternativ. Siden Avkastningsportal allerede er delt opp i moduler var det et enkelt valg for

oss å modernisere applikasjonen ved bruk av konteinerarkitektur.

31

Mikrotjenestearkitektur

“Cloud native”-arkitektur, også omtalt som mikrotjenester, er små uavhengige

mikrotjenester som arbeider sammen i et system og kommuniserer gjennom et RESTful API.

Innen utvikling er dette fordelaktig ettersom mikrotjenester er språknøytralt og fremmer

frihet til å benytte programmeringsspråk og teknologier som best løser problemstillingen.

Det er enklere å gjøre endringer på uavhengige mikrotjenester i motsetning til endring av

kildekode på en monolittisk arkitektur, hvor hele systemet må oppgraderes for å tilpasse

endringene. Med Avkastningsportal var det praktisk at applikasjonen allerede var delt inn i

de tre tjenestene beregning, rapportering og renteimport. Det var derfor ikke nødvendig

med kodeendringer før vi kunne lage konteinere av løsningen.

Figur 4-4 - Forskjellen på monolittisk arkitektur og mikrotjenestearkitektur (Malav, 2017)

Konteinerteknologi - Docker

Konteinerteknologi legger til rette muligheten for å dele opp og pakke applikasjoner som

små isolerte tjenester. Konteinere lages og pakkes med kildekode og nødvendige

avhengigheter som sørger for at konteinere kjøres uavhengig av hverandre. Tanken med

32

dette er å isolere miljøer for å mitigere “single point of failure”5. Konteinere pakkes tettere

på serveren siden de ikke trenger et fullverdig operativsystem for å kjøre. Fordelen med

dette er at lettvekts-operativsystemer som eksempelvis Alpine Linux kan installeres direkte

på konteiner sammen med annen ønsket programvare.

Videre legger konteinerteknologi til rette for DevOps- prosesser og effektivisering av

prosesser rundt integrasjon, leveranse og skalering av applikasjoner. Dette kan i situasjoner

tilpasset DevOps gi positive utslag i forhold til ressursbruk og driftskostnader hos IT-

selskaper. Med vårt mål om å modernisere arkitekturen til Avkastningsportal ble det tidlig

avgjort å ta i bruk Docker, som er en ledende aktør innen konteinerteknologi. Oppdragsgiver

ønsket at vi utviklet en løsning som støttes fremover i tid, og det oppfylles ved å bruke

Docker. Det finnes utfyllende dokumentasjon som gjør det enkelt å jobbe med teknologien.

En vesentlig fordel med Docker er at applikasjoner får bedre portabilitet og kan kjøres på alle

operativsystemer og plattformer som har Docker installert. En annen fordel er økt sikkerhet

siden prosesser i konteinere kjører med en ikke-priviligert bruker som ikke har root- eller

administratortilgang til host-maskinen. Det finnes muligheter for å ytterligere kunne øke

sikkerheten til konteinere. Dette kan for eksempel for eksempel gjøres ved å ta i bruk

sikkerhetsmoduler som AppArmor, SELinux eller GRSEC for Linux-kjerner (docs.docker.com,

2018).

Docker-arkitektur

Docker bruker en klient-server-arkitektur [Se figur 4-5]. Kort beskrevet er det klienten som

snakker med Docker daemon som tar seg av bygging, kjøring og distribuering av Docker-

konteinere. Klienten og Docker daemon kommuniserer ved hjelp av et sett med REST API,

hvor daemon lytter etter Docker API-forespørsler og håndterer Docker-objekter som images,

konteinere, nettverk eller volumer. Et Docker-image er en kjørbar pakke av en avgrenset

løsning som kan publiseres til et register lignende Git. Brukere av løsningen kan så hente ut

ønsket versjon fra registeret. Siden det er Docker som tar imot disse imagene vil de oppføre

seg likt uavhengig av hvilket operativsystem Docker kjører på. Imaget inneholder en

5 Et single point of failure (SPOF), er et kritisk systemkomponent med evne til å ødelegge hele systemet (What is a Single Point of Failure (SPOF)?, udatert).

33

Dockerfile som er et sett med instruksjoner for hva som skal utføres ved kjøring av

konteineren. Når en bruker kjører et Docker-image, lages det en ny uavhengig konteiner som

utfører oppgaver definert i Dockerfilen. Det er også mulig å bygge videre på et image, og

legge til ønsket funksjonalitet på en eksisterende installasjon.

For å bygge et image skriver man en Dockerfil som definerer stegene som inngår i byggingen

av imaget. Konteineren som blir produsert er en kjørbar instans av imaget som kan startes,

stoppes, flyttes eller slettes ved hjelp av Docker API-et eller kommandolinjen. Prosessen

med å sette opp dette imaget lokalt hos en utvikler er kun én kommando: “docker run

<navn-på-image>”. Denne kommandoen vil laste ned eventuelle avhengigheter samt imaget

som skal kjøres og starter det opp. Videre finnes det måter å legge inn flere Docker images i

én fil ved å bruke Docker-compose. Disse defineres under hverandre i en og samme fil og

kan også startes ved å kjøre en konsollkommando. Dersom compose-filen refererer til et

image som ikke finnes lokalt vil det lastes ned på samme måte som for enkeltstående

images. Et eksempel på bruksområde for dette er hvis man vil sette opp en database

samtidig som en webserver uten å måtte starte tjenestene hver for seg.

Figur 4-5 - Illustrasjon av Docker-arkitektur (docs.docker.com, 2018)

34

Valg av operativsystem til konteinerne

I møte med oppdragsgiver i januar diskuterte vi størrelsen på konteinerne vi skulle lage og

hvilket operativsystem de skulle kjøre på. En mulighet var å bruke Ubuntu 16.04 men dette

ville krevd unødvendig mye diskplass for å kjøre de tre modulene til Avkastningsportal.

Konteinere av mindre størrelse går raskt å bygge og krever lite ressurser i drift. Vi fant at

Alpine Linux var godt egnet til konteinere og fungerte uten problemer til dette formålet.

Med Alpine fikk vi et grunn-image på 5 MB, i motsetning til et Ubuntu-image på omtrent 188

MB ("Docker Image Size Comparison", 2015). Videre var det nødvendig å ha Java-JDK

installert på operativsystemet for kunne kjøre å Java-applikasjoner. Til dette brukte vi et

Docker-image for operativsystemet som allerede inneholder en JDK6, kalt “alpine-java”.

Figur 4-6 - Oversikt over størrelse på operativsystemer brukt til konteinerløsninger - ("Docker Image Size Comparison", 2015)

Konteinerhåndteringsplattform

En konteinerisert applikasjon av en viss størrelse består ofte av mange konteinerinstanser.

En slik løsning kan fungere godt for applikasjoner med høy trafikk hvor det er ønskelig å

fordele arbeidsmengde på flere maskiner med lastbalansering. Samlingen av konteinere

kalles en klynge og administreres med en konteinerhåndteringsplattform eller

konteinerorkestreringsplattform. Plattformen skal sørge for at klyngen til enhver tid har

6 Java Development Kit, brukt for å skrive Java-programmer.

35

tilstrekkelig antall kjørende instanser av konteinerne, kalt skalering, for å opprettholde

tjenestene applikasjonen skal tilby. Plattformen skal også sørge for samhandling mellom

konteinere i klyngen og mot eksterne ressurser.

Konteinerorkestreringsplattformer defineres av Khan (2017) som et system som leverer

rammeverk på forretningsnivå for storskala integrasjon og håndtering av konteinere.

Systemet skal forenkle initiell konteinerutplassering og håndtering av flere konteinere som

én entitet med tanke på tilgjengelighet, skalering og networking. Videre fremhever Khan

(2017) syv hovedoppgaver for konteinerorkestreringsplattformer:

• Klyngetilstandshåndtering og planlegging av oppgaver skal ivaretas av programvaren.

Vedlikeholdsoppgaver som eksempelvis backup, garbage-collection og indeksering

planlegges etter ulike mønstre som skal minimere innvirkningen på kjøring av

applikasjonen.

• Tilby høy tilgjengelighet og feiltoleranse gjennom komponentredundans, oppdagelse

av feil og reallokering av oppgaver til fungerende komponenter. Dette kan gjøre at

systemer som ved feil ville brutt sammen kan fortsette operasjoner, eventuelt med

begrenset kapasistet. Ved å benytte lastbalansering reduseres faren for

overbelastning av komponenter samtidig som ressursbruk optimaliseres for å

maksimere ytelse og minimere responstid.

• Sørge for sikkerhet. Plattformen må påse at konteiner-image’ene er signerte og

kommer fra et sikkert register. Videre må den håndtere skreddersydde tilganger for

ulike brukere å gjøre endringer på systemet etter hvilken rolle de har. Secrets som

sertifikater, SQL-tilkoblingsstrenger, kontonøkler, SSH-nøkler, krypteringsnøkler m.m.

må også håndteres av plattformen. Disse kan oppbevares i et register som

konteinerne i systemet har tilgang til.

• Forenkle networking gjennom dynamisk håndtering av porter og IP-adresser for å

sikre sømløs tilkobling av konteinere i klynger. Behovet for ytelse i kommunikasjonen

innad i løsningen må balanseres mot behovet for sikkerhet gjennom isolasjon og

lagdeling.

36

• Tilgjengeliggjøre service discovery via et serviceregister. Dette registeret skal

inneholde IP og port for hver kjørende serviceinstans eller konteiner som leverer en

mikrotjeneste. Klienter skal kunne sende en spørring til dette registeret, ofte

gjennom en load balancer på serversiden, og deretter rutes til en konteiner som ikke

er overbelastet.

• Muliggjøre kontinuerlig leveranse ved å støtte automatiseringsverktøy som Jenkins

eller Drone.

• Tilby overvåkning og styring av både infrastrukturen konteinerne kjører på og

aktiviteten i konteinerne. På infrastruktursiden bør nettverk, sikkerhet, prosessor- og

minnebruk monitoreres. I konteinerne bør ytelse monitoreres for å oppdage feil som

minnelekkasje eller overdreven ressursbruk. Samtidig må logging og hvitboks-sporing

av forespørsler være mulig. Plattformen må ha regler for håndtering av feil.

Valg av konteinerhåndteringsplattform - Rancher

For å sørge for at vi ikke låste oss til en leverandør valgte vi bort skytjenestetilbydernes egne

konteinertjenester som Amazon ECS og Azure Fabric. Grunnen til dette var å sørge for

portabilitet slik at oppdragsgiver enkelt kan skifte hostingleverandør dersom det skulle bli

aktuelt. Etter å ha sett på ulike muligheter og etter å ha snakket med både oppdragsgiver og

andre bekjente i IT-bransjen ble vi gjort oppmerksomme på Rancher som

konteinerhåndteringsplattform.

Vi testet ut programvaren etter en gjennomgang av dokumentasjon på Rancher sine

nettsider og videoressurser av Codemy på youtube. Deretter presenterte vi en liten demo

for oppdragsgiver for å få tilbakemelding på arbeidet vi hadde gjort. En av veilederne hos

oppdragsgiver hadde inngående kjennskap til Rancher, og løsningen vi presenterte ble

mottatt med begeistring.

37

Rancher publiserer og konfigurerer konteinere, sørger for overvåking av dem og tilbyr

sikkerhetshåndtering ved hjelp av Active Directory og LDAP7. Dette er funksjoner som Docker

ikke har mulighet til å bruke av seg selv. Det ble også tatt et valg om å bruke Ubuntu 16.04

som operativsystem siden Rancher oppgir det som en av de anbefalte og mest utprøvde

Linux-distribusjonene. Konteinerhåndteringsplattformene bruker et underliggende system

for å administrere konteinere. Kubernetes og Cattle er begge eksempler på slike systemer

som håndterer automatisert deployment, skalering og håndtering av konteinerbaserte

applikasjoner. Vi valgte å bruke Cattle med standard konfigurasjon som er Rancher sin egen

variant av Kubernetes.

Rancher består av fire hovedkomponenter:

• Infrastrukturorkestrering

• Konteinerorkestrering

• Applikasjonskatalog

• Tilgangsstyring hvor team og enkeltpersoner kan få ulike rettigheter

Figuren nedenfor viser Ranchers disse fire hovedkomponenter og deres egenskaper

Figur 4-7 - Rancher-arkitektur

7 Active Directory er en katalog for administrering av brukere og sikkerhetsgrupper, og LDAP er protokollen som brukes.

38

4.3 Skytjenester

Datakraft, lagring, applikasjoner og it-ressurser leveres over internett som skytjenester med

en prismodell hvor man betaler for det man bruker. Dette kan ha en rekke fordeler fremfor

tradisjonelle hostingløsninger som Avkastningsportal hostes fra i dag. Gandhi, V. A., &

Kumbharana, C. K. (2014) påpeker flere fordeler og hovedtrekk ved skytjenester som:

• Redusering av kostnader

• Enhets- og lokasjonsuavhengighet

• Maks lastkapasitet-økning

• Forbedret stabilitet

• Skalerbarhet

• Sikkerhet

• Enkelt vedlikehold

Det er mange tilbydere å velge mellom og vi ønsket derfor å snevre inn søket vårt slik at vi

fant en god skyløsning som passet til våre behov. Amazon Web Services, Google Cloud

Platform og Microsoft Azure, samt Basefarm er store aktører som tilbyr løsninger vi

vurderte. Av disse var Amazon Web Services og Microsoft Azure aktuelle for oss på bakgrunn

av god integrasjon med Rancher som beskrevet tidligere.

Skytjenestemodeller

Skytjenestetilbydere leier ut datakraft og ressurser til kunder i form av tjenester som

defineres ved ulike skytjenestemodeller. Modellene baseres på hvilke ressurser som er

inkludert i dem, og om det er kunde eller leverandør som har ansvaret for disse.

Illustrasjonen nedenfor gir en god oversikt over tjenestemodellene IaaS, Paas og SaaS.

39

Figur 4-8 - Skytjenestemodeller (Kavis, 2014)

IaaS (Infrastructure as a Service) er en tjeneste som leverer maskinkraft og fysiske ressurser

for håndtering av lagring og prosessering. Tjenesten er ment for sluttbrukere som vil å kjøre

virtuelle maskiner eller nettverk og load balancing med mer etter behov. IaaS erstatter

fysiske servere og fysiske ressurser hvor hele infrastrukturen leveres over internett.

PaaS (Platform as a Service) tilbyr et utviklingsmiljø over internett som en tjeneste, hvor det

er mulig å utvikle applikasjoner med forskjellige teknologier og verktøy. Tjenesten tilbyr en

plattform til sluttbrukere hvor applikasjoner kan hostes.

SaaS (Software as a Service) er en tjeneste som tilbyr kjørende applikasjoner i skyen, typisk

brukt for applikasjoner som aksesseres og brukes via internett av forskjellige klienter fremfor

å installere applikasjonen på en lokal maskin.

40

I prosjektoppgaven var det mest naturlig å bruke IaaS slik at vi kunne ha full kontroll over

ressursene i systemet vi lagde. Dersom vi hadde gått for et av de andre alternativene ville

oppsettet vært enklere, men vi hadde risikert å låse oss til en bestemt leverandør og deres

måte å håndtere oppsettet på. Med IaaS er det derimot enkelt å bytte hosting-leverandør.

Dette kan gjøres ved å eksportere konfigurasjonsfilene fra én server til en annen.

Skytjenesteleverandører

Amazon Web Services

Amazon er pioneren innen skytjenester og lanserte i 2006 AWS Elastic Compute Cloud (EC2).

AWS har lenge vært den ubestridte markedslederen av skytjenesteløsninger. I 2017

dominerte AWS det offentlige markedet for skytjenester med 32% markedsandel, som utgjør

nesten en tredjedel av hele skytjenestemarkedet (Hollander, R., 2018).

Figur 4-9 - Markedsandel for skytjenestetilbydere (Hollander, 2018)

41

Elastic Compute Cloud (EC2) og Elastic Container Service (ECS)

EC2 er en kommersiell tjeneste som tilbyr skybaserte plattformer med skalerbare virtuelle

miljøer for infrastruktur og programvare. EC2 lar brukeren selv administrere plattformen og

installere nødvendig programvare.

ECS er en skalerbar konteinerhåndterings- og orkestreringstjeneste med høy ytelse som

støtter Docker-konteinere. Tjenesten tillater kjøring og skalering av konteinerbaserte

applikasjoner og kan eliminere behovet for håndtering og skalering av virtuelle maskiner.

ECS tilbyr to launch types: Fargate og EC2. En launch type beskriver infrastrukturen

applikasjoner og tjenester skal kjøres på. Fargate er en teknologi som tilbyr kjøring av

konteinere uten at man selv må håndtere servere og klynger ettersom den tilbyr en

serverløs infrastruktur i henhold til mikrotjenestearkitektur. Med Fargate launch type

trenger man kun å pakke applikasjonen i konteinere, spesifisere CPU, minne og

nettverksregler, og deretter kjøre applikasjonen. EC2 launch type ligner mer tradisjonell

VM/server-infrastruktur og gir bedre brukerkontroll på servernivå og kan skalere og

håndtere ressursbruk for EC2-instanser i ECS.

Figur 4-10 - EC2 vs. Fargate (aws.amazon.com)

Microsoft Azure

Microsoft lanserte i 2010 Windows Azure, som i 2014 endret navn til Microsoft Azure. Azure

tilbyr skytjenester for bygging, publisering og håndtering av applikasjoner gjennom et globalt

nettverk av datasentre, med integrerte verktøy for DevOps-praksiser og brukerstøtte. Azure

42

er den nest største aktøren innenfor skytjenester etter AWS, med en markedsandel på rundt

14% (Hollander, R., 2018).

Azure Service Fabric

Azure Service Fabric er en distribuert systemplattform for enklere pakking, publisering og

håndtering av mikrotjenester som konteinere. Systemet er i tillegg til dette også en

orkestreringstjeneste for publisering av mikrotjeneste-/konteinerbaserte applikasjoner.

Tjenesten baserer seg på mikrotjenestearkitektur med serverløs infrastruktur og eliminerer

problemer knyttet til system, skalerbarhet, administrasjon og ventetid.

Figur 4-11 - Azure Service Fabric (docs.microsoft.com, 2018)

43

4.4 Vurdering av skytjenesteleverandører

Leverandører som ble valgt bort

Basefarm er en leverandør av blant annet skytjenester med datasentre både i Norge og

ellers i Europa. Vi ønsket i utgangspunktet å vurdere deres skytjenester med tanke på at

oppdragsgiver allerede leier servere av dem til hosting for blant annet Avkastningsportal.

Siden Basefarm ikke hadde innebygget integrasjon med Rancher, ble den ikke tatt med

videre i vurderingen av skytjenester.

DigitalOcean er en skyleverandør som fokuserer på å selge billige virtuelle servere (kalt

“droplets”) med brukervennlig og superraskt oppsett. I motsetning til AWS hvor virtuelle

servere er en av mange tjenester som tilbys har DigitalOcean manglende støtte for

databasehosting, og er primært en IaaS-leverandør for utviklere som trenger et sted for å

kunne utplassere og teste applikasjoner. Vi fant derfor at DigitalOcean ikke tilbød det vi

hadde behov for til produksjonsmiljøet.

Google Cloud Platform kommer best ut blant konkurrentene når det kommer til oppetid

ifølge statistikk fra 2017, og har blitt jevnt bedre og bedre siden 2015 (MacLaughlin og

Sullivan, 2017). Manglende integrasjon mot Rancher gjorde likevel at Google ikke ble vurdert

som et alternativ.

Packet tilbyr tilsvarende tjenester som DigitalOcean med den samme begrensningen i form

av manglende støtte for databasehåndtering. Packet ble derfor heller ikke tatt med som et

alternativ.

Håndtering av secrets

Secret er sensitive data som passord, krypteringsnøkler, API-nøkler, sertifikater og tokens.

Dette bør ikke lagres i kildekoden av opplagte sikkerhetsmessige årsaker og bør heller

håndteres på en sikker måte, noe som også er et absolutt krav fra oppdragsgivers side. Både

AWS og Azure har løsninger for å håndtere secrets, og for å lagre dem i skyen. AWS tilbyr

AWS Secret Manager og Azure har en tjeneste som kalles Azure Key Vault. Rancher tilbyr

også lignende funksjonalitet. Alle tre lar utviklerne legge inn sensitiv informasjon som så blir

kryptert og dermed utilgjengelig for andre. Informasjonen blir gjort tilgjengelig som

44

miljøvariabler. En applikasjon kan så bruke disse referansene i koden eller konfigurasjonsfiler

uten å tenke på at de blir tilgjengelig for utenforstående.

Pris

Vi har ikke gransket ikke kostnader som er relatert til pris på hostingtjenester ettersom dette

ikke var aktuelt etter kravendringer. For å kunne estimere kostnader ville det vært

nødvendig med tilgang på informasjon om oppdragsgivers nåværende kostnader, i tillegg til

informasjon om nettverkstrafikk på Avkastningsportal. Denne informasjonen har vi ikke hatt

tilgang til. Konkurrentene AWS og Azure har ifølge Utley (2018) ligget relativt tett inntil

hverandre i pris de siste årene. Vi anså derfor ikke pris som en avgjørende faktor i

forbindelse med vurderingene vi gjorde.

Oppetid og stabilitet

For å kunne ta stilling til kravet om oppetid søkte vi etter informasjon og statistikk for å

undersøke hvordan Amazon og Microsoft hadde skilt seg fra hverandre over tid.

CloudHarmony er et selskap som blant annet sammenligner skytjenester ved å levere

objektive ytelsesanalyser og -rapporter. I følge MacLaughlin et al. (2017), som henviser til

data levert av CloudHarmony, fremstilles markante forskjeller mellom tilbyderne og deres

nedetid. Microsoft Azure kommer spesielt dårlig ut i forhold til Amazon og Google, hvor det i

2017 ble målt 740 minutter med nedetid for Azure mot 205 minutter for Amazon.

MacLaughlin et.al. (2017) belyser også at Amazon hadde totalt 448 minutter nedetid fra

2015 til 2017, hvorav 40% var knyttet til en enkeltepisode i 2017. Microsoft målte totalt

1652 minutter under den samme perioden.

45

Figur 4-12 - Antall minutter nedetid hos Amazon, Microsoft og Google (MacLaughline et.al. (2017)

4.5 Diskusjon og valg av skytjeneste

Amazon og Microsoft tilfredsstiller begge kravet om håndtering av secrets og stilte likt på

dette punktet. For å differensiere tilbyderne har vi blant annet støttet oss på funn beskrevet

i kapittel 4.3.3, hvor det fremkommer at Amazon ville være et godt valg med tanke på høy

grad av oppetid. Ettersom dette var et krav fra oppdragsgivers side, anså vi derfor Amazon

Web Services som et trygt valg.

Amazon ECS med Fargate launch type kunne vært et godt valg for å beholde mikrotjeneste-

/konteineriseringsprinsippene på både applikasjons- og infrastrukturnivå. Denne løsningen

er cloud-native og kan kjøre på en black-box serverløs infrastruktur som medfører mindre

arbeid, ansvar, drift og vedlikehold. Fargate kunne vært en god og enkel løsning hvor

administrasjonen av konteinerne gjøres hos Amazon. Det er også mulig å kjøre EC2-instanser

med ECS, men vi valgte heller å gå for en ren EC2-løsning. Siden Rancher er en komplett

plattform for administrering av konteinere låste vi oss ikke til en leverandør.

46

4.6 Databaseløsning

For å hindre tap av data ved bruk av konteinerisert database bruker vi RDS (Relational

Database Service) fra Amazon i produksjonsmiljøet. Denne løsningen tillater konfigurasjon

av databasen og fungerer på samme måte som andre AWS-produkter ved at

man enkelt kan legge til sikkerhetsgrupper og andre rettigheter. Sikkerhetsinnstillingene

inkluderer muligheten for å begrense tilgang til databasen utenfra. Dette er

implementert i vår produksjonssatte applikasjon, og databasen er konfigurert slik at den kun

aksepterer tilgang fra sikkerhetsgruppen EC2-instansen kjører på. Det vil si at det kun er

de tre konteinerne vi har i produksjon som kan aksessere databasen. Videre har RDS

konfigurerbar automatisk backup. Ved bruk av en konteinerisert database vil man selv måtte

sørge for dataintegritet og backup, mens bruk av RDS gjør dette for deg. Vi har

kommet frem til at dette er den beste måten å sørge for at data blir bevart og at det gjør det

enklest mulig for en utvikler å gjøre endringer på applikasjonen uten å måtte tenke på

problemer som omhandler databasen.

4.7 Kontinuerlig integrasjon og leveranse

Kontinuerlig integrasjon og leveranse8 er en utviklingspraksis som går ut på at utviklere

publiserer kode til et repository flere ganger daglig. Dette er en prosess for å bygge og

utplassere kode, samt kjøre tester automatisk når ny kode blir pushet til et repository. Disse

prosessene kjører på en separat server, i vårt tilfelle ved hjelp av applikasjonen Drone. En

slik arbeidsflyt kan gi enorme fordeler ved å vite om alle jobbene som er konfigurert

fungerer som de skal, i tillegg til rask feedback for feilmeldinger med detaljerte beskrivelser

om hvilke feil som er oppstått på hvilke jobber, hvor, og av hvem (Sneha, 2018).

Illustrasjonen nedenfor viser arbeidsflyten i et typisk kontinuerlig integrasjonssystem.

8 Kontinuerlig integrasjon og leveranse refereres heretter til som “CI/CD” (continuous integration / continuous delivery) eller “pipeline”.

47

Figur 4-13 - Prosess for kontinuerlig integrasjon (RHD Blog, 2017)

Det er flere fordeler med å bruke et CI/CD-system som Drone eller Jenkins sammen med

konteinere. En av disse er at løsningen man bygger automatisk vil kunne utplasseres til

skyen. Dersom utviklerne selv skulle gjøre dette på en tradisjonell måte ville de måtte

kopiere over ferdig bygde JAR- eller WAR-filer og konfigurasjonsfiler til en virtuell

maskin/skytjeneste via programmer som SCP (Secure Copy) for å legge over filene til

leverandør av hosting, og SSH (Secure Shell) for å sette riktige rettigheter på filene på server.

Utvikleren må også sørge for at filene ligger i riktig mappe på server og må eventuelt

restarte en UNIX-service på serveren for å sørge for at det faktisk er den nye versjonen som

kjører og ikke en gammel versjon.

Slik vi kjenner til oppdragsgivers arbeidsmetode benytter utviklerne deres VPN for å få

tilgang til hostingleverandørens servere. Dette må gjøres for både preprod-miljøet for

testing og for produksjonsmiljøet når applikasjonen er klar for produksjonssetting. En vanlig

måte å sørge for at man er i riktig miljø, observert hos oppdragsgiver, er å sette en bestemt

bakgrunnsfarge på terminalvinduet når man skal legge noe ut i produksjon. Dette virker som

48

en ekstra sikkerhet for utvikleren slik at han eller hun ikke sletter data i produksjon ved en

feiltakelse. Fordelen med å bruke Rancher og Drone i vår oppgave er at logikken for

utplassering til preprod og til produksjon er bestemt i konfigurasjonsfiler, og at utvikleren

derfor ikke trenger å tenke på å logge seg inn i riktig miljø via terminal.

Alt som skal til er å publisere en endring ved hjelp av Git og så vil CI/CD-verktøyene sørge for

at alt havner der det skal. Bruken av konteinere gjør at ingen manuell kopiering er nødvendig

og bruken av Drone lar hele prosessen med testing, deployment og restart av applikasjonen

skjer automatisk. Videre er vårt oppsett slik at kun en teamleder vil kunne publisere

endringer i master-branchen i Git og en utvikler vil derfor aldri kunne legge ut nye versjoner i

produksjon uten at en teamleder har godkjent endringene. Ved bruk av terminalvinduer og

manuell kopiering er det lettere å gjøre denne feilen, mens det i vår løsning ikke er mulig å

gjøre dette ved en feil. For å verifisere applikasjonen før produksjonssetting må teamleder

påse at systemtest er utført, samt foreta en manuell gjennomgang av oppdatert kildekode.

Drone og Jenkins

Kontinuerlig integrasjon og levering er en viktig del av prosjektet, og det ble naturlig å først

ta i bruk Jenkins, som er industristandard for automatisering av byggeprosesser. Etter å ha

kikket nærmere på temaet om CI oppdaget vi Drone som er konteinerbasert og derfor passer

godt inn i vårt konteinerbaserte miljø. I en sammenligning av Drone og Jenkins på Rancher

sine nettsider presiseres det at en plugin i Drone er et konteiner-image. Avhengigheter i

programvaren trenger derfor ikke å håndteres separat, siden de er bakt inn i et konteiner-

image, i motsetning til Jenkins som må konfigureres for å kunne snakke med Docker.

Sammenlignet med Jenkins kommer Drone godt ut i en konteinerbasert sammenheng på

grunn av dens simplisitet, og blir fremstilt som et populært valg for mindre team og

prosjekter. Dette syntes vi passet godt til oppgaven og bestemte oss derfor å ta i bruk Drone

(Rancherlabs, 2018).

49

Janitor

Janitor er programvare som kjører på alle hosts og sletter alle ubrukte Docker images og

uallokerte datavolum. Denne prosessen sørger for at filsystemet (ofte i katalogen

“/var/lib/docker”) ikke fylles opp med gamle og ubrukte konteiner images som ikke lenger er

i bruk.

ELK-Stack

For å ytterligere underbygge DevOps-tankegangen ønsket vi å sette opp en en sentralisert

logging-tjeneste for overvåking av systemet. Vi har brukt ELK stack, som er et sett med gratis

åpen kildekode verktøy. Sentralisering av loggene er hensiktsmessig fordi løsningen kjører på

flere konteinere og hoster i flere miljøer som genererer store mengder med loggdata. For å

få verdi av disse datastrømmene må dataene struktureres for å få bedre synlighet og

lesbarhet, slik at informasjonssøking i systemet blir enklere. I forbindelse med drift,

vedlikehold og overvåking gir indekserte data et godt overblikk over status og historikk på

systemet i sanntid.

Elasticsearch er en distribuert søkemotor som tilbyr horisontal skalering, og muligheter for

sanntidssøk med fulltekst. ES sine egenskaper er eksponert med JSON-data over et RESTful

API som tillater dynamisk indeksering av data som gir rask respons på sanntidssøk ettersom

indekser blir brukt for tekstsøk.

Logstash er et sentralisert dataprosesseringsverktøy som brukes for å samle inn, behandle

og analysere varierte strukturerte og ustrukturerte data som blir generert av forskjellige

systemer i datapipelinen. Ved hjelp av plugins som tilbys for applikasjonen kan man koble til

flere forskjellige inputstrømmer og plattformer. Dette gjør det mulig å effektivt prosessere

logger, hendelser og andre datakilder som ofte kommer i ulike dataformater. Fordelen med

dette er at alle datakilder blir konvertert til ett enkelt dataformat, noe som er meget

hensiktsmessig ved håndtering av større mengder data. Andre muligheter med Logstash er å

bruke filtre, som tilbys både klare til bruk og med støtte for å kunne lage egne (Chhajed,

2015).

50

Kibana er en visualiseringsplattform som brukes for fremstilling av data som blir lagret i

Elasticsearch-indekser. Kommunikasjonen foregår gjennom ES sitt eksponerte REST api, som

Kibana benytter for å presentere grafiske fremstillinger av JSON-data for sluttbrukere. Det er

et kraftig verktøy med uendelige muligheter som blir mye brukt til å vise og dele blant annet

histogrammer, kakediagrammer, kart og tabeller på et dynamisk dashboard. Verktøyet er

ment for å gi brukervennlig innsikt i store mengder med data, og gir fleksible muligheter til

alt fra analyse og debugging i sanntid til BI (eng: “business intelligence”). Illustrasjonen

nedenfor viser en typisk data-pipeline i ELK stack (Chhajed, 2015).

Bildet nedenfor viser at logger fra tre forskjellige applikasjonsservere blir sendt med

”Logstash shipper”, til den sentraliserte” Logstash indexeren” med output data til

Elasticsearch. I dette leddet kan Kibana kan utføre indeksbaserte spørringer på gjennom det

eksponerte RESTful API-et til Elasticsearch for å visualisere JSON-data.

Figur 4-14 - Illustrasjon av en ELK-stack datapipline (Chhajed, 2015)

51

Logspout er en logg-ruter for Docker-konteinere som tilfører ELK stack

funksjonalitet. Logspout kobler seg til alle kjørende konteinerinstanser på hosten, fanger

opp deres logger som går gjennom stderr og stdout9, og deretter sender de videre til

Logstash.

4.8 Andre hensyn

Let’s Encrypt

For å få HTTPS-tilkobling er det nødvendig å få utdelt et signert sertifikat som bekrefter

identiteten til en server. Vanligvis er dette noe man betaler for, men det finnes også et gratis

alternativ kalt Let’s Encrypt. Denne tjenesten utsteder signerte sertifikater så lenge man kan

bevise at man eier en server. Prosessen innebærer at man kjører et skript fra Let’s Encrypt

på sin egen server.

Studentlisenser og kostnader

Som studenter hadde vi fått utdelt lisenser for både Microsoft Azure og for Amazon Web

Services, som begge kommer med $100 i studentkreditt. Kostnader utover de som ikke ble

dekket av studentlisenser har blitt refundert av oppdragsgiver etter avtale om dette.

Datasikkerhet og personvern (GDPR)

GDPR (General data protection regulation) er en stor endring i regulering av personvern,

som ble vedtatt av EU parlamentet i April 2016, og som trer i kraft 25. mai 2018. Loven er

utformet for å harmonisere personvernlover i Europa og beskytte all personlig data og

borgeres personvern. Dette er noe alle organisasjoner og selskaper må ta stilling til, inkludert

oppdragsgiver. GDPR er derimot er ikke noe vi behøver å ta høyde for ettersom

Avkastningsportal kun benytter offentlige data (EU GDPR Information Portal, 2018).

9 stderr står for Standard Error og stdout for Standard Out. Begge to er inputstrømmer hvor dataflyten i operativsystemet går

52

4.9 Oppsummering

Vi valgte å bruke Docker og konteinerteknologi i stedet for en tradisjonell infrastruktur hvor

applikasjonen manuelt må legges over på host-maskinen for hver gang den bygges. Dette var

en enkel endring siden applikasjonen allerede var inndelt i mikrotjenester. Det var derfor et

naturlig valg å bruke Docker for å legge disse modulene inn i selvstendige konteinere. For å

kunne håndtere dette valgte vi Rancher som konteinerhåndteringsplattform. Med Rancher

kan arbeidsgiver selv velge å bytte skytjenestetilbyder dersom de senere skulle ønske dette.

Det er forholdsvis små endringer som skal til for å bytte ut leverandøren, og all konfigurasjon

av applikasjoner og tjenester er håndtert i Rancher som tilbyr eksportering av

konfigurasjonsfiler ved behov.

Vi landet på Amazon EC2 som skytjenesteplattform. I motsetning til ECS lot dette lot oss selv

bestemme hvilken administrasjonsplattform for konteinere som skulle benyttes. Tilbyderne

av skytjenester vurderes for vår problemstilling som tilnærmet like dersom man kun ønsker å

benytte seg av en virtuell maskin i skyen, og begge tilbyderne med integrasjon til Rancher

tilfredsstilte kravene om håndtering av secrets. Det ble også valgt å bruke Amazon sin egen

databaseløsning, RDS, som utfører automatisk backup og unngår problemer med tapt data

som kan forekomme dersom det benyttes en konteinerisert database.

For å støtte et DevOps-tankesett er det blitt valgt å sette opp kontinuerlig integrasjon og

levering ved hjelp av Drone som både er lettere og mer tilpasset et konteinermiljø enn

Jenkins. På grunn av tidsbegrensninger har vi kun satt opp standard konfigurasjon av ELK-

stack, da konfigurasjon av stacken er omfattende. Vi har testet forskjellige oppsett av ELK på

skolens VM, men ikke kommet frem til et oppsett som passet å implementere i løsningen.

Sentralisering av loggene er derfor ikke implementert. I tillegg satt vi opp Janitor for enklere

drift og administrasjon av maskinvareressurser. Vi benyttet også Let’s Encrypt for å få HTTPS-

tilkobling til preprod-miljøet.

53

5 Systemdokumentasjon

Dette kapitlet beskriver løsningen som er satt opp. Resultatet av den tekniske delen av

prosjektoppgaven er en CI/CD-pipeline som forenkler utviklernes arbeidsflyt og -metode ved

å håndtere utplassering av oppdaterte applikasjoner automatisk ved en kodeendring. Når en

utvikler publiserer kode ved hjelp av Git vil automasjonsverktøyet Drone starte en prosess

med å bygge, pakke og publisere den nye versjonen av Avkastningsportal. Byggingen

håndteres av en Maven-plugin i Drone, pakkingen av en Docker-plugin og publiseringen

håndteres til slutt av en Rancher-plugin. Etter dette er Drone ferdig med sin del av prosessen

og Rancher sørger for at de nye versjonene legges ut enten i preprod eller produksjon hos

henholdsvis DigitalOcean og Amazon EC2.

I figuren på neste side er den øverste boksen hele Avkastningsportal med de ulike modulene,

databasen og den innebygde webserveren som gir tilgang til grensesnittet. Neste steg er

pilen mellom de to boksene som viser at det er via GitHub at koden til Avkastningsportal blir

tilgjengeliggjort for Rancher-serveren og dermed Drone.

54

Figur 5-1 - Prosessflyten i løsningen

I boksen i midten er det en prosessflyt fra Drone. Når koden er hentet ned fra GitHub bygges

prosjektet i Drone ved hjelp av en plugin-konteiner som inneholder Maven, verktøyet for å

bygge Java-prosjekter. Dersom en test feiler vil Drone avbryte byggeprosessen og gi en

tilbakemelding. Ved hjelp av webhooks mot GitHub gjennom OAuth-applikasjonen vil det

også være synlig på GitHub om en commit førte til feil i koden. Det samme gjelder hvis noe

55

feiler i et annet ledd i prosessen, for eksempel dersom konteiner-registeret ikke er oppe og

Drone dermed ikke kan publisere nye images. En mer detaljert oversikt over CI/CD-pipelinen

i systemet finnes i sekvensdiagrammet under.

Figur 5-2 - Sekvensdiagram for løsningen

5.1 Oppsett for testing og utvikling

Vi benyttet Ubuntu 16.04 som operativsystem på våre maskiner av to grunner: (1) for å ha

likt utgangspunkt når vi jobbet med det tekniske, og (2) for å være sikre på at Docker kunne

brukes. Som nevnt tidligere hadde vi fra før Windows 10 Home som ikke støttet Docker. For

lokal testing og utvikling installerte vi følgende programvare:

• MySQL Server versjon 5.5

• MySQL Workbench (nyeste versjon)

• Intellij IDEA (nyeste versjon)

• Maven (nyeste versjon)

• Git (nyeste versjon)

• Oracle JDK 8

56

• Docker (versjon 17.12)

5.2 Oppsett av utvikling og preprod-miljø

VM fra OsloMet – utviklingsmiljø

Utviklingsmiljøet var fra begynnelsen av satt opp på VM-en vi fikk tilgang til fra universitetet.

Operativsystemet var det samme som vi brukte på lokalt på våre egne datamaskiner –

Ubuntu 16.04. Vi fikk tildelt en standardbruker som vi kunne logge oss inn med. Vi installerte

så de samme programmene som nevnt i avsnittet over, bortsett fra Intellij IDEA og MySQL

Workbench. Disse verktøyene trenger et grafisk grensesnitt og vi valgte å kun bruke SSH via

terminalvinduer mot VM-en. Rancher-server (versjon 1.6.16) ble deretter installert slik at vi

kunne begynne det grunnleggende arbeidet med å administrere konteinerne vi lagde.

VM fra DigitalOcean – preprod-miljø

Når vi etterhvert fikk problemer med brannmuren hos universitet leide vi en VM fra

DigitalOcean, slik at kunne vi ha full kontroll på ressurser, konfigurasjon og sikkerhet. Vi

brukte en ferdig «droplet» som var klar til bruk med med Ubuntu 16.04 installert og

opprettet personlige brukere for hvert medlem i prosjektgruppen. SSH-nøkler ble generert

på maskinene til hver bruker for å forenkle innloggingen til VM-en uten passord og kopiert

over til VM-en. Vi installerte så de samme programmene som på VM-en fra universitetet. Til

slutt satt vi opp en grunnleggende brannmur ved hjelp av programmet ufw i Ubuntu, og satt

opp tillatelser for SSH og alle nødvendige porter som skulle eksponeres ut fra VM-en. Etter

at oppsettet hos DigitalOcean var ferdig brukte vi kun denne VM-en til å administrere

konteinerne fra Rancher.

57

Figur 5-3 - Regler i brannmuren

5.3 Oppsett av Avkastningsportal i Rancher

For å sette opp Rancher må Docker først installeres før man starter opp Rancher-serveren

med kommandoen:

$ sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server

Etter noen minutter er installasjonen ferdig og man kan logge inn i Rancher ved å gå til

http://<server-ip>:8000, hvor <server-ip> i vårt tilfelle er ip-adressen til VM-en. Første gang

man går inn i en ny Rancher-installasjon blir man bedt om å sette opp adgangskontroll, og vi

brukte brukernavn og passord som autentisering. Etter dette må man legge til en «host». En

host er en maskin som skal kjøre konteinerne som administreres med Rancher, og det

trenger ikke å være den samme maskinen som kjører Rancher-serveren. I vårt tilfelle var det

enklest å la VM-en være host for preprod-miljøet.

58

Figur 5-4 - Legge til ny host i Rancher

Rancher kommer fra før med en integrasjon mot DigitalOcean hvor man kan legge inn en

nøkkel som genereres fra innloggingssiden på digitalocean sine nettsider. Ved å legge til

denne nøkkelen vil Rancher selv sette opp de nødvendige containerne for at maskinen skal

virke som en host, og dermed kunne administreres fra Rancher-serveren.

Figur 5-5 - Legge til DigitalOcean som host i Rancher

Dersom man bruker en host som ikke har integrasjon i Rancher fra før, slik som VM-en fra

universitetet, må man velge «custom» i skjermbildet over. Brukeren legger inn ip-en til

maskinen som skal være Rancher host, og det genereres til slutt en konsollkommando som

må kjøres for at oppsettet skal fullføres. Etter et par minutter er hosten klar til å brukes og

den dukker opp som i figur 5-5.

Figur 5-6 - Konsollkommando for å legge til host i Rancher

59

Figur 5-7 - Ferdig oppsett av host i Rancher (ip-adressen er skjult)

Containere til Avkastningsportal

Vi lagde tre konteinere – en for hver modul av Avkastningsportal som inngår i

prosjektoppgaven: «Rapportering», «Beregning» og «Renteimport». Vi lagde et Docker

image for hver modul, hvor hver av dem brukte Alpine Linux som grunn-image, og la til

nødvendige JAR-filer og konfigurasjonsfiler i Dockerfilen.

Databasecontainer til testing

Vi lagde en konteiner til bruk under testing og under kjøring av CI/CD-pipelinen. Her brukte

vi et offisielt MySQL-image som grunnlag og la til konfigurasjonsfiler og testdata i imaget slik

at databasen enklest mulig kunne startes og stoppes ved behov.

60

Docker registry

Et Docker registry ble installert på VM-en for å kunne pushe ferdiglagde images til et sentralt

register slik at Rancher kunne hente ut images og kjøre dem på de ulike hostene. Etter at

registeret var satt opp ble konteinerne til Avkastningsportal og testdatabasen publisert dit.

Dette er en to-trinns prosess hvor man først «tagger» et image med versjonsnummer og så

pusher det til registeret.

Figur 5-8 - Kjørende Docker-register i Rancher

Et Docker-register kommer også med et eget RESTful API som brukes til kommunikasjon. Det

medfører at brukere med tilgang til registeret kan bruke en nettleser til å se innholdet ved å

gå inn på http://<register-adresse>/v2/_catalog.

61

Figur 5-9 - JSON-respons fra Docker-registeret

Avkastningsportal-stack

I Rancher kan det defineres egne grupper av tjenester som kjører sammen, og dette kalles

for en stack. Vi fant det mest naturlig å opprette en egen stack for Avkastningsportal. For å

gjøre dette går man inn i Rancher og velger «Add Stack» fra hovedsiden. På den påfølgende

siden velger man et navn for stack-en og den blir lagt til i Rancher som en tom gruppe.

Figur 5-10 - Oppsett av Stack i Rancher

Vi satt opp en tjeneste («Service») for hver av modulene i Avkastningsportal i tillegg til

databasekonteineren. Siden konteiner-image’ene allerede var publisert til registeret kunne

vi nå hente dem ut ved hjelp av Rancher.

62

Figur 5-11 - Oppsett av tjenester i en stack ved bruk av eget register

Oppsettet for hver konteiner inneholder en rekke ulike konfigurasjonsmuligheter slik som

secrets, porter som skal brukes, miljøvariabler og hvilke hosts som skal kjøre tjenesten. Vi

definerte først tjenesten for databasen på grunn av at alle modulene til Avkastningsportal

trenger denne for å kunne hente ut data. Under oppsettet av modulene ble det også

spesifisert at de skulle lenkes sammen med databasekonteineren. Dette gjør at konteinere

alltid vil ha tilgang til databasen gjennom det navnet man velger å kalle lenken for. Det

trengs derfor ikke tas hensyn til dynamisk ip-adresse på databasen siden Rancher og Docker

håndterer dette automatisk. Konfigurasjonsfilene til Avkastningsportal har definert

databaseadressen til å være «avkastning-db» som er navnet vi ga lenken mellom databasen

og modulene.

Figur 5-12 - Ferdig oppsatt stack til Avkastningsportal med testdatabase

63

Drone

Drone tilbys som en konfigurerbar pakke man kan hente ut fra Rancher Community Catalog.

Installasjonen av Drone er konfigurert til å interagere med GitHub, hvor det først ble satt

opp en egen applikasjon (OAuth) for å håndtere autorisasjon ved hjelp av GitHubs eget API.

Når applikasjonen er satt opp genereres det en klient-ID og -Secret som må legges inn i

konfigurasjonen til Drone.

Figur 5-13 - Drone hentet i Rancher Community Catalog

Når OAuth-applikasjonen er satt opp og drone kjører kan installasjonen aksesseres på

http://<drone-server-adresse>:<port>/. Brukeren vil så bli sendt til GitHub for innlogging og

blir bedt om å autorisere OAuth-applikasjonen slik at systemene kan kommunisere med

hverandre.

64

Figur 5-14 - Gruppens registrerte OAuth-applikasjoner

Til slutt kan brukeren se sine GitHub-repositories og velge hvilke av disse Drone skal følge

med på. For prosjektgruppen er det Avkastningsportal som er interessant og er det eneste

som ble lagt til. Når dette er lagt inn i Drone kan man konfigurere hendelser som trigger

Drone til å sette i gang en CI-prosess. Hendelsene legges inn i GitHub og kalles «webhooks».

Konfigurasjon er satt til å trigge Drone ved en push til Avkastningsportal på GitHub.

Figur 5-15 - Prosjektgruppens GitHub-repository lagt til i Drone

For at Drone skal kunne gjøre noe som helst må det lages en konfigurasjonsfil med

standardnavnet «.drone.yml», og filen plasseres i rotkatalogen til prosjektet. Når Drone

kjører CI-prosessen sin vil den først hente ut prosjektet fra GitHub og dermed oppdage

konfigurasjonen som skal kjøres. Utfyllende beskrivelse av prosessen med CI/CD-pipeline

kommer i kapittel 5.7.

65

Janitor

Verktøyet legges inn på samme måte som Drone via Rancher Community Catalog. For vårt

behov var standardkonfigurasjonen god nok. Den bestemmer at Janitor skal kjøre en gang i

timen og kun slette ubrukte Docker images og ikke konteinere. På denne måten blir ingen

ting slettet uventet. Vi opplevde stor plassbesparelse av å la Janitor kjøre i bakgrunnen,

siden det ved hver kjøring av CI/CD-pipelinen ble liggende igjen gamle Docker images av

Avkastningsportal og testdatabasen. Hvert av disse har en størrelse på mellom 140 og 210

MB og totalstørrelsen på alle fire er rundt 700 MB. Testing av applikasjonen krevde svært

mange forsøk og vi opplevde at VM-en fra OsloMet raskt gikk tom for diskplass. Etter at

Janitor var satt i gang var ikke dette et problem lenger.

Figur 5-16 - Henting av Janitor fra Rancher Community Catalog

ELK-stack og Logspout

Sentralisering av logger er viktig for å strukturere og gi verdi til loggdata som genereres av

systemet. ELK-stack ble satt opp ved hjelp av rancher-compose-kommandoer hvor vi først

installerte Elasticsearch. Dette deployer elasticsearch clusteret bestående av fire konteinere

med tjenestene master, data og client node, samt kopf som er web-brukergrensesnittet for

elasticsearch.

66

Figur 5-17 - Elasticsearch-stack i Rancher

Webgrensesnittet var som standard konfigurert til å bruke port 80 men i og med at denne

porten allerede var i bruk ble det benyttet port 85. Webgrensesnittet nås via nettleser ved

ip-adresse/url på port 85 (http://hp5.vlab.cs.hioa.no:85), og tillater konfigurasjon av

elasticsearch.

Figur 5-18 - Kopf - Webgrensesnitt for elasticsearch

Etter at Kopf kjører og er tilgjengelig installeres logstash som starter opp 3 konteinere med

tjenestene Redis, logstash collector og logstash indexer. Når disse er oppe kan man peke

loggene til adressen logtstash://host:5000.

67

Figur 5-19 - Logstash-stack i Rancher

For å legge til rette for enklere logg-konfigurering la vi til logspout som samler logger fra alle

kjørende konteinerinstanser og dirigerer de til samme destinasjon. Logspout er en

tilleggstjeneste og er ikke nødvendig for at ELK stack skal fungere.

Figur 5-20 - Logspout-stack i Rancher

Til slutt ble Kibana installert for visualisering av loggdata som er generert av systemet.

Kibana starter opp konteinerne kibana-vip og nginx-proxy og tilbyr et webgrensesnitt for

visualisering av data. Dette webgrensesnittet var også som standard satt til å bruke port 80,

som var allerede i bruk. Porten ble derfor endret til port 92, og kan nås via en nettleser på ip-

adresse/url (http://hp5.vlab.cs.hioa.no:92).

Figur 5-21 - Kibana-stack i Rancher

68

Figur 5-22 - Kibanas webgrensesnitt

Lastbalansering

For å kunne allokere nødvendig maskinvare for å kjøre containere finnes det funksjonalitet i

Rancher for å bruke en lastbalanserer. Funksjonaliteten er innebygd i Rancher og legges til

enten selvstendig eller som del av en stack. Ved å konfigurere lastbalansereren og stacken

kan Rancher følge med på tjenestene som kjører, og starte opp flere instanser dersom

tilkoblingen til en eksisterende stack går sakte. Dette kan komme av treg internett-tilkobling

eller for stor trafikk inn mot en enkelt Rancher host som ikke har kapasitet til å håndtere alle

brukerne. I løsningen er dette konfigurert, men på grunn av begrenset trafikk inn til

applikasjonen har ikke funksjonaliteten vært nødvendig eller avgjørende for stabiliteten.

Figur 5-23 - Ferdig oppsatt lastbalanserer på VM-en hos DigitalOcean

69

Ferdig Docker-oppsett på VM

Etter at alle konteinerne var satt opp på VM-en endte vi opp med instansene vist i figurene

under. Den første figuren er beskrivelsen som kommer i terminalen ved å bruke Docker-

kommandoer, mens den siste viser tilsvarende beskrivelse hentet ut fra Rancher. Her blir

flere fordeler med bruk av Rancher synlige: 1) Mer utfyllende beskrivelse av hver konteiner,

2) vi får en oversikt over maskinvareressurser som er tilgjengelige og oppbrukt, og 3)

administrasjonen av konteinere blir enklere ved hjelp av det grafiske grensesnittet i Rancher.

Figur 5-24 - Oversikt over kjørende Docker-konteinere på VM-en

70

Figur 5-25 - Tilsvarende oversikt i Rancher

5.4 Domenenavn til VM

Let’s Encrypt og Duck DNS

For å kunne sikre applikasjonen med HTTPS10 fant vi ut av vi kunne benyttes en tjeneste fra

Let’s Encrypt (https://letsencrypt.org/). Ved å kjøre et script på en server med et registrert

domenenavn vil Let’s Encrypt lage et godkjent SSL-sertifikat. Dette lagres så på serveren og

kan legges inn i Rancher for å sette opp HTTPS. Ved hjelp av lastbalansereren beskrevet i

forrige avsnitt kan man også bestemme hvilke tjenester som skal ha mulighet til å bruke

HTTPS. Oppsettet for dette er i figur 5-21. Let’s Encrypt finnes også som en Stack i Rancher

Community Catalog som vi brukte for å sette det opp.

10 HTTPS (Hyper Text Transfer Protocol Secure) er en protokoll for sikker kommunikasjon over internett.

71

Figur 5-26 - Sikker tilkobling til Rancher og Avkastningsportal

Som nevnt er det nødvendig med et domenenavn for å kunne bruke Let’s Encrypt. Når vi

leide VM-en fra DigitalOcean fikk vi utdelt ip-adressen til VM-en. Siden ip-en er statisk kunne

vi så sette opp et domenenavn ved hjelp av en dns-tjeneste. For å unnslippe kostnader og

formaliteter rundt registrering av et «ekte» .no- eller .com-domene undersøkte vi

kostnadsfrie alternativer. Det beste alternativet vi fant heter Duck DNS

(https://www.duckdns.org/), og her registrerte vi en bruker og la inn ip-adressen til VM-en.

Domenenavnet «avkastningsportal.duckdns.org» var ledig og vi fikk registrert det til ip-

adressen. Endringen var gjort på sekunder og vi kunne med en gang bruke domenenavnet i

stedet for ip-adressen for å koble oss til VM-en.

Figur 5-27 - Registrering av domenenavn hos Duck DNS

72

5.5 Oppsett av egen Rancher Catalog

Det har i guiden flere steder blitt referert til Rancher Community Catalog som inneholder

ulike pakker for å legge til tjenester i Rancher. Vi fant ut at vi kunne lage vår egen katalog

som inneholdt modulene til Avkastningsportal. Dette ble løst ved hjelp av dokumentasjonen

til Rancher11, og består av et eget repository på GitHub med to konfigurasjonsfiler: en for

Docker-containerne og en for oppsettet av egen Stack i Rancher med innstillingene som

kreves. Logoen til Norsk Pensjon er tatt med i registeret for enklere gjenkjenning. Det går

også an å legge til variabler kalt «questions», slik at oppsettet blir konfigurerbart når man

legger til løsningen i Rancher.

Verdien i dette oppsettet ligger i at en utvikler ikke trenger å definere tjenester og lage egen

Stack i Rancher for å legge ut Avkastningsportal på nytt. Dette er tidsbesparende for

utviklerne og gjør portabilitet mellom skytjenesteleverandørene trivielt. Dersom det fra

oppdragsgivers side blir bestemt at løsningen heller skal ligge på Microsoft Azure i stedet for

Amazon EC2 trengs det kun å legges til en ny host i Rancher, og så finne Avkastningsportal i

den egendefinerte katalogen som vist under. Etter at man trykker på «View Details» er det

kun ett museklikk som skal til for å ha en kjørende instans av Avkastningsportal hvor som

helst.

Figur 5-28 - Avkastningsportal som publiserbar pakke i Rancher

11 https://rancher.com/docs/rancher/v1.6/en/catalog/private-catalog/.

73

5.6 Oppsett av produksjonsmiljø – Amazon AWS

Amazon EC2

Med Rancher som plattform for administrering av konteinere kan man også sette opp ulike

miljøer. Alt som er omtalt i systembeskrivelsen så langt har vært for preprod-miljøet med

testdatabase. For å faktisk kjøre Avkastningsportal med konteinere i skyen måtte vi legge til

en EC2-instans fra Amazon AWS. Vi satt opp et nytt miljø i Rancher og brukte integrasjonen

mot Amazon EC2 for å sette opp instansen. Dette gjøres ved hjelp av en Access Key og en

Secret Key som genereres hos Amazon.

Figur 5-29 - Oppsett av EC2-host i Rancher

Når instansen er kjørende dukker EC2 opp som en egen host i Rancher under miljøet «Prod».

Vi brukte deretter vår egen Rancher-katalog for å publisere Avkastningsportal til Amazon, og

satt opp Janitor for å sørge for plassbesparelse i skyen.

74

Figur 5-30 - Ferdig oppsatt Avkastningsportal og Janitor i skyen hos Amazon.

Figur 5-31 - Kjørende EC2-instans hos Amazon

Amazon RDS

For å sørge for integriteten til databasen opprettet vi en databaseinstans ved hjelp av

tjenesten RDS (Relational Database Service). RDS tilbyr flere ulike typer database, og i vårt

tilfelle fortsatte vi å bruke MySQL. Avkastningsportal inneholder en rekke

databasemigreringer som det ville tatt mye tid å konfigurere på nytt dersom vi valgte en

annen databasetype. Vi anså det derfor som lite hensiktsmessig å bytte ut databasetypen

siden RDS tilbyr MySQL som løsning.

75

Figur 5-32 - Oppsett av database i RDS

Figur 5-33 - Valg av versjon i RDS

Når instansen til databasen var ferdig satt opp brukte vi MySQL Workbench for å legge inn

de nødvendige migreringene i databasen slik at den var klar til bruk. Vi satte også opp en

76

egen sikkerhetsgruppe til databasen slik at den kun tillot tilkoblinger fra sikkerhetsgruppen

som Avkastningsportal bruker i skyen. Etter at migreringene var på plass ble databasen

videre konfigurert til å ikke tillate tilkoblinger utenfra Amazon-miljøet. Med disse

sikkerhetsinnstillingene på plass vil det være svært krevende for utenforstående å få tilgang

til databasen. Vi anser derfor på dette punktet at dataintegriteten er ivaretatt. Konfigurerbar

backup av databasen fra Amazon sin side sørger også for at data ikke går tapt ved

uforutsette hendelser.

Figur 5-34 - Kjørende databaseinstans hos Amazon RDS

5.7 CI/CD-pipeline prosessbeskrivelse

Prosessflyt

Hvis alle prosessene til Drone kjører som de skal vil løsningen bygges, pakkes, publiseres til

Docker-registeret og til slutt legges ut som nye versjoner enten i preprod- eller

produksjonsmiljøet avhengig av hvilken branch på GitHub som ble endret.

77

Figur 5-35 - Feil under publisering til Docker-registeret

78

Figur 5-36 - Komplett kjøring av Drone med utplassering av Avkastningsportal i produksjon

Det vil være synlig i Rancher at containerne har blitt oppgradert. Fordelen med dette er at en

bruker kan gå inn i applikasjonen, enten i preprod eller produksjon, og bekrefte at den kjører

som forventet. Hvis applikasjonen ikke oppfører seg tilfredsstillende vil Rancher raskt kunne

avbryte oppdateringen og gå tilbake til forrige fungerende versjon. Hvis applikasjonen er

oppgradert riktig og kjører som forventet går man inn i Rancher og bekrefte dette slik at

gammel versjon fjernes og den nye settes ut i produksjon.

79

Figur 5-37 - Oppgraderte tjenester sett i Rancher

Drone - arbeidsoppgaver

Hvis vi ser tilbake på figur 5-35 kan vi se ni ulike trinn i prosessen til Drone:

1. Hent ut prosjektet fra GitHub («clone»)

2. Sett opp testdatabase for å kunne kjøre enhets- og integrasjonstester

3. Bygg prosjektet ved hjelp av Maven-plugin til Drone

4. Lag konteiner til Rapportering og legg den ut på vårt Docker-register ved hjelp av

Docker-plugin i Drone

5. Lag konteiner til Beregning og legg den ut på vårt Docker-register ved hjelp av

Docker-plugin i Drone

6. Lag konteiner til Renteimport og legg den ut på vårt Docker-register ved hjelp av

Docker-plugin i Drone

7. Legg ut oppgradert versjon av Rapportering i produksjon ved hjelp av Rancher-plugin

i Drone

8. Legg ut oppgradert versjon av Beregning i produksjon ved hjelp av Rancher-plugin i

Drone

9. Legg ut oppgradert versjon av Renteimport i produksjon ved hjelp av Rancher-plugin i

Drone

80

I stegene 4-6 får konteinerne i dette tilfellet versjonsnavn («tag») «latest». Dette er gjort for

å skille mellom preprod- og produksjonsversjoner. Tilsvarende versjonsnavn for en preprod-

versjon er «preprod».

I stegene 7-9 brukes det et sett med API-nøkler generert i Rancher for å kunne autorisere

Drone til å interagere med Rancher. Disse nøklene er unike for hvert miljø i Rancher og det

er derfor to sett med nøkler, ett for preprod og ett for produksjon. Disse nøklene er lagret

som secrets i Drone og er derfor ikke synlige for utenforstående selv om de får tak i

konfigurasjonsfilen til Drone. Alt som er synlig er referanser til variabler som

«rancher_access_key» og «rancher_secret_key». På denne måten er sikkerheten til

applikasjonen ivaretatt ved at Rancher ikke vil autorisere brukere uten disse nøklene.

Konfigurasjonen til Drone har satt inn betingede steg for å skille mellom preprod- og

produksjonsmiljøene. Dette sørger for at en utvikler ikke kan legge ut endringer i produksjon

uten at en leder har godkjent endringene i preprod. Dette har vi løst ved at de ulike stegene i

konfigurasjonsfilen til Drone har fått påsatt betingelser. Det betyr at konteinerne til preprod

kun vil bygges og legges ut dersom en utvikler pusher endringer til en egen branch på

GitHub, og at konteinerne til produksjon kun vil bygges og legges ut hos Amazon når en pull

request til master-branchen lages og godkjennes av en leder. I figur 5-35 er det

produksjonsvarianten som har kjørt som vi kan se ved at de siste seks stegene har navn som

«release» og «prod». Prosessen i figuren er altså startet automatisk i Drone ved at en pull

request mot master-branchen har blitt opprettet.

5.8 Testing

Kravspesifikasjonen beskriver at nyutviklet kode automatisk skal testes før integrasjon og

levering. Enhets- og integrasjonstestene kjøres under bygging av prosjektet. Utover disse har

ikke oppdragsgiver hatt ønsker om testing av løsningen. Vi har likevel fått tilgang til Kantegas

systemtester for brukergrensesnittet. Disse omhandlet blant annet testing av

innrapportering av data i forbindelse med administrasjonsmodulen. Denne modulen er ikke

en del av løsningen vi har jobbet med og utgikk derfor fra testplanen.

Vi har utført enhets- og integrasjonstester, systemtest for brukergrensesnitt og systemtest

for automasjon av av bygging, integrasjon og levering. Testrapport for disse med testplan

81

ligger vedlagt rapporten. Systemtest for automasjon har vi utviklet selv. Tester utviklet av

Kantega skal kjøres i forbindelse med endringer av Avkastningsportal for å påse at

endringene ikke har uønskede effekter på applikasjonens funksjonalitet. Enhetstestene

utlevert fra Kantega har dekningsgrad på 72% av kildekodens klasser og 48% av dets linjer,

men vi har ikke satt oss mål om å videreutvikle enhetstestene for å øke dekningsgraden

siden dette verken har vært et krav eller fokus i oppgaven.

Før endringer i Avkastningsportal settes i produksjon må enhetstester, integrasjonstester og

systemtest for brukergrensesnitt kjøres og bestå. Enhets- og integrasjonstestene kjøres av

Maven ved bygging av prosjektet gjennom vår automatiserte leveranse-pipeline. Siden

dekningsgraden av enhetstestene er lav er videre verifisering av produktet før

produksjonssetting avgjørende for å sikre systemet mot feil. Systemtest for

brukergrensesnittet må gjennomføres av teamleder med endringsrettigheter i

Avkastningsportals master-branch før endringer settes ut i produksjonsmiljøet. Dette for å

sikre at produksjonssatt applikasjon fungerer som den skal. Automatisering av systemtest er

en mulig videreutvikling av systemet og er beskrevet i systemevalueringen. I tillegg til å påse

at testene utføres bør teamleder gjøre en manuell kodegjennomgang. Dette blir i praksis

enklest om utviklere skriver utfyllende oppdateringsnotater12 over hva som er endret ved ny

kode slik at teamleder kan se over disse endringene.

5.9 Adresser til løsningene

Løsning Adresse Beskrivelse

Rancher (utviklingsmiljø) http://hp5.vlab.cs.hioa.no/ Rancher-installasjon brukt til

utvikling. Brukernavn og

passord er bachelorprosjekt

/ avkastningsportal

Avkastningsportal

(produksjon)

http://ec2-18-197-78-223.eu-

central-

1.compute.amazonaws.com:9

016/rapportering/

Produksjonssatt versjon hos

AWS

12 Her menes en “commit message” i Git.

82

Kopf (elasticsearch) http://hp5.vlab.cs.hioa.no:85/ Grensesnitt for elasticsearch

Kibana http://hp5.vlab.cs.hioa.no:92/ Grensesnitt for Kibana

Figur 5-38 – Tabell over adresser til utviklede løsninger

83

6 Evaluering

6.1 Evaluering av planlegging

Planlegging og estimering av hvordan prosjektet skulle utføres var en utfordrende oppgave.

Dette var på grunn av mange uklarheter om innholdet i oppgaven i starten av prosjektet.

Som et resultat av dette lagde vi overordnede arbeidsoppgaver som måtte utføres basert på

tidligere erfaringer og kunnskap tilegnet gjennom systemutviklingsfaget. Estimering var noe

vi fant vanskelig og vi ser i etterkant at vi har bommet ganske mye på estimeringen. Dette

gjelder både hvor lang tid det tar å utvikle de forskjellige delene av systemet og hvilke

arbeidsoppgaver vi måtte utføre. Endringer i krav, ansvarsområder og arbeidsoppgaver

gjorde at hvordan vi faktisk arbeidet og hvordan vi planla å løse prosjektet ikke stemte

overens. Planlagte arbeidsoppgaver som for eksempel omfattende testing av ikke-

funksjonelle krav ble ikke like aktuelt, mens tilrettelegging for automatisering ble en større

del av prosjektet. Prosjektet, slik det først ble presentert fra oppdragsgiver, var mindre i

omfang og omfattet kun tilrettelegging for flytting av løsningen til skyen. Vi brukte derfor

mye tid på å definere og utføre ekstraoppgaver til prosjektet. Dette påvirket ikke

planleggingen nevneverdig da vi har jobbet smidig gjennom hele prosjektperioden. I et

større prosjekt ville det muligens vært hensiktsmessig å gå tilbake til planleggingsfasen ved

endringer.

6.2 Evaluering av metodikk og arbeidsmetode

Prosjektgruppen har under arbeid med prosjektet forsøkt å benytte en smidig

utviklingsprosess for å utvikle løsningen med hyppige møter 1-2 ganger i uken. Dette har

fungert godt, og vi har jobbet iterativt for å løse de problemstillingene som kom frem under

utviklingen. På denne måten klarte vi å bryte ned store utfordringer til håndterlige

arbeidsoppgaver vi kunne løse.

Selv om vi har brukt en smidig tilnærming var det ytre faktorer som gjorde at vi ikke kunne

ha faste sprinter innenfor definerte tidsblokker. Påvente av tilgang til kildekode og

dokumentasjon, samt svar på tekniske spørsmål var de største faktorene som førte til noe

84

ventetid og påvirket progresjonen. Som et resultat av dette var det enkelte perioder med

noe kortere gruppemøter med mindre progresjon. Vi kunne hatt tettere kontakt med

veiledere både fra skolen og fra oppdragsgiver for å få mer hjelp underveis i prosjektet. Selv

om arbeidet har gått bra kunne problemstillinger blitt løst raskere dersom vi hadde utnyttet

disse ressursene bedre. Det må nevnes at vi til tider opplevde at det var vanskelig å få

teknisk veiledning ettersom ressurser både fra skole og oppdragsgiver har vært utilgjengelige

i perioder. Vi kunne også vært raskere til å få oversikt over hvilke teknologier og muligheter

som var aktuelle for å løse oppdraget. Som følge av dette har vi oppdaget konsepter og

aktuelle løsninger sent i prosjektet som ikke kunne implementeres på grunn av

tidsbegrensninger.

I utgangspunktet vurderte vi Scrum som arbeidsmetode, men det viste seg lite passende

med tanke på omfanget av læring og tilegning av kunnskap med temaer og konsepter vi ikke

hadde kjennskap til. Dette ville gjort det vanskelig å definere sprinter med konkrete

arbeidsoppgaver. Oppdragsgiver anbefalte oss å løse oppgavene mest mulig i plenum, som

var medvirkende årsak for å ikke benytte Scrum som arbeidsmetodikk. Prosjektgruppen

kunne vært flinkere til å dele opp problemstillingene til mindre oppgaver slik at vi kunne

brukt kanban mer aktivt.

Et problem ved arbeidsprosessen var tilgang til testmiljø for utvikling. Vi brukte først en

virtuell maskin tildelt fra OsloMet. Denne viste seg å ikke ha tilstrekkelig med ressurser og vi

valgte heller å leie vår egen VM fra DigitalOcean som kunne administreres slik vi selv ønsket.

Før vi byttet til DigitalOcean opplevde vi flere ganger å måtte be om ytterligere ressurser og

tilganger. Dette forsinket arbeidet og progresjonen unødig siden vi måtte vente på

tilbakemelding før den tekniske utviklingen kunne fortsette. Etter at vi byttet til DigitalOcean

var det ikke lenger problemer med administrasjon av utviklingsmiljøet.

6.3 Evaluering av prosjektgruppen

Som nevnt innledningsvis i sluttrapporten hadde ikke prosjektgruppen jobbet sammen

tidligere. Prosjektmedlemmene hadde derimot jobbet to og to sammen i grupper gjennom

mesteparten av bachelorgraden. Før arbeidet med oppgaven startet hadde vi flere

85

avklaringsmøter for å diskutere samarbeid, oppgavefordeling og kulturen rundt

møtevirksomhet. Under disse møtene ble det klart at prosjektgruppen tenkte forholdsvis likt

rundt disse temaene og det ble ikke oppdaget noen konflikter eller uenigheter rundt

arbeidsprosessen. Det dukket heller ikke opp noen problemer med samarbeidet etter hvert

som arbeidet med oppgaven kom i gang. Prosjektgruppen har samarbeidet godt gjennom

hele prosessen og ingen av medlemmene har uttrykt misnøye underveis.

6.4 Evaluering av løsningen

Oppnåelse av funksjonelle krav

Begge kravene er oppnådd gjennom bruken av Drone med webhooks mot GitHub. Ved hver

publisering av oppdatert kode blir CI/CD-prosessen kjørt og den oppdaterte løsningen blir

utplassert i preprod eller produksjon. Enhets- og integrasjonstester kjøres ved hver

oppdatering og Drone vil stoppe byggingen dersom noen av disse feiler.

Oppnåelse av ikke-funksjonelle krav

Secrets

Håndtering av secrets var et absolutt krav fra oppdragsgiver. I begynnelsen av prosjektet

gjaldt dette tilkoblingen til sftp-serveren hos Oslo Børs for uthenting av avkastningsdata.

Som nevnt i kravspesifikasjonen står det beskrevet at vi ikke skulle bruke denne serveren

allikevel. De gjenstående områdene hvor secrets ble benyttet i prosjektet er i integrasjon

mellom Drone og Rancher når nye versjoner av Avkastningsportal legges ut i preprod eller

produksjon. Secrets håndteres i dette tilfellet av Drone, hvor de er lagt inn slik at de

eksponeres som miljøvariabler og kun er tilgjengelige for Drone-konteinerne. Dersom

funksjonaliteten for å hente data fra Oslo Børs skulle implementeres ville det blitt løst på

samme måte i Rancher som tilbyr tilsvarende håndtering av secrets. Vi anser derfor kravet

oppfylt.

86

Pris

Pris falt bort som krav på grunn av applikasjonens beskjedne nettverkstrafikk og behov for

maskinvare.

Oppetid, stabilitet og sikkerhet

Vårt valg av skytjeneste sørger for god oppetid og stabilitet. Kravene anses som godt

oppnådd. Videre er preprod-miljøet sikret med HTTPS gjennom Let’s Encrypt for å forhindre

at utenforstående får tilgang til miljøet.

Integritet av data og sikkerhet i databasetilkobling

Bruk av Amazon RDS som databasetilbyder i produksjon har vist seg å være et godt valg.

Integriteten av data er opprettholdt ved at utenforstående ikke har tilgang til databasen og

sikkerheten i tilkobling til database er håndtert gjennom sikkerhetsgrupper i Amazon AWS.

Kravene anses som godt oppnådd.

Levetid på miljøet applikasjonen kjører i

Med Ubuntu LTS som operativsystem der Rancher-serveren kjører er levetiden ved hver

oppgradering av operativsystem fem år. Docker-versjoner er aldri støttet i mer enn et år av

gangen. Docker Enterprise Edition har utgivelser årlig og støttes dermed lengst. Vi måtte

bruke Docker Community Edition da det fra oppdragsgivers side ble bestemt at lisenser for

Docker Enterprise Edition ble for dyrt. Vi har valgt å bruke Docker CE Stable som har

utgivelser hver tredje måned over Docker CE Edge som har månedlige oppdateringer.

Miljøet er egnet for oppgraderinger gjennom pakkesystemet til Ubuntu. Kravet anses som

oppnådd.

Applikasjonens funksjonalitet

Ved bruk av system- og regresjonstester underveis i prosessen har vi kommet frem til at

applikasjonens funksjonalitet er, med begrensningene i prosjektoppgavens omfang tatt i

betraktning, godt ivaretatt. Alle funksjoner gruppen er kjent med virker likt som dagens

produksjonssatte Avkastningsportal. Kravet anses som oppfylt i sin helhet.

87

6.5 Forbedring og videreutvikling

Vi har under utviklingsprosessen fått en økt forståelse av infrastruktur, konteinerteknologi,

skytjenester og i retrospekt innsett at det er fremdeles muligheter for å ytterligere forbedre

løsningen. De umiddelbare forbedringene som vi kan identifisere er som følgende:

Optimalisering

Konteinerne som kjører selve Avkastningsportal kan optimaliseres for å bruke mindre minne

og diskplass. Dette kan gjøres ved å manuelt definere størrelsen på ressursene som blir

tildelt hver konteiner.

ELK

ELK-stack har mange muligheter for å gjøre overvåking av systemet brukervennlig, oversiktlig

og effektivt. Ideelt sett ønsket vi å konfigurere ELK-stack til å kunne hente og visualisere mer

data enn det vi fikk tid til. Konfigurasjon for henting av konteinerlogg, systemlogg og

nettverkslogger ville vært en naturlig forbedring i løsningen. Det ville også vært

hensiktsmessig å sentralisere data fra Log4J-rammeverket som allerede er implementert i

applikasjonen. Kibana gir muligheter for å utforme dashboards med aggregerte data fra

sentraliserte logger, noe som ville gitt brukervennlig monitorering i sanntid og innsikt i

systemets loggførte data.

Automasjon av systemtest

I løsningen vi har utviklet legges det opp til manuell systemtesting for brukerinteraksjoner på

grensesnittet til Avkastningsportal, og det er også lagd systemtest for hele

automasjonsprosessen. Det finnes muligheter for å automatisere disse testene med verktøy

som Selenium. Selenium kan utføre skriptede operasjoner på en nettleser med eksempelvis

museklikk, og teste resultat av handlinger mot forventet resultat.

Automasjon av tester kan være verdifullt og ressursbesparende for selskaper som driver

med hyppige leveranser og testdrevet utvikling. Dette er også en videre forbedring av

produktets kvalitetssikring siden testing foregår kontinuerlig og er konsistent. Automatiserte

88

systemtester er hensiktsmessige og noe vi ønsket å implementere for å redusere

mulighetene for menneskelige feil, men tidsbegrensninger gjorde at dette ikke ble utviklet.

Synkronisering av innrapportering

Ved videreutvikling av løsningen kunne det være aktuelt å implementere synkronisering av

databasen. Slik kan produksjonsdatabasen spiles mot databasen i løsningen vi har utviklet.

Dette kan gjøres ved å hente ut data fra eksisterende database ved nye innrapporteringer og

legge disse inn i vår database ved hjelp av en SOAP-basert webtjeneste.

89

7 Konklusjon

7.1 Læringsutbytte

Læringsutbyttet har vært verdifullt for samtlige medlemmer i prosjektgruppen, og vi sitter

igjen med kunnskap som er ettertraktet på arbeidsmarkedet. Læringsutbyttet oppsummeres

i listen under.

• Teori og praksis om arkitektur og infrastruktur for webapplikasjoner

• Utvikling og kvalitetssikring av digitale løsninger

• Kontinuerlig og effektiv leveranse av applikasjoner

• Bruk av skytjenester

• Konteinerteknologi og flytting av eksisterende løsninger til konteinere

• Verdien av prosjektstyringsverktøy og agile arbeidsmetoder

• Praktisk erfaring med fremtidsrettede teknologier

• Erfaring med arbeidslivet i et IT-selskap

7.2 Konklusjon

Gjennom løsningen vi har utviklet kjører Avkastningsportal problemfritt i skyen, og

hovedmålet med prosjektoppgaven er oppnådd. Videre har vi utvidet løsningen ved å legge

til elementer som har tilført tilleggsverdi for oppdragsgiver. Dette har hovedsakelig dreid seg

om tilretteleggelse for kontinuerlig integrasjon og levering gjennom automasjonsverktøyet

Drone. Konteinerisering av applikasjonen med Docker sikrer økt stabilitet, robusthet og

mindre ressursbruk. Konteinerne håndteres av Rancher som tar seg av administrering og

utplassering.

Alle kravene, både fra arbeidsgiver og de som er utarbeidet av prosjektgruppen, har blitt

oppfylt selv om det fremdeles er forbedringspotensiale ved løsningen. Verdien for

oppdragsgiver ligger i enklere arbeidsflyt og dermed besparelser i arbeidstid vedrørende

utvikling, vedlikehold og overvåking. Løsningen gir også oppdragsgiver grunnlag for å

vurdere om de skal flytte øvrige applikasjoner ut til skyen.

90

Tidsbegrensninger tillot oss dessverre ikke å ferdigstille hele løsningen slik vi ønsket. Vi kan

heller ikke med sikkerhet si hvordan en produksjonssatt versjon med reelle brukere ville

oppført seg siden dette ikke har vært en del av oppgaven.

Under prosjektperioden har vi tilegnet oss kunnskap med moderne teknologi og fått en

forsmak på hvordan bedrifter jobber i dag for å forbedre og effektivisere drift og vedlikehold

av webapplikasjoner.

91

8 Teknisk ordliste

Term Beskrivelse

Agil Fellesbegrep for smidige prosesser

Back-end Serverprogrammering hvor logikken i applikasjonen

ligger

Branch En kopi av kode i versjonshåndteringssystemet hvor

utviklere gjør sine endringer

Build/Bygging Bygging av applikasjoner

CD - Continuous Delivery Kontinuerlig levering er en utviklingspraksis

CI - Continuous Integration Kontinuerlig integrasjon er en utviklingspraksis

DevOps Developer and Operations

Front-end Klientprogrammering hvor funksjonalitet i et grensesnitt

ligger

FTP Protokoll for filoverføring

Host Server som inneholder applikasjon og kan aksesseres

over nettverk.

Image En statisk lesbar fil med kjørbar kode som mal for

oppsett av en konteiner

IP Internet Protocol, format for data som skal sendes over

et nettverk

Konteiner / Container En kjørende instans av et konteiner-image

Konteinerhåndteringsplattform System for å administrere containere og deres

utplassering

92

Linux Et UNIX-basert distrubusjonssystem basert på åpen

kildekode, utviklet av Linus Torvalds

Merging Sammenstilling av kode fra flere branches

Networking Prosessen med å lage eller bruke et datanettverk

Node En vertsmaskin eller knutepunkt i et nettverk hvor

kommunikasjonslinjer møtes og kobles sammen

Open source Åpen kildekode

Pipeline Et sett med ledd som data går igjennom

Preprod-miljø Et utviklingsmiljø som ligner så mye som mulig på en

produksjonssatt applikasjon. Dette benyttes som en test

før produksjon og er brukt for å teste versjoner som er

antatt klare for produksjonssetting.

Produksjonsmiljø Teknisk miljø hvor en ferdig produksjonssatt applikasjon

befinner seg

Pull Hente kode fra et versjonshåndteringssystem

Pull request Forespørsel om å legge inn endret kode i en annen

branch

Push Lagre kode i et versjonshåndteringssystem

Read-Only Rettigheter til å lese en fil, men ikke skrive til den

SOAP Meldingsprotokoll for dataoverføring i webtjenester

Stack Et sett med tjenester som henger sammen. Brukes i

Rancher for å strukturere løsninger

Utviklingsmiljø Et utviklingsmiljø med den infrastrukturen som trengs for

å utvikle applikasjoner

93

VM Virtuell maskin

Webapplikasjon Applikasjon kjørende på internett som nås via nettleser

Figur 8-1 - Tabell med teknisk ordliste

94

9 Referanser

Amazon Web Services. (2017). Introducing AWS Fargate – Run Containers without Managing

Infrastructure | Amazon Web Services. Hentet fra

https://aws.amazon.com/blogs/aws/aws-fargate/

Apache Maven Project. (2018). Maven - Introduction. Hentet fra

https://maven.apache.org/what-is-maven.html

Atlassian. (udatert). What is DevOps? Hentet fra https://www.atlassian.com/devops

Chakraborty, S. (2017). ELK Stack Tutorial with Example - HowToDoInJava. Hentet fra

https://howtodoinjava.com/microservices/elk-stack-tutorial-example/

Chhajed, S. (2015). Learning ELK Stack. Packt Publishing Ltd. Hentet fra

https://books.google.no/books?hl=en&lr=&id=EfqoCwAAQBAJ&oi=fnd&pg=PP1&dq=

elk+stach+buisness+intelligence&ots=lPF0oUfHB3&sig=BdH6xSmKuupbKHtV26H7xjiU

1ww&redir_esc=y#v=onepage&q=buisness&f=false

Christner, B. (2015). Docker Image Size Comparison [Bilde]. Hentet fra

https://www.brianchristner.io/docker-image-base-os-size-comparison/

Chugh, S. (2018). DigitalOcean vs AWS EC2: 8 Factors to Decide Who’s the Winner?

ServerGuy.com. Hentet fra https://serverguy.com/comparison/digitalocean-vs-aws-

ec2/

Codemy School. (2016). Docker: An introduction to Rancher [Videoklipp]. Hentet fra

https://www.youtube.com/watch?v=C8H0TdLB2aA&index=10&list=PLjQo0sojbbxViG

EbI_87SPXpb3neuVqDL

DashBouquet. (2017, 4. oktober). AWS vs. DigitalOcean: Which Cloud Server is Better. Hentet

fra https://hackernoon.com/aws-vs-digitalocean-which-cloud-server-is-better-

1386499a6664

Docker. (2018). Docker Documentation [Bilde]. Hentet fra

https://docs.docker.com/engine/docker-overview/#the-docker-daemon

95

Docker. (2018). Docker Documentation. Hentet fra

https://docs.docker.com/engine/security/security/#conclusions

Drone Continuous Delivery. (2018). Drone IO: Installation Overview. Hentet fra

http://docs.drone.io/installation/

Ebert, C., Gallardo, G., Hernantes, J., & Serrano, N. (2016). DevOps. IEEE Software, 33(3), (ss.

94–100). https://doi.org/10.1109/MS.2016.68

EU GDPR Information Portal. (2018). EU GDPR Portal. Hentet fra https://www.eugdpr.org/

Hollander, R. (2018). The global cloud market jumped 46% in Q4. Hentet fra

http://www.businessinsider.com/global-cloud-market-q4-2018-2

Jabbari, R., bin Ali, N., Petersen, K., & Tanveer, B. (2016). What is DevOps?: A Systematic

Mapping Study on Definitions and Practices. In Proceedings of the Scientific Workshop

Proceedings of XP2016 (ss. 12:1–12:11). New York, NY, USA: ACM.

https://doi.org/10.1145/2962695.2962707

Jaramillo, D., Nguyen, D. V., & Smart, R. (2016, mars). Leveraging microservices architecture

by using Docker technology. In SoutheastCon, 2016 (ss. 1-5). IEEE.

Kantega AS. (udatert). Hvem er vi. Hentet fra https://www.kantega.no/hvemervi/

Kavis, M. J. (2014). Architecting the Cloud: Design Decisions for Cloud Computing Service

Models (SaaS, PaaS, and IaaS). Somerset, UNITED STATES: John Wiley & Sons,

Incorporated. Hentet fra

http://ebookcentral.proquest.com/lib/hioa/detail.action?docID=1605593

Khan, A. (2017). Key Characteristics of a Container Orchestration Platform to Enable a

Modern Application. IEEE Cloud Computing, 4(5), (ss. 42-48).

LeanKit. (2018, 2. mai). What is Kanban? Hentet fra https://leankit.com/learn/kanban/what-

is-kanban/

Lean Communications. (udatert). Hva er Lean. Hentet fra

https://www.leancommunications.no/om-oss/hva-er-lean/

96

Lwakatare, L. E., Kuvaja, P., & Oivo, M. (2016). Relationship of DevOps to Agile, Lean and

Continuous Deployment. In Product-Focused Software Process Improvement (ss. 399–

415). Springer, Cham. https://doi.org/10.1007/978-3-319-49094-6_27

MacLaughlin, K., Sullivan, M. (2017, mars) How AWS Stacks Up Against Rivals on Downtime.

Hentet fra https://www.theinformation.com/articles/how-aws-stacks-up-against-

rivals-on-downtime

Malav, B. (2017, 16. desember). Microservices vs Monolithic architecture. Hentet fra

https://medium.com/startlovingyourself/microservices-vs-monolithic-architecture-

c8df91f16bb4

Manifesto for Agile Software Development. (udatert). Hentet fra http://agilemanifesto.org/

Microsoft. (2017). Overview of Service Fabric on Azure. Hentet fra

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview

Pahl, C. (2015). Containerization and the Paas cloud. IEEE Cloud Computing, 2(3) (ss. 24-31).

Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit:

An Agile Toolkit. Addison-Wesley. Hentet fra

https://books.google.no/books?id=IJ1gAgAAQBAJ

Preeth, E. N., Mulerickal, F. J. P., Paul, B., & Sastri, Y. (2015, november). Evaluation of Docker

containers based on hardware utilization. In Control Communication & Computing

India (ICCC), 2015 International Conference on (ss. 697-700). IEEE.

Rancher Labs. (2018). CICD Debates: Drone vs Jenkins. Hentet fra

https://rancher.com/drone-vs-jenkins/

Rightscale.com. (2017). Cloud Computing Trends: 2017 State of the Cloud Survey. Hentet fra

https://www.rightscale.com/blog/cloud-industry-insights/cloud-computing-trends-

2017-state-cloud-survey

Rosenfeld, L., Morville, P., & Arango, J. (2015). Information architecture: for the web and

beyond. Sebastopol (CA): O’Reilly Media.

97

RHD Blog. (2017). Continuous Integration: A "Typical" Process - RHD Blog. Hentet fra

https://developers.redhat.com/blog/2017/09/06/continuous-integration-a-typical-

process

Sala-Zárate, M., & Colombo-Mendoza, L. (2012). CLOUD COMPUTING: A REVIEW OF PAAS,

IAAS, SAAS SERVICES AND PROVIDERS. Lámpsakos, 0(7) (ss. 47-57). Hentet fra

http://www.funlam.edu.co/revistas/index.php/lampsakos/article/view/844/811

Scheepers, M. J. (2014, juni). Virtualization and containerization of application

infrastructure: A comparison. In 21st Twente Student Conference on IT (Vol. 21).

Selenium. (2018). Introduction — Selenium Documentation. Hentet fra

https://www.seleniumhq.org/docs/01_introducing_selenium.jsp

Sneha S.K. (2018). What is Jenkins? - Vmokshagroup.com. Hentet fra

https://vmokshagroup.com/blog/what-is-jenkins/

Taipale, O., Kasurinen, J., Karhu, K., & Smolander, K. (2011). Trade-off between automated

and manual software testing. International Journal of System Assurance Engineering

and Management, 2(2) (ss. 114–125). https://doi.org/10.1007/s13198-011-0065-6

Techopedia. (udatert). What is a Single Point of Failure (SPOF)? - Definition from Techopedia.

(udatert). Hentet fra https://www.techopedia.com/definition/4351/single-point-of-

failure-spof

Utley, G. (2018, april). Microsoft Azure vs. AWS – How They Stack Up in 2018. Hentet fra

https://www.cwps.com/blog/microsoft-azure-vs.-aws-how-they-stack-up-in-2018

Wallen J. (2013). 10 benefits of virtualization in the data center. - TechRepublic.com. Hentet

fra https://www.techrepublic.com/blog/10-things/10-benefits-of-virtualization-in-

the-data-center/

98

10 Vedlegg 1 - Konfigurasjonsoppsett

10.1 Versjoner brukt i prosjektet

• Docker 17.12

• Rancher 1.16.14

10.2 Oppsett

• Installer Docker via hjelpescript fra Rancher:

$ curl https://releases.rancher.com/install-docker/17.12.sh |sh

• Installer Rancher-serveren via Docker:

$ sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server:stable

• Vent et par minutter og gå til http://localhost:8080 for å få opp Rancher-serveren.

Når serveren er i gang er første steg å legge til en host

• Gå tilbake til Rancher og velg “Add Host”. Legg til IP til ønsket maskin som skal være

Rancher host. Denne vil bli lagt til i Rancher og kjøre de konteinerne som den

skeduleres for

Figur 10-1 - Inntasting av ip-adresse for Rancher host

• Til slutt kopierer du ut kommandoen fra steg 5 og kjør den i terminal. Etter et par

minutter vil ny host dukke opp i Rancher

99

Konfigurasjon av Docker

Scriptene runBeregning.sh og runRenteimport.sh må kopieres inn og tilpasses

mappestruktur og filsystem for å kjøre tjenestene på rett måte. Renteimport vil som før

trenge renteimport-spring.properties med informasjon om sftp-server hos Oslo Børs.

Renteimport og beregning har også definert en log4j.xml-fil i sine oppstartsscripts. Et

eksempel på denne ligger nederst i dette avsnittet

Rapportering

Dockerfile

FROM anapsix/alpine-java

COPY Rapportering/target/rapportering-jetty-console.war

/home/avkastning

COPY config/src/main/resources/avkastning.properties

/home/avkastning

Bygging og pakking

sudo docker build -t rapportering .

sudo docker tag rapportering <docker-registry-

url>/rapportering

sudo docker push <docker-registry-url>/rapportering

Beregning

Dockerfile

FROM anapsix/alpine-java

COPY beregning-2.3-SNAPSHOT.jar /home/beregning/

COPY avkastning.properties /home/beregning/

COPY runBeregning.sh /home/beregning/

Bygging og pakking

sudo docker build -t beregning .

sudo docker tag beregning <docker-registry-url>/beregning

Sudo docker push <docker-registry-url>/beregning

Renteimport

Dockerfile

100

FROM anapsix/alpine-java

COPY renteimport-2.3-SNAPSHOT-exec.jar /home/renteimport/

COPY avkastning.properties /home/renteimport/

COPY runRenteimport.sh /home/renteimport/

COPY log4j.xml /home/renteimport/

Bygging og pakking

sudo docker build -t renteimport .

sudo docker tag renteimport <docker-registry-url>/renteimport

Sudo docker push <docker-registry-url>/renteimport

Log4j.xml

Denne logger til konsoll med debug og er grei å bruke til testing:

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration debug="true"

xmlns:log4j='http://jakarta.apache.org/log4j/'>

<appender name="console"

class="org.apache.log4j.ConsoleAppender">

<layout class="org.apache.log4j.PatternLayout">

<param name="ConversionPattern"

value="%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n"

/>

</layout>

</appender>

<root>

<level value="DEBUG" />

<appender-ref ref="console" />

</root>

</log4j:configuration>

Logging til både konsoll og fil med loggnivå INFO:

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration debug="true"

xmlns:log4j='http://jakarta.apache.org/log4j/'>

<appender name="console"

class="org.apache.log4j.ConsoleAppender">

<layout class="org.apache.log4j.PatternLayout">

<param name="ConversionPattern"

101

value="%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L -

%m%n" />

</layout>

</appender>

<appender name="file"

class="org.apache.log4j.RollingFileAppender">

<param name="append" value="false" />

<param name="maxFileSize" value="10MB" />

<param name="maxBackupIndex" value="10" />

<param name="file" value="applikasjonsnavn.log" />

<layout class="org.apache.log4j.PatternLayout">

<param name="ConversionPattern"

value="%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L -

%m%n" />

</layout>

</appender>

<root>

<level value="INFO" />

<appender-ref ref="console" />

<appender-ref ref="file" />

</root>

</log4j:configuration>

Konfigurasjon av Rancher

Avkastningsportal-stack - lokalt og preprod-miljø

1. Det må opprettes en stack i rancher for å samle tjenestene. Velg “Add stack” fra

hovedsiden. Alle stegene i denne seksjonen legges til som nye services under samme

stack

2. For å kjøre Avkastningsportal lokalt og i preprod-miljøet opprettes en

databasecontainer. Konfigurasjonen av denne er lagd for å ligne så mye som mulig på

slik databasen til dagens Avkastningsportal er satt opp, og dette beskrives i større

detalj lenger ned

3. En tjeneste for Rapportering ble definert. Denne ble i Rancher linket sammen med

mysql-tjenesten og har startkommandoen ‘java -jar /home/avkastning/rapportering-

jetty-console.war --headless --forwarded --port 9016 --contextPath /rapportering’.

Porten en brukt for testing og må endres når før produksjonssetting Videre ble det i

Rancher definert en miljøvariabel for å få inn en nødvendig konfigurasjonsfil slik:

102

variabel ‘AV_ENV’ med verdien ’file:/home/avkastning/avkastning.properties’. Vi har

brukt versjonsnavn “latest” for konteinerne som brukes i preprod/staging.

Figur 10-2 - Oppsett for Rapportering i preprod

4. Når tjenestene linkes sammen i Rancher vil man kunne bruke navnet på linken som

adresse til databasen. I vårt tilfelle heter linken “avkastning-db”, og for å få

tjenestene til å kommunisere sammen endres konfigurasjonsfilen

avkastning.properties til å peke på “avkastning-db:3306” som adresse til databasen.

5. Tilsvarende oppsett ble gjort for beregning og renteimport. Startkommandoene er

like, men tjenestene er satt opp til å kun kjøre på kommando ved å gå inn i Rancher.

Dette står i motsetning til rapportering som kjører hele tiden.

Figur 10-3 - Ferdig oppsatt stack for Avkastningsportal lokalt og preprod

103

Eksportert konfigurasjon fra Rancher

Rancher-compose.yml:

version: '2'

services:

database:

scale: 1

start_on_create: true

rapportering:

scale: 1

start_on_create: true

renteimport:

scale: 1

start_on_create: true

beregning:

scale: 1

start_on_create: true

Docker-compose.yml:

version: '2'

services:

database:

image: <docker-registry-url>/avkastning-drone-db:latest

environment:

MYSQL_ROOT_PASSWORD: <ønsket databasepassord>

stdin_open: true

tty: true

labels:

io.rancher.container.pull_image: always

rapportering:

image: <docker-registry-url>/rapportering:latest

environment:

AV_ENV: file:/opt/rapportering/avkastning.properties

stdin_open: true

tty: true

links:

- database:avkastning-db

labels:

io.rancher.container.pull_image: always

renteimport:

image: <docker-registry-url>/renteimport:latest

environment:

AV_ENV: file:/opt/renteimport/avkastning.properties

stdin_open: true

tty: true

links:

- database:avkastning-db

labels:

io.rancher.container.pull_image: always

104

io.rancher.container.start_once: 'true'

beregning:

image: <docker-registry-url>/beregning:latest

environment:

AV_ENV: file:/opt/beregning/avkastning.properties

stdin_open: true

tty: true

links:

- database:avkastning-db

labels:

io.rancher.container.pull_image: always

io.rancher.container.start_once: 'true'

Avkastningsportal-stack - produksjonsmiljø

Stacken opprettes på samme måte som over. I vårt tilfelle lagde vi et eget Rancher

environment kalt “prod” hvor vår Amazon EC2-instans er lagt til som eneste host. Databasen

er en RDS-instans fra amazon og det blir derfor ingen databasekonteiner i stacken. Vi har

brukt en avkastningPROD.properties-fil for å legge inn jdbc-adressen slik som det er gjort fra

før i vår utleverte versjon av Avkastningsportal.

Når servicene blir lagt til har de hos oss fått versjon “prod” av de ulike Docker-image’ene i

vårt registry. Hva man kaller versjonene for kan bestemmes i konfigurasjonen til Drone.

Figur 10-4 - Oppsett for rapportering i produksjon

105

Figur 10-5 - Ferdig oppsatt stack for Avkastningsportal i produksjon

Eksportert konfigurasjon fra Rancher

Rancher-compose.yml:

version: '2'

services:

rapportering:

scale: 1

start_on_create: true

renteimport:

scale: 1

start_on_create: true

beregning:

scale: 1

start_on_create: true

Docker-compose.yml:

version: '2'

services:

rapportering:

image: <docker-registry-url>/rapportering:prod

environment:

AV_ENV: file:/opt/rapportering/avkastningPROD.properties

stdin_open: true

tty: true

ports:

- 9016:9016/tcp

labels:

106

io.rancher.container.pull_image: always

renteimport:

image: <docker-registry-url>/renteimport:prod

environment:

AV_ENV: file:/opt/renteimport/avkastningPROD.properties

stdin_open: true

tty: true

labels:

io.rancher.container.pull_image: always

io.rancher.container.start_once: 'true'

beregning:

image: <docker-registry-url>/beregning:prod

environment:

AV_ENV: file:/opt/beregning/avkastningPROD.properties

stdin_open: true

tty: true

labels:

io.rancher.container.pull_image: always

io.rancher.container.start_once: 'true'

Tjenester i Rancher

Janitor

Janitor brukes for å frigi diskplass. Den virker ved å slette gamle ubrukte docker images som

ikke lenger er i bruk. For å sørge for at den ikke sletter ting som er i bruk har vi satt den opp

til å ikke slette konteinere under noen omstendigheter. Dette er nødvendig fordi to av

modulene i Avkastnings-stacken kun kommer til å kjøre på faste tider ved bruk av en

scheduler. I andre tilfeller slik som oppsett av Drone er det konteinere som kun oppretter

datavolum, og disse vil også kun kjøre første gang Drone settes opp. Disse ville ha blitt slettet

av Janitor hvis den var konfigurert til å fjerne alt som ikke var i bruk. Ved å bruke

standardinnstillingen kjører Janitor en gang i timen og beholder alle konteinere, og kun

ubrukte docker images blir fjernet.

107

Figur 10-6 - Janitor stack fra Rancher Community Catalog

Figur 10-7 - Konfigurasjon av Janitor

Oppsett av Drone CI

For å knytte Drone opp mot GitHub måtte det først opprettes en OAuth-applikasjon inne på

GitHub. Oppsettet for denne ser på VM-en vi fikk fra HiOA slik ut:

108

Figur 10-8 - Definisjon av GitHub OAuth-applikasjonen

109

Dette oppsettet spesifiseres når man legger til Drone stack på Rancher, og det er da Client ID

og Client Secret som må defineres. Videre ble port 8000 valgt til Drone.

Endelig oppsett av en Drone stack kan se slik ut:

Figur 10-9 - Oppsett av Drone stack i Rancher

Figur 10-10 - Ferdig utplassering av Drone stack i Rancher

110

Oppsett for å kjøre CI/CD med Drone CI

Drone ble satt opp til å kjøre en konteiner med MySQL for å forenkle testingen. For at dette

skulle fungere var det nødvendig å gjøre følgende:

Det ble opprettet en egen avkastningDRONE.properties for å kjøre i test og preprod/staging.

Kun første verdi i filen er endret slik:

avkastning.database.mysql.hostname=avkastning-db

I Drone-konfigurasjonsfilen vist under (.drone.yml) er databasen satt opp som en tjeneste

(service). Navnet på denne tjenesten, i vårt tilfelle “database”, vil også virke som et

hostname inne i konteinere Drone setter opp, og det er derfor endringen i

avkastningDRONE.properties er nødvendig.

Konfigurasjon av API keys i Rancher

For å oppdatere applikasjonen i Rancher etter at de bygges i Drone er det nødvendig å sette

opp API-nøkler som Drone bruker for å kommunisere med Rancher. Dette gjøres fra Rancher

sin meny. Første steg er å velge riktig environment i Rancher, altså preprod/staging eller

prod avhengig av hvilke nøkler man skal sette opp. Dette må gjøres for begge miljøene for at

Drone skal kunne oppdatere tjenestene.

Figur 10-11 - Menyvalg for å lage API-nøkler i Rancher

Inne på denne siden velges “Advanced options” og så “Add Environment API Key”. Det lages

så en access key og en secret key som oppføres som secrets inne i Drone og senere refereres

i konfigurasjonsfilen til Drone som beskrives i neste kapittel. Man må også notere seg

Endpoint-adressen til rancher. Denne er unik for hvert environment man har lagd og må

111

også refereres til i Drone-konfigurasjonsfilen. I vårt tilfelle har vi brukt versjon 1 av

endpointet siden versjon 2 står listet som en beta-versjon.

Oppsett av webhooks og secrets i Drone CI

Første gang man går inn i Drone vil man redirectes til GitHub eller tilsvarende der hvor

OAuth-applikasjonen ble satt opp. Man logger så inn og bekrefter at man vil bruke OAuth-

applikasjonen. Etter at dette er gjort vil Drone få oversikt over repository-ene og man velger

det som skal brukes til bygging av prosjektet. Etter at dette er gjort kan man sette opp

nødvendige webhooks i Drone og disse blir så automatisk lagt til hos GitHub eller annen Git-

løsning.

Figur 10-12 - Menyen i Drone

Figur 10-13 - Menyvalg for innstillinger

I vårt tilfelle bruker vi “push” som webhook. Tanken er at det kun er en teamleder som har

tilgang til å pushe til master, og at de andre som jobber på prosjektet bruker sin egen feature

branch. Når en utvikler pusher til sin feature branch vil Drone kjøre en CI/CD-pipeline og

legge ut nye versjoner i preprod/staging. Når teamleder til slutt godkjenner en pull request

til master vil Drone legge ut endelige versjoner i produksjon. Hvordan dette settes opp

beskrives i neste kapittel.

112

Figur 10-14 - Oppsett av webhooks i Drone

For å legge inn secrets i Drone går man tilbake til menyen øverst til høyre og velger Secrets.

Det er viktig at man bruker riktig navn på secrets da disse oppdages automatisk av plugins til

Drone. Hva som er riktig navn finner man i plugin-dokumentasjonen på

http://plugins.drone.io/. I vårt tilfelle trenger vi secrets til Rancher-pluginen som er ansvarlig

for å oppdatere tjenestene for både preprod/staging og for produksjon. Riktig navn på

secrets er “rancher_access_key” og “rancher_secret_key”, og dette er API-nøklene som ble

lagd i forrige kapittel. Siden vi bruker Rancher-pluginen både til preprod/staging og til

produksjon må vi gi et annet navn til produksjonsnøklene, og disse kan i konfigurasjonsfilen

til Drone refereres til ved et annet navn. Dette beskrives i neste kapittel.

Figur 10-15 - Ferdig oppsett av nødvendige secrets i Drone

113

Konfigurasjonsfil til Drone CI

Konfigurasjonsfilen som vises under inneholder all nødvendig konfigurasjon for både

preprod og for produksjon.

Filen er delt inn i seksjonene “pipeline” og “service”. I seksjonen “pipeline” ligger alle

stegene i rekkefølge slik Drone vil kjøre dem når prosjektet skal bygges og deployes i skyen.

Steg 1 - build

Dette steget bruker Drone sin maven-plugin for å bygge prosjektet. Til slutt kjøres filen

buildProjects.sh for å gjøre klar filene som trengs til å bygge de tre ulike docker images.

Dette scriptet er beskrevet lengre ned under overskriften “buildProjects.sh”.

Stegene 2-4 - bygg containere til preprod

Disse stegene bruker Drone sin docker plugin for å bygge docker images av hver av de tre

modulene som ble ferdigstilt i steg 1. Legg merke til siste del av hvert steg, hvor betingelsen

for hvilken git branch det skal bygges fra defineres. Siden preprod -containerne kun skal

bygges fra branches som ikke er master er denne betingelsen satt på, og disse tre stegene vil

derfor kun kjøres når det utvikles i en feature branch. I stegene er det også bestemt at de

ferdigstilte docker images skal ha tag “latest”, slik som ble beskrevet tidligere under

overskriften “Avkastningsportal-stack - lokalt og preprod/staging-miljø”.

Stegene 5-7 - bygg containere til produksjon

Disse stegene er like som de tre forrige, bortsett fra at begrensningen er satt til at de kun

skal kjøres dersom man pusher til master. Docker-image’ene som bygges her vil få tag-en

“prod”, og blir derfor liggende i vårt docker registry som separate versjoner fra de som

bygges til bruk i preprod/staging. Slik sørger vi for å skille mellom de ulike versjonene av

modulene når vi i de siste stegene definerer hvilke versjoner som skal brukes hvor.

Stegene 8-10 - legg ut nye versjoner i Rancher for preprod/staging

Nå benytter vi oss av Drone sin Rancher-plugin. Denne lar oss integrere med Rancher-

installasjonen og vi kan definere hvilken stack og hvilke services som skal oppgraderes. Likt

som i de to forrige overskriftene er betingelsen om at branch på git ikke skal være master til

stede. Vi refererer så til API-nøklene til rancher som vi la til som secrets i forrige kapittel.

114

Stegene 11-13 - legg ut nye versjoner i Rancher for produksjon

Disse stegene er like som de forrige, bortsett fra at betingelsen om git branch nå er satt til å

kun gjelde for master. Videre må vi referere til secrets på en annen måte siden de nå ikke

har default navn slik som Rancher plugin forventer. Her benytter vi oss av source/target-

konvensjonen til Drone ved å si at nøkkelen som heter “rancher_access_key_prod” skal

brukes som pluginen sin forventede nøkkel “rancher_access_key”, og det samme gjelder for

secret key.

.drone.yml:

pipeline: build: image: maven:3.5.3-jdk-8

commands: - export

AV_ENV=file:/drone/src/github.com/akingdon/Avkastning/config/s

rc/main/resources/avkastningDRONE.properties - mvn clean install -B -

Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4

jMavenTransferListener=warn

- chmod 755 buildProjects.sh - ./buildProjects.sh

rapportering-container-latest:

image: plugins/docker repo: <docker-registry-url>:<docker-registry-

port>/rapportering registry: <docker-registry-url>:<docker-registry-port>

tag: latest dockerfile: /drone/containers/rapportering/Dockerfile context: /drone/containers/rapportering/

debug: true launch_debug: true storage_driver: overlay insecure: true

when: branch: exclude: master beregning-container-latest:

image: plugins/docker repo: <docker-registry-url>:<docker-registry-

port>/beregning

registry: <docker-registry-url>:<docker-registry-port> tag: latest dockerfile: /drone/containers/beregning/Dockerfile context: /drone/containers/beregning/

115

insecure: true

when: branch: exclude: master

renteimport-container-latest: image: plugins/docker repo: <docker-registry-url>:<docker-registry-

port>/renteimport

registry: <docker-registry-url>:<docker-registry-port> tag: latest dockerfile: /drone/containers/renteimport/Dockerfile

context: /drone/containers/renteimport/ insecure: true when: branch:

exclude: master

rapportering-container-release: image: plugins/docker repo: <docker-registry-url>:<docker-registry-

port>rapportering registry: <docker-registry-url>:<docker-registry-port> tag: prod

dockerfile: /drone/containers/rapportering/Dockerfile context: /drone/containers/rapportering/ insecure: true when:

branch: master beregning-container-release: image: plugins/docker

repo: <docker-registry-url>:<docker-registry-

port>/beregning registry: <docker-registry-url>:<docker-registry-port> tag: prod

dockerfile: /drone/containers/beregning/Dockerfile context: /drone/containers/beregning/ insecure: true

when: branch: master renteimport-container-release: image: plugins/docker

repo: <docker-registry-url>:<docker-registry-

port>/renteimport registry: <docker-registry-url>:<docker-registry-port>

tag: prod dockerfile: /drone/containers/renteimport/Dockerfile context: /drone/containers/renteimport/ insecure: true

when: branch: master

116

rapportering-rancher-preprod:

image: peloton/drone-rancher url: https://<rancher-url>/v1/projects/1a5 secrets: [ rancher_access_key, rancher_secret_key ]

service: avkastningsportal/rapportering docker_image: <docker-registry-url>:<docker-registry-

port>/rapportering:latest when:

branch: exclude: master beregning-rancher-preprod:

image: peloton/drone-rancher url: https://<rancher-url>/v1/projects/1a5 secrets: [ rancher_access_key, rancher_secret_key ] service: avkastningsportal/beregning

docker_image: <docker-registry-url>:<docker-registry-

port>/beregning:latest when: branch:

exclude: master renteimport-rancher-preprod: image: peloton/drone-rancher

url: https://<rancher-url>/v1/projects/1a5 secrets: [ rancher_access_key, rancher_secret_key ] service: avkastningsportal/renteimport docker_image: <docker-registry-url>:<docker-registry-

port>/renteimport:latest when: branch:

exclude: master

rapportering-rancher-prod: image: peloton/drone-rancher url: https://<rancher-url>/v1/projects/1a25

secrets: - source: rancher_access_key_prod target: rancher_access_key

- source: rancher_secret_key_prod target: rancher_secret_key service: avkastningsportal/rapportering docker_image: <docker-registry-url>:<docker-registry-

port>/rapportering:prod when: branch: master

beregning-rancher-prod: image: peloton/drone-rancher url: https://<rancher-url>/v1/projects/1a25 secrets:

- source: rancher_access_key_prod target: rancher_access_key - source: rancher_secret_key_prod

117

target: rancher_secret_key

service: avkastningsportal/beregning docker_image: <docker-registry-url>:<docker-registry-

port>/beregning:prod

when: branch: master renteimport-rancher-prod: image: peloton/drone-rancher

url: https://<rancher-url>/v1/projects/1a25 secrets: - source: rancher_access_key_prod

target: rancher_access_key - source: rancher_secret_key_prod target: rancher_secret_key service: avkastningsportal/renteimport

docker_image: <docker-registry-url>:<docker-registry-

port>/renteimport:prod when: branch: master

services: database: image: <docker-registry-url>:<docker-registry-

port>/avkastning-drone-db environment: - MYSQL_ROOT_PASSWORD=***

118

Etter at Drone har kjørt CI-prosessen ser sluttrapporten slik ut:

Figur 10-16 - Fullført kjøring av Drone for preprod

119

Figur 10-17 - Oppgradert stack i Rancher etter at Drone er ferdig

buildProjects.sh:

Dette scriptet er ansvarlig for å kopiere nødvendige filer til undermapper i prosjektet slik at

containerne kan oppdatere seg. For hver av de tre modulene i Avkastningsportal kopierer

scriptet ut en kjørbar .jar- eller .war-fil sammen med nødvendige konfigurasjonsfiler inn i

hver sin undermappe. Dette er et ledd i prosessen for at Drone skal kunne kjøre docker-

pluginen sin. Denne pluginen bygger opp nye docker images og legger de ut på vårt eget

registry. Scriptet er kopiert inn under:

#!/bin/bash

avkastning_home=/drone/src/github.com/akingdon/Avkastning/

container_home_directory=/drone/containers

mkdir -p $container_home_directory

properties=config/src/main/resources/avkastning.properties

rapportering_container_directory=$container_home_directory/rap

portering

mkdir -p $rapportering_container_directory

cp $avkastning_home/Rapportering/target/rapportering-jetty-

console.war $rapportering_container_directory

cp $properties $rapportering_container_directory

cp $avkastning_home/Rapportering/Dockerfile

$rapportering_container_directory

cd $rapportering_container_directory

cd $avkastning_home

beregning_container_directory=$container_home_directory/beregn

ing

mkdir -p $beregning_container_directory

120

cp $avkastning_home/beregning/target/beregning-2.3-

SNAPSHOT.jar $beregning_container_directory

cp $properties $beregning_container_directory

cp $avkastning_home/beregning/runBeregning.sh

$beregning_container_directory

cp $avkastning_home/beregning/log4j.xml

$beregning_container_directory

cp $avkastning_home/beregning/Dockerfile

$beregning_container_directory

cd $beregning_container_directory

cd $avkastning_home

renteimport_container_directory=$container_home_directory/rent

eimport

mkdir -p $renteimport_container_directory

cp $avkastning_home/valutaimport/target/renteimport-2.3-

SNAPSHOT-exec.jar $renteimport_container_directory

cp $properties $renteimport_container_directory

cp $avkastning_home/valutaimport/runRenteimport.sh

$renteimport_container_directory

cp $avkastning_home/valutaimport/log4j.xml

$renteimport_container_directory

cp $avkastning_home/valutaimport/Dockerfile

$renteimport_container_directory

Egendefinert MySQL-container

Vi opprettet et egendefinert MySQL container image for å legge inn testdata i databasen, og

dette la vi ut på vårt eget Docker-registry. Denne databasen brukes kun i preprod/staging, og

i produksjon er databasen satt opp med Amazon sin egen databasetjeneste RDS som sørger

for ukentlig backup og vedlikehold. Grunnen til dette valget er at containerisert database er

mer sårbar, og hvis den blir slettet vil all data forsvinne samtidig. Amazon sin egen

databasetjeneste tar hånd om disse problemene automatisk og tilbyr også ulike

sikkerhetsinnstillinger som er vanskelige å implementere i en container.

Det ligger også ved en databasekonfigurasjon for å sette MySQL til å ignorere case sensitivity

i tabellnavn. Dette er tatt inn som en migrering i databaseoppsettet til Avkastningsportal,

men databasecontaineren vil ikke virke som forventet med mindre det settes spesifikt.

Konfigurasjonsfilen heter “custom-mysql.cnf” og beskrives under.

121

Dockerfile

FROM mysql:5.5 COPY custom-mysql.cnf /etc/mysql/conf.d/

COPY create_db.sql /docker-entrypoint-initdb.d/ COPY create_org_nr.sql /docker-entrypoint-initdb.d/ COPY create_test_data.sql /docker-entrypoint-initdb.d/

Custom-mysql.cnf

[mysqld]

lower_case_table_names=1

Deploy av container

sudo docker build -t avkastning-drone-db .

sudo docker tag avkastning-drone-db:latest <registry-

adresse>/avkastning-drone-db

sudo docker push <registry-adresse>/avkastning-drone-db:latest

Figur 10-18 - Oppsett for konteinerisert database til testing og preprod

Databasen opprettes i service avkastningsportal på Rancher med miljøvariabelen

MYSQL_ROOT_PASSWORD=***

122

Figur 10-19 - Definisjon av miljøvariabel for root-passord i databasen

Installasjon av ELK-Stack

ELK stack intstallajonsguide:

https://rancher.com/running-our-own-elk-stack-with-docker-and-rancher/

1: Klon følgende Git repository:

$ git clone https://github.com/rancher/compose-templates.git

2: Elastic search

1. $ cd compose-templates/elasticsearch

2. $ rancher-compose -p es up

3. Når Knopf er oppe, klikk på konteineren i Rancher, og få tak i IP’en som noden kjører

på.

4. Åpne en ny tab i nettleseren og gå til IP’en. Her skal man se en datanode på siden

3: Logstash.

1. $ cd ../logstash

2. $ rancher-compose -p logstash up

3. Følgende services kommer opp: Redis - logstash-collector - logstash-indexer

4. Nå kan applikasjonene peke på logtstash://<host>:5000.

4: Logsput

1. $ cd ../logspout

2. $ rancher-compose -p logspout up

5: Kibana 4

1. $ cd ../kibana

123

2. $ rancher-compose -p kibana up

3. Åpne en ny tab i nettleseren og gå til IP’en. Her skal man se Kibana dashboard.

Kopf Webgrensesnitt: http://<host>:85/

Kibana Webgrensesnitt: http://<host>:92/

124

11 Vedlegg 2 - Brukerveiledning til oppdragsgiver

Arbeidet med testing og publisering av løsninger har blitt enklere enn tidligere. Som før

jobbes det i egen feature branch for det som skal utvikles. Ved en push til Git-tilbyder vil

løsningen bygges, pakkes og legges ut i preprod. Det er derfor antatt at testing gjøres lokalt,

og systemet legger opp til en DevOps-tankegang med hyppig utplassering av endringer i

preprod. I løsningen er det tiltenkt bruk av egne team i Git-tilbyderen hvor kun teamleder

har anledning til å pushe til master. Dersom en test feiler under bygging vil prosessen som i

dag avsluttes og Drone gir beskjed på samme måte som Jenkins gjør.

Figur 11-1 - Komplett kjøring i Drone uten feil

125

Utplasseringen av nye versjoner i preprod skjer som sagt automatisk ved hjelp av Drone, og

CI/CD-prosessen ender med at tjenestene som det er utviklet på vil oppgraderes i Rancher.

Etter at dette er gjort vil man kunne gå inn på Avkastningsportal i preprod og sjekke at alt

har gått som forventet.

Når endringene som er gjort har blitt godkjent og er produksjonsklare opprettes det en pull-

/merge-request i Git-tilbyderen og det er opp til en teamleder å godkjenne endringene. Når

requesten en godkjent, og dermed tatt inn i master-branchen, vil CI/CD-prosessen kjøre på

nytt mot produksjonsmiljøet. Tjenestene blir i Rancher oppgradert på samme måte som for

preprod og man har anledning til å enten akseptere eller avvise en oppgradering avhengig av

om den oppfører seg som forventet eller ikke.

Figur 11-2 - Oppgradert stack i Rancher

126

12 Vedlegg 3 – Testrapport

12.1 Sammendrag

Det er gjennomført tilstrekkelig testing for å sikre at Avkastningsportals funksjonalitet er

ivaretatt etter migrasjon til skyen og at automasjons av integrasjon og leveranse fungerer

som planlagt. Dette er gjort gjennom enhets-, integrasjons-, og systemtester utviklet av

Kantega AS, samt systemtest for automasjon utviklet av prosjektgruppen.

12.2 Avvik i forhold til testplan

Alle tester er gjennomført i henhold til testplanen.

12.3 Testens grundighet

Enhets- og integrasjonstestene i denne testen er utviklet av Kantega i forbindelse med

utvikling av Avkastningsportal. Dekningsgraden av disse enhetstestene er 72% for klassene

og 48% av linjene i prosjektet. Dette kan virke lavt, men vi har ikke tatt stilling til denne

dekningsgraden da vi ikke har jobbet med applikasjonens kildekode og ikke kan avgjøre om

dekningsgraden er tilstrekkelig. Vi har heller ikke grunnlag for å evaluere dekningen av

integrasjonstestene da dette krever inngående kjennskap til og ettersyn av kildekoden. Vi

forutsetter derfor at dekningen av enhets- og integrasjonstester er tilstrekkelig slik de er

utviklet av Kantega.

Figur 12-1 - Kodedekning i Avkastningsportal

127

Systemtesten for brukergrensesnittet tar for seg funksjonalitet forbundet med

tabellvisningen, detaljvisningen av individuelle porteføljer og sammenligningen av

porteføljer. Dette er i vår applikasjon all funksjonalitet tilgjengelig for brukeren og testene

regnes derfor som dekkende.

Systemtesten for automasjon vil kun bestå ved suksess i bygge-, integrasjons- og

leveranseprosessene.

12.4 Avvik i produktet

Det er ikke funnet avvik i produktet ved noen av testene. Logg fra kjøring av enhets- og

integrasjonstester viser at 106 av 108 tester har bestått. De resterende to testene er ikke

gjennomført da de er annotert med “@Ignore” i kildekoden og ikke skal kjøres. Disse skal

ignoreres fordi de støtter funksjonalitet som ikke er inkludert i vår versjon av

Avkastningsportal. Dette er beskrevet i kravspesifikasjonen. Også samtlige systemtester har

bestått da observert resultat samsvarer med forventet resultat.

12.5 Testplan

Innledning

Testplanen gjelder applikasjonen Avkastningsportal etter migrering til skyen. Den omfatter

enhets-, integrasjons-, og systemtester produsert av Kantega AS under utvikling av

applikasjonen og systemtester utviklet av bachelorgruppen. Samlet skal disse testene

bekrefte både at applikasjonens eksisterende funksjonalitet fortsatt fungerer etter migrasjon

til skyen og at nyutviklet leveranseautomasjon fungerer opp imot de ulike produksjons- test-

og utviklingsmiljøene.

Testobjekter

Alle metoder i kildekoden til Avkastningsportal som har enhetstester ferdigskrevet av

Kantega ved bacheloroppgavens oppstart skal enhetstestes, og det samme gjelder for

ferdigskrevne integrasjonstester. Applikasjonens brukergrensesnitt skal testes ved hjelp av

Kantegas ferdigproduserte systemtest. Automatisering av kontinuerlig integrasjon og

leveranse for Avkastningsportal skal testes gjennom nyutviklede systemtester.

128

Fremgangsmåte

Samtlige enhets- og integrasjonstester kjøres automatisk av Maven under bygging av

prosjektet med Drone i Rancher. Ved feilede enhets- og integrasjonstester stopper

byggeprosessen.

Systemtesten for brukergrensesnittet utføres manuelt i nettleser ved å følge teststegene

definert av Kantega i testbeskrivelsen og observere resultatet.

Systemtestene for automasjon utføres manuelt gjennom observasjon av resultatet av

igangsatt automatisk bygging, integrasjon og leveranse.

Godkjenningskriterier

Testen er godkjent når samtlige tester er gjennomført uten avvik. Enhetstester annotert i

kildekoden med “@Ignore” teller ikke mot antall tester som skal gjennomføres.

Testmiljø

Det er ikke opprettet et eget testmiljø for testing av prosjektet. Testmiljøet tilsvarer dermed

preproduksjonsmiljøet for prosjektet. Enhets- og integrasjonstester er utført ved hjelp av

Maven som kjøres av Drone for å håndtere bygging av prosjektet. Preproduksjonsmiljøet er

satt opp med operativsystem Ubuntu 16.04. Systemtest for brukergrensesnitt er også utført i

preproduksjonsmiljø og utføres dermed på webapplikasjonen hostet hos DigitalOcean.

Resultatet for systemtest av automasjon observeres i Rancher i både preproduksjonsmiljøet

og produksjonsmiljøet. Se systembeskrivelsen i prosjektrapporten for utfyllende beskrivelse

av disse miljøene.

Resultatdokumenter

Logg fra kjøring av enhets- og integrasjonstester

Under følger utsnitt av logg hentet fra Drone etter utført bygging, integrasjon og levering.

Loggutsnittene omhandler enhets- og integrasjonstester kjørt av Maven via Drone i

byggeprosessen. Testene er gruppert slik at hvert sett med tester tilhører et steg i

129

byggeprosessen i Drone. Resultatene for hver gruppe av tester er uthevet i bunn av hvert

loggutsnitt. Testene er utført 25.04.2018. For lesbarhet er loggene forkortet slik at de kun

viser at testene har kjørt for hver enkelt modul prosjektet er inndelt i. Moduler uten tester

er følgelig ikke en del av loggen.

Figur 12-2 - Eksempel på loggresultat sett i Drone

[INFO] -----------------< no.norskpensjon.avkastning:felles >------------------

[INFO] Building felles 2.3-SNAPSHOT [5/14]

[INFO] --------------------------------[ jar ]---------------------------------

-------------------------------------------------------

T E S T S

-------------------------------------------------------

Results :

Tests run: 26, Failures: 0, Errors: 0, Skipped: 1

[INFO] ---------------< no.norskpensjon.avkastning:avkastning >----------------

[INFO] Building Avkastningdata tjeneste 2.3-SNAPSHOT [6/14]

[INFO] --------------------------------[ war ]---------------------------------

-------------------------------------------------------

T E S T S

-------------------------------------------------------

Results :

Tests run: 10, Failures: 0, Errors: 0, Skipped: 1

[INFO] --------------< no.norskpensjon.avkastning:rapportering >---------------

[INFO] Building Rapportering 2.3-SNAPSHOT [7/14]

[INFO] --------------------------------[ war ]---------------------------------

-------------------------------------------------------

130

T E S T S

-------------------------------------------------------

Results :

Tests run: 49, Failures: 0, Errors: 0, Skipped: 0

[INFO] ----------------< no.norskpensjon.avkastning:beregning >----------------

[INFO] Building beregning 2.3-SNAPSHOT [9/14]

[INFO] --------------------------------[ jar ]---------------------------------

-------------------------------------------------------

T E S T S

-------------------------------------------------------

Results :

Tests run: 12, Failures: 0, Errors: 0, Skipped: 0

[INFO] ---------------< no.norskpensjon.avkastning:renteimport >---------------

[INFO] Building renteimport 2.3-SNAPSHOT [14/14]

[INFO] --------------------------------[ jar ]---------------------------------

-------------------------------------------------------

T E S T S

-------------------------------------------------------

Results :

Tests run: 9, Failures: 0, Errors: 0, Skipped: 0

Systemtest av brukergrensesnitt

Testdato

25.04.2018

Sammendrag

Testen skal sjekke at brukergrensesnitt fungerer riktig.

Gjennomføring

Testen kan kjøres både i preprod og på np-st.

Forutsetning for alle tester

131

# Teststeg Forventet resultat Observert

resultat

1 Åpne et nettleservindu

til

<server>/rapportering/

En side med en tabell av porteføljer dukker

opp. Tabellen er sortert etter feltet

"Risikojustert avkastning" i synkende

rekkefølge.

Som

forventet

Filtrer på risikoklasse

# Teststeg Forventet resultat Observert

resultat

1 Velg "lav" som

risikoklasse

Tabell viser kun produkter som har frem til

30% i felt "Målsatt aksjeandel"

Som forventet

2 Velg "Høy" som

risikoklasse

Tabell viser bare produkter som har "Målsatt

aksjeandel " høyere enn 70%

Som forventet

3 Velg "Medium" som

risikoklasse

Tabell viser bare produkter som har "Målsatt

aksjeandel " mellom 30% og 70%

Som forventet

4 Velg alle Tabell viser alle produkter Som forventet

5 Velg Avansert Fordeling endrer seg, nå finnes det 10

risikoklasser

Som forventet

6 Klikk på alle klassene Tabellen oppdaterer seg basert på klassen

som blir valgt.

Ingen porteføljer dukker opp i flere klasser

Som forventet

7 Klikk på enkel Filter kommer tilbake til å inneholde kun 3

klasser

Som forventet

132

Filtrer på avkastningsperiode

# Teststeg Forventet resultat Observert

resultat

1 Velg 1 år som

avkastningperiode

Tabellen blir oppdatert:

a. Ny verdi vises for felter "Risikojustert

avkastning", "Avkastningsvariasjon" og

"Bruttoavkastning"

b. Tabell er sortert etter "Risikojustert

avkastning"

c. Det vises "Ikke tilgjengelig" for alle

porteføljer i felt Avkastningsvariasjon

Som

forventet

2 Velg 15 år som

avkastningperiode

Tabellen blir oppdatert

Det finnes flere porteføljer som viser "Ikke

tilgjengelig" i felter "Risikojustert avkastning",

"Avkastningsvariasjon" og "Bruttoavkastning"

Som

forventet

3 Velg 5 år som

avkastningperiode

Tabellen blir oppdatert. Det vises data for de

porteføljer som har dette

Som

forventet

133

Sorter per kolonne

# Teststeg Forventet resultat Observert

resultat

1 Klikk på header til

"Bruttoavkastning"

kolonne

Tabellen blir sortert etter

"Bruttoavkastning" kolonne

Som forventet

2 Klikk igjen på samme header Sortering snur seg Som forventet

3 Klikk på Målsatt aksjeandel Tabellen blir sortert etter Målsatt

aksjeandel

Som forventet

Detaljside

# Teststeg Forventet resultat Observert

resultat

1 Klikk på en av

porteføljenes navn

En ny side dukker opp med detaljer av valgt

portefølje. Siden inneholder en graf som viser

utvikling av portefølje gjennom siste 3 år

Som

forventet

2 Velg 1 år som

avkastningsperiode

Bare grafen oppdaterer seg16 Velg 15 år som

avkastningsperiode Grafen vises ikke, og det

vises en melding som sier at porteføljen ikke har

lang nok historikk

Som

forventet

3 Klikk på et blått

spørsmålstegn

Det vises en blå popup som inneholder

hjelpetekst relatert til feltet

Som

forventet

4 Klikk tilbake Du kommer igjen til oversikttabell Som

forventet

134

Sammenlign porteføljer

# Teststeg Forventet resultat Observert

resultat

1 Klikk på checkbox ved

siden av 5

forskjellige porteføljer

Sammenlign-knappen blir aktiv Som

forventet

2 Klikk på Sammenlign-

knappen

Du kommer til en ny side som viser detaljer

og graf for alle valgte porteføjer

Hvert portefølje har egen farge i grafen

Det finnes hjelpeikon for alle feltene.

Radene i tabell endrer farge ved

mouseover

Som

forventet

3 Klikk på et av

porteføljenavnene i

grafen

Porteføljen forsvinner fra grafen Som

forventet

4 Klikk på 10 år Grafen viser bare porteføljer som har lang

nok historikk

Som

forventet

135

Systemtest av kontinuerlig integrasjon og levering

Testdato

25.04.2018

Sammendrag

Testen skal påvise at prosjektet bygges og leveres til riktig produksjonsmiljø ved oppdatering

av kode.

Gjennomføring

Testen igangsettes ved kodeoppdatering i Git. Resultatet blir observert i nettleser gjennom

Ranchers brukergrensesnitt for Avkastningsportal.

Forutsetning for testen:

Åpne ønsket programvare for å pushe kode til prosjektet i Github

Bygg og lever prosjektet til preproduksjonsmiljø

# Teststeg Forventet resultat Observert

resultat

1 Push ny kode til prosjektet

på Github i en branch som

ikke er ‘master’.

Prosjektet bygges i Drone og

Avkastningsportal-stacken i Rancher viser

oppdaterte tjenester i preprod-miljøet.

Som

forventet

Bygg og lever prosjektet til produksjonsmiljø

# Teststeg Forventet resultat Observert

resultat

1 Push ny kode til

prosjektet på Github i

‘master’ branch.

Prosjektet bygges i Drone og

Avkastningsportal-stacken i Rancher viser

oppdaterte tjenester i produksjon-miljøet.

Som

forventet

136

13 Vedlegg 4 - Oppdragsgivers tilbakemelding