streamalism.org

1. Oversigt

I denne vejledning skal vi se på Spinnaker, en open source-kontinuerlig leveringsplatform bygget af Netflix. Vi kan bruge det til at implementere vores applikationer på tværs af flere cloud-udbydere.

Systemet er bygget oven på Spring Boot og understøtter mange skyudbydere.

Vi får se, hvordan det fungerer, og i hvilke tilfælde vi kan bruge det.

2. Baggrund

Lad os se på historien om softwareudvikling. For det første havde vi vandfaldet med sjældne udgivelser.

Derefter begyndte vi at arbejde Agile og leverede funktioner hver sprint. Imidlertid implementerede vi stadig ikke til produktion hver sprint. Desværre kunne brugerne stadig ikke bruge de nye funktioner, der lå på en hylde.

Der var nogle grunde til ikke at implementere regelmæssigt. En af dem var det faktum, at implementeringstrin ofte blev udført manuelt og udsat for menneskelige fejl.

Derudover troede nogle mennesker, at implementering oftere betød større risiko for potentielle problemer. I dag er vi mest enige om, at implementering af små ændringer betyder mindre risiko for store fejl. Alligevel, hvis der er en fejl, kan vi hurtigt finde den i den lille ændring og frigive en ny version, der løser problemet.

3. Spinnaker

Med Spinnaker kan vi bruge kontinuerlig levering eller kontinuerlig implementering til automatisk at frigive vores applikation til produktion. Kontinuerlig levering betyder, at alt er klar til en produktionsudgivelse.

Frigivelsen godkendes dog manuelt, inden applikationen implementeres i produktion. Kontinuerlig implementering betyder, at der ikke er nogen manuel indgriben. Alle trin udføres, inklusive implementering til produktion. Vi skubber bare vores applikationskode til et versionskontrolsystem, og det er det.

Fra at skubbe vores kode til versionskontrol indtil implementeringen til produktion kan vi udføre mange trin. Vi kan bygge vores kode, enhedsteste koden, implementere den i et testmiljø og udføre funktionelle tests. Vi bruger en såkaldt pipeline til at konfigurere alle disse trin.

Med Spinnaker kan vi oprette en sådan pipeline og implementere vores applikation på de fleste cloud-udbydere.

4. Komponenter

Spinnaker består grundlæggende af to dele: et abstraktionslag oven på forskellige cloud-udbydere og et værktøj til kontinuerlig levering.

4.1. Traditionelle skyinstallationer

Når vi ser på skyudbydere, tilbyder de alle mere eller mindre de samme tjenester. Disse tjenester inkluderer ting som forekomster, serverløs og containersupport.

Imidlertid varierer konfigurationen af ​​disse tjenester meget mellem udbyderne. Det gør det sværere at skifte mellem udbydere. Det tager lidt tid at flytte til en anden skyudbyder og lære alle detaljerne, hvilket betyder, at vi stort set har leverandørlås med vores skyudbyder.

Netflix ønskede at have muligheden for let at skifte mellem cloud-udbydere snarere end at være afhængige af kun en. Derfor byggede de et abstraktionslag oven på skyudbyderne.

4.2. Abstraktionslag

Når vi bruger Spinnaker, er det det samme for alle cloud-udbydere. Vi kan bruge det på Amazon Web Services, Microsoft Azure, Google Cloud Platform, OpenStack, Google App Engine eller Kubernetes. Dette giver os mulighed for at flytte til en anden skyudbyder, hvis priserne er mere konkurrencedygtige.

Endnu mere kan vi vælge at implementere hos flere udbydere på samme tid. På den måde kan vi køre vores applikation på to eller flere udbydere for ekstra redundans.

En anden fordel ved abstraktionslaget er, at det fokuserer på applikationerne i stedet for ressourcerne. Normalt viser cloududbydere os de ressourcer, vi bruger i øjeblikket. Vi skal dog selv finde ud af, hvilken applikation der bruger hvilke ressourcer.

Men ressourcer er ikke interessante for os. Vi ønsker at køre vores applikation uden at bruge tid på at holde styr på ressourcerne. Spinnaker har en applikationscentreret visning. Så når vi ser på det, ser vi først applikationen, og så ser vi de ressourcer, der bruges af applikationen.

4.3. Kontinuerlig levering

Oven på abstraktionslaget byggede Netflix en kontinuerlig leveringsplatform. Denne platform giver os mulighed for at implementere vores applikation på en eller flere cloud-udbydere. Det ligner lidt Jenkins, men det giver pænere integration med cloud-udbydere og kræver mindre konfiguration.

Vi kan udløse den kontinuerlige leveringsrørledning for eksempel fra Jenkins, et uploadet Docker-billede eller et git-push. Derefter kan vi blot oprette et billede eller en container med vores applikation og starte det med produktion.

Der er dog mange flere muligheder, såsom automatiserede tests og manuelle godkendelser, inden de implementeres på produktion.

Vi kan endda beslutte, hvilken strategi vi vil følge, når vi implementerer en ny version af en eksisterende applikation. Som sådan er det muligt simpelthen at erstatte den gamle version med den nye version. En bedre strategi ville imidlertid være at køre dem side om side først. På den måde kan vi automatisk eller manuelt kontrollere, om den nye version fungerer, og i så fald fjerne den gamle version.

5. Netflix Cloud Model

Hver applikation består af en eller flere servergrupper. Den samme version af applikationen kører på alle forekomster i servergruppen. Følgende navngivningskonvention bruges: ---. (Valgfri) stakfelt bruges til at specificere, om servergruppen er til test, produktion eller andre formål. Det valgfri detaljeringsfelt bruges til ekstra information.

Endelig har vi konceptet med en klynge, der indeholder en eller flere servergrupper med samme navn, stak og detalje. Imidlertid kører det meste af tiden hver servergruppe i klyngen en anden version af applikationen. Mislykkede forekomster erstattes af en ny forekomst.

Det er også muligt automatisk at tilføje forekomster til en servergruppe for at imødekomme den øgede belastning.

6. Implementeringsstrategi

Når vi distribuerer en ny version af en applikation, vælges "rød / sort" -strategien normalt. Først indsættes en ny servergruppe, der indeholder den nye version af applikationen, til klyngen. Efter applikationsinstallationen udføres en kontrol for at kontrollere, om den nye servergruppe er sund.

Nu er servergruppen aktiveret og tilgængelig for vores kunder. Endelig er den gamle servergruppe deaktiveret.

I dette scenarie er det let at rulle tilbage, hvis noget går galt med den nye applikationsserver. Vi kan blot aktivere servergruppen med den gamle version igen og gøre den tilgængelig for vores kunder.

7. Hvorfor Spinnaker

Med Spinnaker kan vi fokusere på vores applikation i stedet for de skyressourcer, vi bruger. Dette gør det lettere at implementere og vedligeholde vores applikationer.

Derudover gør Spinnaker det muligt at køre på flere cloud-udbydere på samme tid. Desuden kan vi nemt skifte til andre cloud-udbydere afhængigt af deres prisstrategi og tilgængelige funktioner.

8. Konklusion

Spinnaker bygger på oplevelsen af ​​Netflix. Vi kan bruge deres viden og arbejde på samme måde med minimal indsats. Baseret på disse værktøjer kan vi nemt implementere en implementeringspipeline til at implementere vores applikationer til produktion.

Hvis du vil lære mere om Spinnaker, skal du downloade den gratis kontinuerlige levering med Spinnaker e-bog.