"Cloud native" of gewoan "cloud" applikaasjes wurde spesifyk makke om te wurkjen yn wolkinfrastruktuer. Se wurde typysk boud as in set fan los keppele mikrotsjinsten ferpakt yn konteners, dy't op har beurt wurde beheard troch in wolkplatfoarm. Sokke applikaasjes binne standert taret op flaters, wat betsjut dat se betrouber wurkje en skaalje, sels yn gefal fan serieuze flaters op ynfrastruktuernivo. De oare kant fan 'e munt binne de sets fan beheiningen (kontrakten) dy't it wolkplatfoarm oplein op kontenerapplikaasjes om se automatysk te behearjen.
Wylst se folslein bewust binne fan de needsaak en it belang fan it ferpleatsen nei cloud-basearre applikaasjes, witte in protte organisaasjes noch altyd net wêr't se moatte begjinne. Yn dit post sille wy nei in oantal prinsipes sjen dy't, as folge by it ûntwikkeljen fan kontenerisearre applikaasjes, jo it potensjeel fan wolkplatfoarms kinne realisearje en betroubere operaasje en skaalfergrutting fan applikaasjes realisearje, sels yn it gefal fan serieuze mislearrings yn 'e IT-ynfrastruktuer peil. It ultime doel fan 'e hjir beskreaune prinsipes is om te learen hoe't jo applikaasjes bouwe kinne dy't automatysk kinne wurde beheard troch wolkplatfoarms lykas Kubernetes.
Software Design Prinsipes
Yn 'e programmearringwrâld ferwize prinsipes nei frij algemiene regels dy't moatte wurde folge by it ûntwikkeljen fan software. Se kinne brûkt wurde by it wurkjen mei elke programmeartaal. Elk prinsipe hat syn eigen doelen, de ark foar it realisearjen dy't normaal sjabloanen en praktiken binne. D'r binne ek in oantal fûnemintele prinsipes foar it meitsjen fan heechweardige software, wêrfan alle oaren streame. Hjir binne wat foarbylden fan fûnemintele prinsipes:
- (Hâld it ienfâldich, dom) - komplisearje it net;
- (Werhelje dysels net) - werhelje dysels net;
- (Jo sille it net nedich hawwe) - meitsje net iets dat net direkt nedich is;
- Skieding fan soargen - diele ferantwurdlikheden.
Sa't jo sjen kinne, dizze prinsipes stelle gjin spesifike regels, mar hearre ta de kategory fan saneamde sûn ferstân oerwagings basearre op praktyske ûnderfining, dy't wurde dield troch in protte ûntwikkelders en dêr't se geregeldwei ferwize.
Derneist is d'r - In set fan 'e earste fiif prinsipes fan objekt-rjochte programmearring en ûntwerp, formulearre troch Robert Martin. SOLID omfettet brede, iepen-einige, komplementêre prinsipes dy't - as se tegearre tapast wurde - helpe om bettere softwaresystemen te meitsjen en se op 'e lange termyn better te ûnderhâlden.
De SOLID-prinsipes hearre ta it mêd fan OOP en wurde formulearre yn 'e taal fan sokke begripen en begripen as klassen, ynterfaces en erfenis. Troch analogy kinne ûntwikkelingsprinsipes ek formulearre wurde foar wolkapplikaasjes, allinich it basiselemint sil hjir gjin klasse wêze, mar in kontener. Troch dizze prinsipes te folgjen kinne jo kontenerisearre applikaasjes meitsje dy't better foldogge oan de doelen en doelstellingen fan wolkplatfoarms lykas Kubernetes.
Wolken-native konteners: de Red Hat-oanpak
Tsjintwurdich kin hast elke applikaasje relatyf maklik yn konteners wurde ferpakt. Mar foar applikaasjes om effektyf automatisearre en orkestreare te wurden binnen in wolkplatfoarm lykas Kubernetes, is ekstra ynspanning nedich.
De basis foar de ûndersteande ideeën wie de metodyk en in protte oare wurken oer ferskate aspekten fan it bouwen fan webapplikaasjes, fan boarnekoadebehear oant skaalfergruttingsmodellen. De beskreaune prinsipes jilde allinich foar de ûntwikkeling fan kontenerisearre applikaasjes dy't binne boud boppe op mikrotsjinsten en ûntworpen foar wolkplatfoarms lykas Kubernetes. It basiselemint yn ús diskusje is it kontenerôfbylding, en de doelkontener-runtime is it kontenerorkestraasjeplatfoarm. It doel fan 'e foarstelde prinsipes is om konteners te meitsjen wêrfoar taken foar planning, skaalfergrutting en monitoaring kinne wurde automatisearre op de measte orkestraasjeplatfoarms. De prinsipes wurde presintearre yn gjin bepaalde folchoarder.
Single Concern Principle (SCP)
Dit prinsipe is op in protte manieren fergelykber mei it ienige ferantwurdlikensprinsipe. ), dy't diel útmakket fan 'e SOLID-set en stelt dat elk objekt ien ferantwurdlikens moat hawwe, en dy ferantwurdlikens moat folslein ynkapsele wurde yn in klasse. It punt fan SRP is dat elke ferantwurdlikens in reden is foar feroaring, en in klasse moat ien en ien reden hawwe foar feroaring.
Yn SCP brûke wy it wurd "soarch" ynstee fan it wurd "ferantwurdlikens" om it hegere nivo fan abstraksje en bredere doel fan in kontener oan te jaan yn ferliking mei in OOP-klasse. En as it doel fan SRP is om mar ien reden foar feroaring te hawwen, dan is efter SCP de winsk om de mooglikheid út te wreidzjen om konteners opnij te brûken en te ferfangen. Troch de SRP te folgjen en in kontener te meitsjen dy't ien probleem oplost en it op in funksjoneel folsleine manier docht, ferheegje jo de kânsen om dat kontenerôfbylding opnij te brûken yn ferskate applikaasje-konteksten.
It SCP-prinsipe stelt dat elke kontener ien probleem oplosse moat en goed dwaan. Boppedat is SCP yn 'e kontenerwrâld makliker te berikken as SRP yn' e OOP-wrâld, om't konteners meastentiids ien proses útfiere, en meastentiids lost dit proses ien inkele taak op.
As guon kontenermikrotsjinsten ferskate problemen tagelyk moatte oplosse, dan kin it wurde ferdield yn konteners mei ien taak en kombineare binnen ien pod (in ienheid fan ynset fan kontenerplatfoarm) mei help fan sidecar- en init-containersjabloanen. Derneist makket SCP it maklik om in âlde kontener (lykas in webserver of berjochtmakelaar) te ferfangen mei in nije dy't itselde probleem oplost, mar funksjonaliteit hat útwreide of better skalen.
High Observability Principle (HOP)
As konteners wurde brûkt as ienige manier om applikaasjes te ferpakken en út te fieren, wurde de applikaasjes sels behannele as in swarte doaze. As dit lykwols wolkkonteners binne, dan moatte se spesjale API's leverje oan 'e runtime om de sûnens fan' e konteners te kontrolearjen en, as nedich, passende aksje te nimmen. Sûnder dit sil it net mooglik wêze om de automatisearring fan it bywurkjen fan konteners te ferienigjen en har libbenssyklus te behearjen, wat op syn beurt de stabiliteit en brûkberens fan it softwaresysteem sil fergrieme.
Yn 'e praktyk soe in kontenerisearre applikaasje op syn minst in API moatte hawwe foar ferskate soarten sûnenskontrôles: livenesstests en reewilligenstests. As in applikaasje beweart mear te dwaan, moat it oare middels leverje om har steat te kontrolearjen. Bygelyks, logging wichtige barrens fia STDERR en STDOUT foar log aggregaasje mei help Fluentd, Logstash en oare ferlykbere ark. Lykas yntegraasje mei tracing- en metriksamlingsbiblioteken, lykas OpenTracing, Prometheus, ensfh.
Yn 't algemien kin de applikaasje noch as in swarte doaze behannele wurde, mar it moat wurde foarsjoen fan alle API's dy't it platfoarm nedich is om it op de bêste mooglike manier te kontrolearjen en te behearjen.
Life-cycle Conformance Principle (LCP)
LCP is de antithese fan HOP. Wylst HOP stelt dat de kontener lês-API's moat bleatstelle oan it platfoarm, fereasket LCP dat de applikaasje ynformaasje fan it platfoarm akseptearje kin. Boppedat moat de kontener net allinnich eveneminten ûntfange, mar ek oanpasse, mei oare wurden, dêrop reagearje. Dêrfandinne de namme fan it prinsipe, dat kin wurde beskôge as in eask om it platfoarm te foarsjen mei skriuwende API's.
Platfoarms hawwe ferskate soarten eveneminten om te helpen by it behearen fan de libbenssyklus fan in kontener. Mar it is oan de applikaasje sels om te besluten hokker fan har te waarnimme en hoe te reagearjen.
It is dúdlik dat guon eveneminten wichtiger binne as oaren. Bygelyks, as in applikaasje crashes net goed tolerearret, moat it sinjaal akseptearje: beëinigje (SIGTERM) berjochten en syn beëinigingsroutine sa gau mooglik begjinne om it sinjaal te fangen: kill (SIGKILL) dat komt nei SIGTERM.
Derneist kinne eveneminten lykas PostStart en PreStop wichtich wêze foar de libbenssyklus fan in applikaasje. Bygelyks, nei it lansearjen fan in applikaasje, kin it wat opwaarmingstiid nedich wêze foardat it kin reagearje op oanfragen. Of de applikaasje moat boarnen op in spesjale manier frijlitte by it ôfsluten.
The Image Immutability Principle (IIP)
It wurdt algemien akseptearre dat containerized applikaasjes moatte bliuwe ûnferoare neidat se binne boud, sels as se wurde útfierd yn ferskillende omjouwings. Dit fereasket de needsaak om gegevensopslach op runtime te eksternalisearjen (mei oare wurden, om hjirfoar eksterne ark te brûken) en te fertrouwe op eksterne, runtime-spesifike konfiguraasjes, yn stee fan it wizigjen of oanmeitsjen fan unike konteners foar elke omjouwing. Nei alle wizigingen oan 'e applikaasje moat de kontenerôfbylding opnij wurde opboud en ynset yn alle brûkte omjouwings. Trouwens, by it behearen fan IT-systemen wurdt in ferlykber prinsipe brûkt, bekend as it prinsipe fan ûnferoarlikens fan servers en ynfrastruktuer.
It doel fan IIP is om it oanmeitsjen fan aparte kontenerôfbyldings foar ferskate runtime-omjouwings te foarkommen en deselde ôfbylding oeral te brûken tegearre mei de passende omjouwingsspesifike konfiguraasje. Troch dit prinsipe te folgjen kinne jo sokke wichtige praktiken ymplementearje út it eachpunt fan automatisearring fan wolksystemen as roll-back en roll-forward fan applikaasje-updates.
Process Disposability Principle (PDP)
Ien fan 'e wichtichste skaaimerken fan in kontener is syn ehemeraliteit: in eksimplaar fan in kontener is maklik te meitsjen en maklik te ferneatigjen, sadat it op elk momint maklik ferfongen wurde kin troch in oar eksimplaar. D'r kinne in protte redenen wêze foar sa'n ferfanging: mislearjen fan in tsjinstberenstest, skaalfergrutting fan 'e applikaasje, oerdracht nei in oare host, útputting fan platfoarmboarnen, of oare situaasjes.
As konsekwinsje moatte kontenerisearre applikaasjes har steat behâlde mei guon eksterne middels, of ynterne ferdielde skema's mei oerstalligens brûke foar dit. Derneist moat de applikaasje rap begjinne en rap ôfslute, en wurde taret op hommelse fatale hardwarefout.
Ien praktyk dy't helpt by it útfieren fan dit prinsipe is om konteners lyts te hâlden. Wolke-omjouwings kinne automatysk in host selektearje om in kontenereksimplaar op te starten, dus hoe lytser de kontener, hoe flugger it sil begjinne - it sil gewoan rapper kopiearje nei de doelhost oer it netwurk.
Self-containment Principle (S-CP)
Neffens dit prinsipe, yn 'e gearstalling poadium alle nedige komponinten opnommen yn' e kontener. De kontener moat boud wurde op 'e oanname dat it systeem allinich in reine Linux-kernel hat, sadat alle nedige ekstra biblioteken yn' e kontener sels pleatst wurde moatte. It moat ek dingen befetsje lykas de runtime foar de oerienkommende programmeartaal, it applikaasjeplatfoarm (as nedich), en oare ôfhinklikens dy't nedich binne wylst de kontenerapplikaasje rint.
Utsûnderings wurde makke foar konfiguraasjes dy't fariearje fan omjouwing nei omjouwing en moatte wurde levere by runtime, bygelyks fia in Kubernetes ConfigMap.
In applikaasje kin ferskate containerisearre komponinten omfetsje, bygelyks in aparte DBMS-container binnen in containerisearre webapplikaasje. Neffens it S-CP-prinsipe moatte dizze konteners net yn ien kombineare wurde, mar moatte wurde makke sadat de DBMS-kontener alles befettet dat nedich is foar de wurking fan 'e databank, en de kontener foar webapplikaasje befettet alles dat nedich is foar de wurking fan it web applikaasje, deselde webserver. As resultaat sil de kontener fan 'e webapplikaasje by runtime ôfhinklik wêze fan' e DBMS-kontener en tagong krije as nedich.
Runtime Confinement Principle (RCP)
It S-CP-prinsipe definiearret hoe't de kontener boud wurde moat en wat it binêr byld moat befetsje. Mar in kontener is net allinich in "swarte doaze" dy't mar ien karakteristyk hat - triemgrutte. Tidens de útfiering nimt de kontener oare dimensjes oan: de hoemannichte brûkte ûnthâld, CPU-tiid en oare systeemboarnen.
En hjir komt it RCP-prinsipe goed fan pas, neffens dêr't de kontener syn easken foar systeemboarnen moat dekapitearje en oerdrage nei it platfoarm. Mei de boarneprofilen fan elke kontener (hoefolle CPU-, ûnthâld-, netwurk- en skiifboarnen it nedich is), kin it platfoarm optimaal scheduling en autoscaling útfiere, IT-kapasiteit beheare en SLA-nivo's foar konteners behâlde.
Neist it foldwaan oan de boarne easken fan 'e kontener is it ek wichtich dat de applikaasje net oer de eigen grinzen giet. Oars, as in boarne tekoart optreedt, is it platfoarm mear kâns om it op te nimmen yn 'e list mei applikaasjes dy't moatte wurde beëinige of migrearre.
As wy prate oer wolk-earst wêze, hawwe wy it oer de manier wêrop wy wurkje.
Hjirboppe formulearre wy in oantal algemiene prinsipes dy't de metodologyske basis stelle foar it bouwen fan heechweardige kontenerapplikaasjes foar wolkomjouwings.
Tink derom dat jo neist dizze algemiene prinsipes ek ekstra avansearre metoaden en techniken nedich binne foar wurkjen mei konteners. Derneist hawwe wy in pear koarte oanbefellings dy't mear spesifyk binne en moatte wurde tapast (of net tapast) ôfhinklik fan 'e situaasje:
- Besykje de grutte fan ôfbyldings te ferminderjen: tydlike bestannen wiskje en gjin ûnnedige pakketten ynstallearje - hoe lytser de kontenergrutte, hoe rapper it wurdt gearstald en kopieare nei de doelhost oer it netwurk.
- Fokus op willekeurige brûkers-ID's: brûk it sudo-kommando of in spesjale brûkersid net om jo konteners te starten.
- Markearje wichtige havens: Jo kinne poartenûmers ynstelle by runtime, mar it is better om se oan te jaan mei it kommando EXPOSE - it sil it makliker meitsje foar oare minsken en programma's om jo ôfbyldings te brûken.
- Bewarje persistente gegevens oer folumes: Gegevens dy't moatte bliuwe nei't de kontener ferneatige is, moatte wurde skreaun nei folumes.
- Skriuw ôfbyldingsmetadata: tags, labels en annotaasjes meitsje ôfbyldings makliker te brûken - oare ûntwikkelders sille jo tankje.
- Syngronisearje host en ôfbyldings: Guon containerized applikaasjes fereaskje dat de container syngronisearje mei de host op bepaalde attributen, lykas tiid of masine ID.
- Ta beslút, diele wy sjabloanen en bêste praktiken dy't jo sille helpe om de hjirboppe neamde prinsipes effektiver út te fieren:
11 juny om 11.00 oere
Wat jo sille leare:
- Immutable Red Hat Enterprise Linux CoreOS
- OpenShift-tsjinstmesh
- Operator ramt
- Knative kader
Boarne: www.habr.com