Aplicațiile „Cloud native” sau pur și simplu „cloud” sunt create special pentru a funcționa în infrastructurile cloud. Ele sunt de obicei construite ca un set de microservicii slab cuplate, ambalate în containere, care, la rândul lor, sunt gestionate de o platformă cloud. Astfel de aplicații sunt pregătite pentru defecțiuni în mod implicit, ceea ce înseamnă că funcționează fiabil și se scalează chiar și în cazul unor defecțiuni grave la nivel de infrastructură. Cealaltă față a monedei sunt seturile de restricții (contracte) pe care platforma cloud le impune aplicațiilor container pentru a le putea gestiona automat.
Deși sunt pe deplin conștiente de necesitatea și importanța trecerii la aplicații bazate pe cloud, multe organizații încă nu știu de unde să înceapă. În această postare, ne vom uita la o serie de principii care, dacă sunt urmate atunci când dezvoltați aplicații containerizate, vă vor permite să realizați potențialul platformelor cloud și să obțineți o funcționare și scalare fiabilă a aplicațiilor chiar și în cazul unor defecțiuni grave la infrastructura IT. nivel. Scopul final al principiilor subliniate aici este de a învăța cum să construiești aplicații care pot fi gestionate automat de platforme cloud, cum ar fi Kubernetes.
Principii de proiectare software
În lumea programării, principiile se referă la reguli destul de generale care trebuie respectate la dezvoltarea software-ului. Ele pot fi folosite atunci când lucrați cu orice limbaj de programare. Fiecare principiu are propriile sale obiective, instrumentele de realizare care sunt de obicei șabloane și practici. Există, de asemenea, o serie de principii fundamentale pentru crearea de software de înaltă calitate, din care derivă toate celelalte. Iată câteva exemple de principii fundamentale:
- (Keep it simple, stupid) – nu-l complica;
- (Don't repeat yourself) - nu te repeta;
- (Nu veți avea nevoie de el) - nu creați ceva care nu este necesar imediat;
- Separarea preocupărilor – împărțiți responsabilitățile.
După cum puteți vedea, aceste principii nu stabilesc reguli specifice, ci aparțin categoriei așa-numitelor considerații de bun simț bazate pe experiență practică, care sunt împărtășite de mulți dezvoltatori și la care se referă în mod regulat.
În plus, există – Un set al primelor cinci principii de programare și design orientate pe obiecte, formulate de Robert Martin. SOLID include principii ample, deschise și complementare care, atunci când sunt aplicate împreună, ajută la crearea unor sisteme software mai bune și la menținerea mai bună a acestora pe termen lung.
Principiile SOLID aparțin domeniului OOP și sunt formulate în limbajul unor concepte și concepte precum clase, interfețe și moștenire. Prin analogie, principiile de dezvoltare pot fi formulate și pentru aplicațiile cloud, doar că elementul de bază aici nu va fi o clasă, ci un container. Urmând aceste principii, puteți crea aplicații containerizate care îndeplinesc mai bine scopurile și obiectivele platformelor cloud precum Kubernetes.
Containere native din cloud: abordarea Red Hat
Astăzi, aproape orice aplicație poate fi ambalată relativ ușor în containere. Dar pentru ca aplicațiile să fie automatizate și orchestrate în mod eficient într-o platformă cloud precum Kubernetes, este necesar un efort suplimentar.
Baza ideilor prezentate mai jos a fost metodologia și multe alte lucrări pe diverse aspecte ale construirii de aplicații web, de la managementul codului sursă la modele de scalare. Principiile descrise se aplică numai dezvoltării de aplicații containerizate care sunt construite pe baza microserviciilor și concepute pentru platforme cloud, cum ar fi Kubernetes. Elementul de bază în discuția noastră este imaginea containerului, iar timpul de rulare a containerului țintă este platforma de orchestrare a containerului. Scopul principiilor propuse este de a crea containere pentru care sarcinile de programare, scalare și monitorizare pot fi automatizate pe majoritatea platformelor de orchestrare. Principiile nu sunt prezentate într-o ordine anume.
Principiul preocupării unice (SCP)
Acest principiu este în multe privințe similar cu Principiul responsabilității unice. ), care face parte din setul SOLID și afirmă că fiecare obiect trebuie să aibă o singură responsabilitate și acea responsabilitate trebuie să fie complet încapsulată într-o clasă. Ideea SRP este că fiecare responsabilitate este un motiv pentru schimbare, iar o clasă trebuie să aibă unul și un singur motiv pentru schimbare.
În SCP, folosim cuvântul „preocupare” în loc de cuvântul „responsabilitate” pentru a indica nivelul mai înalt de abstractizare și scopul mai larg al unui container în comparație cu o clasă OOP. Și dacă scopul SRP este să aibă un singur motiv pentru schimbare, atunci în spatele SCP se află dorința de a extinde capacitatea de reutilizare și înlocuire a containerelor. Urmând SRP-ul și creând un container care rezolvă o singură problemă și o face într-un mod complet funcțional, creșteți șansele de a reutiliza acea imagine a containerului în diferite contexte de aplicație.
Principiul SCP prevede că fiecare container ar trebui să rezolve o singură problemă și să o facă bine. În plus, SCP în lumea containerelor este mai ușor de realizat decât SRP în lumea OOP, deoarece containerele rulează de obicei un singur proces și de cele mai multe ori acest proces rezolvă o singură sarcină.
Dacă un microserviciu container trebuie să rezolve mai multe probleme simultan, atunci acesta poate fi împărțit în containere cu o singură sarcină și combinat într-un singur pod (o unitate de implementare a platformei containerului) folosind șabloane sidecar și container init. În plus, SCP facilitează înlocuirea unui container vechi (cum ar fi un server web sau un broker de mesaje) cu unul nou care rezolvă aceeași problemă, dar are o funcționalitate extinsă sau se scalează mai bine.
Principiul de înaltă observabilitate (HOP)
Când containerele sunt folosite ca o modalitate unificată de a împacheta și rula aplicații, aplicațiile în sine sunt tratate ca o cutie neagră. Cu toate acestea, dacă acestea sunt containere cloud, atunci trebuie să furnizeze API-uri speciale timpului de execuție pentru a monitoriza starea de sănătate a containerelor și, dacă este necesar, să ia măsurile corespunzătoare. Fără aceasta, nu va fi posibilă unificarea automatizării actualizării containerelor și a gestionării ciclului de viață al acestora, ceea ce, la rândul său, va înrăutăți stabilitatea și gradul de utilizare a sistemului software.
În practică, o aplicație containerizată ar trebui să aibă, cel puțin, un API pentru diferite tipuri de controale de sănătate: teste de viață și teste de pregătire. Dacă o aplicație pretinde că face mai mult, trebuie să ofere alte mijloace de monitorizare a stării sale. De exemplu, înregistrarea evenimentelor importante prin STDERR și STDOUT pentru agregarea jurnalelor folosind Fluentd, Logstash și alte instrumente similare. Precum și integrarea cu biblioteci de urmărire și colecție de metrici, cum ar fi OpenTracing, Prometheus etc.
În general, aplicația poate fi totuși tratată ca o cutie neagră, dar trebuie să fie prevăzută cu toate API-urile de care are nevoie platforma pentru a o monitoriza și gestiona în cel mai bun mod posibil.
Principiul de conformitate a ciclului de viață (LCP)
LCP este antiteza HOP. În timp ce HOP afirmă că containerul trebuie să expună API-urile de citire pe platformă, LCP necesită ca aplicația să poată accepta informații de pe platformă. Mai mult, containerul nu trebuie doar să primească evenimente, ci și să se adapteze, cu alte cuvinte, să reacționeze la acestea. De aici și denumirea principiului, care poate fi considerat o cerință pentru a oferi platformei API-uri de scriere.
Platformele au diferite tipuri de evenimente pentru a ajuta la gestionarea ciclului de viață al unui container. Dar depinde de aplicația însăși să decidă pe care dintre ei să-l perceapă și cum să reacționeze.
Este clar că unele evenimente sunt mai importante decât altele. De exemplu, dacă o aplicație nu tolerează bine blocările, trebuie să accepte mesajele semnal: terminate (SIGTERM) și să-și inițieze rutina de terminare cât mai repede posibil pentru a capta semnalul: kill (SIGKILL) care vine după SIGTERM.
În plus, evenimente precum PostStart și PreStop pot fi importante pentru ciclul de viață al unei aplicații. De exemplu, după lansarea unei aplicații, poate fi nevoie de un timp de încălzire înainte ca aceasta să poată răspunde solicitărilor. Sau aplicația trebuie să elibereze resurse într-un mod special când se închide.
Principiul imuabilității imaginii (IIP)
Este în general acceptat că aplicațiile containerizate ar trebui să rămână neschimbate după ce au fost construite, chiar dacă sunt rulate în medii diferite. Acest lucru necesită necesitatea de a externaliza stocarea datelor în timpul execuției (cu alte cuvinte, de a utiliza instrumente externe pentru aceasta) și de a se baza pe configurații externe, specifice timpului de execuție, mai degrabă decât modificarea sau crearea de containere unice pentru fiecare mediu. După orice modificare a aplicației, imaginea containerului trebuie reconstruită și implementată în toate mediile utilizate. Apropo, la gestionarea sistemelor IT se folosește un principiu similar, cunoscut sub numele de principiul imuabilității serverelor și infrastructurii.
Scopul IIP este de a preveni crearea de imagini container separate pentru medii de rulare diferite și de a utiliza aceeași imagine peste tot împreună cu configurația adecvată specifică mediului. Urmărirea acestui principiu vă permite să implementați practici atât de importante din punct de vedere al automatizării sistemelor cloud, cum ar fi roll-back și roll-forward a actualizărilor aplicațiilor.
Principiul de eliminare a procesului (PDP)
Una dintre cele mai importante caracteristici ale unui container este efemeritatea acestuia: o instanță a unui container este ușor de creat și ușor de distrus, astfel încât poate fi înlocuită cu ușurință cu o altă instanță în orice moment. Pot exista multe motive pentru o astfel de înlocuire: eșecul unui test de funcționare, scalarea aplicației, transferul la o altă gazdă, epuizarea resurselor platformei sau alte situații.
În consecință, aplicațiile containerizate trebuie să își mențină starea folosind unele mijloace externe sau să utilizeze scheme interne distribuite cu redundanță pentru aceasta. În plus, aplicația trebuie să pornească rapid și să se închidă rapid și să fie pregătită pentru o defecțiune brutală a hardware-ului.
O practică care ajută la implementarea acestui principiu este păstrarea containerelor mici. Mediile cloud pot selecta automat o gazdă pe care să lanseze o instanță de container, astfel încât, cu cât containerul este mai mic, cu atât va porni mai repede - pur și simplu se va copia în gazda țintă prin rețea mai repede.
Principiul auto-conținerii (S-CP)
Conform acestui principiu, în etapa de asamblare, toate componentele necesare sunt incluse în container. Containerul ar trebui să fie construit pe presupunerea că sistemul are doar un nucleu Linux pur, astfel încât toate bibliotecile suplimentare necesare ar trebui plasate în containerul însuși. De asemenea, ar trebui să conțină lucruri precum timpul de execuție pentru limbajul de programare corespunzător, platforma aplicației (dacă este necesar) și alte dependențe care vor fi necesare în timp ce aplicația container rulează.
Se fac excepții pentru configurațiile care variază de la mediu la mediu și trebuie furnizate în timpul execuției, de exemplu printr-un ConfigMap Kubernetes.
O aplicație poate include mai multe componente containerizate, de exemplu, un container DBMS separat într-o aplicație web containerizată. Conform principiului S-CP, aceste containere nu trebuie combinate într-unul singur, ci ar trebui realizate astfel încât containerul DBMS să conțină tot ceea ce este necesar pentru funcționarea bazei de date, iar containerul aplicației web să conțină tot ceea ce este necesar pentru funcționarea web-ului. aplicație, același server web. Ca rezultat, în timpul execuției, containerul aplicației web va depinde de containerul DBMS și îl va accesa după cum este necesar.
Principiul limitării timpului de rulare (RCP)
Principiul S-CP definește modul în care trebuie construit containerul și ce ar trebui să conțină imaginea binară. Dar un container nu este doar o „cutie neagră” care are o singură caracteristică - dimensiunea fișierului. În timpul execuției, containerul ia alte dimensiuni: cantitatea de memorie utilizată, timpul CPU și alte resurse de sistem.
Și aici vine la îndemână principiul RCP, conform căruia containerul trebuie să-și decapiteze cerințele pentru resursele sistemului și să le transfere pe platformă. Cu profilurile de resurse ale fiecărui container (de câte resurse CPU, memorie, rețea și disc are nevoie), platforma poate efectua în mod optim programarea și scalarea automată, gestiona capacitatea IT și menține nivelurile SLA pentru containere.
Pe lângă îndeplinirea cerințelor de resurse ale containerului, este, de asemenea, important ca aplicația să nu depășească propriile limite. În caz contrar, atunci când apare o lipsă de resurse, este mai probabil ca platforma să o includă în lista de aplicații care trebuie să fie terminate sau migrate.
Când vorbim despre cloud-first, vorbim despre modul în care lucrăm.
Mai sus, am formulat o serie de principii generale care stabilesc baza metodologică pentru construirea de aplicații container de înaltă calitate pentru mediile cloud.
Rețineți că, pe lângă aceste principii generale, veți avea nevoie și de metode și tehnici avansate suplimentare pentru lucrul cu containerele. În plus, avem câteva scurte recomandări care sunt mai specifice și ar trebui aplicate (sau nu aplicate) în funcție de situație:
- Încercați să reduceți dimensiunea imaginilor: ștergeți fișierele temporare și nu instalați pachete inutile - cu cât dimensiunea containerului este mai mică, cu atât este mai rapid asamblat și copiat în gazda țintă prin rețea.
- Concentrați-vă pe ID-uri de utilizator arbitrare: nu utilizați comanda sudo sau orice ID de utilizator special pentru a vă lansa containerele.
- Marcați porturile importante: puteți seta numerele de porturi în timpul execuției, dar este mai bine să le specificați folosind comanda EXPOSE - va face mai ușor pentru alte persoane și programe să vă folosească imaginile.
- Stocarea datelor persistente pe volume: datele care ar trebui să rămână după ce containerul este distrus trebuie scrise în volume.
- Scrieți metadatele imaginii: etichetele, etichetele și adnotările fac imaginile mai ușor de utilizat - alți dezvoltatori vă vor mulțumi.
- Sincronizați gazda și imaginile: unele aplicații containerizate necesită sincronizarea containerului cu gazda pe anumite atribute, cum ar fi ora sau ID-ul mașinii.
- În concluzie, împărtășim șabloane și cele mai bune practici care vă vor ajuta să implementați mai eficient principiile enumerate mai sus:
11 iunie ora 11.00
Ce vei invata:
- Red Hat Enterprise Linux CoreOS imuabil
- Mesh de serviciu OpenShift
- Cadru operator
- Cadru knative
Sursa: www.habr.com