nrk.no

Continuous Delivery i NRK

Kategorier: Dev,Linux & NRK

Script skrevet i Fabric for å stoppe en instans av Apache Tomcat.

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.
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.
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.
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?

44 kommentarer

    • Ole Christian Haga (svar til Andreas Holen)

      Har vært på sånn omvisning og der ble man ikke så mye klokere av det tekniske, omviseren hadde ikke en gang lov til at vi gikk innom noe kontrollrom.

    • Andreas Holen (NRK) (svar til Birger Vestrheim)

      Hei Birger, takk for innspill. Du har rett, det er en blanding av ny og gammel teknologi i NRK.

      På IT-siden er det mange av verktøyene og løsningene vi bruker som har sin opprinnelse for 20-30 år siden. Av de jeg nevner ovenfor er det vel MySQL som er eldst, med sine snart 20 år. (Men alle er under aktiv videreutvikling fortsatt) Vi tar også i bruk nyere teknologi som websockets, NoSQL-databaser mm.

  1. Pål Bergquist

    Jeg synes NRK burde lage noen TV programmer om de tekniske tingene som ligger bak nrk.no og løsningene for streaming av radio og TV. Det er alt for lite teknisk stoff i NRK. Det er bare kultur og kjendis sladder. Programmer om nettbanker og finn.no burde også få noe sendetid. Få noen ingeniører til å lage TV programmer.

    Svar på denne kommentaren

    • Andreas Holen (NRK) (svar til Pål Bergquist)

      Hei Pål, takk for innspill. Det er nok sikkert flere som er interessert i mye av det tekniske som foregår i NRK – skal gi beskjeden videre.

    • Roy Sigurd Karlsbakk (svar til Pål Bergquist)

      Tiltredes! En gjennomgang av NRKs løsninger og infrastruktur hadde vært svært gledelig, spesielt med tanke på strømmeløsningen og hvordan dere gjør adaptiv strømming. Er det hjemmemekk eller proprietære systemer eller en kombinasjon?

    • Roy Sigurd Karlsbakk (svar til Marte Radmann)

      Takktakk 🙂

      Men er denne litt utdatert nå? Det funker jo med Android 4.1 og sikkert win8…

      men takk for en interessant artikkel okke som 🙂

      roy

    • Marte Radmann (svar til Roy Sigurd Karlsbakk)

      Ja, den er ikke akkurat ferskvare lenger. Men prinsippene er fortsatt gjeldene 🙂

      Windows Phone 8 spiller av HLS-strømmene via en avspiller utviklet av Apptelic, Android-telefonene bruker en flash-avspiller som er pakket inn i en Air-app.

    • Andreas Holen (NRK) (svar til Martin Bekkelund)

      Takk for linken Martin, kjempeinteressant lesning.

      Nyttig for alle parter med åpenhet på teknologivalg og hvordan man jobber – håper flere og flere blir med på dette. Er nok ikke umulig vi kommer med en artikkel som går mer på utviklingsprosesser mm. også.

    • Martin Bekkelund (svar til Andreas Holen)

      Kunne kanskje også vært interessant med litt erfaringsutveksling både om teknologivalg og prosess. Si gjerne i fra når dere kommer med en artikkel om prosessen.

    • Vegard Storstad (NRK) (svar til Martin Bekkelund)

      Hei Martin!

      Interessant lesning fra dere som videutvikler Digipost! Notatet ditt burde fungerer godt for mange teknologidrevne virksomheter for å levere forutsigbart og risikobevisst.

      Vi deler gjerne tanker og erfaringer med dere (og andre som vil sparre) når det gjelder prosess- og digital produktutvikling 🙂

      -V

    • Interessant lesning!

      Ang. vidre utvikling av digipost: Er det noen planer om skikkelig sikker kommunikasjon, med ende-til-ende kryptering?

    • Martin Bekkelund (svar til Bjørn L)

      Hei Bjørn,

      Digipost støtter allerede sikker ende-til-ende-kommunikasjon, hvor avsender har mulighet til å prekryptere post med mottakers offentlige nøkkel før den sendes til Digipost. Dette er f.eks. standardprosedyre når det sendes helseopplysninger gjennom Digipost.

      Utover dette har jeg et ønske om å tilby muligheten for å la mottakere generere sitt eget nøkkelpar, laste opp den offentlige nøkkelen til Digipost og beholde den private selv. Dette er selvsagt for de mer avanserte som både har kompetansen og kjenner fordeler og ulemper ved å benytte seg av dette. Men prinsipielt er det en viktig funksjon.

    • Det er mulig jeg har misforstått, men jeg trodde dekrypteringen av posten hos digipost ble gjort _hos_ digipost, dvs. at dere har en kopi av den private nøkkelen, og så blir dataene sendt via https til bruker? Dette er jo ikke ende til ende..

      Men det kanskje den slags type ende til ende du mente at dere håper å kunne få i framtiden (altså, javascriptbibliotek på klientsiden som tar seg av dekrypteringen.. og som på ett eller annet vis får tak i den private nøkkelen)?

    • Martin Bekkelund (svar til Bjørn L)

      Du har rett i at det ikke er reell ende-til-ende-kryptering så lenge det ikke er mottaker som selv har generert sitt eget nøkkelpar, og lastet opp sin offenlige nøkkel. Det er altså her jeg har et ønske om en slik funksjon, så får man se hvordan dette kan løses på klientsiden uten å være avhengig av tillit for å få løsningen til å fungere.

      I klassisk kryptografi opererer man med et nøkkelpar som er generert av mottaker selv, og hvor mottaker også oppbevarer sin privatnøkkel. I en nylig samtale med Kristian Gjøsteen ved NTNU mener han at denne måten å tenke på ikke lenger er like aktuell for dagens trusselbilde, hvor klienten ofte er like utsatt for angrep som serveren. Det vil si at mange brukere ikke vil ha forutsetning for å oppbevare sin privatnøkkel trygt skjermet fra virus, phishing, etc.

      I valget mellom oppbevaring av privatnøkler sentralt på server, eller oppbevaring på mottakers egen datamaskin, mener Gjøsteen at oppbevaring på server er «the lesser evil», en oppfatning jeg deler.

      Jeg kan for øvrig anbefale følgende artikkel fra Megaupload om tilsvarende problemstilling: mega.co.nz/#blog_3

    • Hei,

      Mtp. «klienten mer utsatt» trusselbilde: Det er nok sant.. en kan eventuelt ha en option for brukere om hvilken løsning de vil bruke.

      Og i praksis – digipost vil vel ikke bli brukt til ekstremt sensitive ting uansett. Helseopplysninger kan en haug folk få tilgang til per dags dato, og de gamle papirjournalene er neppe låst inn i Så sikre skap hos Olsens Legekontor.. point being: For folk flest er det å stole på posten godt nok.

      Når det er sagt: Konsekvensene av at noen får tilgang til Ola Nordmanns maskin er at hans post blir kompromittert. Konsekvensene av at noen får tilgang til privatnøklene og de krypterte dataene er at posten til potensielt sett flere hundre tusen nordmenn ligger på the pirate bay.

      Klart, dette er ting du vet… Men jeg finner lite om den faktiske sikkerheten på digipost sine sider. Det står f.eks «Ingen andre enn deg og mottakeren har tilgang til informasjonen i brevene som sendes», og «Ansatte i Digipost har verken adgang til dine dokumenter eller personopplysninger.».

      Dette er jo ikke sant! De rette ansatte hos posten _kan_ lese posten din. Hvis dette ikke er tilfellet vil jeg gjerne høre om hvordan dere har løst problemet med «slem ansatt». Jeg tipper at det ikke er løst, og at det er noe dere bør opplyse om. Hvis det Er løst vil jeg gjerne lese om hvordan…

      Takker for diskusjon! Jeg får kanskje signe opp på digipost selv, papir er jo noe ræl..

    • Martin Bekkelund (svar til Bjørn L)

      Hei igjen,

      Det er riktig som det står. Digipost er skrudd sammen for å eliminere problemet med utro tjenere, enten de jobber i Posten eller for Postens underleverandører (utviklere, driftere, etc).

      Nøklene vi tidligere har diskutert er opprettet og lagret i en SOSM, en ekvivalent til en HSM. Denne fungerer slik at en enkelt person alene ikke får tilgang til innholdet. Heller ikke to personer i samme organisasjon kan få tilgang til den, dersom de skulle finne på å alliere seg. Detaljene utover dette tror jeg at jeg skal få sikkerhetsansvarlig til å skrive mer om i Digipost-bloggen, da han har langt bedre innsikt i funksjonaliteten enn hva jeg har.

      Digipost skal kunne være et sted for den mest sensitive informasjonen vi har. For de aller fleste vil dagens løsning være god nok, så skal vi alltid etterstrebe å bli mindre proprietære, mer åpne, tilby enda bedre sikkerhet og fullverdig ende-til-ende-kryptering, og være en instans man ikke trenger å ha tillit til.

      Uansett, god diskusjon. Jeg diskuterer gjerne videre hvis du vil ha flere detaljer. Visittkortet mitt finner du selvfølgelig på nett. 🙂

      Mvh Martin

    • Hei,

      Takker for info! Ja, jeg vil gjerne lese en bloggpost om hvordan dette er løst. Mange av de «sikkerhetsløsningene» jeg har lest om i forbindelse med beskyttelse av sensitiv info, f.eks i helsesektoren, kan «lett» omgås av system admins med rett kunnskap. En kan håpe dere har fått det til slik at det er «rimelig vanskelig» og/eller «svært sannsynlig å bli tatt i ettertid» for en «uærlig ansatt» som skaffer seg tilgang til ting han ikke skal ha tilgang til.

      Kjenner ikke til akronymet SOSM – det er en NSM sak dere har eller? Hva heter nøkkel-store produktet deres? Hjemmelaget?

      I det hele tatt, en teknisk beskrivelse av digipost fra et sikkerhetsperspektiv hadde vært veldig interessant. Både for å vite i hvor stor grad nordmenn kan stole på digipost («Bare stol på oss» er ikke så godt 😉 ), og så finner jeg det faglig og jobbmessig (i helsesektoren) interssant.

    • Birger Vestrheim (svar til John)

      Ser den. Er litt som å fly et F-35 for å besøke naboen i huset ved siden av.

      Jeg kjenner ikke til Fabric, men jeg regner med fordelen er at skulle en deploy være korrupt, så kan en lett revertere tilbake til den forrige.

    • Sigurd Gartmann (svar til Birger Vestrheim)

      Fabric har en del fordeler: Det gjør det mye enklere å kjøre skallkommandoer, både lokalt, remote og som sudo.

      Fabric kan, men må ikke, gjøre det enkelt å gå fra en versjon til en neste, eller tilbake. Jeg gjør dette med symlinker, så blir det ikke nedetid.

      (ba)sh er ikke moro, det skaper altfor lett frustrasjoner. Fabric og Python (som det er skrevet i) er klare og tydelige verktøy uten for mye spenning og overraskelser.

      Jeg skjønner ikke sammenlikningen med F-35 og naboen. Vil heller se på det som å ta en moderne sykkel til andre enden av byen, enn en av de første syklene av tre.

    • Andreas Holen (NRK) (svar til Sigurd Gartmann)

      Stiller meg bak det Sigurd skriver – Fabric gjør det lettere og raskere enn om man skulle gjort alt i bash-scripts. Verdt å nevne at man trenger ikke å installere Python/Fabric på serverene, kun den man kjører scriptet fra, så terskelen for å komme igang er ikke så høy.

      Personlig synes jeg det også er penere og morsommere å programmere i python enn bash.

    • Det at Fabric gjør det enklere å kjøre skallkommandoer, både lokalt, remote og som sudo, er vel et ganske situasjonsbetinget. Hvis man har adekvat kunnskap om linux-systemer, så skal ikke dette være noe problem å gjøre ved hjelp av bash.

      «(ba)sh er ikke moro, det skaper altfor lett frustrasjoner.»

      Om man oppfatter noe som moro er noe som er veldig relativt, og i tilegg dypt knyttet til vår evne til å forstå.

      «Fabric og Python (som det er skrevet i) er klare og tydelige verktøy uten for mye spenning og overraskelser.»

      Jeg kan ikke forestille meg i hvilket univers fabric/python er mer klart og tydelig enn konsollkommandoer, og python oppdateringer har mange ganger bidratt til både spenning og overraskelser…

      «Jeg skjønner ikke sammenlikningen med F-35 og naboen.»

      Vel, når jeg trodde jeg hadde sett uvirkelig bloat før… Ta for eksempel «hello world»-eksempelet fra docs.fabfile.org:

      Du må installere python, fabric, skrive en modul som definerer funksjonen som igjen sier hva som skal kjøres.

      Her er et alternativ til Fabric, som jeg vil tro kjører på de aller fleste linux-servere:

      SERVERS=»example1.org example2.org example3.org»
      cat > task.sh <<EOF
      uname -a
      EOF
      for i in $SERVERS; do scp task.sh $i: && ssh $i '/bin/sh ~/task.sh ; [[ $? != 0 ]] && echo "stuff broke" || rm -f ~/task.sh' ; done

      Verdt å nevne at man trenger ikke å installere (ba)sh på serverene, da det finnes på de fleste, så terskelen for å komme igang er ikke så høy…

      Tror neste innbetaling av lisensen kommer til å svi litt ekstra med tanke på hva pengene går til.

    • Andreas Holen (NRK) (svar til John)

      Hei John, ssh-løkker i bash kan funke de, men til vårt bruk får vi så mye gratis med Fabric at det knapt kan sammenlignes med bash. Se heller Fabric som et rammeverk for å kjøre bash-kommandoer remote enn som en erstatning.

      Forøvrig kan bash-alternativet ditt gjøres slik i Fabric:
      fab -H example1.org,example2.org,example3.org — uname -a

    • Birger Vestrheim (svar til John)

      > Jeg skjønner ikke sammenlikningen med F-35 og naboen.

      Hvorfor ta en F-35 til huset ved siden av når du kan gå?

    • Birger Vestrheim (svar til Sigurd Gartmann)

      Kommentaren over var ment til Sigurd.

      For å gå på lag med John her, hvorfor involvere noe så stort og kraftig til å gjøre noe så enkelt. Skallet eksisterte lenge før Python og vil fortsette å eksistere lenge etter at Python har blitt erstattet av noe bedre.

    • Jeg henger meg på her. Sh/bash er tusen ganger kjappere, mer stabilt og mer lettvekt enn et deklarativt domenespesifikt custom-made skriptspråk for et Python-script som fungerer som en interpreter og til syvende og sist gjør helt enkle ting som det tar noen sekunder å gjøre i utgangspunktet. Skjønner ikke puppet eller fabric. Det er som om ingen kan standard sys-admin ting lengre. Devops er en blaff av at php-generasjonen plutselig får sudo-konto for å slutte å mase så mye – og i stedet for å lære seg sys-admin automasjon så finner man opp hjulet på nytt – nå firkanta og implementert i Python og ruby; Greit om man skal forholde seg til tusenvis av bokser med hundrevis av operativsystem som man faktisk må i landet hvor devops buzzwordet kommer fra – men hos oss er alt i en helt annen skala. Om man virkelig trenger et deklarativt språk for å konfe 50 bokser i så har man kanskje designa ting litt feil? Eller er det kompleksiteter her man kan eksemplifisere som gjør at Birger, John og meg ville skjønt opplegget?

    • Andreas Holen (NRK) (svar til Sverre)

      Hei Sverre, innslagspunktet før man får igjen for å bruke verktøy som Puppet og Fabric er langt lavere enn tusenvis av servere, ref. tidligere kommentarer. (og NRKs linux-miljø er forøvrig flere ganger større en de rundt 50 serverene i løsningen nevnt i artikkelen.)

      Og igjen, vi bruker ikke Fabric som en erstatning for bash, men et rammeverk for å håndtere bl.a. remote execution på en elegant og effektiv måte. (med nyttige funksjoner som passordhåndtering, kontroll på parallell eksekvering mm.) Jeg kjenner ikke tilsvarende rammeverk skrevet i bash.

      Integrasjon med andre verktøy/systemer (som Jenkins) blir også lettere i python/Fabric, f.eks. parsing av JSON-data, da bibliotek for dette finnes lettere i python enn bash. Jobbing med datastrukturer er også langt lettere i python enn bash. (Vi bruker dette ganske aktivt i en funksjonalitet nevnt i artikkelen, som går på å varme opp webapps/fylle cache ut fra mest besøkte URL-er)

      Personlig, selv om jeg har jobbet mye mer med bash enn python, finner jeg python mye mer håndterlig enn bash til dette formålet.

  2. Spennende. Men hvorfor bruker man puppet på virtuelle maskiner? Jeg skjønner ikke poenget? Strider ikke det litt imot det å skulle ha et homogent miljø og å gjøre ting riktig fra starten? Jeg skjønner ikke engang hva slags utbytte man har av det – om det er den deklarative måten å konfe på så kan man metaprogrammere i sh om så skulle være nødvendig. Jeg liker devops-tankene men jeg tror mye er litt for grand scale for norske bedrifter. Jeg kan skjønne at Google eller rackspace trenger puppet – de har sikkert hundrevis av forskjellige operativsystem der med enda flere patchenivåer – men 50 vmer lissom?? Er det ikke bare å skrote dem og flekke opp et nytt image og kjøre det samme skriptet på klonene alt ettersom hvilken funksjon den skal ha da? ….. Homogent og riktig fra starten? Eller?

    Svar på denne kommentaren

    • Andreas Holen (NRK) (svar til Sverre)

      Hei Sverre. For det første så er ikke alle serverene våre virtuelle av forskjellige årsaker – så vi hadde trengt puppet uansett. Nytten av puppet (og andre konfigurasjonsstyringsverktøy) vises lenge før du får 50 servere. Det er dessuten raskere og billigere å endre litt på et puppet-manifest enn å tanke opp en ny server fra scratch.

      Typisk tanker vi en ny server med et «NRK-image» for Linux, og gir den et puppet-manifest så den settes opp riktig. Egentlig noen lunde det samme du skriver i siste delen av kommentaren din.

  3. Ulrik Sundby

    Hallo!

    Hva med å kunne velge streaming-kvalitet (bitrate) også for direktesendt innhold?

    Dette fungerte fint på forrige versjonen av nett-tv.

    Det kan ta fort to timer før en sending blir lagt i arkivet slik at man får muligheten å endre bitraten.

    Relevant for oss med mobilt bredbånd og fast månedlig datakvote.

    Jeg har riktignok 100 GB hos netcom, men en time stream for eksempel Dagsnytt 18– bruker kjapt 1.5 gb…

    Må da være bedre kapasitetsmessig også for dere om ikke alle skal streame i full pupp ?-)

    Svar på denne kommentaren

    • Marte Radmann (svar til Ulrik Sundby)

      Hei Ulrik,

      Alle direktestrømmene våre strømmes i 7 kvaliteter. Avspilleren på mobilen velger selv hvilken kvalitet den skal spille av avhengig av tilgjengelig prosessorkapasitet og båndbredde, såkalt adaptive strømning. På tv.nrk.no/innstillinger kan du, som du sier, hvor høy kvalitet du vil strømme, men denne innstillingen fungerer foreløpig bare for programmer i opptak. Vi har det på arbeidsplanen vår i høst å få denne innstillingen til også å gjelde for direktestrømmer.

      Hilsen Marte
      Prosjektleder for NRK TV og NRK Radio

Legg igjen en kommentar til Martin Bekkelund Avbryt svar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *. Les vår personvernserklæring for informasjon om hvilke data vi lagrer om deg som kommenterer.