"Cloud izvorne" ili jednostavno "cloud" aplikacije su kreirane posebno za rad u infrastrukturama oblaka. Obično su izgrađeni kao skup slabo povezanih mikroservisa upakovanih u kontejnere, kojima zauzvrat upravlja platforma u oblaku. Takve aplikacije su prema zadanim postavkama pripremljene za kvarove, što znači da rade pouzdano i skaliraju čak iu slučaju ozbiljnih kvarova na nivou infrastrukture. Druga strana medalje su skupovi ograničenja (ugovora) koje cloud platforma nameće kontejnerskim aplikacijama kako bi se njima moglo automatski upravljati.
Iako su potpuno svjesne potrebe i važnosti prelaska na aplikacije zasnovane na oblaku, mnoge organizacije još uvijek ne znaju odakle da počnu. U ovom postu ćemo se osvrnuti na niz principa koji će vam, ako se pridržavate pri razvoju kontejnerskih aplikacija, omogućiti da ostvarite potencijal cloud platformi i postignete pouzdan rad i skaliranje aplikacija čak i u slučaju ozbiljnih kvarova na IT infrastrukturi. nivo. Krajnji cilj ovdje navedenih principa je naučiti kako napraviti aplikacije kojima mogu automatski upravljati platforme u oblaku kao što je Kubernetes.
Principi dizajna softvera
U svijetu programiranja, principi se odnose na prilično opšta pravila koja se moraju poštovati prilikom razvoja softvera. Mogu se koristiti pri radu sa bilo kojim programskim jezikom. Svaki princip ima svoje ciljeve, a alati za postizanje kojih su obično šabloni i prakse. Postoji i niz osnovnih principa za kreiranje visokokvalitetnog softvera iz kojeg proizilaze svi ostali. Evo nekoliko primjera osnovnih principa:
- (Neka bude jednostavno, glupo) – ne komplikujte;
- (Ne ponavljaj se) - ne ponavljaj se;
- (Neće vam trebati) - ne stvarajte nešto što vam nije odmah potrebno;
- Razdvajanje briga – podijelite odgovornosti.
Kao što vidite, ovi principi ne postavljaju nikakva posebna pravila, već spadaju u kategoriju takozvanih zdravorazumskih razmatranja zasnovanih na praktičnom iskustvu, koje dijele mnogi programeri i na koje se redovno pozivaju.
Osim toga, postoji – Skup od prvih pet principa objektno orijentisanog programiranja i dizajna, koji je formulisao Robert Martin. SOLID uključuje široke, otvorene, komplementarne principe koji – kada se primjenjuju zajedno – pomažu u stvaranju boljih softverskih sistema i boljem održavanju na duži rok.
SOLID principi pripadaju polju OOP-a i formulisani su jezikom takvih koncepata i koncepata kao što su klase, interfejsi i nasleđe. Po analogiji, principi razvoja mogu se formulisati i za aplikacije u oblaku, samo što osnovni element ovdje neće biti klasa, već kontejner. Prateći ove principe, možete kreirati kontejnerske aplikacije koje bolje ispunjavaju ciljeve i ciljeve platformi u oblaku kao što je Kubernetes.
Kontejneri u Cloudu: Red Hat pristup
Danas se skoro svaka aplikacija može relativno lako upakovati u kontejnere. Ali da bi aplikacije bile efikasno automatizovane i orkestrirane unutar platforme u oblaku kao što je Kubernetes, potreban je dodatni napor.
Osnova za ideje navedene u nastavku bila je metodologija i mnogi drugi radovi na različitim aspektima izgradnje web aplikacija, od upravljanja izvornim kodom do modela skaliranja. Opisani principi se primjenjuju samo na razvoj kontejnerskih aplikacija koje su izgrađene na mikroservisima i dizajnirane za platforme u oblaku kao što je Kubernetes. Osnovni element u našoj diskusiji je slika kontejnera, a ciljno vreme izvođenja kontejnera je platforma orkestracije kontejnera. Cilj predloženih principa je stvaranje kontejnera za koje se zadaci planiranja, skaliranja i praćenja mogu automatizirati na većini platformi za orkestraciju. Principi su predstavljeni bez posebnog redosleda.
Princip jedne zabrinutosti (SCP)
Ovaj princip je na mnogo načina sličan principu jedinstvene odgovornosti. ), koji je dio SOLID skupa i navodi da svaki objekt mora imati jednu odgovornost i ta odgovornost mora biti u potpunosti inkapsulirana u klasi. Poenta 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” da označimo viši nivo apstrakcije i širu svrhu kontejnera u poređenju sa OOP klasom. A ako je cilj SRP-a da ima samo jedan razlog za promjenu, onda iza SCP-a stoji želja da se proširi mogućnost ponovne upotrebe i zamjene kontejnera. Praćenjem SRP-a i kreiranjem kontejnera koji rješava jedan problem i radi to na funkcionalno potpun način, povećavate šanse za ponovnu upotrebu te slike kontejnera u različitim kontekstima aplikacije.
SCP princip kaže da svaki kontejner treba riješiti jedan problem i to dobro. Štaviše, SCP u svijetu kontejnera je lakše postići nego SRP u OOP svijetu, budući da kontejneri obično pokreću jedan proces, a većinu vremena ovaj proces rješava samo jedan zadatak.
Ako mikroservis kontejnera mora riješiti nekoliko problema odjednom, onda se može podijeliti u kontejnere s jednim zadatkom i kombinirati unutar jednog pod-a (jedinica implementacije kontejnerske platforme) koristeći sidecar i init šablone kontejnera. Osim toga, SCP olakšava zamjenu starog kontejnera (kao što je web server ili broker poruka) novim koji rješava isti problem, ali ima proširenu funkcionalnost ili bolje skaliranje.
Princip visoke uočljivosti (HOP)
Kada se kontejneri koriste kao objedinjeni način pakovanja i pokretanja aplikacija, same aplikacije se tretiraju kao crna kutija. Međutim, ako se radi o kontejnerima u oblaku, onda moraju osigurati posebne API-je za vrijeme izvođenja kako bi nadgledali zdravlje kontejnera i, ako je potrebno, poduzeli odgovarajuće mjere. Bez toga neće biti moguće objediniti automatizaciju ažuriranja kontejnera i upravljanja njihovim životnim ciklusom, što će zauzvrat pogoršati stabilnost i upotrebljivost softverskog sistema.
U praksi, kontejnerska aplikacija treba, u najmanju ruku, imati API za različite vrste provjera zdravlja: testove životnosti i testove spremnosti. Ako aplikacija tvrdi da radi više, ona mora obezbijediti druga sredstva za praćenje svog stanja. Na primjer, evidentiranje važnih događaja putem STDERR-a i STDOUT-a za agregaciju dnevnika koristeći Fluentd, Logstash i druge slične alate. Kao i integracija sa bibliotekama za praćenje i prikupljanje metrika, kao što su OpenTracing, Prometheus, itd.
Općenito, aplikacija se i dalje može tretirati kao crna kutija, ali mora imati sve API-je koji su potrebni platformi kako bi je pratila i upravljala na najbolji mogući način.
Princip usklađenosti životnog ciklusa (LCP)
LCP je antiteza HOP-a. Dok HOP navodi da kontejner mora izložiti API-je za čitanje platformi, LCP zahtijeva da aplikacija može prihvatiti informacije s platforme. Štaviše, kontejner ne samo da mora primati događaje, već se i prilagođavati, drugim riječima, reagirati na njih. Otuda i naziv principa, koji se može smatrati uslovom da se platformi obezbedi API za pisanje.
Platforme imaju različite tipove događaja koji pomažu u upravljanju životnim ciklusom kontejnera. Ali na samoj aplikaciji je da odluči koje će od njih uočiti i kako reagovati.
Jasno je da su neki događaji važniji od drugih. Na primjer, ako aplikacija ne podnosi dobro padove, mora prihvatiti signal: prekinuti (SIGTERM) poruke i pokrenuti svoju terminsku rutinu što je prije moguće kako bi uhvatila signal: kill (SIGKILL) koji dolazi nakon SIGTERM.
Dodatno, događaji kao što su PostStart i PreStop mogu biti važni za životni ciklus aplikacije. Na primjer, nakon pokretanja aplikacije, može biti potrebno neko vrijeme za zagrijavanje prije nego što može odgovoriti na zahtjeve. Ili aplikacija mora osloboditi resurse na neki poseban način kada se gasi.
Princip nepromjenjivosti slike (IIP)
Općenito je prihvaćeno da kontejnerizirane aplikacije trebaju ostati nepromijenjene nakon izrade, čak i ako se pokreću u različitim okruženjima. Ovo zahtijeva eksternalizaciju skladištenja podataka u vrijeme izvođenja (drugim riječima, korištenje vanjskih alata za ovo) i oslanjanje na eksterne konfiguracije specifične za vrijeme izvođenja, umjesto da se modificiraju ili kreiraju jedinstveni kontejneri za svako okruženje. Nakon bilo kakvih promjena u aplikaciji, slika kontejnera mora biti ponovo izgrađena i raspoređena u svim korištenim okruženjima. Inače, kod upravljanja IT sistemima se koristi sličan princip, poznat kao princip nepromjenjivosti servera i infrastrukture.
Cilj IIP-a je spriječiti kreiranje zasebnih slika spremnika za različita okruženja za izvršavanje i koristiti istu sliku svuda zajedno sa odgovarajućom konfiguracijom specifičnom za okruženje. Praćenje ovog principa vam omogućava da implementirate tako važne prakse sa stanovišta automatizacije cloud sistema kao što su vraćanje i vraćanje unapred ažuriranja aplikacija.
Princip jednokratne upotrebe procesa (PDP)
Jedna od najvažnijih karakteristika kontejnera je njegova efemernost: instancu kontejnera je lako stvoriti i lako uništiti, tako da se može lako zamijeniti drugom instancom u bilo kojem trenutku. Razloga za takvu zamjenu može biti mnogo: neuspjeh testa uslužnosti, skaliranje aplikacije, prijenos na drugi host, iscrpljivanje resursa platforme ili druge situacije.
Kao posljedica toga, kontejnerizirane aplikacije moraju održavati svoje stanje korištenjem nekih eksternih sredstava, ili za to koristiti interne distribuirane sheme sa redundantnošću. Osim toga, aplikacija se mora brzo pokrenuti i brzo isključiti, te biti spremna za iznenadni fatalni kvar hardvera.
Jedna praksa koja pomaže u implementaciji ovog principa je da kontejneri budu mali. Cloud okruženja mogu automatski odabrati host na kojem će pokrenuti instancu kontejnera, tako da što je manji kontejner, to će se brže pokrenuti - jednostavno će se brže kopirati na ciljni host preko mreže.
Princip samoodržavanja (S-CP)
Prema ovom principu, u fazi montaže, sve potrebne komponente su uključene u kontejner. Kontejner bi trebao biti izgrađen pod pretpostavkom da sistem ima samo čisto Linux kernel, tako da sve potrebne dodatne biblioteke treba staviti u sam kontejner. Također bi trebao sadržavati stvari kao što su vrijeme izvođenja za odgovarajući programski jezik, platforma aplikacije (ako je potrebno) i druge ovisnosti koje će biti potrebne dok se kontejnerska aplikacija izvodi.
Izuzeci su napravljeni za konfiguracije koje se razlikuju od okruženja do okruženja i moraju se obezbediti tokom izvršavanja, na primer preko Kubernetes ConfigMap.
Aplikacija može uključivati nekoliko kontejneriziranih komponenti, na primjer, poseban DBMS kontejner unutar kontejnerizirane web aplikacije. Prema S-CP principu, ovi kontejneri ne bi trebali biti kombinovani u jedan, već bi trebali biti napravljeni tako da DBMS kontejner sadrži sve što je potrebno za rad baze podataka, a kontejner web aplikacije sadrži sve što je potrebno za rad weba. aplikacija, isti web server. Kao rezultat toga, za vrijeme izvođenja kontejner web aplikacije ovisit će o DBMS kontejneru i pristupati mu po potrebi.
Princip ograničavanja vremena rada (RCP)
S-CP princip definira kako bi kontejner trebao biti izgrađen i šta bi binarna slika trebala sadržavati. Ali kontejner nije samo “crna kutija” koja ima samo jednu karakteristiku - veličinu datoteke. Tokom izvršavanja, kontejner poprima druge dimenzije: količinu korišćene memorije, CPU vreme i druge sistemske resurse.
I tu dobro dolazi princip RCP-a, prema kojem kontejner mora obezglaviti svoje zahtjeve za sistemskim resursima i prenijeti ih na platformu. Sa profilima resursa svakog kontejnera (koliko CPU-a, memorije, mreže i diskovnih resursa treba), platforma može optimalno izvršiti zakazivanje i automatsko skaliranje, upravljati IT kapacitetom i održavati SLA nivoe za kontejnere.
Osim što ispunjava zahtjeve za resurse kontejnera, također je važno da aplikacija ne prelazi svoje granice. U suprotnom, kada dođe do nedostatka resursa, vjerojatnije je da će je platforma uključiti na listu aplikacija koje treba prekinuti ili migrirati.
Kada govorimo o tome da smo na prvom mjestu u oblaku, govorimo o načinu na koji radimo.
Iznad smo formulirali niz općih principa koji postavljaju metodološku osnovu za izgradnju visokokvalitetnih kontejnerskih aplikacija za okruženja u oblaku.
Imajte na umu da će vam pored ovih općih principa trebati i dodatne napredne metode i tehnike za rad sa kontejnerima. Osim toga, imamo nekoliko kratkih preporuka koje su konkretnije i koje treba primijeniti (ili ne primijeniti) ovisno o situaciji:
- Pokušajte smanjiti veličinu slika: izbrišite privremene datoteke i nemojte instalirati nepotrebne pakete - što je manji spremnik, to se brže sklapa i kopira na ciljni host preko mreže.
- Fokusirajte se na proizvoljne korisničke ID-ove: nemojte koristiti naredbu sudo ili bilo koji poseban korisnički ID za pokretanje vaših kontejnera.
- Označavanje važnih portova: Možete postaviti brojeve portova u vrijeme izvođenja, ali je bolje da ih navedete pomoću naredbe EXPOSE - to će olakšati drugim ljudima i programima korištenje vaših slika.
- Čuvajte trajne podatke na volumenima: Podaci koji bi trebali ostati nakon uništenja spremnika trebali bi biti upisani u volumene.
- Pišite metapodatke slike: oznake, oznake i napomene čine slike lakšim za korištenje - drugi programeri će vam biti zahvalni.
- Sinhronizacija hosta i slika: Neke kontejnerizirane aplikacije zahtijevaju da se kontejner sinhronizuje s hostom na određenim atributima, kao što su vrijeme ili ID mašine.
- U zaključku, dijelimo šablone i najbolje prakse koje će vam pomoći da efikasnije implementirate gore navedene principe:
11. juna u 11.00
Šta ćete naučiti:
- Nepromjenjivi Red Hat Enterprise Linux CoreOS
- OpenShift servisna mreža
- Operatorski okvir
- Knativni okvir
izvor: www.habr.com