streamalism.org

1. Oversikt

I denne opplæringen skal vi se på Spinnaker, en åpen kildekode kontinuerlig leveringsplattform bygget av Netflix. Vi kan bruke den til å distribuere applikasjonene våre over flere skyleverandører.

Systemet er bygget oppå Spring Boot og støtter mange skyleverandører.

Vi får se hvordan det fungerer og i hvilke tilfeller vi kan bruke det.

2. Bakgrunn

La oss ta en titt på historien om programvareutvikling. Først hadde vi fossen med sjeldne utgivelser.

Etter det begynte vi å jobbe Agile og leverte funksjoner hver eneste sprint. Imidlertid distribuerte vi fortsatt ikke til produksjon hver sprint. Dessverre kunne brukerne fortsatt ikke bruke de nye funksjonene, som lå på en hylle.

Det var noen grunner til ikke å distribuere regelmessig. En av dem var det faktum at distribusjonstrinn ofte ble utført manuelt og utsatt for menneskelige feil.

I tillegg trodde noen at distribusjon oftere innebar større risiko for potensielle problemer. I dag er vi stort sett enige om at distribusjon av små endringer betyr mindre risiko for store feil. Likevel, hvis det er en feil, kan vi raskt finne den i liten endring og gi ut en ny versjon som løser problemet.

3. Spinnaker

Med Spinnaker kan vi bruke kontinuerlig levering eller kontinuerlig distribusjon for å frigjøre applikasjonen vår om produksjon automatisk. Kontinuerlig levering betyr at alt er forberedt på en produksjonsutgivelse.

Utgivelsen godkjennes imidlertid manuelt før applikasjonen distribueres i produksjon. Kontinuerlig distribusjon betyr at det ikke er noen manuell inngrep. Alle trinn utføres, inkludert distribusjon til produksjon. Vi skyver bare søknadskoden vår til et versjonskontrollsystem, og det er det.

Fra å trykke koden vår til versjonskontroll til distribusjonen til produksjonen, kan vi utføre mange trinn. Vi kan bygge koden vår, enhetsteste koden, distribuere den på et testmiljø og utføre funksjonelle tester. Vi bruker en såkalt pipeline for å konfigurere alle disse trinnene.

Med Spinnaker kan vi lage en slik rørledning og distribuere applikasjonen vår på de fleste skyleverandører.

4. Komponenter

Spinnaker består i utgangspunktet av to deler: et abstraksjonslag på toppen av forskjellige skyleverandører og et verktøy for kontinuerlig levering.

4.1. Tradisjonelle skyinstallasjoner

Når vi ser på skyleverandører, tilbyr de alle mer eller mindre de samme tjenestene. Disse tjenestene inkluderer ting som forekomster, serverløs og containerstøtte.

Imidlertid varierer konfigurasjonen av disse tjenestene veldig mellom leverandørene. Det gjør det vanskeligere å bytte mellom leverandører. Det tar litt tid å flytte til en annen skyleverandør og lære alle detaljene, noe som betyr at vi i utgangspunktet har leverandørinnlåsing hos skyleverandøren.

Netflix ønsket å ha muligheten til enkelt å bytte mellom skyleverandører, i stedet for å være avhengig av bare en. Derfor bygde de et abstraksjonslag på skyleverandørene.

4.2. Abstraksjonssjikt

Når vi bruker Spinnaker, er det det samme for alle skyleverandører. Vi kan bruke den på Amazon Web Services, Microsoft Azure, Google Cloud Platform, OpenStack, Google App Engine eller Kubernetes. Dette gjør at vi kan flytte til en annen skyleverandør hvis prisene er mer konkurransedyktige.

Enda mer kan vi velge å distribuere til flere leverandører samtidig. På den måten kan vi kjøre applikasjonen vår på to eller flere leverandører for ekstra redundans.

En annen fordel med abstraksjonslaget er at det fokuserer på applikasjonene i stedet for ressursene. Normalt viser skyleverandører oss ressursene vi bruker for øyeblikket. Vi må imidlertid selv finne ut hvilken applikasjon som bruker hvilke ressurser.

Men ressurser er ikke interessante for oss. Vi ønsker å kjøre applikasjonen vår uten å bruke tid på å holde oversikt over ressursene. Spinnaker har et applikasjonssentrisk syn. Så når vi ser på det, ser vi først applikasjonen, og så ser vi ressursene som brukes av applikasjonen.

4.3. Kontinuerlig levering

På toppen av abstraksjonslaget bygde Netflix en kontinuerlig leveringsplattform. Denne plattformen lar oss distribuere applikasjonen vår på en eller flere skyleverandører. Det ser litt ut som Jenkins, men det gir bedre integrering med skyleverandørene og krever mindre konfigurasjon.

Vi kan utløse den kontinuerlige leveringsrørledningen fra Jenkins, for eksempel et opplastet Docker-bilde eller et git-trykk. Etter det kan vi bare lage et bilde eller en container med applikasjonen vår og starte den på produksjon.

Imidlertid er det mange flere tilgjengelige alternativer, for eksempel automatiserte tester og manuelle godkjenninger før de brukes på produksjon.

Vi kan til og med bestemme hvilken strategi vi vil følge når vi distribuerer en ny versjon av en eksisterende applikasjon. Som sådan er det mulig å bare erstatte den gamle versjonen med den nye versjonen. En bedre strategi ville imidlertid være å kjøre dem side om side først. På den måten kan vi automatisk eller manuelt sjekke om den nye versjonen fungerer, og i så fall fjerne den gamle versjonen.

5. Netflix Cloud Model

Hver applikasjon består av en eller flere servergrupper. Den samme versjonen av applikasjonen kjører på alle forekomster i servergruppen. Følgende navnekonvensjon brukes: ---. (Valgfritt) stabelfelt brukes til å spesifisere om servergruppen er for test, produksjon eller andre formål. Det valgfrie detaljfeltet brukes for ekstra informasjon.

Til slutt har vi konseptet med en klynge som inneholder en eller flere servergrupper med samme navn, stack og detalj. Imidlertid kjører det meste av tiden hver servergruppe i klyngen en annen versjon av applikasjonen. Mislykkede forekomster blir erstattet av en ny forekomst.

Det er også mulig å automatisk legge til forekomster i en servergruppe for å imøtekomme den økte belastningen.

6. Distribusjonsstrategi

Når vi distribuerer en ny versjon av en applikasjon, velges normalt “rød / svart” -strategien. Først distribueres en ny servergruppe som inneholder den nye versjonen av applikasjonen til klyngen. Etter applikasjonsdistribusjonen blir det utført en sjekk for å verifisere om den nye servergruppen er sunn.

Nå er servergruppen aktivert og tilgjengelig for våre kunder. Til slutt er den gamle servergruppen deaktivert.

I dette scenariet er det enkelt å rulle tilbake hvis noe går galt med den nye applikasjonsserveren. Vi kan ganske enkelt aktivere servergruppen med den gamle versjonen igjen og gjøre den tilgjengelig for våre kunder.

7. Hvorfor Spinnaker

Med Spinnaker kan vi fokusere på applikasjonen vår i stedet for skyressursene vi bruker. Dette gjør det lettere å distribuere og vedlikeholde applikasjonene våre.

I tillegg gjør Spinnaker det mulig å kjøre på flere skyleverandører samtidig. Videre kan vi enkelt bytte til andre skyleverandører avhengig av prisstrategi og tilgjengelige funksjoner.

8. Konklusjon

Spinnaker bygger på opplevelsen av Netflix. Vi kan bruke deres kunnskap og arbeide på samme måte med minimal innsats. Basert på disse verktøyene kan vi enkelt implementere en distribusjonsrørledning for å distribuere applikasjonene våre til produksjon.

For å lære mer om Spinnaker, last ned gratis kontinuerlig levering med Spinnaker eBok.