Aplikacionet "Cloud native" ose thjesht "cloud" janë krijuar posaçërisht për të punuar në infrastrukturat cloud. Ato zakonisht ndërtohen si një grup mikroshërbimesh të lidhura lirshëm të paketuara në kontejnerë, të cilët nga ana tjetër menaxhohen nga një platformë cloud. Aplikacione të tilla përgatiten për dështime si parazgjedhje, që do të thotë se ato funksionojnë me besueshmëri dhe shkallëzohen edhe në rast të dështimeve serioze të nivelit të infrastrukturës. Ana tjetër e medaljes janë grupet e kufizimeve (kontratave) që platforma cloud vendos mbi aplikacionet e kontejnerëve në mënyrë që të jetë në gjendje t'i menaxhojë ato automatikisht.
Ndërsa janë plotësisht të vetëdijshëm për nevojën dhe rëndësinë e kalimit në aplikacione të bazuara në cloud, shumë organizata ende nuk dinë se ku të fillojnë. Në këtë postim, ne do të shikojmë një sërë parimesh që, nëse ndiqen gjatë zhvillimit të aplikacioneve me kontejnerë, do t'ju lejojnë të realizoni potencialin e platformave cloud dhe të arrini funksionimin dhe shkallëzimin e besueshëm të aplikacioneve edhe në rast të dështimeve serioze në infrastrukturën e IT. niveli. Qëllimi përfundimtar i parimeve të përshkruara këtu është të mësoni se si të ndërtoni aplikacione që mund të menaxhohen automatikisht nga platformat cloud si Kubernetes.
Parimet e dizajnit të softuerit
Në botën e programimit, parimet i referohen rregullave mjaft të përgjithshme që duhen ndjekur gjatë zhvillimit të softuerit. Ato mund të përdoren kur punoni me çdo gjuhë programimi. Secili parim ka qëllimet e veta, mjetet për t'i arritur të cilat zakonisht janë shabllone dhe praktika. Ekzistojnë gjithashtu një sërë parimesh themelore për krijimin e softuerit me cilësi të lartë, nga të cilat rrjedhin të gjithë të tjerët. Këtu janë disa shembuj të parimeve themelore:
- (Keep it simple, stupid) - mos e ndërliko;
- (Mos e përsërit veten) - mos e përsërit veten;
- (Nuk do t'ju duhet) - mos krijoni diçka që nuk është e nevojshme menjëherë;
- Ndarja e shqetësimeve – ndani përgjegjësitë.
Siç mund ta shihni, këto parime nuk përcaktojnë ndonjë rregull specifik, por i përkasin kategorisë së të ashtuquajturave konsiderata me sens të përbashkët bazuar në përvojën praktike, të cilat ndahen nga shumë zhvillues dhe të cilave ato i referohen rregullisht.
Përveç kësaj, ka – Një grup prej pesë parimeve të para të programimit dhe dizajnit të orientuar drejt objektit, të formuluara nga Robert Martin. SOLID përfshin parime të gjera, të hapura, plotësuese, të cilat – kur zbatohen së bashku – ndihmojnë në krijimin e sistemeve më të mira softuerike dhe mirëmbajtjen e tyre për një afat të gjatë.
Parimet SOLID i përkasin fushës së OOP dhe janë formuluar në gjuhën e koncepteve dhe koncepteve të tilla si klasa, ndërfaqe dhe trashëgimi. Për analogji, parimet e zhvillimit mund të formulohen edhe për aplikacionet cloud, vetëm elementi bazë këtu nuk do të jetë një klasë, por një enë. Duke ndjekur këto parime, ju mund të krijoni aplikacione me kontejnerë që përmbushin më mirë qëllimet dhe objektivat e platformave cloud si Kubernetes.
Kontejnerët vendas të reve: qasja e Red Hat
Sot, pothuajse çdo aplikacion mund të paketohet relativisht lehtë në kontejnerë. Por që aplikacionet të automatizohen dhe orkestrohen në mënyrë efektive brenda një platforme cloud si Kubernetes, kërkohet përpjekje shtesë.
Baza për idetë e përshkruara më poshtë ishte metodologjia dhe shumë punë të tjera në aspekte të ndryshme të ndërtimit të aplikacioneve në ueb, nga menaxhimi i kodit burimor deri te modelet e shkallëzimit. Parimet e përshkruara zbatohen vetëm për zhvillimin e aplikacioneve me kontejnerë që janë ndërtuar në krye të mikroshërbimeve dhe të dizajnuara për platforma cloud si Kubernetes. Elementi bazë në diskutimin tonë është imazhi i kontejnerit, dhe koha e funksionimit të kontejnerit të synuar është platforma e orkestrimit të kontejnerit. Qëllimi i parimeve të propozuara është krijimi i kontejnerëve për të cilët detyrat e planifikimit, shkallëzimit dhe monitorimit mund të automatizohen në shumicën e platformave të orkestrimit. Parimet janë paraqitur në asnjë mënyrë të veçantë.
Parimi i vetëm i shqetësimit (SCP)
Ky parim është në shumë mënyra i ngjashëm me Parimin e Përgjegjësisë së Vetëm. ), i cili është pjesë e grupit SOLID dhe thotë se çdo objekt duhet të ketë një përgjegjësi dhe se përgjegjësia duhet të përfshihet plotësisht në një klasë. Thelbi i SRP është se çdo përgjegjësi është një arsye për ndryshim, dhe një klasë duhet të ketë një dhe vetëm një arsye për ndryshim.
Në SCP, ne përdorim fjalën "shqetësim" në vend të fjalës "përgjegjësi" për të treguar nivelin më të lartë të abstraksionit dhe qëllimin më të gjerë të një kontejneri në krahasim me një klasë OOP. Dhe nëse qëllimi i SRP është të ketë vetëm një arsye për ndryshim, atëherë pas SCP qëndron dëshira për të zgjeruar aftësinë për të ripërdorur dhe zëvendësuar kontejnerët. Duke ndjekur SRP dhe duke krijuar një kontejner që zgjidh një problem të vetëm dhe e bën atë në një mënyrë funksionalisht të plotë, ju rritni shanset për të ripërdorur atë imazh të kontejnerit në kontekste të ndryshme aplikimi.
Parimi SCP thotë se çdo kontejner duhet të zgjidhë një problem të vetëm dhe ta bëjë atë mirë. Për më tepër, SCP në botën e kontejnerëve është më e lehtë për t'u arritur sesa SRP në botën OOP, pasi kontejnerët zakonisht kryejnë një proces të vetëm, dhe shumicën e kohës ky proces zgjidh një detyrë të vetme.
Nëse një mikroshërbim kontejneri duhet të zgjidhë disa probleme në të njëjtën kohë, atëherë ai mund të ndahet në kontejnerë me një detyrë dhe të kombinohet brenda një pod (një njësi e vendosjes së platformës së kontejnerit) duke përdorur shabllonet e kontejnerit anësor dhe init. Përveç kësaj, SCP e bën të lehtë zëvendësimin e një kontejneri të vjetër (si p.sh. një server në internet ose ndërmjetës mesazhesh) me një të ri që zgjidh të njëjtin problem, por ka funksionalitet të zgjeruar ose shkallëzohet më mirë.
Parimi i Vëzhgueshmërisë së Lartë (HOP)
Kur kontejnerët përdoren si një mënyrë e unifikuar për paketimin dhe ekzekutimin e aplikacioneve, vetë aplikacionet trajtohen si një kuti e zezë. Megjithatë, nëse këto janë kontejnerë cloud, atëherë ata duhet të ofrojnë API të veçanta për kohën e ekzekutimit për të monitoruar shëndetin e kontejnerëve dhe, nëse është e nevojshme, të ndërmarrin veprimet e duhura. Pa këtë, nuk do të jetë e mundur të unifikohet automatizimi i përditësimit të kontejnerëve dhe administrimi i ciklit të tyre të jetës, i cili, nga ana tjetër, do të përkeqësojë stabilitetin dhe përdorshmërinë e sistemit softuer.
Në praktikë, një aplikacion me kontejnerë duhet, të paktën, të ketë një API për lloje të ndryshme kontrollesh shëndetësore: testet e gjallërisë dhe testet e gatishmërisë. Nëse një aplikacion pretendon të bëjë më shumë, ai duhet të sigurojë mjete të tjera për të monitoruar gjendjen e tij. Për shembull, regjistrimi i ngjarjeve të rëndësishme nëpërmjet STDERR dhe STDOUT për grumbullimin e regjistrave duke përdorur Fluentd, Logstash dhe mjete të tjera të ngjashme. Si dhe integrimi me bibliotekat e grumbullimit të gjurmimit dhe metrikës si OpenTracing, Prometheus, etj.
Në përgjithësi, aplikacioni mund të trajtohet ende si një kuti e zezë, por duhet të pajiset me të gjitha API-të që i nevojiten platformës për ta monitoruar dhe menaxhuar atë në mënyrën më të mirë të mundshme.
Parimi i konformitetit të ciklit jetësor (LCP)
LCP është antiteza e HOP. Ndërsa HOP thotë se kontejneri duhet të ekspozojë API-të e lexuara në platformë, LCP kërkon që aplikacioni të jetë në gjendje të pranojë informacione nga platforma. Për më tepër, kontejneri jo vetëm që duhet të marrë ngjarje, por edhe të përshtatet, me fjalë të tjera, të reagojë ndaj tyre. Prandaj emri i parimit, i cili mund të konsiderohet si një kërkesë për të siguruar platformën me shkrim API.
Platformat kanë lloje të ndryshme ngjarjesh për të ndihmuar në menaxhimin e ciklit jetësor të një kontejneri. Por i takon vetë aplikacionit të vendosë se cilin prej tyre do të perceptojë dhe si të reagojë.
Është e qartë se disa ngjarje janë më të rëndësishme se të tjerat. Për shembull, nëse një aplikacion nuk i toleron mirë përplasjet, ai duhet të pranojë mesazhet e sinjalit: mbyll (SIGTERM) dhe të fillojë rutinën e përfundimit sa më shpejt të jetë e mundur për të kapur sinjalin: vras (SIGKILL) që vjen pas SIGTERM.
Për më tepër, ngjarje të tilla si PostStart dhe PreStop mund të jenë të rëndësishme për ciklin jetësor të një aplikacioni. Për shembull, pas hapjes së një aplikacioni, mund të kërkojë pak kohë ngrohjeje përpara se të mund t'u përgjigjet kërkesave. Ose aplikacioni duhet të lëshojë burime në një mënyrë të veçantë kur mbyllet.
Parimi i pandryshueshmërisë së imazhit (IIP)
Në përgjithësi pranohet që aplikacionet e kontejnerit duhet të mbeten të pandryshuara pasi të ndërtohen, edhe nëse ato përdoren në mjedise të ndryshme. Kjo kërkon nevojën për të eksternalizuar ruajtjen e të dhënave në kohën e ekzekutimit (me fjalë të tjera, për të përdorur mjete të jashtme për këtë) dhe për t'u mbështetur në konfigurime të jashtme, specifike për kohën e ekzekutimit, në vend që të modifikoni ose krijoni kontejnerë unikë për çdo mjedis. Pas çdo ndryshimi në aplikacion, imazhi i kontejnerit duhet të rindërtohet dhe të vendoset në të gjitha mjediset e përdorura. Nga rruga, kur menaxhoni sistemet e TI-së, përdoret një parim i ngjashëm, i njohur si parimi i pandryshueshmërisë së serverëve dhe infrastrukturës.
Qëllimi i IIP është të parandalojë krijimin e imazheve të kontejnerëve të veçantë për mjedise të ndryshme të kohës së funksionimit dhe të përdorë të njëjtin imazh kudo së bashku me konfigurimin e duhur specifik për mjedisin. Ndjekja e këtij parimi ju lejon të zbatoni praktika të tilla të rëndësishme nga pikëpamja e automatizimit të sistemeve cloud si rikthimi dhe rikthimi i përditësimeve të aplikacionit.
Parimi i disponueshmërisë së procesit (PDP)
Një nga karakteristikat më të rëndësishme të një kontejneri është kalueshmëria e tij: një shembull i një kontejneri është i lehtë për t'u krijuar dhe i lehtë për t'u shkatërruar, kështu që mund të zëvendësohet lehtësisht me një shembull tjetër në çdo kohë. Mund të ketë shumë arsye për një zëvendësim të tillë: dështimi i një testi shërbimi, shkallëzimi i aplikacionit, transferimi në një host tjetër, shterimi i burimeve të platformës ose situata të tjera.
Si pasojë, aplikacionet me kontejnerë duhet të ruajnë gjendjen e tyre duke përdorur disa mjete të jashtme, ose të përdorin skema të brendshme të shpërndara me tepricë për këtë. Përveç kësaj, aplikacioni duhet të fillojë shpejt dhe të mbyllet shpejt dhe të jetë i përgatitur për dështim të papritur fatal të harduerit.
Një praktikë që ndihmon në zbatimin e këtij parimi është mbajtja e kontejnerëve të vegjël. Mjediset në renë kompjuterike mund të zgjedhin automatikisht një host për të nisur një shembull kontejneri, kështu që sa më i vogël të jetë kontejneri, aq më shpejt do të fillojë - ai thjesht do të kopjojë në hostin e synuar përmes rrjetit më shpejt.
Parimi i vetëpërmbajtjes (S-CP)
Sipas këtij parimi, në fazën e montimit, të gjithë përbërësit e nevojshëm përfshihen në enë. Kontejneri duhet të ndërtohet mbi supozimin se sistemi ka vetëm një kernel të pastër Linux, kështu që të gjitha bibliotekat e nevojshme shtesë duhet të vendosen në vetë kontejnerin. Ai gjithashtu duhet të përmbajë gjëra të tilla si koha e ekzekutimit për gjuhën përkatëse të programimit, platformën e aplikacionit (nëse është e nevojshme) dhe varësi të tjera që do të kërkohen gjatë ekzekutimit të aplikacionit të kontejnerit.
Bëhen përjashtime për konfigurimet që ndryshojnë nga mjedisi në mjedis dhe duhet të sigurohen në kohën e ekzekutimit, për shembull përmes një Kubernetes ConfigMap.
Një aplikacion mund të përfshijë disa komponentë të kontejneruar, për shembull, një kontejner të veçantë DBMS brenda një aplikacioni ueb të kontejneruar. Sipas parimit S-CP, këto kontejnerë nuk duhet të kombinohen në një, por duhet të bëhen në mënyrë që kontejneri DBMS të përmbajë gjithçka që është e nevojshme për funksionimin e bazës së të dhënave, dhe kontejneri i aplikacionit në internet përmban gjithçka që është e nevojshme për funksionimin e uebit. aplikacioni, i njëjti web server . Si rezultat, në kohën e ekzekutimit, kontejneri i aplikacionit në ueb do të varet nga kontejneri DBMS dhe do të hyjë në të sipas nevojës.
Parimi i izolimit në kohëzgjatje (RCP)
Parimi S-CP përcakton se si duhet të ndërtohet kontejneri dhe çfarë duhet të përmbajë binarja e imazhit. Por një kontejner nuk është thjesht një "kuti e zezë" që ka vetëm një karakteristikë - madhësinë e skedarit. Gjatë ekzekutimit, kontejneri merr dimensione të tjera: sasinë e memories së përdorur, kohën e CPU-së dhe burimet e tjera të sistemit.
Dhe këtu është i dobishëm parimi RCP, sipas të cilit kontejneri duhet të presë kërkesat e tij për burimet e sistemit dhe t'i transferojë ato në platformë. Me profilet e burimeve të çdo kontejneri (sa burime CPU, memorie, rrjeti dhe disku i nevojiten), platforma mund të kryejë në mënyrë optimale planifikimin dhe shkallëzimin automatik, të menaxhojë kapacitetin e IT dhe të ruajë nivelet SLA për kontejnerët.
Përveç plotësimit të kërkesave për burime të kontejnerit, është gjithashtu e rëndësishme që aplikacioni të mos shkojë përtej kufijve të tij. Përndryshe, kur ndodh një mungesë burimesh, platforma ka më shumë gjasa ta përfshijë atë në listën e aplikacioneve që duhet të ndërpriten ose të migrohen.
Kur flasim për të qenit i pari në cloud, ne po flasim për mënyrën se si punojmë.
Më sipër, ne formuluam një sërë parimesh të përgjithshme që vendosin bazën metodologjike për ndërtimin e aplikacioneve të kontejnerëve me cilësi të lartë për mjediset cloud.
Vini re se përveç këtyre parimeve të përgjithshme, do t'ju nevojiten edhe metoda dhe teknika shtesë të avancuara për të punuar me kontejnerë. Përveç kësaj, ne kemi disa rekomandime të shkurtra që janë më specifike dhe duhet të zbatohen (ose jo) në varësi të situatës:
- Përpiquni të zvogëloni madhësinë e imazheve: fshini skedarët e përkohshëm dhe mos instaloni paketa të panevojshme - sa më e vogël të jetë madhësia e kontejnerit, aq më shpejt mblidhet dhe kopjohet në hostin e synuar përmes rrjetit.
- Përqendrohuni në ID-të arbitrare të Përdoruesit: mos përdorni komandën sudo ose ndonjë përdorues të veçantë për të nisur kontejnerët tuaj.
- Shënoni portet e rëndësishme: Mund të vendosni numrat e porteve në kohën e ekzekutimit, por është më mirë t'i specifikoni duke përdorur komandën EXPOSE - kjo do ta bëjë më të lehtë për njerëzit dhe programet e tjera të përdorin imazhet tuaja.
- Ruani të dhënat e vazhdueshme për vëllimet: Të dhënat që duhet të mbeten pas shkatërrimit të kontejnerit duhet të shkruhen në vëllime.
- Shkruani meta të dhënat e imazhit: etiketat, etiketat dhe shënimet i bëjnë imazhet më të lehta për t'u përdorur - zhvilluesit e tjerë do t'ju falënderojnë.
- Sinkronizoni hostin dhe imazhet: Disa aplikacione me kontejnerë kërkojnë që kontejneri të sinkronizohet me hostin në atribute të caktuara, si koha ose ID e makinës.
- Si përfundim, ne ndajmë shabllonet dhe praktikat më të mira që do t'ju ndihmojnë të zbatoni në mënyrë më efektive parimet e listuara më sipër:
11 qershor ora 11.00
Çfarë do të mësoni:
- Red Hat Enterprise Linux CoreOS i pandryshueshëm
- Rrjetë e shërbimit OpenShift
- Korniza e operatorit
- Kornizë knative
Burimi: www.habr.com