"Cloud native" eller blot "cloud" applikationer er skabt specifikt til at arbejde i cloud infrastrukturer. De er typisk bygget som et sæt af løst koblede mikrotjenester pakket i containere, som igen styres af en cloud-platform. Sådanne applikationer er som standard forberedt på fejl, hvilket betyder, at de fungerer pålideligt og skaleres selv i tilfælde af alvorlige fejl på infrastrukturniveau. Den anden side af medaljen er de sæt af restriktioner (kontrakter), som cloud-platformen pålægger containerapplikationer for at kunne administrere dem automatisk.
Selvom de er fuldt ud klar over behovet og vigtigheden af at flytte til cloud-baserede applikationer, ved mange organisationer stadig ikke, hvor de skal starte. I dette indlæg vil vi se på en række principper, som, hvis de følges ved udvikling af containeriserede applikationer, vil give dig mulighed for at realisere potentialet i cloud-platforme og opnå pålidelig drift og skalering af applikationer selv i tilfælde af alvorlige fejl i IT-infrastrukturen niveau. Det ultimative mål med principperne, der er skitseret her, er at lære, hvordan man bygger applikationer, der automatisk kan administreres af cloud-platforme såsom Kubernetes.
Softwaredesignprincipper
I programmeringsverdenen henviser principper til ret generelle regler, som skal følges ved udvikling af software. De kan bruges, når du arbejder med et hvilket som helst programmeringssprog. Hvert princip har sine egne mål, værktøjerne til at opnå, som normalt er skabeloner og praksisser. Der er også en række grundlæggende principper for at skabe software af høj kvalitet, som alle andre udspringer af. Her er nogle eksempler på grundlæggende principper:
- (Keep it simple, stupid) – komplicer det ikke;
- (Gentag ikke dig selv) - gentag ikke dig selv;
- (Du får ikke brug for det) - skab ikke noget, der ikke umiddelbart er nødvendigt;
- Adskillelse af bekymringer – del ansvar.
Som du kan se, sætter disse principper ikke nogle specifikke regler, men hører til kategorien af såkaldte common sense-betragtninger baseret på praktisk erfaring, som deles af mange udviklere, og som de jævnligt henviser til.
Derudover er der – Et sæt af de første fem principper for objektorienteret programmering og design, formuleret af Robert Martin. SOLID omfatter brede, åbne, komplementære principper, der – når de anvendes sammen – hjælper med at skabe bedre softwaresystemer og bedre vedligeholde dem på lang sigt.
SOLID-principperne hører til området OOP og er formuleret i sproget for sådanne begreber og begreber som klasser, grænseflader og arv. Analogt kan udviklingsprincipper også formuleres for cloud-applikationer, kun det grundlæggende element her vil ikke være en klasse, men en container. Ved at følge disse principper kan du skabe containeriserede applikationer, der bedre opfylder målene og målene for cloud-platforme som Kubernetes.
Cloud-native containere: Red Hat-tilgangen
I dag kan næsten enhver applikation relativt let pakkes ind i beholdere. Men for at applikationer effektivt kan automatiseres og orkestreres inden for en cloudplatform som Kubernetes, kræves der yderligere indsats.
Grundlaget for de ideer, der er skitseret nedenfor, var metoden og mange andre arbejder med forskellige aspekter af opbygning af webapplikationer, fra kildekodestyring til skaleringsmodeller. De beskrevne principper gælder kun for udvikling af containeriserede applikationer, der er bygget oven på mikrotjenester og designet til cloud-platforme såsom Kubernetes. Det grundlæggende element i vores diskussion er containerbilledet, og målet container runtime er container orkestreringsplatformen. Målet med de foreslåede principper er at skabe containere, for hvilke planlægnings-, skalerings- og overvågningsopgaver kan automatiseres på de fleste orkestreringsplatforme. Principperne er præsenteret i nogen bestemt rækkefølge.
Single Concern Principle (SCP)
Dette princip ligner på mange måder princippet om det fælles ansvar. ), som er en del af SOLID-sættet og siger, at hvert objekt skal have ét ansvar, og det ansvar skal være fuldstændig indkapslet i en klasse. Pointen med SRP er, at ethvert ansvar er en grund til forandring, og en klasse skal have én og kun én grund til forandring.
I SCP bruger vi ordet "bekymring" i stedet for ordet "ansvar" for at angive det højere abstraktionsniveau og bredere formål med en container sammenlignet med en OOP-klasse. Og hvis målet med SRP kun er at have én grund til forandring, så ligger bag SCP ønsket om at udvide muligheden for at genbruge og erstatte containere. Ved at følge SRP'en og skabe en container, der løser et enkelt problem og gør det på en funktionelt komplet måde, øger du chancerne for at genbruge det containerbillede i forskellige applikationssammenhænge.
SCP-princippet siger, at hver container skal løse et enkelt problem og gøre det godt. Desuden er SCP i containerverdenen nemmere at opnå end SRP i OOP-verdenen, da containere normalt kører én enkelt proces, og som oftest løser denne proces én enkelt opgave.
Hvis en containermikroservice skal løse flere problemer på én gang, kan den opdeles i enkeltopgavecontainere og kombineres i én pod (en enhed for containerplatforminstallation) ved hjælp af sidevogns- og init-containerskabeloner. Derudover gør SCP det nemt at udskifte en gammel container (såsom en webserver eller meddelelsesmægler) med en ny, der løser samme problem, men som har udvidet funktionalitet eller skalerer bedre.
High Observability Principle (HOP)
Når containere bruges som en samlet måde at pakke og køre applikationer på, behandles applikationerne selv som en sort boks. Men hvis disse er cloud-containere, skal de levere specielle API'er til runtime for at overvåge containernes tilstand og om nødvendigt træffe passende foranstaltninger. Uden dette vil det ikke være muligt at forene automatiseringen af opdatering af containere og styring af deres livscyklus, hvilket igen vil forværre stabiliteten og anvendeligheden af softwaresystemet.
I praksis bør en containeriseret applikation som minimum have en API til forskellige typer helbredstjek: livhedstest og parathedstest. Hvis en applikation hævder at gøre mere, skal den give andre midler til at overvåge dens tilstand. For eksempel logning af vigtige hændelser via STDERR og STDOUT til log-aggregering ved hjælp af Fluentd, Logstash og andre lignende værktøjer. Samt integration med sporings- og metriksamlingsbiblioteker, såsom OpenTracing, Prometheus osv.
Generelt kan applikationen stadig behandles som en sort boks, men den skal forsynes med alle de API'er, som platformen har brug for, for at overvåge og administrere den bedst muligt.
Livscyklusoverensstemmelsesprincip (LCP)
LCP er antitesen til HOP. Mens HOP angiver, at containeren skal eksponere læste API'er til platformen, kræver LCP, at applikationen kan acceptere information fra platformen. Desuden skal containeren ikke kun modtage begivenheder, men også tilpasse sig, med andre ord reagere på dem. Deraf navnet på princippet, som kan betragtes som et krav for at forsyne platformen med skrive-API'er.
Platforme har forskellige typer begivenheder for at hjælpe med at styre en containers livscyklus. Men det er op til ansøgningen selv at afgøre, hvilke af dem der skal opfattes, og hvordan de skal reagere.
Det er klart, at nogle begivenheder er vigtigere end andre. For eksempel, hvis en applikation ikke tolererer nedbrud godt, skal den acceptere signal: terminate (SIGTERM) beskeder og starte sin termineringsrutine så hurtigt som muligt for at fange signalet: kill (SIGKILL), der kommer efter SIGTERM.
Derudover kan begivenheder som PostStart og PreStop være vigtige for en applikations livscyklus. For eksempel, efter at have startet en applikation, kan det kræve noget opvarmningstid, før det kan reagere på anmodninger. Eller applikationen skal frigive ressourcer på en speciel måde, når den lukkes ned.
The Image Immutability Principle (IIP)
Det er generelt accepteret, at containeriserede applikationer skal forblive uændrede efter at være blevet bygget, selvom de køres i forskellige miljøer. Dette nødvendiggør behovet for at eksternalisere datalagring ved runtime (med andre ord at bruge eksterne værktøjer til dette) og at stole på eksterne, runtime-specifikke konfigurationer i stedet for at ændre eller skabe unikke containere for hvert miljø. Efter eventuelle ændringer af applikationen skal containerbilledet genopbygges og implementeres i alle anvendte miljøer. Forresten, når man administrerer IT-systemer, bruges et lignende princip, kendt som princippet om uforanderlighed af servere og infrastruktur.
Målet med IIP er at forhindre oprettelsen af separate containerbilleder til forskellige runtime-miljøer og at bruge det samme billede overalt sammen med den passende miljøspecifikke konfiguration. At følge dette princip giver dig mulighed for at implementere så vigtige praksisser fra et synspunkt om automatisering af cloud-systemer som roll-back og roll-forward af applikationsopdateringer.
Process Disposability Principle (PDP)
En af de vigtigste egenskaber ved en container er dens flygtigehed: en forekomst af en container er let at skabe og let at ødelægge, så den kan let erstattes med en anden forekomst til enhver tid. Der kan være mange årsager til en sådan udskiftning: svigt af en brugbarhedstest, skalering af applikationen, overførsel til en anden vært, udmattelse af platformsressourcer eller andre situationer.
Som en konsekvens skal containeriserede applikationer opretholde deres tilstand ved hjælp af nogle eksterne midler, eller bruge interne distribuerede ordninger med redundans til dette. Derudover skal applikationen starte hurtigt og lukke hurtigt ned, og være forberedt på pludselig fatal hardwarefejl.
En praksis, der hjælper med at implementere dette princip, er at holde beholdere små. Skymiljøer kan automatisk vælge en vært til at starte en containerforekomst på, så jo mindre containeren er, desto hurtigere starter den – den kopierer simpelthen til målværten over netværket hurtigere.
Selvindeholdelsesprincip (S-CP)
I henhold til dette princip er alle nødvendige komponenter på monteringsstadiet inkluderet i beholderen. Containeren skal bygges ud fra den antagelse, at systemet kun har en ren Linux-kerne, så alle de nødvendige ekstra biblioteker skal placeres i selve containeren. Det bør også indeholde ting som kørselstiden for det tilsvarende programmeringssprog, applikationsplatformen (hvis nødvendigt) og andre afhængigheder, der kræves, mens containerapplikationen kører.
Der gøres undtagelser for konfigurationer, der varierer fra miljø til miljø og skal leveres under kørsel, for eksempel gennem et Kubernetes ConfigMap.
En applikation kan omfatte flere containeriserede komponenter, for eksempel en separat DBMS container i en containeriseret webapplikation. Ifølge S-CP-princippet skal disse containere ikke kombineres til én, men skal laves således, at DBMS-containeren indeholder alt nødvendigt for driften af databasen, og webapplikationscontaineren indeholder alt, hvad der er nødvendigt for driften af nettet. applikation, den samme webserver. Som et resultat vil webapplikationscontaineren under kørsel afhænge af DBMS-beholderen og få adgang til den efter behov.
Runtime Confinement Principle (RCP)
S-CP princippet definerer, hvordan beholderen skal bygges, og hvad det binære billede skal indeholde. Men en container er ikke bare en "sort boks", der kun har én egenskab - filstørrelse. Under udførelsen antager containeren andre dimensioner: mængden af brugt hukommelse, CPU-tid og andre systemressourcer.
Og her kommer RCP-princippet godt med, hvorefter containeren skal halshugge sine krav til systemressourcer og overføre dem til platformen. Med hver containers ressourceprofiler (hvor mange CPU-, hukommelses-, netværks- og diskressourcer den har brug for), kan platformen optimalt udføre planlægning og autoskalering, administrere IT-kapacitet og vedligeholde SLA-niveauer for containere.
Udover at opfylde containerens ressourcekrav, er det også vigtigt, at applikationen ikke går ud over sine egne grænser. Ellers, når der opstår ressourcemangel, er det mere sandsynligt, at platformen inkluderer det på listen over applikationer, der skal afsluttes eller migreres.
Når vi taler om at være cloud-first, taler vi om den måde, vi arbejder på.
Ovenfor har vi formuleret en række generelle principper, der sætter det metodiske grundlag for at bygge højkvalitets containerapplikationer til cloudmiljøer.
Bemærk, at du ud over disse generelle principper også skal bruge yderligere avancerede metoder og teknikker til at arbejde med containere. Derudover har vi et par korte anbefalinger, der er mere specifikke og bør anvendes (eller ikke anvendes) afhængigt af situationen:
- Prøv at reducere størrelsen af billeder: slet midlertidige filer og installer ikke unødvendige pakker - jo mindre containerstørrelsen er, jo hurtigere samles den og kopieres til målværten over netværket.
- Fokus på vilkårlige bruger-id'er: brug ikke sudo-kommandoen eller noget særligt bruger-id til at starte dine containere.
- Marker vigtige porte: Du kan indstille portnumre under kørsel, men det er bedre at angive dem ved hjælp af EXPOSE-kommandoen – det vil gøre det lettere for andre mennesker og programmer at bruge dine billeder.
- Gem vedvarende data på volumener: Data, der skal forblive, efter at containeren er destrueret, skal skrives til volumener.
- Skriv billedmetadata: tags, etiketter og annoteringer gør billeder nemmere at bruge - andre udviklere vil takke dig.
- Synkroniser vært og billeder: Nogle containeriserede applikationer kræver, at containeren synkroniseres med værten på bestemte attributter, såsom tid eller maskin-id.
- Afslutningsvis deler vi skabeloner og bedste praksis, der vil hjælpe dig med at implementere ovenstående principper mere effektivt:
11. juni klokken 11.00
Hvad vil du lære:
- Uforanderlig Red Hat Enterprise Linux CoreOS
- OpenShift service mesh
- Operatørramme
- Knative rammer
Kilde: www.habr.com