Applikasjoner på boks

Computerworld tok en prat med en erfaren utvikler som har jobbet mye med Docker. Magnar Sveen er utvikler i Kodemaker og har programmert fra han var ti år. Nå har han 16 års erfaring som utvikler i it-bransjen, og er begeistret for containere og Docker.

– Jeg ser tre argumenter for å benytte containere. Det vil løse konflikter mellom utviklere på den ene siden og drift og administrasjon på den andre. Du får enklere håndtering av devops ved at applikasjonene pakker ned det de trenger i stedet for at serverne må være satt opp nøyaktig etter en lang smørbrødliste fra utviklerne. (Devops betegner "developer" og "operations" – utviklere og driftsfolk, red. anm).

Han forteller at når alt applikasjonen trenger ligger i containeren – operativsystem, kjøremiljø og programkoden i kompilert form. Da vil utvikleren kunne ta ansvar for drift av applikasjonen uten å gå i veien for it-avdelingens administrasjon av infrastruktur.

Dessuten får utvikleren et annet forhold til koden sin. Det blir ikke lenger slik at den bare overleveres, men utvikleren vil også kunne følge den i drift og finne svakheter eller mulige forbedringer.

Utvikler med kontroll

– Det andre argumentet er at utviklerne får kontroll på avhengigheter. For eksempel kan det være at en applikasjon som er utviklet i en gitt versjon av Ruby ikke kan kjøre i en annen versjon. Samtidig kan du ha en annen applikasjon som krever en annen bestemt versjon.

Om disse plasseres i hver sin container, så vil de aldri se hverandre eller skape konflikter med hverandre fordi de har fått med seg det kjøremiljøet den trenger i containeren.

– Vi ville teste JavaScript-koden vår på byggeserveren, og trengte Node installert. It-avdelingen satte ned foten, de ville ikke ha mer inn på den. Etter mye om og men fikk vi tillatelse, og da oppdaget vi at Node allerede var installert. I en gammel versjon som ikke fungerte til vårt formål. Med containere hadde det aldri vært noen sak, forteller Sveen.

Transportbransjen

– Jeg synes "container" er et greit ord. På samme måte som standardiserte containere som kan fraktes med biler, tog og skip har vært et fremskritt for transportbransjen, kan Docker gjøre tilsvarende innen it-drift, sier Sveen.

Hans tredje argument er at grensesnittet til containerne er håndtering av porter. Du mapper de portene applikasjonen trenger for å kommunisere og slipper at flere applikasjoner skaper konflikt om porter.

– Containere er en stor fordel for it-drift. De trenger ikke lenger forholde seg til alle småting som må være tilstede for å kjøre applikasjoner, som spesifikke binær-filer, tjenester og slikt. Du får den fordelen at oppsettet er likt hele veien, og dermed slipper du "virker på min maskin"-problemer.

Sletter alle spor

Docker har nå støtte for å håndtere ressursene for hver enkelt container. Du kan sette opp hvor mye cpu, minne, cache og andre ressurser skal få.

– Den som håndterer serveren slipper å måtte få en masse forskjellige filer strødd rundt i form av eksekverbar kode, ressursfiler, biblioteker og så videre. Det er bare å installere en container som inneholder applikasjonen og alle ressursene den trenger.

– I stedet for å måtte oppdatere forskjellige ressursfiler til forskjellige tider, skjer en oppdatering ved å bytte ut en container med en ny. Og trenger du den ikke lenger, er det bare å ta den vekk. Den vil ikke ha satt spor etter seg, ingen overflødige filer eller gamle innstillinger i Registry.

For godt til å være sant?

Docker eksekverer på nyere Linux-kjerner, og containere kan settes til å kjøre automatisk. Selv om det høres enkelt ut å bare legge en container på serveren, så har du en fullt fungerende løsning. Men det er ikke så enkelt.

– En bestiller som ikke kan noe om drift, kan få det litt vrient.

Systemer for versjonskontroll bruker gjerne å bare lagre forskjellene mellom versjoner, såkalte deltaer. Tilsvarende er det med Docker. Du starter fra scratch med en Linux-kjerne eller et enkelt operativsystem. Særlig er Ubuntu populært.

– Alt du deretter legger inn i containeren er differanser: delta-filer. Det betyr at det grunnleggende imaget gjenbrukes for alle containerne, slik at man for raske oppdateringer og en effektiv bruk av plass og minne.

Krever litt fra drift

Mange bruker filsystemet XFS, som ble introdusert av Silicon Graphics i 1993. Ifølge Magnar Sveen er det tregt og ikke helt til å stole på i forbindelse med Docker. Derfor vil han anbefale at Docker får en egen disk med et filsystem som støtter layering. Dette kan være BTRFS (B-tree File System), ZFS (Zetabyte File System med opprinnelse hos Sun), OverlayFS eller andre.

– Utviklingen av Docker skjer i rasende fart, og det er et stort miljø rundt med flere startups. Containere gjør det lettere å teste. Du slipper falske positiver og negativer. Fungerer en applikasjon i en container i testmiljø, vil den fungere i produksjon.

– Det vil dukke opp flere tilbydere som vil kjøre containere i skyen for kunder. Fordelene er da at du ikke trenger noen egen maskinvare og slipper å håndtere servere, lagring, nettverk og slikt. De som driver dedikerte servere vil få skybaserte containere å konkurrere mot, mener Sveen, som viser til at Google, Amazon og veldig mange nye startups vil nok tilby dette.