"Cloud native" oder einfach "Cloud" Uwendungen gi speziell erstallt fir an Cloud Infrastrukturen ze schaffen. Si ginn typesch als Set vu locker gekoppelte Mikroservicer gebaut a Container verpackt, déi am Tour vun enger Cloud Plattform geréiert ginn. Esou Applikatioune si virbereet fir Feeler als Standard, dat heescht datt se zouverlässeg funktionnéieren an och am Fall vu schlëmmen Infrastruktur-Niveau Feeler schaffen. Déi aner Säit vun der Mënz sinn d'Sets vu Restriktiounen (Kontrakter), déi d'Cloudplattform op Containerapplikatiounen setzt fir se automatesch ze verwalten.
Wärend voll bewosst iwwer d'Noutwennegkeet an d'Wichtegkeet fir op Cloud-baséiert Uwendungen ze plënneren, wësse vill Organisatiounen nach ëmmer net wou se ufänken. An dësem Post wäerte mir eng Rei vu Prinzipien kucken, déi, wa se gefollegt ginn wann Dir containeriséiert Uwendungen entwéckelen, Iech erlaabt d'Potenzial vu Cloud Plattformen ze realiséieren an zouverlässeg Operatioun a Skaléieren vun Uwendungen z'erreechen, och am Fall vu schlëmme Feeler an der IT Infrastruktur Niveau. D'ultimativ Zil vun de Prinzipien, déi hei skizzéiert sinn, ass ze léieren wéi Uwendungen bauen déi automatesch vu Cloud Plattforme wéi Kubernetes geréiert kënne ginn.
Software Design Prinzipien
An der Programméierungswelt bezéie Prinzipien op zimlech allgemeng Reegelen déi gefollegt musse ginn wann Dir Software entwéckelt. Si kënne benotzt ginn wann Dir mat all Programméierungssprooch schafft. All Prinzip huet seng eegen Ziler, d'Tools fir z'erreechen, déi normalerweis Templates a Praktiken sinn. Et ginn och eng Rei vun fundamental Prinzipien fir d'Schafe vun héich-Qualitéit Software, aus deem all aner Flux. Hei sinn e puer Beispiller vu fundamentale Prinzipien:
- (Halt et einfach, domm) - komplizéiert et net;
- (Widderhuelt Iech net) - widderhuelen Iech net;
- (Dir wäert et net brauchen) - erstellt net eppes wat net direkt gebraucht gëtt;
- Trennung vu Bedenken - Verantwortung deelen.
Wéi Dir gesitt, setzen dës Prinzipien keng spezifesch Reegelen, mee gehéieren zu der Kategorie vu sougenannte gesonde Mënscheverstand Iwwerleeunge baséiert op praktescher Erfahrung, déi vu villen Entwéckler gedeelt ginn an op déi se regelméisseg bezéien.
Zousätzlech gëtt et - E Set vun den éischte fënnef Prinzipien vun objektorientéierter Programméierung an Design, formuléiert vum Robert Martin. SOLID enthält breet, oppene, komplementär Prinzipien déi - wann se zesumme applizéiert ginn - hëllefen besser Software Systemer ze kreéieren a se op laang Dauer besser z'erhalen.
D'SOLID Prinzipien gehéieren zum Gebitt vun der OOP a sinn an der Sprooch vun esou Konzepter a Konzepter formuléiert wéi Klassen, Interfaces an Ierfschaft. Duerch Analogie kënnen Entwécklungsprinzipien och fir Cloudapplikatiounen formuléiert ginn, nëmmen dat Basiselement hei wäert net eng Klass sinn, mee e Container. Andeems Dir dës Prinzipien verfollegt, kënnt Dir containeriséiert Uwendungen erstellen, déi d'Ziler an Ziler vun Cloud Plattformen wéi Kubernetes besser entspriechen.
Cloud-native Container: d'Red Hat Approche
Haut ka bal all Applikatioun relativ einfach a Container verpackt ginn. Awer fir Uwendungen effektiv automatiséiert an orchestréiert an enger Cloud Plattform wéi Kubernetes ze ginn, ass zousätzlech Effort erfuerderlech.
D'Basis fir d'Iddien hei ënnendrënner war d'Methodologie a vill aner Wierker iwwer verschidden Aspekter vum Bau vun Webapplikatiounen, vu Quellcodemanagement bis Skaléierungsmodeller. Déi beschriwwe Prinzipien gëllen nëmme fir d'Entwécklung vu containeriséierte Applikatiounen, déi uewen op Mikroservicer gebaut sinn a fir Cloud Plattforme wéi Kubernetes entworf sinn. D'Basiselement an eiser Diskussioun ass d'Containerbild, an d'Zilbehälter Runtime ass d'Container Orchestratiounsplattform. D'Zil vun de proposéierte Prinzipien ass Container ze kreéieren fir déi Zäitplang, Skaléieren an Iwwerwaachungsaufgaben op de meeschten Orchesterplattformen automatiséiert kënne ginn. D'Prinzipien ginn an keng speziell Uerdnung presentéiert.
Single Concern Principle (SCP)
Dëse Prinzip ass op vill Manéiere ähnlech mam Single Responsibility Principle. ), deen Deel vum SOLID Set ass a seet datt all Objet eng Verantwortung muss hunn, an déi Verantwortung muss komplett an enger Klass akapselt sinn. De Punkt vum SRP ass datt all Verantwortung e Grond fir Ännerung ass, an eng Klass muss een an nëmmen ee Grond fir Ännerung hunn.
Am SCP benotze mir d'Wuert "Bedenken" amplaz vum Wuert "Verantwortung" fir de méi héijen Abstraktiounsniveau a méi breeden Zweck vun engem Container unzeginn am Verglach zu enger OOP Klass. A wann d'Zil vum SRP ass nëmmen ee Grond fir Ännerung ze hunn, dann hannert SCP ass de Wonsch d'Fäegkeet auszebauen fir d'Container ze benotzen an ze ersetzen. Andeems Dir de SRP verfollegt an e Container erstellt deen en eenzege Problem léist an et op eng funktionell komplett Manéier mécht, erhéicht Dir d'Chancen fir dat Containerbild a verschiddene Applikatiounskontexter ze benotzen.
De SCP-Prinzip seet, datt all Container een eenzege Problem soll léisen a gutt maachen. Ausserdeem ass SCP an der Containerwelt méi einfach z'erreechen wéi SRP an der OOP Welt, well Container normalerweis een eenzege Prozess lafen, an déi meescht vun der Zäit léist dëse Prozess eng eenzeg Aufgab.
Wann e Container-Mikroservice e puer Probleemer gläichzäiteg muss léisen, da kann et an eenzel-Aufgab Container opgedeelt ginn a kombinéiert an engem Pod (eng Eenheet vun der Containerplattform Deployment) mat Sidecar an Init Container Templates. Zousätzlech mécht SCP et einfach en alen Container ze ersetzen (wéi e Webserver oder Message Broker) mat engem neien deen dee selwechte Problem léist, awer d'Funktionalitéit erweidert oder besser skaléiert.
Héich Observabilitéitsprinzip (HOP)
Wann Container als vereenegt Wee benotzt gi fir Uwendungen ze packen an ze lafen, ginn d'Applikatiounen selwer als eng schwaarz Këscht behandelt. Wéi och ëmmer, wann dës Cloud Container sinn, da musse se speziell APIen un der Runtime ubidden fir d'Gesondheet vun de Container ze iwwerwaachen an, wann néideg, entspriechend Handlung ze huelen. Ouni dëst wäert et net méiglech sinn d'Automatiséierung vun der Aktualiséierung vu Container ze vereenegen an hire Liewenszyklus ze managen, wat am Tour d'Stabilitéit an d'Benotzerfrëndlechkeet vum Softwaresystem verschlechtert.
An der Praxis soll eng containeriséiert Applikatioun op d'mannst eng API fir verschidden Aarte vu Gesondheetschecken hunn: Liveness Tester a Bereetschaftstester. Wann eng Applikatioun behaapt méi ze maachen, muss se aner Moyene ubidden fir hiren Zoustand ze iwwerwaachen. Zum Beispill loggt wichteg Eventer iwwer STDERR a STDOUT fir Log-Aggregatioun mat Fluentd, Logstash an aner ähnlech Tools. Wéi och Integratioun mat Tracing a Metrik Sammlung Bibliothéiken, wéi OpenTracing, Prometheus, etc.
Am Allgemengen kann d'Applikatioun nach ëmmer als schwaarz Këscht behandelt ginn, awer et muss mat all den APIen geliwwert ginn, déi d'Plattform brauch fir se op déi bescht méiglech Manéier ze iwwerwaachen an ze verwalten.
Liewenszyklus Konformitéitsprinzip (LCP)
LCP ass d'Antithese vum HOP. Wärend HOP seet datt de Container gelies APIs op d'Plattform muss aussoen, erfuerdert LCP datt d'Applikatioun Informatioun vun der Plattform akzeptéiere kann. Desweideren, muss de Container net nëmmen Evenementer kréien, mä och adaptéieren, an anere Wierder, op hinnen reagéieren. Dofir den Numm vum Prinzip, deen als Fuerderung ugesi ka ginn fir d'Plattform mat Schreiwen APIen ze bidden.
Plattformen hu verschidden Aarte vun Eventer fir ze hëllefen de Liewenszyklus vun engem Container ze managen. Awer et ass un der Applikatioun selwer ze entscheeden wéi eng vun hinnen ze gesinn a wéi ze reagéieren.
Et ass kloer datt e puer Evenementer méi wichteg si wéi anerer. Zum Beispill, wann eng Applikatioun Crashen net gutt toleréiert, muss se Signal akzeptéieren: terminate (SIGTERM) Messagen an initiéiert seng Terminatiounsroutine sou séier wéi méiglech fir d'Signal ze fangen: Kill (SIGKILL) dat no SIGTERM kënnt.
Zousätzlech kënnen Eventer wéi PostStart a PreStop fir de Liewenszyklus vun enger Applikatioun wichteg sinn. Zum Beispill, nodeems Dir eng Applikatioun lancéiert, kann et e puer Erwiermungszäit erfuerderen ier se op Ufroe reagéiere kann. Oder d'Applikatioun muss Ressourcen op eng speziell Manéier fräiginn wann se ofgeschalt ginn.
Bild Immutabilitéitsprinzip (IIP)
Et gëtt allgemeng ugeholl datt containeriséiert Uwendungen onverännert solle bleiwen nodeems se gebaut goufen, och wa se a verschiddenen Ëmfeld lafen. Dëst erfuerdert de Besoin fir d'Datelagerung bei der Runtime ze externen (an anere Wierder, extern Tools fir dëst ze benotzen) an op extern, runtime-spezifesch Konfiguratiounen ze vertrauen, anstatt eenzegaarteg Container fir all Ëmfeld z'änneren oder ze kreéieren. No all Ännerungen un der Applikatioun muss d'Containerbild nei opgebaut ginn an an all benotzt Ëmfeld ofgesat ginn. Iwwregens, wann Dir IT Systemer verwalten, gëtt en ähnleche Prinzip benotzt, bekannt als de Prinzip vun der Immutabilitéit vu Serveren an Infrastrukturen.
D'Zil vun IIP ass d'Schafung vun getrennten Containerbiller fir verschidde Runtime-Ëmfeld ze verhënneren an datselwecht Bild iwwerall ze benotzen zesumme mat der entspriechender Ëmweltspezifescher Konfiguratioun. No dësem Prinzip erlaabt Iech esou wichteg Praktiken aus der Siicht vun der Automatiséierung vu Cloud Systemer wéi d'Roll-back a Roll-Forward vun Applikatiounsupdates ëmzesetzen.
Prozess Disposéierbarkeet Prinzip (PDP)
Ee vun de wichtegste Charakteristiken vun engem Container ass seng Ephemeralitéit: eng Instanz vun engem Container ass einfach ze kreéieren an einfach ze zerstéieren, sou datt et zu all Moment einfach duerch eng aner Instanz ersat ka ginn. Et ka vill Grënn fir sou en Ersatz sinn: Echec vun engem Serviceability Test, Skaléieren vun der Applikatioun, Transfert op en aneren Host, Ausschöpfung vun Plattformressourcen oder aner Situatiounen.
Als Konsequenz musse containeriséiert Uwendungen hire Staat erhalen andeems se extern Mëttelen benotzen, oder intern verdeelt Schemae mat Redundanz benotzen fir dëst. Zousätzlech muss d'Applikatioun séier starten a séier ausschalten, a virbereet sinn op plötzlech fatale Hardwarefehler.
Eng Praxis déi hëlleft dëse Prinzip ëmzesetzen ass Container kleng ze halen. Cloud Ëmfeld kënnen automatesch e Host auswielen fir eng Containerinstanz ze lancéieren, sou datt de Container méi kleng ass, dest méi séier fänkt et un - et kopéiert einfach op den Zilhost iwwer d'Netzwierk méi séier.
Self-Containment Prinzip (S-CP)
No dësem Prinzip, an der Montage Etapp, sinn all néideg Komponente am Container abegraff. De Container soll op der Virgab gebaut ginn datt de System nëmmen e pure Linux Kernel huet, sou datt all déi néideg zousätzlech Bibliothéike sollen am Container selwer plazéiert ginn. Et sollt och Saache enthalen wéi d'Runtime fir déi entspriechend Programméierungssprooch, d'Applikatiounsplattform (wann néideg), an aner Ofhängegkeeten déi erfuerderlech sinn wann d'Containerapplikatioun leeft.
Ausname gi fir Konfiguratiounen gemaach, déi vun Ëmfeld zu Ëmfeld variéieren a musse bei der Runtime geliwwert ginn, zum Beispill duerch eng Kubernetes ConfigMap.
Eng Applikatioun kann e puer containeriséiert Komponenten enthalen, zum Beispill e separaten DBMS Container bannent enger containeriséierter Webapplikatioun. Geméiss dem S-CP-Prinzip sollten dës Container net an een kombinéiert ginn, awer solle sou gemaach ginn datt den DBMS-Container alles enthält wat néideg ass fir d'Operatioun vun der Datebank, an de Webapplikatiounscontainer enthält alles wat néideg ass fir d'Operatioun vum Web. Applikatioun, dee selwechte Webserver. Als Resultat, bei der Runtime hänkt de Webapplikatiounscontainer vum DBMS Container of an Zougang et wéi néideg.
Runtime Confinement Principle (RCP)
De S-CP-Prinzip definéiert wéi de Container gebaut soll ginn a wat d'Bildbinär soll enthalen. Awer e Container ass net nëmmen eng "schwaarz Këscht", déi nëmmen eng Charakteristik huet - Dateigréisst. Wärend der Ausféierung hëlt de Container aner Dimensiounen un: d'Quantitéit un Erënnerung benotzt, CPU Zäit an aner Systemressourcen.
An hei kënnt de RCP-Prinzip praktesch, no deem de Container seng Ufuerderunge fir Systemressourcen muss entfalen an se op d'Plattform transferéieren. Mat de Ressourceprofile vun all Container (wéi vill CPU, Erënnerung, Netzwierk an Diskressourcen et brauch), kann d'Plattform optimal Zäitplang an Autoskaléierung ausféieren, IT Kapazitéit verwalten an SLA Niveauen fir Container erhalen.
Zousätzlech fir d'Ressourcefuerderunge vum Container z'erhalen, ass et och wichteg datt d'Applikatioun net iwwer seng eege Grenze geet. Soss, wann e Ressourcemangel optrieden, ass d'Plattform méi wahrscheinlech et an d'Lëscht vun Uwendungen opzehuelen déi musse ofgeschloss oder migréiert ginn.
Wa mir schwätzen iwwer Cloud-first ze sinn, schwätze mir iwwer d'Art a Weis wéi mir schaffen.
Hei uewen hu mir eng Rei vun allgemenge Prinzipien formuléiert, déi de methodologesche Fundament setzen fir qualitativ héichwäerteg Containerapplikatiounen fir Cloud-Ëmfeld ze bauen.
Bedenkt datt Dir zousätzlech zu dësen allgemenge Prinzipien och zousätzlech fortgeschratt Methoden an Technike braucht fir mat Container ze schaffen. Zousätzlech hu mir e puer kuerz Empfehlungen déi méi spezifesch sinn a solle applizéiert ginn (oder net applizéiert) ofhängeg vun der Situatioun:
- Probéiert d'Gréisst vun de Biller ze reduzéieren: temporär Dateien läschen an net onnéideg Packagen installéieren - wat méi kleng d'Containergréisst ass, dest méi séier ass et zesummegesat a kopéiert op den Zilhost iwwer dem Netz.
- Focus op arbiträr User-IDs: benotzt net de sudo Kommando oder e spezielle Userid fir Är Container ze starten.
- Markéiert wichteg Ports: Dir kënnt Portnummeren an der Runtime setzen, awer et ass besser se mat dem EXPOSE Kommando ze spezifizéieren - et mécht et méi einfach fir aner Leit a Programmer Är Biller ze benotzen.
- Store persistent Donnéeën op Bänn: Daten déi solle bleiwen nodeems de Container zerstéiert ass, sollen op Bänn geschriwwe ginn.
- Schreift Bildmetadaten: Tags, Etiketten an Annotatiounen maachen Biller méi einfach ze benotzen - aner Entwéckler soen Iech Merci.
- Synchroniséiert Host a Biller: E puer containeriséierte Applikatiounen erfuerderen de Container mat dem Host op bestëmmten Attributer ze synchroniséieren, wéi Zäit oder Maschinn ID.
- Als Conclusioun deele mir Templates a bescht Praktiken, déi Iech hëllefen d'Prinzipien méi effektiv ëmzesetzen, déi hei uewen opgezielt sinn:
11. Juni um 11.00 Auer
Wat Dir léiere wäert:
- Immutable Red Hat Enterprise Linux CoreOS
- OpenShift Service Mesh
- Bedreiwer Kader
- Knative Kader
Source: will.com