En gjennomgang av hvordan publiseringsteamet i NRK utfører testing og leveranser med Continuous Delivery.
Script skrevet i Fabric for å stoppe en instans av Apache Tomcat.
Innhold på nrk.no er bygget opp av flere systemer – et av de største og mest komplekse av disse er publiseringsløsningen – verktøyet NRKs journalister bruker til å publisere saker på nett. De fleste sidene du ser på nrk.no er laget av nettopp dette systemet. Vi vil i denne artikkelen fortelle om hvordan vi i teamet rundt publiseringsløsningen tester endringer og drifter dette systemet.
Bakgrunn
Løsningen består i hovedsak av ATEX‘ Polopoly og vår egenutviklede utvidelse Panorama. En journalist skriver en sak i Polopoly, som deretter lagres, indekseres og rendres for visning til publikum i Panorama. Hvert publiseringsmiljø krever rundt 10 Linux-servere – på disse kjører vi forskjellig type software – alle åpen kildekodeløsninger – som Apache Tomcat, MySQL, Varnish Cache, Resin, Apache Solr mm. Totalt har vi fire miljøer for publiseringsløsningen – dette kommer vi tilbake til senere i artikkelen.
Konfigurasjonsstyring
Utdrag av Puppet-manifest for oppsett av Apache Tomcat.
Å vedlikeholde 40-50 servere manuelt krever unødvendig mye ressurser av driftspersonell – vi bruker derfor et såkalt Configuration Management-verktøy for å konfigurere og gjøre endringer på serverne. Det finnes flere slike verktøy – vi i NRK har valgt å bruke Puppet på Linux-plattformen. Dette er verktøy for å sette opp, kontrollere og endre oppsett av servere fra ett, sentralt sted, i stedet for å logge inn på hver enkelt server for å gjøre endringer.
Ved hjelp av et eget språk beskriver man hvordan man vil ha oppsettet av en server. Man bruker i Puppet et såkalt deklarativt språk – altså et språk som beskriver hvilken tilstand man ønsker en server skal være – ikke spesifikt hvilke kommandoer man må utføre for å komme dit. Denne informasjonen lagres i et manifest som sendes ut til agenter som kjører på serverne, og som utfører de nødvendige oppgavene for å komme til ønsket tilstand. Dette har flere fordeler:
- Integriteten til systemet vedlikeholdes. Man unngår configuration drift – altså at konfigurasjonen til i utgangspunktet like systemer glir fra hverandre på grunn av mange små, lokale variasjoner.
- Man slipper dobbeltarbeid. Et enkelt manifest kan gjelde for alt fra en til mange tusen servere.
- Risikoen for menneskelig feil minimeres. Man kan enkelt kopiere oppsett fra en server til en annen.
- Manifestet fungerer også som dokumentasjon av systemoppsett.
“Too close for missiles, switching to guns…”
Maverick i Top Gun, 1986
Orkestrering
Verktøy som Puppet best egnet for konfigurasjon av statisk art - det kommer til kort når man vil utføre hyppige og uregelmessige endringer på serveren – vanligvis når man har nye versjoner av av programvare som skal ut i miljøene – til dette bruker vi Fabric. Oppgaven – en deploy – består i all hovedsak ut på å stoppe tjenesten, fjerne gammel versjon av programvare, kopiere ny versjon ut til serverne og starte tjenesten igjen. Fabric er et verktøy basert på programmeringsspråket Python som gjør at ved hjelp av scripts enkelt kan utføre slike operasjoner på flere tjenester og flere servere samtidig. Vi bruker dessuten Fabric til å utføre flere støtteoppgaver i forbindelse med en deploy:
- Oppvarming av servere: Vi ønsker ikke at en tjeneste får trykk fra publikum når den nettopp har startet opp. Vi må varme den opp først, det vil si at sidevisningene kompileres og at diverse mellomlagre (cache) må fylles. Dette gjør vi ved at vi rett før vi stopper tjenesten, leser av og lagrer de mest besøkte URL-ene. Etter ny software er lagt ut, bruker vi disse URL-ene til å varme opp tjenesten, slik at tjenesten responderer raskt med en gang vi slipper inn publikum.
- Smoketests: Vi har programmert Fabric til å kjøre små, kjappe tester av løsningen for å avdekke åpenbare feil umiddelbart etter oppstart. (Fra det virkelige liv: Sett på strømmen og se om det kommer røyk)
- Trigging av automatiske tester: Med en gang Fabric er ferdig med utførelsen av selve deployen gir den beskjed til en annen tjeneste at den skal starte automatiske tester.
- Silo-testing i produksjon: Våre script er skrevet slik at vi kan stenge ute publikum fra halve miljøet, slik at vi der kan deploye ny programvare, teste og verifisere den før vi slipper det ut til publikum. Deretter gjør vi det samme med den andre halvdelen av miljøet.
Dette gir oss mange av de samme fordelene som Puppet: Oppgavene blir enklere for driftsoperatøren, det minsker arbeidsmengden, deployer kan gjøres kjapt, og det gjør at det utføres på en tryggere måte. Man er også mindre personavhengig, da det er en mindre terskel for å deploye software til miljøene. Til sammenligning måtte vi tidligere utføre omtrent 50 forskjellige operasjoner for hver deploy.
Automatisert testing i flere miljøer
Som nevnt ovenfor har vi fire miljøer:
- Dev: Dette miljøet brukes først og fremst til utvikling, er av natur ustabilt.
- Stage: Miljø for å klargjøre kildekode til produksjon, ytterligere tester kjøres automatisk etter deploy.
- Preprod: Siste avsjekk før produksjon: Dedikerte testere utfører systemtester og driftspersonell utfører tester og godkjenner for produksjon.
- Prod: Produksjonsmiljøet, miljøet som vises til publikum
Hver endring på kildekoden må gjennom en testprosess og godkjennes på hvert miljø før vi deployer til produksjon. For dev- og stage-miljøene skjer dette automatisk: Hver gang en utvikler gjør en endring i kildekoden, deployes denne automatisk til “dev” og tester kjøres automatisk. Hvis alle tester blir grønne, gjør vi det samme i “stage”-miljøet, og utfører enda fler tester. Videre deployer vi til “preprod” – hvor de siste testene og verifikasjonene utføres – den får et godkjent-stempel.
Vi jobber ut fra fail fast-prinsippet – hvor vi ønsker å oppdage feil tidligst mulig i prosessen. Dette ut fra at jo lengre man har kommet i prosessen frem mot produksjon før en feil oppdages, jo flere ressurser har man brukt. Oppdager man feilen tidlig, er det lettere og billigere å rette feilen.
Selve flyten gjennom miljøene håndteres av Jenkins’ “Build Pipeline”-plugin, som gir oss automatikken i flyten mellom miljøene. Den gir oss også en oversikt over pågående deployer, status på smoketester og automatiske tester mm. Med et par museklikk kan vi også se logger, trendgrafer på antall deployer med feil osv.
En bedre arbeidsflyt
Skjermskudd av Dashboard vi har hengende i kontorlandskapet.
Hva kan dette gi oss utover fordelene nevnt ovenfor? En av grunnpilarene i devops-kulturen er kommunikasjon, både mellom driftere og utviklere, men også å sørge for at alle involverte har et bevisst forhold til tilstanden til miljøene. For å hjelpe oss mot dette har vi satt opp en stor skjerm i kontorlandskapet som viser status på miljøene. Ved hjelp av et lite rammeverk kalt Dashing kan vi enkelt vise status og målepunkter for hvert enkelt miljø:
- Indikasjon på om en deploy er igang, og hvor lenge det er igjen.
- Hvor mange tester som har feilet
- Hvor mange minutter siden forrige endring.
- En karusell som viser diverse nrk.no-undersider.
Tradisjonelt har man operert med vedlikeholdsvinduer og faste tidspunkter for deployer, men med Continuous Delivery kan vi hurtig levere rettelser og endringer til produksjon – uten at brukeren må vente opptil mange uker på neste vedlikeholdsvindu.
Continuous Delivery og devops passer ikke alle organisasjoner, men er dette noe som virker interessant, kan følgende tips være greie å holde seg til:
- Automatiser alt.
- Gjør mange små endringer, istedet for få og store.
- Involvér alle i prosessen, hold tett kontakt mellom utviklere, prosjektledere og driftspersonell, helst samlokalisert.
- Vær god på informasjon, heller for mye enn for lite.
- Ikke tar snarveier, gjør det riktig fra starten.
- Gjør operasjonene idempotente, dvs at de kan kjøres flere ganger med samme resultat. (Hvis noe feiler, skal du kunne rette feilen og kjøre operasjonen på nytt med en gang)
- Lag miljøene så homogene som mulig. Ikke vær gjerrig på servere, tiden du sparer på homogene miljøer vil i de fleste tilfeller tjene inn igjen dette.
For oss i temaet er ikke arbeidet avsluttet, vi jobber kontinuerlig for å forbedre oss på dette området, blant annet jobber vi nå med å parallellisere oppgavene i større grad, slik at utførelsen blir raskere. Vi jobber også mye med å automatisere testingen etter vi har deployet til prod, slik at vi i større grad slipper manuelle oppgaver etter en produksjonssetting.
Er det noen som jobber på samme måte selv, eller ønsker å komme dit? Har du verktøy eller metoder du vil tipse oss om?