DockerTesting - Del 1: En kort introduksjon til Testing med Docker

Av Richard Rostad, Promis Qualify

Hva er egentlig alle disse docker og kubernetes tingene og hvorfor er det interessant for oss som driver med test?

For mange i testbransjen er alle disse relativt nye begrepene bare ord som ikke strengt tatt gir mye mening. Vi forholder oss gjerne til de samme gamle og velkjente grensesnittene vi alltid har gjort; det være seg brukergrensesnitt eller API-er når vi tester.

Teknologien under blir ofte litt uinteressant og fjern; testene våre er jo de samme uansett? Imidlertid legger slike teknologivalg føringer både for utviklings- og testmetodikk samtidig som de åpner for nye muligheter. Aller viktigst er vel kanskje at kontainerteknologi gir en ganske annen distribusjon av typer feil og det er for oss på test viktig at vi tilpasser oss den verden vi faktisk lever i.

Hvorfor kontainere?

La oss tenke oss en situasjon der du skal teste en tjenerapplikasjon gjennom et API.
Applikasjonen kjører på en *nix Platform og bruker en rekke rammeverk og biblioteker og kjører gjennom en hyllevare webtjener. NoenTM setter opp et testmiljø og vi begynner å teste. Etter at man har rettet en del feil flyttes applikasjonen over i produksjonsmiljøet. Så slutter ting plutselig å virke som det skal. Merkelige feil dukker sporadisk opp, feilsøking tar betydelige mengder tid og stressfaktoren er høyere enn strengt tatt komfortabelt.

Så viser det seg at testmiljøet ikke kjører samme versjon av et rammeverk, et bibliotek eller ‘hyllevare’ som produksjon. Når man oppdaterer produksjon til samme versjon som i test så begynner alt magisk å virke igjen. Alternativt når man oppdaterer testmiljøet så feiler ting der også slik at man kan feilsøke i litt mer kontrollerte former.

Kontainerteknologien fjerner hele denne kategorien med feilkilder ved at man pakker alt av applikasjoner, tjenesteplattformer, biblioteker etc inn i en ‘pod’ som kan flyttes rundt i utvikling, test og produksjonsmiljøer uten endringer. Det betyr at man til enhver tid vet at det som testes faktisk er det samme som senere settes ut i produksjon.

Selvfølgelig kommer det ikke helt uten problemer. Eksempelvis deler alle pod-ene samme virtualiseringsplatform, eksempelvis Docker Engine, slik at man får en helt ny kategori problemstillinger knyttet til sikkerhet og feil på tvers av pods, men det er et emne for en annen dag. Alt i alt må det sies at dagens kontainerplatformer er en vesensforbedring i forhold til tidligere paradigmer. De er også i praksis nærmest en forutsetning for god gjennomføring av kontinuerlige leveranser og god kontinuerlig utforskende testing.

En av de store fordelene i disse hjemmekontortider er at man kan teste en tilnærmet fullstendig on-prem eller skybasert tjenesteplattform med mange distribuerte mikrotjenester i ro og mak på sin egen laptop fra en kano på Femunden uten å måtte ha tilgang på interne nettverk, databaseservere etc.

Hvordan kontainere?

I alt for mange sammenhenger venter vi til et miljø er komplett oppe å kjører før vi begynner testing av nye systemer. Ikke bare er det til hinder for tidlig testing, men det vanskeliggjør også feilsøking og teknisk testing fordi man ikke kan isolere det subsystemet man ønsker å teste. Kontainerteknologi gjør alt så meget bedre. La oss prøve oss frem med noen leketøyseksempler:

1. Installer Docker desktop fra
https://www.docker.com/products/docker-desktop
hvis du er på windows eller mac. Docker og andre kontainerplattformer benytter en del unix systemkall, så det har tradisjonelt blitt en del plunder og heft med windows, men det ryktes at det skal være i orden i disse dager. For Linux bruker man eksempelvis sudo apt install docker.io

2. Når Docker er oppe og kjører kan man finne et komandovindu og skrive:
docker run --name getstart -dp 8080:80 docker/getting-started
Docker vil laste ned det som trengs av docker images og starte opp. Når den er ferdig har du en komplett webtjener med operativsystem, biblioteker, webtjenerplattform og applikasjon kjørende.
Åpne en webleser og gå til http://localhost:8080 for å se hva du nettop har installert. Dette er selvfølgelig kjekt når man skal teste ting, men det er også det som gjør god kontinuerlig leveransemetodikk mulig. Man har ikke én applikasjon i produksjon som man må gjøre endringer på, man har et komplett system.
Når man så skal release en ny versjon så kjører man bare opp den nye ved siden av den gamle. Noen forespørsler går til den gamle og noen til den nye. Siden man har små endringer kan disse gå i parallell en stund. (Typisk sekunder, ikke dager, men begge dele er mulig).
Når man er fornøyd med den nye versjonen så setter man den gamle til å slutte og akseptere forespørsler og når den ikke har mer å gjøre slår man den av.

3. Vi kan åpne Docker desktop og kikke litt på hva som egentlig skjer:

Det er en hel del man kan klikke på i Docker desktop, men hovedpoenget er at modersystemet som du kjører docker på kan se hva som skjer inne i kontaineren, men kontaineren har ikke tilgang på hva som skjer utenfor (eller i veldig liten grad og ganske spesielle unntakstilfeller.) Fordelene med å kunne inspisere innholdet i en serverapplikasjon på sin egen laptop under testing er åpenbare.

 4. Nå er det jo i disse moderne tider ikke så ofte man ønsker å teste en enkelt applikasjon i isolasjon; som regel henger flere tjenester sammen og med mikrotjenester blir det enda mer aktuelt.
Også til det har Docker en løsning; docker-compose. Docker-compose komponerer ved hjelp av en enkel konfigurasjonsfil (docker-compose.yml) opp et komplett miljø med nødvendige tjenere og kommunikasjonskanaler på din lokale maskin.
Alle systemene i dette miljøet blir tilgjengelige i docker desktop og kan inspiseres og manipuleres på samme måte. Avbruddstesting med ett klikk? check.

Dette ble jo en latterlig forenklet introduksjon til noe som for mange testere er en helt ny teknologi, men jeg håper jeg har klart å vekke nysgjerrigheten nok til at noen tar en videre kikk.
Det er masse informasjon på nettet og fordelene med denne typen teknologi for oss testere er rimelig store.