"Cloud native" ili jednostavno "cloud" aplikacije stvorene su posebno za rad u infrastrukturi oblaka. Obično su izgrađeni kao skup labavo povezanih mikroservisa pakiranih u spremnike, kojima zauzvrat upravlja platforma u oblaku. Takve su aplikacije prema zadanim postavkama pripremljene za kvarove, što znači da rade pouzdano i skaliraju se čak i u slučaju ozbiljnih kvarova na razini infrastrukture. Druga strana medalje su skupovi ograničenja (ugovora) koje cloud platforma nameće kontejnerskim aplikacijama kako bi njima automatski upravljali.
Iako su potpuno svjesne potrebe i važnosti prelaska na aplikacije temeljene na oblaku, mnoge organizacije još uvijek ne znaju odakle započeti. U ovom ćemo postu pogledati niz načela koja će vam, ako ih se pridržavate pri razvoju kontejnerskih aplikacija, omogućiti da ostvarite potencijal platformi u oblaku i postignete pouzdan rad i skaliranje aplikacija čak i u slučaju ozbiljnih kvarova na IT infrastrukturi. razini. Krajnji cilj ovdje navedenih načela je naučiti kako izraditi aplikacije kojima se automatski može upravljati na platformama u oblaku kao što je Kubernetes.
Načela dizajna softvera
U svijetu programiranja, načela se odnose na prilično opća pravila koja se moraju slijediti pri razvoju softvera. Mogu se koristiti pri radu s bilo kojim programskim jezikom. Svaki princip ima svoje ciljeve, a alati za postizanje kojih su obično predlošci i prakse. Također postoji niz temeljnih načela za stvaranje visokokvalitetnog softvera, iz kojih proizlaze svi ostali. Evo nekoliko primjera temeljnih načela:
- (Keep it simple, stupid) – ne kompliciraj;
- (Ne ponavljaj se) - ne ponavljaj se;
- (Neće vam trebati) - ne stvarajte nešto što nije odmah potrebno;
- Razdvajanje briga – podijelite odgovornosti.
Kao što vidite, ova načela ne postavljaju nikakva posebna pravila, već pripadaju kategoriji takozvanih zdravorazumskih razmatranja temeljenih na praktičnom iskustvu, koja dijele mnogi programeri i na koja se redovito pozivaju.
Uz to postoji – Skup od prvih pet principa objektno orijentiranog programiranja i dizajna, koje je formulirao Robert Martin. SOLID uključuje široka, otvorena, komplementarna načela koja – kada se primjenjuju zajedno – pomažu u stvaranju boljih softverskih sustava i boljem njihovom dugoročnom održavanju.
Principi SOLID-a pripadaju području OOP-a i formulirani su u jeziku koncepata i koncepata kao što su klase, sučelja i nasljeđivanje. Analogno tome, načela razvoja mogu se formulirati i za aplikacije u oblaku, samo što osnovni element ovdje neće biti klasa, već kontejner. Slijedeći ova načela, možete stvoriti kontejnerske aplikacije koje bolje ispunjavaju ciljeve platformi u oblaku kao što je Kubernetes.
Izvorni spremnici u oblaku: Red Hat pristup
Danas se gotovo svaka aplikacija može relativno lako upakirati u spremnike. Ali da bi aplikacije bile učinkovito automatizirane i orkestrirane unutar platforme u oblaku kao što je Kubernetes, potreban je dodatni napor.
Osnova za dolje navedene ideje bila je metodologija i mnogi drugi radovi o različitim aspektima izgradnje web aplikacija, od upravljanja izvornim kodom do modela skaliranja. Opisani principi primjenjuju se samo na razvoj kontejnerskih aplikacija koje su izgrađene na vrhu mikroservisa i dizajnirane za platforme u oblaku kao što je Kubernetes. Osnovni element u našoj raspravi je slika spremnika, a ciljno vrijeme izvođenja spremnika je platforma za orkestraciju spremnika. Cilj predloženih načela je stvoriti spremnike za koje se zadaci raspoređivanja, skaliranja i praćenja mogu automatizirati na većini platformi za orkestraciju. Načela su predstavljena bez određenog reda.
Načelo jedinstvene brige (SCP)
Ovo je načelo na mnogo načina slično načelu jedinstvene odgovornosti. ), koji je dio skupa SOLID i navodi da svaki objekt mora imati jednu odgovornost, a ta odgovornost mora biti potpuno zatvorena u klasi. Poanta SRP-a je da je svaka odgovornost razlog za promjenu, a klasa mora imati jedan i samo jedan razlog za promjenu.
U SCP-u koristimo riječ "zabrinutost" umjesto riječi "odgovornost" kako bismo ukazali na višu razinu apstrakcije i širu svrhu spremnika u usporedbi s OOP klasom. A ako je cilj SRP-a imati samo jedan razlog za promjenu, onda iza SCP-a stoji želja za proširenjem mogućnosti ponovne uporabe i zamjene spremnika. Prateći SRP i stvarajući spremnik koji rješava jedan problem i to na funkcionalno cjelovit način, povećavate šanse za ponovnu upotrebu te slike spremnika u različitim kontekstima aplikacija.
SCP načelo kaže da bi svaki spremnik trebao riješiti jedan problem i to dobro. Štoviše, SCP u svijetu kontejnera lakše je postići nego SRP u OOP svijetu, budući da kontejneri obično pokreću jedan jedini proces, a većinu vremena ovaj proces rješava jedan jedini zadatak.
Ako mikroservis spremnika mora riješiti nekoliko problema odjednom, tada se može podijeliti u spremnike s jednim zadatkom i kombinirati unutar jednog pod-a (jedinice postavljanja platforme spremnika) pomoću predložaka sidecar i init spremnika. Osim toga, SCP olakšava zamjenu starog spremnika (kao što je web poslužitelj ili posrednik poruka) novim koji rješava isti problem, ali ima proširenu funkcionalnost ili se bolje skalira.
Načelo visoke vidljivosti (HOP)
Kada se spremnici koriste kao objedinjeni način pakiranja i pokretanja aplikacija, same aplikacije se tretiraju kao crna kutija. Međutim, ako su to spremnici u oblaku, tada moraju osigurati posebne API-je za vrijeme izvođenja za praćenje ispravnosti spremnika i, ako je potrebno, poduzeti odgovarajuće radnje. Bez toga neće biti moguće objediniti automatizaciju ažuriranja spremnika i upravljanja njihovim životnim ciklusom, što će zauzvrat pogoršati stabilnost i upotrebljivost softverskog sustava.
U praksi, kontejnerska aplikacija trebala bi barem imati API za različite vrste provjera zdravlja: testove živosti i testove spremnosti. Ako aplikacija tvrdi da radi više, mora osigurati druge načine praćenja svog stanja. Na primjer, bilježenje važnih događaja putem STDERR-a i STDOUT-a za agregaciju dnevnika pomoću Fluentd-a, Logstash-a i drugih sličnih alata. Kao i integracija s zbirkama praćenja i metrike, kao što su OpenTracing, Prometheus itd.
Općenito, aplikacija se još uvijek može tretirati kao crna kutija, ali mora imati sve API-je koji su potrebni platformi kako bi je nadzirala i upravljala na najbolji mogući način.
Načelo usklađenosti životnog ciklusa (LCP)
LCP je antiteza HOP-u. Dok HOP navodi da spremnik mora izložiti čitanje API-ja platformi, LCP zahtijeva da aplikacija može prihvatiti informacije s platforme. Štoviše, spremnik ne samo da mora primati događaje, već i prilagođavati se, drugim riječima, reagirati na njih. Otuda i naziv principa, koji se može smatrati zahtjevom za pružanje platformi pisanja API-ja.
Platforme imaju različite vrste događaja koji pomažu u upravljanju životnim ciklusom spremnika. No, na samoj aplikaciji je da odluči koje će od njih percipirati i kako reagirati.
Jasno je da su neki događaji važniji od drugih. Na primjer, ako aplikacija ne podnosi dobro padove, mora prihvatiti poruke signal: prekinuti (SIGTERM) i pokrenuti svoju rutinu prekida što je brže moguće kako bi uhvatila signal: ukini (SIGKILL) koji dolazi nakon SIGTERM.
Osim toga, događaji kao što su PostStart i PreStop mogu biti važni za životni ciklus aplikacije. Na primjer, nakon pokretanja aplikacije, može joj trebati neko vrijeme zagrijavanja prije nego što može odgovoriti na zahtjeve. Ili aplikacija mora osloboditi resurse na neki poseban način kada se gasi.
Načelo nepromjenjivosti slike (IIP)
Općenito je prihvaćeno da aplikacije u kontejnerima trebaju ostati nepromijenjene nakon izgradnje, čak i ako se izvode u različitim okruženjima. To zahtijeva eksternalizaciju pohrane podataka tijekom izvođenja (drugim riječima, korištenje vanjskih alata za to) i oslanjanje na vanjske konfiguracije specifične za vrijeme izvođenja, umjesto mijenjanja ili stvaranja jedinstvenih spremnika za svako okruženje. Nakon bilo kakvih promjena u aplikaciji, slika spremnika mora se ponovno izgraditi i implementirati u sva korištena okruženja. Inače, pri upravljanju IT sustavima koristi se sličan princip, poznat kao princip nepromjenjivosti servera i infrastrukture.
Cilj IIP-a je spriječiti stvaranje zasebnih slika spremnika za različita okruženja vremena izvođenja i svugdje koristiti istu sliku zajedno s odgovarajućom konfiguracijom specifičnom za okruženje. Slijeđenje ovog načela omogućuje vam implementaciju tako važnih praksi sa stajališta automatizacije sustava u oblaku kao što su vraćanje i vraćanje ažuriranja aplikacija.
Načelo raspoloživosti procesa (PDP)
Jedna od najvažnijih karakteristika spremnika je njegova prolaznost: instancu spremnika je lako stvoriti i uništiti, tako da se može lako zamijeniti drugom instancom u bilo kojem trenutku. Može postojati mnogo razloga za takvu zamjenu: neuspjeh testa upotrebljivosti, skaliranje aplikacije, prijenos na drugi host, iscrpljenost resursa platforme ili druge situacije.
Kao posljedica toga, kontejnerske aplikacije moraju održavati svoje stanje pomoću nekih vanjskih sredstava ili za to koristiti interne distribuirane sheme sa redundancijom. Osim toga, aplikacija se mora brzo pokrenuti i brzo zatvoriti te biti spremna na iznenadni fatalni kvar hardvera.
Jedna praksa koja pomaže u provedbi ovog načela je da spremnici budu mali. Okolina u oblaku može automatski odabrati host za pokretanje instance spremnika, tako da što je spremnik manji, to će se brže pokrenuti - jednostavno će se brže kopirati na ciljno računalo preko mreže.
Načelo samoodrživosti (S-CP)
Prema ovom principu, u fazi montaže, sve potrebne komponente su uključene u spremnik. Spremnik bi trebao biti izgrađen na pretpostavci da sustav ima samo čisti Linux kernel, tako da sve potrebne dodatne biblioteke treba smjestiti u sam spremnik. Također bi trebao sadržavati stvari poput vremena izvođenja za odgovarajući programski jezik, platformu aplikacije (ako je potrebno) i druge ovisnosti koje će biti potrebne dok se aplikacija spremnika izvodi.
Iznimke su napravljene za konfiguracije koje se razlikuju od okruženja do okruženja i moraju se osigurati tijekom izvođenja, na primjer putem Kubernetes ConfigMapa.
Aplikacija može uključivati nekoliko kontejnerskih komponenti, na primjer, zasebni DBMS spremnik unutar kontejnerske web aplikacije. Prema S-CP principu, ovi spremnici se ne smiju spajati u jedan, već trebaju biti napravljeni tako da spremnik DBMS sadrži sve što je potrebno za rad baze podataka, a spremnik web aplikacije sadrži sve što je potrebno za rad weba. aplikacija, isti web poslužitelj . Kao rezultat toga, za vrijeme izvođenja spremnik web aplikacije ovisit će o spremniku DBMS-a i pristupati mu po potrebi.
Runtime Confinement Principle (RCP)
S-CP princip definira kako se spremnik treba izgraditi i što bi binarna slika trebala sadržavati. Ali spremnik nije samo "crna kutija" koja ima samo jednu karakteristiku - veličinu datoteke. Tijekom izvođenja, spremnik poprima druge dimenzije: količinu korištene memorije, CPU vrijeme i druge resurse sustava.
I tu dobro dolazi RCP princip prema kojem kontejner mora obezglaviti svoje zahtjeve za sistemskim resursima i prenijeti ih na platformu. S profilima resursa svakog spremnika (koliko CPU-a, memorije, mrežnih i diskovnih resursa treba), platforma može optimalno izvršiti raspoređivanje i automatsko skaliranje, upravljati IT kapacitetom i održavati SLA razine za spremnike.
Osim ispunjavanja resursnih zahtjeva spremnika, također je važno da aplikacija ne izlazi izvan vlastitih granica. U suprotnom, kada dođe do nedostatka resursa, vjerojatnije je da će ga platforma uključiti na popis aplikacija koje treba prekinuti ili migrirati.
Kada govorimo o tome da smo na prvom mjestu u oblaku, govorimo o načinu na koji radimo.
Gore smo formulirali nekoliko općih načela koja postavljaju metodološke temelje za izgradnju visokokvalitetnih spremničkih aplikacija za okruženja oblaka.
Imajte na umu da ćete osim ovih općih načela trebati i dodatne napredne metode i tehnike za rad sa spremnicima. Osim toga, imamo nekoliko kratkih preporuka koje su specifičnije i trebaju se primijeniti (ili ne primijeniti) ovisno o situaciji:
- Pokušajte smanjiti veličinu slika: izbrišite privremene datoteke i nemojte instalirati nepotrebne pakete - što je manja veličina spremnika, to se brže sastavlja i kopira na ciljno računalo putem mreže.
- Usredotočite se na proizvoljne korisničke ID-ove: nemojte koristiti naredbu sudo ili bilo koji poseban korisnički id za pokretanje spremnika.
- Označi važne priključke: Možete postaviti brojeve priključaka tijekom izvođenja, ali bolje je odrediti ih pomoću naredbe EXPOSE - to će drugim ljudima i programima olakšati korištenje vaših slika.
- Pohranite trajne podatke na volumene: Podaci koji bi trebali ostati nakon što se spremnik uništi trebali bi se zapisati na volumene.
- Zapišite metapodatke o slikama: oznake, oznake i bilješke olakšavaju korištenje slika - drugi programeri će vam biti zahvalni.
- Sinkronizirajte host i slike: Neke kontejnerske aplikacije zahtijevaju da se spremnik sinkronizira s hostom na određenim atributima, kao što je vrijeme ili ID stroja.
- Zaključno, dijelimo predloške i najbolje prakse koji će vam pomoći da učinkovitije implementirate gore navedena načela:
11. lipnja u 11.00 sati
Što ćete naučiti:
- Nepromjenjivi Red Hat Enterprise Linux CoreOS
- OpenShift servisna mreža
- Okvir operatora
- Knativni okvir
Izvor: www.habr.com