"Wolk-georiënteerde" (wolk inheems) of bloot "wolk" toepassings word spesifiek geskep om in wolkinfrastruktuur te werk. Hulle word gewoonlik gebou as 'n stel losgekoppelde mikrodienste wat in houers verpak word, wat op hul beurt deur 'n wolkplatform bestuur word. Hierdie toepassings is by verstek faalveilig, wat beteken dat hulle betroubaar werk en skaal selfs in die lig van ernstige infrastruktuurvlakfoute. Die agterkant van die muntstuk is die stelle beperkings (kontrakte) wat die wolkplatform op houertoepassings stel om dit outomaties te kan bestuur.
Ten volle bewus van die behoefte en belangrikheid om na die wolk te beweeg, weet baie organisasies steeds nie waar om te begin nie. In hierdie plasing sal ons kyk na 'n aantal beginsels wat, wanneer u toepassings met houers ontwikkel, u in staat sal stel om die potensiaal van wolkplatforms te besef en betroubare werking en skaal van toepassings te bereik, selfs met ernstige mislukkings op die IT-infrastruktuurvlak. Die uiteindelike doel van die beginsels wat hier uiteengesit word, is om te leer hoe om toepassings te bou wat outomaties deur wolkplatforms soos Kubernetes bestuur kan word.
Sagteware-ontwerpbeginsels
In die wêreld van programmering is beginsels redelik algemene reëls wat nagekom moet word wanneer sagteware ontwikkel word. Hulle kan met enige programmeertaal gebruik word. Elke beginsel het sy eie doelwitte, wat gewoonlik deur patrone en praktyke bereik word. Daar is ook 'n aantal fundamentele beginsels vir die skep van hoë kwaliteit sagteware, waaruit al die res volg. Hier is 'n paar voorbeelde van fundamentele beginsels:
- (Hou dit eenvoudig, dom) - moenie kompliseer nie;
- (Moenie jouself herhaal nie) - moenie jouself herhaal nie;
- (Jy gaan dit nie nodig hê nie) - moenie iets skep waarvoor daar geen onmiddellike behoefte is nie;
- (Skeiding van bekommernisse) - om verantwoordelikhede te deel.
Soos u kan sien, stel hierdie beginsels geen spesifieke reëls nie, maar behoort dit tot die kategorie van sogenaamde gesonde verstand-oorwegings gebaseer op praktiese ervaring, wat deur baie ontwikkelaars gedeel word en waarna hulle gereeld verwys.
Daarbenewens is daar - 'n stel van die eerste vyf beginsels van objekgeoriënteerde programmering en ontwerp, geformuleer deur Robert Martin. SOLID sluit veralgemeende en oop vir interpretasie komplementêre beginsels in wat – wanneer dit in kombinasie toegepas word – help om beter sagtewarestelsels te skep en dit op lang termyn beter te onderhou.
Die beginsels van SOLID behoort tot die gebied van OOP en word geformuleer in die taal van konsepte en konsepte soos klasse, koppelvlakke en oorerwing. Na analogie, vir wolktoepassings, kan ontwikkelingsbeginsels ook geformuleer word, slegs die basiese element hier sal nie 'n klas wees nie, maar 'n houer. Deur hierdie beginsels te volg, kan jy houertoepassings skep wat die doelwitte en doelwitte van wolkplatforms soos Kubernetes beter dien.
Wolk-gebaseerde houers: Die Red Hat-benadering
Vandag kan byna enige toediening relatief maklik in houers verpak word. Maar om toepassings effektief geoutomatiseer en georkestreer te word binne 'n wolkplatform soos Kubernetes, is bykomende pogings nodig.
Die volgende metodologie is as basis vir die idees gebruik en baie ander werke oor verskeie aspekte van die bou van webtoepassings, van bronkodebestuur tot skaalmodelle. Die beskryfde beginsels is slegs van toepassing op die ontwikkeling van houertoepassings wat bo-op mikrodienste gebou is en ontwerp is vir wolkplatforms soos Kubernetes. Die basiselement in ons bespreking is die houerbeeld, en die teikenlooptyd van houers is die houerorkestrasieplatform. Die doel van die voorgestelde beginsels is om houers te skep waarvoor dit op die meeste orkestrasieplatforms moontlik is om die take van skedulering (skedulering - die keuse van 'n gasheer om 'n houerinstansie uit te voer), skaal en monitering te outomatiseer. Die beginsels word in geen spesifieke volgorde aangebied nie.
Die enkelbesorgdheidsbeginsel (SCP)
Hierdie beginsel is in baie opsigte soortgelyk aan die Enkel Verantwoordelikheidsbeginsel. ), wat deel is van die SOLID-stel en stel dat elke voorwerp een verantwoordelikheid moet hê, en hierdie verantwoordelikheid moet volledig in 'n klas ingekapsuleer word. Die essensie van SRP is dat elke verantwoordelikheid 'n rede is om te verander, en 'n klas moet een en slegs een rede hê om te verander.
In SCP, in plaas van die woord "verantwoordelikheid" (verantwoordelikheid), gebruik ons die woord "taak" (bekommernis) om 'n hoër vlak van abstraksie en wyer doel van die houer aan te dui in vergelyking met die OOP-klas. En as die doel van SRP is om net een rede vir verandering te hê, dan is die begeerte agter SCP om die moontlikhede van hergebruik en vervanging van houers uit te brei. Deur die SRP te volg en 'n houer te skep wat 'n enkele ding doen en dit op 'n funksioneel volledige manier doen, verhoog jy die kanse om daardie houer se beeld in verskillende toepassingskontekste te hergebruik.
Die SCP-beginsel sê dat elke houer een enkele taak moet oplos en dit goed moet doen. Boonop is SCP in die houerwêreld makliker om te bereik as SRP in die OOP-wêreld, aangesien houers gewoonlik een enkele proses uitvoer, en die meeste van die tyd los hierdie proses een enkele taak op.
As 'n houer-mikrodiens verskeie take gelyktydig moet oplos, kan dit in enkeltaakhouers verdeel word en binne een peul (houerplatformontplooiingseenheid) gekombineer word deur syspan-sjablone en inithouers te gebruik. Daarbenewens maak SCP dit maklik om 'n ou houer (soos 'n webbediener of boodskapmakelaar) te vervang met 'n nuwe een wat dieselfde werk doen, maar meer funksionaliteit het of beter skaal.
Hoë Waarneembaarheidsbeginsel (HOP)
Wanneer houers gebruik word as 'n verenigde manier om toepassings te verpak en uit te voer, word die toepassings self as 'n "swart boks" hanteer. As dit egter wolkhouers is, moet hulle spesifieke API's aan die looptyd verskaf om die gesondheid van die houers te monitor en toepaslike stappe te neem indien nodig. Sonder dit sal dit nie moontlik wees om die outomatisering van die opdatering van houers en die bestuur van hul lewensiklus te verenig nie, wat op sy beurt die stabiliteit en bruikbaarheid van die sagtewarestelsel sal vererger.
In die praktyk moet 'n houertoepassing ten minste 'n API hê vir verskeie tipes gesondheidsondersoeke: lewendheidstoetse en gereedheidstoetse. As 'n aansoek meer as dit eis, moet dit ander maniere verskaf om sy toestand te monitor. Byvoorbeeld, die aanteken van belangrike gebeurtenisse via STDERR en STDOUT vir die aanteken van samevoeging met Fluentd, Logstash en ander soortgelyke instrumente. Sowel as integrasie met opsporing en metrieke biblioteke soos OpenTracing, Prometheus, ens.
Oor die algemeen kan 'n toepassing steeds as 'n "swart boks" beskou word, maar dit moet voorsien word van al die API's wat die platform benodig om dit op die beste moontlike manier te monitor en te bestuur.
Lewensiklus-konformiteitsbeginsel (LCP)
LCP is die antitese van HOP. Terwyl die HOP sê dat die houer lees-API's aan die platform moet verskaf, vereis die LCP dat die toepassing inligting vanaf die platform kan lees. Boonop moet die houer nie net gebeure ontvang nie, maar ook aanpas, met ander woorde, daarop reageer. Vandaar die naam van die beginsel, wat beskou kan word as 'n vereiste om skryf-API's aan die platform te verskaf.
Platforms het verskillende soorte gebeurtenisse om die lewensiklus van 'n houer te help bestuur. Maar dit is aan die aansoek om te besluit watter van hulle om waar te neem en hoe om te reageer.
Dit is duidelik dat sommige gebeure belangriker is as ander. Byvoorbeeld, as 'n toepassing nie goed duld om neer te stort nie, moet dit sein: beëindig (SIGTERM) boodskappe aanvaar en sy beëindigingsprosedure so gou moontlik begin om betyds te wees vir die sein: dood (SIGKILL) wat ná SIGTERM kom .
Boonop kan gebeurtenisse soos PostStart en PreStop belangrik wees vir die lewensiklus van 'n toepassing. Byvoorbeeld, nadat 'n toepassing bekendgestel is, kan dit 'n sekere tyd neem om "op te warm" voordat dit op versoeke kan reageer. Of die toepassing moet hulpbronne op een of ander spesiale manier vrystel wanneer dit gesluit word.
Die beginsel van onveranderlikheid van die houerbeeld (Image Immutability Principle, IIP)
Dit word algemeen aanvaar dat houertoepassings dieselfde moet bly nadat dit gebou is, selfs al word dit in verskillende omgewings uitgevoer. Dit noodsaak die behoefte om runtime-databerging te eksternaliseer (met ander woorde, gebruik eksterne gereedskap om dit te doen), en ook staatmaak op eksterne runtime-spesifieke konfigurasies, eerder as om unieke houers vir elke omgewing te wysig of te skep. Na enige veranderinge aan die toepassing, moet die houerbeeld herbou en ontplooi word na alle omgewings wat gebruik word. Terloops, wanneer IT-stelsels bestuur word, word 'n soortgelyke beginsel gebruik, bekend as die beginsel van onveranderlikheid van bedieners en infrastruktuur.
Die doel van IIP is om die skepping van afsonderlike houerbeelde vir verskillende looptydomgewings te voorkom en om dieselfde beeld oral saam met die toepaslike omgewingspesifieke konfigurasie te gebruik. Deur hierdie beginsel te volg, kan jy sulke belangrike praktyke implementeer vanuit die oogpunt van outomatisering van wolkstelsels soos terugrol (terugrol) en terugrol (rol vorentoe) van toepassingopdaterings.
Proses weggooibaarheidsbeginsel (PDP)
Een van die belangrikste kenmerke van 'n houer is die kortstondige aard daarvan: 'n instansie van 'n houer word maklik geskep en maklik vernietig, dus kan dit te eniger tyd maklik met 'n ander instansie vervang word. Daar kan baie redes vir so 'n vervanging wees: mislukking van die gesondheidstoets, toepassingskaal, oordrag na 'n ander gasheer, uitputting van platformhulpbronne of ander situasies.
Gevolglik moet houertoepassings hul toestand stoor met behulp van een of ander eksterne middel, of interne oortollige verspreide skemas hiervoor gebruik. Daarbenewens moet die toepassing vinnig begin en eindig, en voorbereid wees op 'n skielike noodlottige hardeware-fout.
Een praktyk om hierdie beginsel te help implementeer, is om houers klein te hou. Wolk-omgewings kan outomaties 'n gasheer kies om 'n houerinstansie op te laat loop, so hoe kleiner die houergrootte is, hoe vinniger sal dit begin - dit sal net vinniger na die teikengasheer oor die netwerk kopieer.
Selfbeperkingsbeginsel (S-CP)
Volgens hierdie beginsel word al die nodige komponente by die monteringstadium in die houer ingesluit. Die houer moet gebou word met die aanname dat die stelsel slegs 'n suiwer Linux-kern het, dus moet al die nodige bykomende biblioteke in die houer self geplaas word. Dit moet ook dinge bevat soos die looptyd vir die toepaslike programmeertaal, die toepassingsplatform (indien nodig) en ander afhanklikhede wat benodig sal word tydens die werking van die houertoepassing.
Uitsonderings word slegs gemaak vir konfigurasies, wat van omgewing tot omgewing verskil, en moet tydens looptyd verskaf word, byvoorbeeld deur die Kubernetes ConfigMap.
'n Toepassing kan veelvuldige houer-komponente insluit, soos 'n aparte DBMS-houer as deel van 'n houer-webtoepassing. Volgens die S-CP-beginsel moet hierdie houers nie in een gekombineer word nie, maar moet so gemaak word dat die DBMS-houer alles bevat wat nodig is vir die werking van die databasis, en die webtoepassingshouer alles bevat wat nodig is vir die werking van die web toepassing, dieselfde webbediener . Gevolglik sal die webtoepassinghouer tydens looptyd afhang van die DBMS-houer en toegang daartoe verkry soos nodig.
Runtime Confinement Principle (RCP)
Die S-CP-beginsel definieer hoe die houer gebou moet word en wat die binêre beeldlêer moet bevat. Maar 'n houer is nie net 'n "swart boks" wat net een kenmerk het nie - lêergrootte. Tydens looptyd kry die houer ook ander dimensies: die hoeveelheid geheue wat gebruik word, verwerkertyd en ander stelselhulpbronne.
En hier kom die RCP-beginsel handig te pas, waarvolgens die houer sy vereistes vir stelselhulpbronne moet onthoof en na die platform moet oordra. Deur hulpbronprofiele vir elke houer te hê (hoeveel SVE-, geheue-, netwerk- en skyfhulpbronne dit benodig), kan die platform optimaal versend en outoskaal, IT-kapasiteit bestuur en SLA-vlakke vir houers handhaaf.
Benewens die bevrediging van die hulpbronvereistes van die houer, is dit ook belangrik dat die aansoek nie verder gaan as die perke wat deur homself aangedui word nie. Andersins, wanneer 'n hulpbrontekort voorkom, is die platform meer geneig om dit by die lys toepassings in te sluit wat onderbreek of gemigreer moet word.
As ons daaroor praat om wolkgesentreerd te wees, bedoel ons hoofsaaklik die manier waarop ons werk.
Hierbo het ons 'n aantal algemene beginsels geformuleer wat die metodologiese grondslag lê vir die bou van hoëgehalte-houertoepassings vir wolkomgewings.
Let daarop dat jy benewens hierdie algemene beginsels ook bykomende gevorderde metodes en tegnieke sal benodig om met houers te werk. Daarbenewens het ons 'n paar kort riglyne wat meer spesifiek is en toegepas moet word (of nie toegepas word nie), afhangende van die situasie:
- Probeer om die grootte van beelde te verminder: verwyder tydelike lêers en moenie onnodige pakkette installeer nie - hoe kleiner die houergrootte, hoe vinniger word dit saamgestel en na die teikengasheer oor die netwerk gekopieer.
- Teiken arbitrêre gebruiker-ID's: moenie die sudo-opdrag of enige spesiale gebruikers-ID gebruik om jou houers te begin nie.
- Benoem belangrike poorte: Poortnommers kan ook tydens looptyd gestel word, maar dit is beter om dit met die EXPOSE-opdrag te spesifiseer sodat ander mense en programme jou beelde makliker kan gebruik.
- Stoor volgehoue data op volumes: Data wat moet oorbly nadat die houer vernietig is, moet na volumes geskryf word.
- Skryf prentmetadata: merkers, etikette en aantekeninge maak prente makliker om te gebruik - ander ontwikkelaars sal jou bedank.
- Sinkroniseer gasheer en beelde: Sommige houertoepassings vereis dat die houer met die gasheer sinchroniseer op grond van sekere eienskappe, soos tyd of masjien-ID.
- Ten slotte deel ons patrone en beste praktyke wat jou sal help om die beginsels wat hierbo gelys is meer effektief te implementeer:
11 Junie om 11.00:XNUMX
Wat sal jy leer:
- Onveranderlike Red Hat Enterprise Linux CoreOS
- OpenShift-diensnetwerk
- operateur raamwerk
- Knatiewe raamwerk
Bron: will.com