Ā«Cloud-nativeĀ» of gewoon Ā«cloudĀ»-applicaties worden speciaal ontwikkeld voor gebruik in cloudinfrastructuren. Ze zijn meestal opgebouwd als een set van losjes gekoppelde microservices, verpakt in containers die op hun beurt worden beheerd door een cloudplatform. Dergelijke applicaties zijn standaard bestand tegen storingen, wat betekent dat ze betrouwbaar functioneren en opschalen, zelfs bij ernstige infrastructuurfouten. De keerzijde is een reeks beperkingen (contracten) die het cloudplatform oplegt aan containerapplicaties om ze automatisch te kunnen beheren.
Hoewel veel organisaties zich bewust zijn van de noodzaak en het belang van de overstap naar cloudapplicaties, weten ze nog steeds niet waar te beginnen. In dit artikel bespreken we een aantal principes die, wanneer ze worden nageleefd bij de ontwikkeling van containerapplicaties, het potentieel van cloudplatforms kunnen ontsluiten en zorgen voor betrouwbare werking en opschaling van applicaties, zelfs bij ernstige uitval van de IT-infrastructuur. Het uiteindelijke doel van de hier uiteengezette principes is om te leren applicaties te bouwen die automatisch beheerd kunnen worden door cloudplatforms zoals Kubernetes.
Principes voor softwareontwerp
In de programmeerwereld verwijzen principes naar vrij algemene regels die moeten worden gevolgd bij de ontwikkeling van software. Ze kunnen worden toegepast bij elk programmeertaal. Elk principe heeft zijn eigen doelen, die doorgaans worden bereikt met behulp van sjablonen en praktijken. Er zijn ook een aantal fundamentele principes voor het creƫren van kwalitatieve software waarvan alle andere voortkomen. Laten we een paar voorbeelden van fundamentele principes geven:
- (Keep it simple, stupid) ā houd het simpel;
- (Donāt repeat yourself) ā herhaal jezelf niet;
- (You arenāt gonna need it) ā maak niets dat je niet direct nodig hebt;
- (Separation of concerns) ā scheid verantwoordelijkheden.
Zoals blijkt, stellen deze principes geen specifieke regels vast, maar behoren ze tot het type zogenaamde gezond verstandsoverwegingen op basis van praktische ervaring, die door veel ontwikkelaars worden gedeeld en waar ze regelmatig naar verwijzen.
Bovendien zijn er ā een set van de eerste vijf principes van objectgeoriĆ«nteerd programmeren en ontwerp, geformuleerd door Robert Martin. SOLID omvat algemene en open te interpreteren complementaire principes die ā wanneer ze in samenhang worden toegepast ā helpen om kwalitatief betere softwaresystemen te creĆ«ren en deze beter op lange termijn te onderhouden.
De SOLID-principes zijn gerelateerd aan OOP en worden geformuleerd in de taal van concepten zoals klassen, interfaces en overerving. Evenzo kunnen voor cloudapplicaties ontwikkelingsprincipes worden geformuleerd, waarbij het basis element hier geen klasse maar een container is. Door deze principes te volgen, kunnen containerapplicaties worden gemaakt die beter voldoen aan de doelen en taken van cloudplatformen zoals Kubernetes.
Cloud-georiƫnteerde containers: de aanpak van Red Hat
Tegenwoordig kunnen vrijwel alle applicaties relatief eenvoudig in containers worden verpakt. Maar om ervoor te zorgen dat applicaties effectief worden geautomatiseerd en georkestreerd binnen een cloudplatform zoals Kubernetes, zijn extra inspanningen vereist.
De basis voor de hieronder uiteengezette ideeĆ«n is de methodologie en talloze andere werken over verschillende aspecten van het creĆ«ren van webapplicaties, van broncodebeheer tot schaalmodellen. De beschreven principes zijn alleen van toepassing op het ontwikkelen van containerapplicaties die zijn gebouwd op basis van microservices en bestemd zijn voor cloudplatforms zoals Kubernetes. Het basis element in onze overwegingen is het containerimage, en de doelruntime-omgeving voor containers wordt gedefinieerd als het platform voor containerorkestratie. Het doel van de voorgestelde principes is om containers te creĆ«ren waarvoor op de meeste orkestratieplatforms automatisering van dispatchtaken (scheduling ā het kiezen van een host voor het starten van een containerinstantie), schaling en monitoring mogelijk is. De principes worden in willekeurige volgorde gepresenteerd.
Principle of Single Responsibility (Single Concern Principle, SCP)
Dit principe lijkt sterk op het principe van enkele verantwoordelijkheden (Single Responsibility Principle, ), dat deel uitmaakt van de SOLID-sets en stelt dat elk object Ć©Ć©n verantwoordelijkheid moet hebben, en deze verantwoordelijkheid volledig in de klasse moet worden ingekapseld. De essentie van SRP is dat elke verantwoordelijkheid een reden voor wijzigingen is, en de klasse moet exact Ć©Ć©n reden voor wijziging hebben.
In SCP gebruiken we in plaats van het woord 'verantwoordelijkheid' (responsibility) het woord 'taak' (concern) om te verwijzen naar een hoger abstractieniveau en een bredere rol van de container in vergelijking met een OOP-klasse. En als het doel van SRP is om slechts ƩƩn reden voor wijzigingen te hebben, dan is SCP bedoeld om de mogelijkheden voor hergebruik en vervanging van containers te vergroten. Door SRP te volgen en een container te creƫren die ƩƩn enkele taak oplost en dit op een functioneel afgeronde manier doet, verhoog je de kans op hergebruik van deze container in verschillende toepassingscontexten.
Het SCP-principe stelt dat elke container Ć©Ć©n enkele taak moet oplossen en dit goed moet doen. SCP wordt in de wereld van containers eenvoudiger bereikt dan SRP in de wereld van OOP, omdat containers meestal Ć©Ć©n enkel proces uitvoeren, en dat proces vaak Ć©Ć©n enkele taak oplost.
Als een bepaalde container-microservice meerdere taken moet oplossen, kan deze worden opgesplitst in enkelvoudige taakcontainers en samengevoegd binnen Ć©Ć©n pod (de eenheid voor de uitrol van een containerplatform) met behulp van sidecar- en init-containertemplates. Bovendien vergemakkelijkt SCP de vervanging van een oude container (bijvoorbeeld een webserver of een berichtenbroker) door een nieuwe die dezelfde taak oplost, maar met uitgebreide functionaliteit of betere schaalbaarheid.
Principe van hoge observeerbaarheid (High Observability Principle, HOP)
Bij het gebruik van containers als een uniforme manier om applicaties te verpakken en uit te voeren, worden de applicaties zelf beschouwd als een "zwarte doos". Als het echter cloudcontainers zijn, moeten ze de runtime speciale API's bieden om de gezondheid van de containers te controleren en indien nodig passende maatregelen te nemen. Zonder dit is het niet mogelijk om de automatisering van de containerupdates en het beheer van hun levenscyclus te uniformiseren, wat op zijn beurt de stabiliteit en gebruiksvriendelijkheid van het softwaresysteem zal verslechteren.
In de praktijk moet een containerapplicatie tenminste een API hebben voor verschillende soorten gezondheidscontroles: liveness-tests en readiness-tests. Als de applicatie meer vereist, moet deze ook andere middelen bieden om zijn status te controleren. Bijvoorbeeld, het loggen van belangrijke gebeurtenissen via STDERR en STDOUT voor het aggregeren van logs met behulp van tools zoals Fluentd, Logstash en andere soortgelijke tools. En ook integratie met tracing- en metric-verzamelbibliotheken zoals OpenTracing, Prometheus, enzovoort.
In het algemeen kan de applicatie nog steeds worden beschouwd als een "zwarte doos", maar het moet worden voorzien van alle API's die de platform nodig heeft om het op de best mogelijke manier te monitoren en te beheren.
Het principe van aanpassing aan de levenscyclus (Life-cycle Conformance Principle, LCP)
LCP is de tegenhanger van HOP. Terwijl HOP stelt dat een container API's moet bieden voor het platform om te lezen, vereist LCP dat de applicatie in staat is om informatie van het platform te ontvangen. Bovendien moet de container niet alleen gebeurtenissen ontvangen, maar ook hierop reageren; dit verklaart de naam van het principe, dat kan worden gezien als de vereiste om de platform API's voor schrijfbewerkingen te bieden.
Platformen hebben verschillende soorten gebeurtenissen die helpen bij het beheren van de levenscyclus van de container. Maar het moet de applicatie zelf zijn die beslist welke hiervan te ontvangen en hoe te reageren.
Het is duidelijk dat sommige gebeurtenissen belangrijker zijn dan andere. Als een applicatie bijvoorbeeld slecht omgaat met een onverwachte afsluiting, moet deze berichten van type signal: terminate (SIGTERM) accepteren en zo snel mogelijk zijn afsluitprocedure in gang zetten, om te kunnen reageren voordat signal: kill (SIGKILL) binnenkomt, dat volgt op SIGTERM.
Bovendien kunnen voor de levenscyclus van een applicatie gebeurtenissen zoals PostStart en PreStop belangrijk zijn. Na de start kan een applicatie bepaalde tijd nodig hebben om āop te warmenā voordat deze op verzoeken kan reageren. Of de applicatie moet op een specifieke manier middelen vrijgeven wanneer deze wordt afgesloten.
Principe van de onveranderlijkheid van containerafbeeldingen (Image Immutability Principle, IIP)
Het is algemeen aanvaard dat containerapplicaties onveranderlijk moeten blijven na de bouw, zelfs als ze in verschillende omgevingen worden uitgevoerd. Hieruit volgt de noodzaak om opslag van gegevens te externaliseren tijdens het draaien (met andere woorden, externe middelen daarvoor te gebruiken) en om afhankelijk te zijn van externe configuraties, die zijn ingesteld voor de specifieke uitvoeringsomgeving, in plaats van unieke containers voor elke omgeving te wijzigen of te creƫren. Na enige wijziging in de applicatie moet de containerafbeelding opnieuw worden gebouwd en in alle gebruikte omgevingen worden uitgerold. Ter info, bij het beheer van IT-systemen wordt een vergelijkbaar principe gebruikt, bekend als het principe van de onveranderlijkheid van servers en infrastructuur.
Het doel van IIP is om de creatie van aparte containerafbeeldingen voor verschillende uitvoeringsomgevingen te voorkomen en overal dezelfde afbeelding samen met de bijbehorende configuratie voor de specifieke omgeving te gebruiken. Het volgen van dit principe maakt belangrijke praktijken voor de automatisering van cloudsystemen mogelijk, zoals het terugdraaien (roll-back) en doorvoeren (roll-forward) van applicatie-updates.
Principe van de eenmaligheid van processen (Process Disposability Principle, PDP)
Een van de belangrijkste kenmerken van een container is zijn efemere karakter: een container-exemplaar kan eenvoudig worden gemaakt en vernietigd, waardoor het op elk moment gemakkelijk kan worden vervangen door een ander exemplaar. Er kunnen tal van redenen zijn voor een dergelijke vervanging: falen van een gezondheidscontrole, schaling van de applicatie, migratie naar een andere host, uitputting van platformbronnen of andere situaties.
Als gevolg hiervan moeten containerapplicaties hun status opslaan met behulp van externe middelen of interne gedistribueerde schema's met redundantie. Bovendien moet de applicatie snel opstarten en snel afsluiten, en klaar zijn voor plotselinge fatale hardwarefouten.
Een van de praktijken die helpt om dit principe te realiseren, is het creĆ«ren van kleine containers. Cloudomgevingen kunnen automatisch een host kiezen om een containerinstantie te starten, dus hoe kleiner de container, des te sneller deze opstart ā hij wordt gewoon sneller via het netwerk naar de doelhost gekopieerd.
Het zelfvoorzienendheidsprincipe (Self-containment Principle, S-CP)
Volgens dit principe worden tijdens de assemblage alle nodige componenten in de container opgenomen. De container moet worden gebouwd met de aanname dat er alleen een schone Linux-kern in het systeem is, zodat alle noodzakelijke extra bibliotheken in de container zelf moeten worden geplaatst. Ook moeten zaken zoals de runtime voor de betreffende programmeertaal, de applicatieplatform (indien nodig) en andere afhankelijkheden die tijdens de werking van de containerapplicatie nodig zijn, daar aanwezig zijn.
Uitzonderingen worden alleen gemaakt voor configuraties die variƫren van omgeving tot omgeving en moeten tijdens runtime worden verstrekt, bijvoorbeeld via Kubernetes ConfigMap.
De applicatie kan verschillende gecontaineriseerde componenten bevatten, bijvoorbeeld een aparte databasecontainer binnen een containerwebapplicatie. Volgens het S-CP-principe moeten deze containers niet worden samengevoegd tot Ć©Ć©n, maar moet de databasecontainer al het nodige voor de werking van de database bevatten, terwijl de webapplicatiecontainer alles moet bevatten wat nodig is voor de werking van de webapplicatie, inclusief de webserver. Hierdoor zal de container van de webapplicatie tijdens uitvoering afhankelijk zijn van de databasecontainer en ernaar refereren wanneer nodig.
Het principe van runtime beperking (Runtime Confinement Principle, RCP)
Het S-CP-principe bepaalt hoe een container moet worden opgebouwd en wat de binaire afbeeldingsbestand moet bevatten. Maar een container is niet slechts een 'zwarte doos' met slechts Ć©Ć©n kenmerk - de bestandsgrootte. Tijdens zijn uitvoering krijgt een container andere dimensies: het verbruikte geheugen, CPU-tijd en andere systeembronnen.
Hier komt het RCP-principe van pas, volgens welke de container zijn vereisten voor systeembronnen moet decoupleren en doorgeven aan het platform. Met de profielinformatie van elke container (hoeveel CPU, geheugen, netwerk en schijfruimte het nodig heeft), kan het platform optimaal de scheduling en autoscaling uitvoeren, de IT-capaciteit beheren en de SLA-niveaus voor de containers handhaven.
Naast het voldoen aan de vereisten van de container is het ook belangrijk voor de applicatie om binnen de door zichzelf gestelde grenzen te blijven. Anders, bij een tekort aan middelen, zal het platform de kans groter maken dat deze applicatie op de lijst komt van applicaties die moeten worden gestopt of gemigreerd.
Als we spreken over cloudgerichtheid, bedoelen we in de eerste plaats de werkmethoden.
Boven hebben we een aantal algemene principes geformuleerd die de methodologische basis vormen voor het ontwikkelen van kwaliteitscontainers voor cloudomgevingen.
We merken op dat naast deze algemene principes ook aanvullende geavanceerde methoden en technieken voor het werken met containers nodig zijn. Daarnaast hebben we verschillende korte aanbevelingen die meer specifiek zijn en afhankelijk van de situatie moeten worden toegepast (of niet):
- Probeer de afbeeldingsgrootte te verkleinen: verwijder tijdelijke bestanden en installeer geen onnodige pakketten - hoe kleiner de container, hoe sneller deze wordt opgebouwd en via het netwerk naar de doelhost wordt gekopieerd.
- Focus op willekeurige User-ID's: gebruik geen sudo-commando of speciale userid's om je containers te starten.
- Label belangrijke poorten: poortnummers kunnen ook tijdens de uitvoering worden ingesteld, maar het is beter om ze op te geven met behulp van het EXPOSE-commando - het zal voor andere mensen en programma's gemakkelijker zijn om je afbeeldingen te gebruiken.
- Bewaar permanente gegevens op volumes: gegevens die moeten blijven bestaan na het verwijderen van de container, moeten op volumes worden geschreven.
- Schrijf metadata voor de afbeelding: tags, labels en annotaties vergemakkelijken het gebruik van afbeeldingen - andere ontwikkelaars zullen je dankbaar zijn.
- Synchroniseer host en afbeeldingen: voor sommige containerapplicaties is het nodig om de container met de host te synchroniseren op bepaalde attributen zoals tijd of machine-ID.
- Tot slot delen we sjablonen en best practices die je helpen de bovenstaande principes effectiever toe te passen:
11 juni om 11.00 uur
Wat je zult leren:
- Immutable Red Hat Enterprise Linux CoreOS
- OpenShift service mesh
- Operator framework
- Knative framework
Bron: habr.com
