"Cloud native" eller ganske enkelt "cloud"-applikasjoner er laget spesielt for å fungere i skyinfrastrukturer. De er vanligvis bygget som et sett med løst koblede mikrotjenester pakket i containere, som igjen administreres av en skyplattform. Slike applikasjoner er forberedt på feil som standard, noe som betyr at de fungerer pålitelig og skaleres selv ved alvorlige feil på infrastrukturnivå. Den andre siden av mynten er settene med restriksjoner (kontrakter) som skyplattformen pålegger containerapplikasjoner for å kunne administrere dem automatisk.
Selv om de er fullt klar over behovet og viktigheten av å gå over til skybaserte applikasjoner, vet mange organisasjoner fortsatt ikke hvor de skal begynne. I dette innlegget vil vi se på en rekke prinsipper som, hvis de følges når du utvikler containeriserte applikasjoner, vil tillate deg å realisere potensialet til skyplattformer og oppnå pålitelig drift og skalering av applikasjoner selv i tilfelle alvorlige feil i IT-infrastrukturen nivå. Det endelige målet med prinsippene som er skissert her, er å lære å bygge applikasjoner som kan administreres automatisk av skyplattformer som Kubernetes.
Prinsipper for programvaredesign
I programmeringsverdenen refererer prinsipper til ganske generelle regler som må følges når man utvikler programvare. De kan brukes når du arbeider med et hvilket som helst programmeringsspråk. Hvert prinsipp har sine egne mål, verktøyene for å oppnå som vanligvis er maler og praksis. Det er også en rekke grunnleggende prinsipper for å lage programvare av høy kvalitet, som alle andre kommer fra. Her er noen eksempler på grunnleggende prinsipper:
- (Keep it simple, stupid) – ikke kompliser det;
- (Ikke gjenta deg selv) - ikke gjenta deg selv;
- (Du kommer ikke til å trenge det) - ikke lag noe som ikke er umiddelbart nødvendig;
- Separasjon av bekymringer – del ansvar.
Som du kan se, setter ikke disse prinsippene noen spesifikke regler, men tilhører kategorien såkalte sunn fornuftsbetraktninger basert på praktisk erfaring, som deles av mange utviklere og som de jevnlig refererer til.
I tillegg er det – Et sett med de fem første prinsippene for objektorientert programmering og design, formulert av Robert Martin. SOLID inkluderer brede, åpne, komplementære prinsipper som – når de brukes sammen – bidrar til å skape bedre programvaresystemer og bedre vedlikeholde dem på lang sikt.
SOLID-prinsippene tilhører feltet OOP og er formulert i språket til slike begreper og begreper som klasser, grensesnitt og arv. I analogi kan utviklingsprinsipper også formuleres for skyapplikasjoner, bare det grunnleggende elementet her vil ikke være en klasse, men en container. Ved å følge disse prinsippene kan du lage containeriserte applikasjoner som bedre oppfyller målene og målene til skyplattformer som Kubernetes.
Cloud-native containere: Red Hat-tilnærmingen
I dag kan nesten alle applikasjoner pakkes relativt enkelt inn i beholdere. Men for at applikasjoner skal bli effektivt automatisert og orkestrert innenfor en skyplattform som Kubernetes, kreves det ekstra innsats.
Grunnlaget for ideene skissert nedenfor var metodikken og mange andre arbeider med ulike aspekter ved å bygge nettapplikasjoner, fra kildekodeadministrasjon til skaleringsmodeller. Prinsippene som beskrives gjelder kun for utvikling av containeriserte applikasjoner som er bygget på toppen av mikrotjenester og designet for skyplattformer som Kubernetes. Det grunnleggende elementet i diskusjonen vår er containerbildet, og målbeholderens kjøretid er containerorkestreringsplattformen. Målet med de foreslåtte prinsippene er å lage beholdere der planlegging, skalering og overvåkingsoppgaver kan automatiseres på de fleste orkestreringsplattformer. Prinsippene presenteres i ingen spesiell rekkefølge.
Single Concern Principle (SCP)
Dette prinsippet ligner på mange måter Single Responsibility Principle. ), som er en del av SOLID-settet og sier at hvert objekt må ha ett ansvar, og at ansvaret må være fullstendig innkapslet i en klasse. Poenget med SRP er at ethvert ansvar er en årsak til endring, og en klasse må ha én og bare én årsak til endring.
I SCP bruker vi ordet "bekymring" i stedet for ordet "ansvar" for å indikere det høyere abstraksjonsnivået og bredere formålet med en beholder sammenlignet med en OOP-klasse. Og hvis målet med SRP er å kun ha én grunn til endring, så ligger bak SCP ønsket om å utvide muligheten til å gjenbruke og erstatte containere. Ved å følge SRP og lage en container som løser et enkelt problem og gjør det på en funksjonelt komplett måte, øker du sjansene for å gjenbruke det containerbildet i ulike applikasjonskontekster.
SCP-prinsippet sier at hver container skal løse ett enkelt problem og gjøre det bra. Dessuten er SCP i containerverdenen lettere å oppnå enn SRP i OOP-verdenen, siden containere vanligvis kjører én enkelt prosess, og som oftest løser denne prosessen én enkelt oppgave.
Hvis en containermikrotjeneste må løse flere problemer på en gang, kan den deles inn i enkeltoppdragsbeholdere og kombineres i én pod (en enhet av containerplattformdistribusjon) ved å bruke sidevogn- og initbeholdermaler. I tillegg gjør SCP det enkelt å erstatte en gammel container (som en webserver eller meldingsmegler) med en ny som løser det samme problemet, men som har utvidet funksjonalitet eller skalerer bedre.
Høyt observerbarhetsprinsipp (HOP)
Når beholdere brukes som en enhetlig måte å pakke og kjøre applikasjoner på, behandles applikasjonene i seg selv som en svart boks. Men hvis disse er skybeholdere, må de gi spesielle APIer til kjøretiden for å overvåke helsen til beholderne og, om nødvendig, iverksette passende tiltak. Uten dette vil det ikke være mulig å forene automatiseringen av å oppdatere beholdere og administrere deres livssyklus, noe som igjen vil forringe stabiliteten og brukervennligheten til programvaresystemet.
I praksis bør en containerisert applikasjon som et minimum ha et API for ulike typer helsesjekker: livlighetstester og beredskapstester. Hvis en applikasjon hevder å gjøre mer, må den tilby andre måter å overvåke tilstanden på. For eksempel logging av viktige hendelser via STDERR og STDOUT for loggaggregering ved bruk av Fluentd, Logstash og andre lignende verktøy. Samt integrasjon med sporings- og metrikksamlingsbiblioteker, som OpenTracing, Prometheus, etc.
Generelt kan applikasjonen fortsatt behandles som en svart boks, men den må være utstyrt med alle APIer som plattformen trenger for å overvåke og administrere den på best mulig måte.
Livssykluskonformitetsprinsipp (LCP)
LCP er antitesen til HOP. Mens HOP sier at containeren må eksponere lese-APIer til plattformen, krever LCP at applikasjonen skal kunne akseptere informasjon fra plattformen. Dessuten må beholderen ikke bare motta hendelser, men også tilpasse seg, med andre ord, reagere på dem. Derav navnet på prinsippet, som kan betraktes som et krav for å gi plattformen skrive-APIer.
Plattformer har forskjellige typer hendelser for å hjelpe med å administrere livssyklusen til en container. Men det er opp til søknaden selv å bestemme hvem av dem som skal oppfattes og hvordan de skal reagere.
Det er tydelig at noen hendelser er viktigere enn andre. For eksempel, hvis en applikasjon ikke tåler krasj godt, må den godta signal: terminate (SIGTERM) meldinger og starte sin termineringsrutine så raskt som mulig for å fange signalet: kill (SIGKILL) som kommer etter SIGTERM.
I tillegg kan hendelser som PostStart og PreStop være viktige for livssyklusen til en applikasjon. For eksempel, etter å ha startet et program, kan det kreve litt oppvarmingstid før det kan svare på forespørsler. Eller applikasjonen må frigjøre ressurser på en spesiell måte når den stenges.
The Image Immutability Principle (IIP)
Det er generelt akseptert at containeriserte applikasjoner skal forbli uendret etter å ha blitt bygget, selv om de kjøres i forskjellige miljøer. Dette nødvendiggjør behovet for å eksternalisere datalagring ved kjøretid (med andre ord å bruke eksterne verktøy for dette) og å stole på eksterne, kjøretidsspesifikke konfigurasjoner, i stedet for å modifisere eller lage unike beholdere for hvert miljø. Etter eventuelle endringer i applikasjonen, må beholderbildet bygges om og distribueres til alle miljøer som brukes. Forresten, når man administrerer IT-systemer, brukes et lignende prinsipp, kjent som prinsippet om uforanderlighet av servere og infrastruktur.
Målet med IIP er å forhindre opprettelsen av separate containerbilder for forskjellige kjøretidsmiljøer og å bruke det samme bildet overalt sammen med den aktuelle miljøspesifikke konfigurasjonen. Ved å følge dette prinsippet kan du implementere slike viktige praksiser med tanke på automatisering av skysystemer som tilbakerulling og fremrulling av applikasjonsoppdateringer.
Process Disposability Principle (PDP)
En av de viktigste egenskapene til en container er dens flyktighet: en forekomst av en container er lett å lage og lett å ødelegge, så den kan enkelt erstattes med en annen forekomst når som helst. Det kan være mange årsaker til en slik utskifting: feil i en brukbarhetstest, skalering av applikasjonen, overføring til en annen vert, utmattelse av plattformressurser eller andre situasjoner.
Som en konsekvens må containeriserte applikasjoner opprettholde sin tilstand ved å bruke noen eksterne midler, eller bruke interne distribuerte ordninger med redundans for dette. I tillegg må applikasjonen starte raskt og slå seg av raskt, og være forberedt på plutselig fatal maskinvarefeil.
En praksis som bidrar til å implementere dette prinsippet er å holde beholdere små. Skymiljøer kan automatisk velge en vert å starte en beholderforekomst på, så jo mindre beholderen er, desto raskere starter den – den vil ganske enkelt kopiere til målverten over nettverket raskere.
Selvstendighetsprinsipp (S-CP)
I henhold til dette prinsippet, på monteringsstadiet, er alle nødvendige komponenter inkludert i beholderen. Beholderen bør bygges på antakelsen om at systemet kun har en ren Linux-kjerne, så alle nødvendige tilleggsbiblioteker bør plasseres i selve beholderen. Den bør også inneholde ting som kjøretiden for det korresponderende programmeringsspråket, applikasjonsplattformen (om nødvendig) og andre avhengigheter som kreves mens containerapplikasjonen kjører.
Unntak er gjort for konfigurasjoner som varierer fra miljø til miljø og må leveres under kjøring, for eksempel gjennom et Kubernetes ConfigMap.
En applikasjon kan inneholde flere containeriserte komponenter, for eksempel en separat DBMS-beholder i en containerisert nettapplikasjon. I henhold til S-CP-prinsippet skal disse beholderne ikke kombineres til én, men lages slik at DBMS-beholderen inneholder alt som er nødvendig for driften av databasen, og webapplikasjonsbeholderen inneholder alt som er nødvendig for driften av nettet. applikasjon, samme webserver . Som et resultat vil webapplikasjonsbeholderen under kjøring avhenge av DBMS-beholderen og få tilgang til den etter behov.
Runtime Confinement Principle (RCP)
S-CP-prinsippet definerer hvordan beholderen skal bygges og hva bildebinæren skal inneholde. Men en beholder er ikke bare en "svart boks" som bare har én egenskap - filstørrelse. Under kjøring får beholderen andre dimensjoner: mengden minne som brukes, CPU-tid og andre systemressurser.
Og her kommer RCP-prinsippet godt med, ifølge hvilket containeren må halshugge kravene til systemressurser og overføre dem til plattformen. Med hver containers ressursprofiler (hvor mye CPU, minne, nettverk og diskressurser den trenger), kan plattformen optimalt utføre planlegging og autoskalering, administrere IT-kapasitet og opprettholde SLA-nivåer for containere.
I tillegg til å oppfylle ressurskravene til containeren, er det også viktig at søknaden ikke går utover egne grenser. Ellers, når en ressursmangel oppstår, er det mer sannsynlig at plattformen inkluderer den i listen over applikasjoner som må avsluttes eller migreres.
Når vi snakker om å være skyen først, snakker vi om måten vi jobber på.
Ovenfor formulerte vi en rekke generelle prinsipper som legger det metodiske grunnlaget for å bygge høykvalitets containerapplikasjoner for skymiljøer.
Merk at i tillegg til disse generelle prinsippene, vil du også trenge ytterligere avanserte metoder og teknikker for å jobbe med containere. I tillegg har vi noen korte anbefalinger som er mer spesifikke og bør brukes (eller ikke brukes) avhengig av situasjonen:
- Prøv å redusere størrelsen på bilder: slett midlertidige filer og ikke installer unødvendige pakker - jo mindre beholderstørrelsen er, jo raskere blir den satt sammen og kopiert til målverten over nettverket.
- Fokuser på vilkårlige bruker-IDer: ikke bruk sudo-kommandoen eller noen spesiell bruker-ID for å starte containerne dine.
- Merk viktige porter: Du kan angi portnumre under kjøring, men det er bedre å spesifisere dem ved å bruke EXPOSE-kommandoen – det vil gjøre det lettere for andre mennesker og programmer å bruke bildene dine.
- Lagre vedvarende data på volumer: Data som skal forbli etter at beholderen er ødelagt, skal skrives til volumer.
- Skriv bildemetadata: tagger, etiketter og merknader gjør bilder enklere å bruke - andre utviklere vil takke deg.
- Synkroniser vert og bilder: Noen containerbaserte applikasjoner krever at beholderen synkroniseres med verten på visse attributter, for eksempel tid eller maskin-ID.
- Avslutningsvis deler vi maler og beste praksis som vil hjelpe deg med å implementere prinsippene som er oppført ovenfor mer effektivt:
11. juni kl 11.00
Hva vil du lære:
- Uforanderlig Red Hat Enterprise Linux CoreOS
- OpenShift-tjenestenettverk
- Operatørramme
- Knative rammeverk
Kilde: www.habr.com