“Cloud native” of simpelweg “cloud”-applicaties zijn speciaal gemaakt om in cloudinfrastructuren te werken. Ze zijn doorgaans gebouwd als een reeks losjes gekoppelde microservices, verpakt in containers, die op hun beurt worden beheerd door een cloudplatform. Dergelijke applicaties zijn standaard voorbereid op storingen, wat betekent dat ze betrouwbaar werken en schaalbaar zijn, zelfs in het geval van ernstige storingen op infrastructuurniveau. De andere kant van de medaille zijn de sets beperkingen (contracten) die het cloudplatform oplegt aan containerapplicaties om deze automatisch te kunnen beheren.
Hoewel ze zich volledig bewust zijn van de noodzaak en het belang van de overstap naar cloudgebaseerde applicaties, weten veel organisaties nog steeds niet waar ze moeten beginnen. In dit bericht zullen we kijken naar een aantal principes die, als ze worden gevolgd bij het ontwikkelen van gecontaineriseerde applicaties, je in staat zullen stellen het potentieel van cloudplatforms te realiseren en een betrouwbare werking en schaalbaarheid van applicaties te bereiken, zelfs in het geval van ernstige storingen in de IT-infrastructuur. niveau. Het uiteindelijke doel van de hier geschetste principes is om te leren hoe je applicaties kunt bouwen die automatisch kunnen worden beheerd door cloudplatforms zoals Kubernetes.
Softwareontwerpprincipes
In de programmeerwereld verwijzen principes naar vrij algemene regels die moeten worden gevolgd bij het ontwikkelen van software. Ze kunnen worden gebruikt bij het werken met elke programmeertaal. Elk principe heeft zijn eigen doelen, waarbij de instrumenten om dit te bereiken meestal sjablonen en praktijken zijn. Er zijn ook een aantal fundamentele principes voor het creëren van software van hoge kwaliteit, waaruit alle andere voortkomen. Hier zijn enkele voorbeelden van fundamentele principes:
- (Houd het simpel, dom) – maak het niet ingewikkeld;
- (Herhaal jezelf niet) - herhaal jezelf niet;
- (Je hebt het niet nodig) – creëer niet iets dat niet onmiddellijk nodig is;
- Scheiding van zorgen – deel verantwoordelijkheden.
Zoals je ziet stellen deze principes geen specifieke regels, maar behoren ze tot de categorie van zogenaamde ‘common sense’-overwegingen gebaseerd op praktijkervaring, die door veel ontwikkelaars worden gedeeld en waarnaar ze regelmatig verwijzen.
Daarnaast is er – Een set van de eerste vijf principes van objectgeoriënteerd programmeren en ontwerpen, geformuleerd door Robert Martin. SOLID omvat brede, open, complementaire principes die, wanneer ze samen worden toegepast, helpen betere softwaresystemen te creëren en deze op de lange termijn beter te onderhouden.
De SOLID-principes behoren tot het vakgebied van OOP en zijn geformuleerd in de taal van concepten en concepten als klassen, interfaces en overerving. Naar analogie kunnen er ook ontwikkelingsprincipes worden geformuleerd voor cloudapplicaties, alleen zal het basiselement hier geen klasse zijn, maar een container. Door deze principes te volgen, kunt u gecontaineriseerde applicaties maken die beter voldoen aan de doelen en doelstellingen van cloudplatforms zoals Kubernetes.
Cloud-native containers: de Red Hat-aanpak
Tegenwoordig kan vrijwel elke toepassing relatief eenvoudig in containers worden verpakt. Maar om applicaties effectief te automatiseren en te orkestreren binnen een cloudplatform als Kubernetes, zijn extra inspanningen nodig.
De basis voor de hieronder geschetste ideeën was de methodologie en vele andere werken over verschillende aspecten van het bouwen van webapplicaties, van broncodebeheer tot schaalmodellen. De beschreven principes zijn alleen van toepassing op de ontwikkeling van gecontaineriseerde applicaties die bovenop microservices zijn gebouwd en ontworpen voor cloudplatforms zoals Kubernetes. Het basiselement in onze discussie is de containerimage, en de doelcontainerruntime is het containerorkestratieplatform. Het doel van de voorgestelde principes is het creëren van containers waarvoor plannings-, schaal- en monitoringtaken kunnen worden geautomatiseerd op de meeste orkestratieplatforms. De principes worden in willekeurige volgorde gepresenteerd.
Single Concern-principe (SCP)
Dit principe is in veel opzichten vergelijkbaar met het Single Responsibility Principle. ), dat deel uitmaakt van de SOLID-set en stelt dat elk object één verantwoordelijkheid moet hebben, en dat die verantwoordelijkheid volledig in een klasse moet worden ingekapseld. Het punt van SRP is dat elke verantwoordelijkheid een reden voor verandering is, en dat een klasse maar één reden voor verandering mag hebben.
In SCP gebruiken we het woord ‘zorg’ in plaats van het woord ‘verantwoordelijkheid’ om het hogere abstractieniveau en het bredere doel van een container aan te duiden in vergelijking met een OOP-klasse. En als het doel van SRP is om slechts één reden voor verandering te hebben, dan schuilt achter SCP de wens om de mogelijkheid om containers te hergebruiken en te vervangen uit te breiden. Door de SRP te volgen en een container te maken die één enkel probleem oplost en dit op een functioneel volledige manier doet, vergroot u de kans op hergebruik van dat containerimage in verschillende applicatiecontexten.
Het SCP-principe stelt dat elke container één enkel probleem moet oplossen en dat goed moet doen. Bovendien is SCP in de containerwereld gemakkelijker te realiseren dan SRP in de OOP-wereld, omdat containers meestal één enkel proces uitvoeren, en meestal lost dit proces één enkele taak op.
Als een containermicroservice meerdere problemen tegelijk moet oplossen, kan deze worden opgedeeld in containers met één taak en worden gecombineerd binnen één pod (een eenheid voor de implementatie van een containerplatform) met behulp van zijspan- en init-containersjablonen. Bovendien maakt SCP het eenvoudig om een oude container (zoals een webserver of message broker) te vervangen door een nieuwe die hetzelfde probleem oplost maar de functionaliteit heeft uitgebreid of beter schaalbaar is.
Principe van hoge waarneembaarheid (HOP)
Wanneer containers worden gebruikt als een uniforme manier om applicaties te verpakken en uit te voeren, worden de applicaties zelf behandeld als een zwarte doos. Als dit echter cloudcontainers zijn, moeten ze speciale API's aan de runtime leveren om de gezondheid van de containers te monitoren en, indien nodig, passende actie te ondernemen. Zonder dit zal het niet mogelijk zijn om de automatisering van het updaten van containers en het beheren van hun levenscyclus te verenigen, wat op zijn beurt de stabiliteit en bruikbaarheid van het softwaresysteem zal verslechteren.
In de praktijk zou een gecontaineriseerde applicatie minimaal een API moeten hebben voor verschillende soorten health checks: liveness tests en readiness tests. Als een applicatie beweert meer te doen, moet deze andere middelen bieden om de staat ervan te monitoren. Bijvoorbeeld het loggen van belangrijke gebeurtenissen via STDERR en STDOUT voor logaggregatie met behulp van Fluentd, Logstash en andere soortgelijke tools. Evenals integratie met bibliotheken voor tracering en metrische verzamelingen, zoals OpenTracing, Prometheus, enz.
Over het algemeen kan de applicatie nog steeds gezien worden als een black box, maar deze moet wel voorzien zijn van alle API’s die het platform nodig heeft om deze zo goed mogelijk te kunnen monitoren en beheren.
Levenscyclusconformiteitsprincipe (LCP)
LCP is de antithese van HOP. Terwijl HOP stelt dat de container lees-API's aan het platform moet blootstellen, vereist LCP dat de applicatie informatie van het platform kan accepteren. Bovendien moet de container niet alleen gebeurtenissen ontvangen, maar zich ook aanpassen, met andere woorden, erop reageren. Vandaar de naam van het principe, dat gezien kan worden als een vereiste om het platform te voorzien van schrijf-API’s.
Platforms hebben verschillende soorten gebeurtenissen om de levenscyclus van een container te helpen beheren. Maar het is aan de applicatie zelf om te beslissen welke van hen moet worden waargenomen en hoe erop moet worden gereageerd.
Het is duidelijk dat sommige gebeurtenissen belangrijker zijn dan andere. Als een applicatie bijvoorbeeld crashes niet goed verdraagt, moet deze signalen accepteren: beëindigen (SIGTERM) en zo snel mogelijk de beëindigingsroutine starten om het signaal: kill (SIGKILL) op te vangen dat na SIGTERM komt.
Bovendien kunnen gebeurtenissen zoals PostStart en PreStop belangrijk zijn voor de levenscyclus van een applicatie. Na het starten van een applicatie kan het bijvoorbeeld enige opwarmtijd nodig hebben voordat deze op verzoeken kan reageren. Of de applicatie moet op een speciale manier bronnen vrijgeven bij het afsluiten.
Het principe van beeldonveranderlijkheid (IIP)
Het is algemeen aanvaard dat gecontaineriseerde applicaties na de bouw onveranderd moeten blijven, zelfs als ze in verschillende omgevingen worden uitgevoerd. Dit maakt het noodzakelijk om gegevensopslag tijdens runtime te externaliseren (met andere woorden, om hiervoor externe tools te gebruiken) en om te vertrouwen op externe, runtime-specifieke configuraties, in plaats van het aanpassen of creëren van unieke containers voor elke omgeving. Na eventuele wijzigingen aan de applicatie moet de containerimage opnieuw worden opgebouwd en in alle gebruikte omgevingen worden geïmplementeerd. Overigens wordt bij het beheer van IT-systemen een soortgelijk principe gebruikt, bekend als het principe van onveranderlijkheid van servers en infrastructuur.
Het doel van IIP is om te voorkomen dat er afzonderlijke containerimages voor verschillende runtime-omgevingen worden gemaakt en om overal dezelfde image te gebruiken, samen met de juiste omgevingsspecifieke configuratie. Door dit principe te volgen, kunt u belangrijke praktijken implementeren vanuit het oogpunt van automatisering van cloudsystemen, zoals het terugdraaien en vooruitrollen van applicatie-updates.
Principe van proceswegwerpbaarheid (PDP)
Een van de belangrijkste kenmerken van een container is de vergankelijkheid ervan: een exemplaar van een container is gemakkelijk te maken en gemakkelijk te vernietigen, zodat deze op elk moment eenvoudig kan worden vervangen door een ander exemplaar. Er kunnen veel redenen zijn voor een dergelijke vervanging: het mislukken van een bruikbaarheidstest, het schalen van de applicatie, de overdracht naar een andere host, uitputting van platformbronnen of andere situaties.
Als gevolg hiervan moeten containerapplicaties hun status behouden met behulp van externe middelen, of hiervoor intern gedistribueerde schema's met redundantie gebruiken. Bovendien moet de applicatie snel opstarten en snel afsluiten, en voorbereid zijn op plotselinge fatale hardwarestoringen.
Eén praktijk die helpt bij de implementatie van dit principe is het klein houden van containers. Cloudomgevingen kunnen automatisch een host selecteren om een containerinstantie op te starten, dus hoe kleiner de container, hoe sneller deze zal starten - hij zal eenvoudigweg sneller via het netwerk naar de doelhost kopiëren.
Zelfbeheersingsprincipe (S-CP)
Volgens dit principe worden tijdens de montagefase alle benodigde componenten in de container meegeleverd. De container moet worden gebouwd in de veronderstelling dat het systeem alleen een pure Linux-kernel heeft, dus alle benodigde extra bibliotheken moeten in de container zelf worden geplaatst. Het moet ook zaken bevatten zoals de runtime voor de overeenkomstige programmeertaal, het applicatieplatform (indien nodig) en andere afhankelijkheden die nodig zijn terwijl de containerapplicatie draait.
Er worden uitzonderingen gemaakt voor configuraties die variëren van omgeving tot omgeving en tijdens runtime moeten worden verstrekt, bijvoorbeeld via een Kubernetes ConfigMap.
Een applicatie kan meerdere gecontaineriseerde componenten bevatten, bijvoorbeeld een afzonderlijke DBMS-container binnen een gecontaineriseerde webapplicatie. Volgens het S-CP-principe mogen deze containers niet tot één worden gecombineerd, maar moeten ze zo worden gemaakt dat de DBMS-container alles bevat wat nodig is voor de werking van de database, en de webapplicatiecontainer alles bevat wat nodig is voor de werking van het web. applicatie, dezelfde webserver. Als gevolg hiervan zal de webtoepassingscontainer tijdens runtime afhankelijk zijn van de DBMS-container en deze indien nodig openen.
Runtime Confinement-principe (RCP)
Het S-CP-principe definieert hoe de container moet worden gebouwd en wat het binaire beeldbestand moet bevatten. Maar een container is niet zomaar een ‘zwarte doos’ die maar één kenmerk heeft: de bestandsgrootte. Tijdens de uitvoering krijgt de container andere dimensies: de hoeveelheid gebruikt geheugen, CPU-tijd en andere systeembronnen.
En hier komt het RCP-principe van pas, volgens welke de container zijn vereisten voor systeembronnen moet onthoofden en deze naar het platform moet overbrengen. Met de resourceprofielen van elke container (hoeveel CPU-, geheugen-, netwerk- en schijfbronnen het nodig heeft) kan het platform de planning en automatische schaling optimaal uitvoeren, de IT-capaciteit beheren en de SLA-niveaus voor containers handhaven.
Naast het voldoen aan de resourcevereisten van de container, is het ook belangrijk dat de applicatie de eigen grenzen niet overschrijdt. Anders is de kans groter dat het platform, als er een tekort aan resources optreedt, deze opneemt in de lijst met applicaties die moeten worden beëindigd of gemigreerd.
Als we het hebben over cloud-first, hebben we het over de manier waarop we werken.
Hierboven hebben we een aantal algemene principes geformuleerd die de methodologische basis vormen voor het bouwen van hoogwaardige containerapplicaties voor cloudomgevingen.
Houd er rekening mee dat u naast deze algemene principes ook aanvullende geavanceerde methoden en technieken nodig heeft voor het werken met containers. Daarnaast hebben we een paar korte aanbevelingen die specifieker zijn en afhankelijk van de situatie al dan niet moeten worden toegepast:
- Probeer de grootte van afbeeldingen te verkleinen: verwijder tijdelijke bestanden en installeer geen onnodige pakketten - hoe kleiner de containergrootte, hoe sneller deze wordt samengesteld en via het netwerk naar de doelhost wordt gekopieerd.
- Focus op willekeurige gebruikers-ID's: gebruik niet het sudo-commando of een speciaal gebruikers-ID om uw containers te starten.
- Markeer belangrijke poorten: U kunt poortnummers tijdens runtime instellen, maar het is beter om ze op te geven met de opdracht EXPOSE - dit maakt het gemakkelijker voor andere mensen en programma's om uw afbeeldingen te gebruiken.
- Bewaar persistente gegevens op volumes: gegevens die achterblijven nadat de container is vernietigd, moeten naar volumes worden geschreven.
- Schrijf metadata voor afbeeldingen: tags, labels en annotaties maken afbeeldingen gemakkelijker te gebruiken - andere ontwikkelaars zullen je dankbaar zijn.
- Synchroniseer host en afbeeldingen: Sommige containertoepassingen vereisen dat de container op bepaalde kenmerken, zoals tijd of computer-ID, met de host synchroniseert.
- Tot slot delen we sjablonen en best practices die u zullen helpen de hierboven genoemde principes effectiever te implementeren:
11 juni om 11.00 uur
Wat je gaat leren:
- Onveranderlijke Red Hat Enterprise Linux CoreOS
- OpenShift-servicemesh
- Operator-framework
- Knatief raamwerk
Bron: www.habr.com