"Nubaj denaskaj" aŭ simple "nubaj" aplikaĵoj estas kreitaj specife por labori en nubaj infrastrukturoj. Ili estas kutime konstruitaj kiel aro de loze kunligitaj mikroservoj pakitaj en ujoj, kiuj siavice estas administritaj de nuba platformo. Tiaj aplikoj estas pretaj por fiaskoj defaŭlte, kio signifas, ke ili funkcias fidinde kaj skalas eĉ en la okazo de gravaj infrastrukturaj fiaskoj. La alia flanko de la monero estas la aroj de limigoj (kontraktoj), kiujn la nuba platformo trudas al uj-aplikoj por povi administri ilin aŭtomate.
Kvankam plene konsciaj pri la bezono kaj graveco de moviĝado al nubo-bazitaj aplikoj, multaj organizoj ankoraŭ ne scias kie komenci. En ĉi tiu afiŝo, ni rigardos kelkajn principojn, kiuj, se sekvataj dum disvolvado de konteneritaj aplikoj, permesos al vi realigi la potencialon de nubaj platformoj kaj atingi fidindan funkciadon kaj skalon de aplikoj eĉ en la okazo de gravaj misfunkciadoj ĉe la IT-infrastrukturo. nivelo. La finfina celo de la principoj skizitaj ĉi tie estas lerni kiel konstrui aplikojn, kiuj povas esti aŭtomate administritaj de nubaj platformoj kiel Kubernetes.
Principoj pri Programaro-Dezajno
En la programa mondo, principoj rilatas al sufiĉe ĝeneralaj reguloj, kiujn oni devas sekvi dum evoluigado de programaro. Ili povas esti uzataj kiam oni laboras kun iu ajn programlingvo. Ĉiu principo havas siajn proprajn celojn, la ilojn por atingi, kiuj kutime estas ŝablonoj kaj praktikoj. Ekzistas ankaŭ kelkaj fundamentaj principoj por krei altkvalitan programaron, el kiuj fluas ĉiuj aliaj. Jen kelkaj ekzemploj de fundamentaj principoj:
- (Keep it simple, stupid) - ne kompliku ĝin;
- (Don't repeat yourself) - ne ripeti vin;
- (You aren't gonna need it) - ne kreu ion, kio ne estas tuj bezonata;
- Apartigo de zorgoj - dividi respondecojn.
Kiel vi povas vidi, ĉi tiuj principoj ne starigas iujn specifajn regulojn, sed apartenas al la kategorio de tiel nomataj ordinaraj konsideroj bazitaj sur praktika sperto, kiuj estas kunhavataj de multaj programistoj kaj al kiuj ili regule rilatas.
Krome, ekzistas – Aro de la unuaj kvin principoj de objekt-orientita programado kaj dezajno, formulita de Robert Martin. SOLID inkluzivas larĝajn, nefermitajn, komplementajn principojn, kiuj—se aplikataj kune—helpas krei pli bonajn programajn sistemojn kaj pli bone konservi ilin longtempe.
La SOLIDAJ principoj apartenas al la kampo de OOP kaj estas formulitaj en la lingvo de tiaj konceptoj kaj konceptoj kiel klasoj, interfacoj kaj heredo. Analogie, evoluprincipoj ankaŭ povas esti formulitaj por nubaj aplikoj, nur la baza elemento ĉi tie ne estos klaso, sed ujo. Sekvante ĉi tiujn principojn, vi povas krei kontenerajn aplikojn, kiuj pli bone plenumas la celojn kaj celojn de nubaj platformoj kiel Kubernetes.
Nub-indiĝenaj ujoj: la Red Hat-aliro
Hodiaŭ, preskaŭ ajna apliko povas esti pakita relative facile en ujojn. Sed por ke aplikoj estu efike aŭtomatigitaj kaj reĝisoritaj ene de nuba platformo kiel Kubernetes, necesas plia peno.
La bazo por la ideoj skizitaj malsupre estis la metodaro kaj multaj aliaj verkoj pri diversaj aspektoj de konstruado de TTT-aplikoj, de fontkodadministrado ĝis skalmodeloj. La priskribitaj principoj validas nur por la disvolviĝo de konteneritaj aplikoj, kiuj estas konstruitaj sur mikroservoj kaj dezajnitaj por nubaj platformoj kiel Kubernetes. La baza elemento en nia diskuto estas la ujo-bildo, kaj la cela ujo rultempo estas la ujo-orkestra platformo. La celo de la proponitaj principoj estas krei ujojn por kiuj planado, skalo, kaj monitorado taskoj povas esti aŭtomatigitaj sur la plej multaj orkestradplatformoj. La principoj estas prezentitaj en neniu aparta ordo.
Ununura Koncerna Principo (SCP)
Ĉi tiu principo estas multmaniere simila al la Unua Responsableca Principo. ), kiu estas parto de la SOLIDA aro kaj deklaras ke ĉiu objekto devas havi unu respondecon, kaj tiu respondeco devas esti tute enkapsuligita en klaso. La punkto de SRP estas, ke ĉiu respondeco estas kialo por ŝanĝo, kaj klaso devas havi unu kaj nur unu kialon por ŝanĝo.
En SCP, ni uzas la vorton "zorgo" anstataŭ la vorto "respondeco" por indiki la pli altan nivelon de abstraktado kaj pli larĝan celon de ujo kompare kun OOP-klaso. Kaj se la celo de SRP estas havi nur unu kialon por ŝanĝo, tiam malantaŭ SCP estas la deziro vastigi la kapablon reuzi kaj anstataŭigi ujojn. Sekvante la SRP kaj kreante ujon kiu solvas ununuran problemon kaj faras ĝin en funkcie kompleta maniero, vi pliigas la ŝancojn reuzi tiun ujan bildon en malsamaj aplikaĵaj kuntekstoj.
La SCP-principo deklaras ke ĉiu ujo devus solvi unu ununuran problemon kaj fari ĝin bone. Plie, SCP en la kontenera mondo estas pli facile atingi ol SRP en la OOP-mondo, ĉar ujoj kutime funkciigas unu ununuran procezon, kaj plejofte ĉi tiu procezo solvas unu ununuran taskon.
Se ujo mikroservo devas solvi plurajn problemojn samtempe, tiam ĝi povas esti dividita en unu-taskaj ujoj kaj kombinita ene de unu pod (unuo de ujo platformo deplojo) uzante sidecar kaj init uj ŝablonoj. Krome, SCP faciligas anstataŭigi malnovan ujon (kiel retservilo aŭ mesaĝmakleristo) per nova, kiu solvas la saman problemon sed pligrandigis funkciecon aŭ pli bone skalas.
Principo de Alta Observeblo (HOP)
Kiam ujoj estas uzataj kiel unuigita maniero paki kaj ruli aplikaĵojn, la aplikaĵoj mem estas traktataj kiel nigra skatolo. Tamen, se ĉi tiuj estas nubaj ujoj, tiam ili devas provizi specialajn API-ojn al la rultempo por kontroli la sanon de la ujoj kaj, se necese, fari taŭgajn agojn. Sen ĉi tio, ne eblos unuigi la aŭtomatigon de ĝisdatigado de ujoj kaj administrado de ilia vivociklo, kio, siavice, plimalbonigos la stabilecon kaj uzeblecon de la programara sistemo.
En praktiko, kontenerita aplikaĵo devus, minimume, havi API por diversaj specoj de sankontroloj: vivectestoj kaj pretectestoj. Se aplikaĵo asertas fari pli, ĝi devas provizi aliajn rimedojn por kontroli sian staton. Ekzemple, registri gravajn eventojn per STDERR kaj STDOUT por protokolo-agregado uzante Fluentd, Logstash kaj aliajn similajn ilojn. Same kiel integriĝo kun paŭsaj kaj metrikaj kolektobibliotekoj, kiel ekzemple OpenTracing, Prometheus, ktp.
Ĝenerale, la aplikaĵo ankoraŭ povas esti traktata kiel nigra skatolo, sed ĝi devas esti provizita per ĉiuj API-oj, kiujn la platformo bezonas por kontroli kaj administri ĝin laŭ la plej bona maniero.
Vivcikla Konforma Principo (LCP)
LCP estas la antitezo de HOP. Dum HOP deklaras, ke la ujo devas elmontri legitajn APIojn al la platformo, LCP postulas, ke la aplikaĵo povu akcepti informojn de la platformo. Krome, la ujo devas ne nur ricevi eventojn, sed ankaŭ adaptiĝi, alivorte, reagi al ili. Tial la nomo de la principo, kiu povas esti konsiderata kiel postulo por provizi la platformon per skribaj API-oj.
Platformoj havas malsamajn specojn de eventoj por helpi administri la vivociklon de ujo. Sed dependas de la aplikaĵo mem decidi, kiun el ili percepti kaj kiel reagi.
Estas klare, ke iuj eventoj estas pli gravaj ol aliaj. Ekzemple, se aplikaĵo ne bone toleras kraŝojn, ĝi devas akcepti signalon: ĉesigi (SIGTERM) mesaĝojn kaj komenci sian finrutinon kiel eble plej rapide por kapti la signalon: mortigi (SIGKILL) kiu venas post SIGTERM.
Aldone, eventoj kiel PostStart kaj PreStop povas esti gravaj al la vivociklo de aplikaĵo. Ekzemple, post lanĉo de aplikaĵo, ĝi povas postuli iom da varmiga tempo antaŭ ol ĝi povas respondi al petoj. Aŭ la aplikaĵo devas liberigi rimedojn en iu speciala maniero kiam fermiĝas.
La Bilda Senŝanĝeca Principo (IIP)
Estas ĝenerale akceptite ke kontenerigitaj aplikoj devus resti senŝanĝaj post estado konstruitaj, eĉ se ili estas rulitaj en malsamaj medioj. Tio necesigas la bezonon eksterigi datumstokadon ĉe rultempo (alivorte, uzi eksterajn ilojn por tio) kaj fidi je eksteraj, rultempa-specifaj konfiguracioj, prefere ol modifi aŭ krei unikajn ujojn por ĉiu medio. Post iuj ŝanĝoj al la aplikaĵo, la ujo-bildo devas esti rekonstruita kaj deplojita al ĉiuj uzataj medioj. Cetere, dum administrado de IT-sistemoj, simila principo estas uzata, konata kiel principo de neŝanĝebleco de serviloj kaj infrastrukturo.
La celo de IIP estas malhelpi la kreadon de apartaj ujbildoj por malsamaj rultempaj medioj kaj uzi la saman bildon ĉie kune kun la taŭga medio-specifa agordo. Sekvante ĉi tiun principon ebligas al vi efektivigi tiajn gravajn praktikojn el la vidpunkto de aŭtomatigo de nubaj sistemoj kiel retrovigo kaj antaŭenigo de aplikaĵaj ĝisdatigoj.
Proceza Disposebleco-Principo (PDP)
Unu el la plej gravaj karakterizaĵoj de ujo estas ĝia efemereco: ekzemplo de ujo estas facile kreebla kaj facile detruebla, do ĝi povas esti facile anstataŭigita per alia kazo en ajna momento. Povas ekzisti multaj kialoj por tia anstataŭaĵo: fiasko de servotesto, skalo de la aplikaĵo, translokigo al alia gastiganto, elĉerpiĝo de platformresursoj aŭ aliaj situacioj.
Kiel sekvo, kontenerigitaj aplikoj devas konservi sian staton uzante iujn eksterajn rimedojn, aŭ uzi internajn distribuitajn kabalojn kun redundo por tio. Krome, la aplikaĵo devas komenci rapide kaj malŝalti rapide, kaj esti preta por subita fatala aparataro fiasko.
Unu praktiko kiu helpas efektivigi ĉi tiun principon estas teni ujojn malgrandaj. Nubaj medioj povas aŭtomate elekti gastiganton por lanĉi ujon, do ju pli malgranda la ujo, des pli rapide ĝi komenciĝos - ĝi simple kopios al la cela gastiganto tra la reto pli rapide.
Memenhava Principo (S-CP)
Laŭ ĉi tiu principo, en la kunigo, ĉiuj necesaj komponantoj estas inkluzivitaj en la ujo. La ujo devas esti konstruita laŭ la supozo, ke la sistemo nur havas puran Linuksan kernon, do ĉiuj necesaj kromaj bibliotekoj estu metitaj en la ujo mem. Ĝi ankaŭ devus enhavi aferojn kiel la rultempo por la responda programlingvo, la aplikaĵa platformo (se necese), kaj aliajn dependecojn kiuj estos postulataj dum la ujo-aplikaĵo funkcias.
Esceptoj estas faritaj por agordoj kiuj varias de medio al medio kaj devas esti provizitaj ĉe rultempo, ekzemple per Kubernetes ConfigMap.
Apliko povas inkludi plurajn kontenerigitajn komponentojn, ekzemple, apartan DBMS-ujon ene de kontenerigita retaplikaĵo. Laŭ la S-CP-principo, ĉi tiuj ujoj ne devas esti kombinitaj en unu, sed devus esti faritaj tiel ke la DBMS-ujo enhavas ĉion necesan por la funkciado de la datumbazo, kaj la TTT-aplika ujo enhavas ĉion necesan por la funkciado de la retejo. aplikaĵo, la sama retservilo. Kiel rezulto, ĉe rultempo la TTT-aplikaĵujo dependos de la DBMS-ujo kaj aliros ĝin laŭbezone.
Runtime Confinement Principo (RCP)
La S-CP-principo difinas kiel la ujo devus esti konstruita kaj kion la bildbinaro devus enhavi. Sed ujo ne estas nur "nigra skatolo", kiu havas nur unu karakterizaĵon - grandeco de dosiero. Dum ekzekuto, la ujo prenas aliajn dimensiojn: la kvanton de memoro uzata, CPU-tempo kaj aliaj sistemaj rimedoj.
Kaj ĉi tie la RCP-principo utilas, laŭ kiu la ujo devas senkapigi siajn postulojn por sistemaj rimedoj kaj transdoni ilin al la platformo. Kun la rimedoprofiloj de ĉiu ujo (kiom da CPU, memoro, reto kaj diskresursoj ĝi bezonas), la platformo povas optimume plenumi planadon kaj aŭtoskalon, administri IT-kapaciton kaj konservi SLA-nivelojn por ujoj.
Krom plenumi la rimedpostulojn de la ujo, ankaŭ gravas, ke la aplikaĵo ne preterpasu siajn proprajn limojn. Alie, kiam mankas rimedoj, la platformo pli verŝajne inkluzivos ĝin en la liston de aplikaĵoj, kiuj devas esti ĉesigitaj aŭ migritaj.
Kiam ni parolas pri esti unua nubo, ni parolas pri la maniero kiel ni laboras.
Supre, ni formulis kelkajn ĝeneralajn principojn, kiuj starigas la metodikan fundamenton por konstrui altkvalitajn ujajn aplikojn por nubaj medioj.
Notu, ke krom ĉi tiuj ĝeneralaj principoj, vi ankaŭ bezonos pliajn altnivelajn metodojn kaj teknikojn por labori kun ujoj. Krome, ni havas kelkajn mallongajn rekomendojn, kiuj estas pli specifaj kaj devus esti aplikataj (aŭ ne aplikataj) laŭ la situacio:
- Provu redukti la grandecon de bildoj: forigu provizorajn dosierojn kaj ne instalu nenecesajn pakaĵojn - ju pli malgranda la ujgrandeco, des pli rapide ĝi estas kunvenita kaj kopiita al la cela gastiganto tra la reto.
- Fokuso sur arbitraj Uzantidentoj: ne uzu la sudo-komandon aŭ ajnan specialan uzantidenton por lanĉi viajn ujojn.
- Marki gravajn havenojn: Vi povas agordi havennumerojn dum rultempo, sed estas pli bone specifi ilin per la komando EXPOSE - ĝi faciligos al aliaj homoj kaj programoj uzi viajn bildojn.
- Stoki konstantajn datumojn pri volumoj: Datumoj, kiuj devus resti post kiam la ujo estas detruita, devas esti skribitaj al volumoj.
- Skribu bildajn metadatumojn: etikedoj, etikedoj kaj komentarioj faciligas uzi bildojn - aliaj programistoj dankos vin.
- Sinkronigi gastiganton kaj bildojn: Iuj konteneritaj aplikoj postulas, ke la ujo sinkronigu kun la gastiganto pri certaj atributoj, kiel tempo aŭ maŝina ID.
- Konklude, ni dividas ŝablonojn kaj plej bonajn praktikojn, kiuj helpos vin pli efike efektivigi la supre listigitajn principojn:
La 11-an de junio je la 11.00
Kion vi lernos:
- Neŝanĝebla Red Hat Enterprise Linux CoreOS
- OpenShift servo maŝo
- Operatora kadro
- Knativa kadro
fonto: www.habr.com