"Cloud native" eller helt enkelt "moln"-applikationer skapas specifikt för att fungera i molninfrastrukturer. De är vanligtvis byggda som en uppsättning löst kopplade mikrotjänster paketerade i containrar, som i sin tur hanteras av en molnplattform. Sådana applikationer är förberedda för fel som standard, vilket innebär att de fungerar tillförlitligt och skalas även i händelse av allvarliga fel på infrastrukturnivå. Den andra sidan av myntet är de uppsättningar av restriktioner (kontrakt) som molnplattformen lägger på containerapplikationer för att kunna hantera dem automatiskt.
Även om de är fullt medvetna om behovet och vikten av att gå över till molnbaserade applikationer, vet många organisationer fortfarande inte var de ska börja. I det här inlägget kommer vi att titta på ett antal principer som, om de följs vid utveckling av containerbaserade applikationer, kommer att göra det möjligt för dig att inse potentialen hos molnplattformar och uppnå tillförlitlig drift och skalning av applikationer även i händelse av allvarliga fel i IT-infrastrukturen nivå. Det slutliga målet med principerna som beskrivs här är att lära sig hur man bygger applikationer som automatiskt kan hanteras av molnplattformar som Kubernetes.
Principer för mjukvarudesign
Inom programmeringsvärlden avser principer ganska generella regler som måste följas vid utveckling av mjukvara. De kan användas när du arbetar med alla programmeringsspråk. Varje princip har sina egna mål, verktygen för att uppnå som vanligtvis är mallar och metoder. Det finns också ett antal grundläggande principer för att skapa högkvalitativ mjukvara, som alla andra kommer från. Här är några exempel på grundläggande principer:
- (Keep it simple, stupid) – komplicera det inte;
- (upprepa inte dig själv) - upprepa inte dig själv;
- (Du kommer inte att behöva det) - skapa inte något som inte omedelbart behövs;
- Separering av bekymmer – dela ansvar.
Som du kan se sätter dessa principer inga specifika regler, utan tillhör kategorin av så kallade sunt förnuftsöverväganden baserade på praktisk erfarenhet, som delas av många utvecklare och som de regelbundet hänvisar till.
Dessutom finns det – En uppsättning av de första fem principerna för objektorienterad programmering och design, formulerade av Robert Martin. SOLID innehåller breda, öppna, kompletterande principer som – när de tillämpas tillsammans – hjälper till att skapa bättre mjukvarusystem och bättre underhålla dem på lång sikt.
SOLID-principerna hör till området OOP och är formulerade på språket för sådana begrepp och begrepp som klasser, gränssnitt och arv. I analogi kan utvecklingsprinciper också formuleras för molnapplikationer, bara grundelementet här kommer inte att vara en klass, utan en container. Genom att följa dessa principer kan du skapa containeriserade applikationer som bättre uppfyller målen och målen för molnplattformar som Kubernetes.
Molnbaserade behållare: Red Hat-metoden
Idag kan nästan alla applikationer förpackas relativt enkelt i behållare. Men för att applikationer effektivt ska kunna automatiseras och orkestreras inom en molnplattform som Kubernetes krävs ytterligare ansträngningar.
Grunden för idéerna nedan var metodiken och många andra arbeten om olika aspekter av att bygga webbapplikationer, från källkodshantering till skalningsmodeller. De beskrivna principerna gäller endast för utveckling av containerbaserade applikationer som är byggda ovanpå mikrotjänster och designade för molnplattformar som Kubernetes. Det grundläggande elementet i vår diskussion är containerbilden, och målcontainerns körtid är containerorkestreringsplattformen. Målet med de föreslagna principerna är att skapa behållare för vilka schemaläggning, skalning och övervakningsuppgifter kan automatiseras på de flesta orkestreringsplattformar. Principerna presenteras utan särskild ordning.
Single Concern Principle (SCP)
Denna princip liknar på många sätt principen om ett enda ansvar. ), som är en del av SOLID-uppsättningen och anger att varje objekt måste ha ett ansvar och att ansvaret måste vara helt inkapslat i en klass. Poängen med SRP är att varje ansvar är en anledning till förändring, och en klass måste ha en och endast en anledning till förändring.
I SCP använder vi ordet "oro" istället för ordet "ansvar" för att indikera den högre abstraktionsnivån och ett bredare syfte med en container jämfört med en OOP-klass. Och om målet med SRP är att bara ha en anledning till förändring, så ligger bakom SCP önskan att utöka möjligheten att återanvända och ersätta behållare. Genom att följa SRP:n och skapa en container som löser ett enstaka problem och gör det på ett funktionellt komplett sätt ökar du chanserna att återanvända den containerbilden i olika applikationssammanhang.
SCP-principen säger att varje container ska lösa ett enda problem och göra det bra. Dessutom är SCP i containervärlden lättare att uppnå än SRP i OOP-världen, eftersom containrar vanligtvis kör en enda process, och för det mesta löser denna process en enda uppgift.
Om en containermikrotjänst måste lösa flera problem samtidigt, kan den delas upp i enuppgiftscontainrar och kombineras i en pod (en enhet för containerplattformsutbyggnad) med hjälp av sidvagns- och init-containermallar. Dessutom gör SCP det enkelt att byta ut en gammal container (som en webbserver eller meddelandeförmedlare) mot en ny som löser samma problem men har utökad funktionalitet eller skalar bättre.
High Observability Principle (HOP)
När behållare används som ett enhetligt sätt att paketera och köra applikationer, behandlas själva applikationerna som en svart låda. Men om dessa är molnbehållare måste de tillhandahålla speciella API:er till körtiden för att övervaka behållarnas tillstånd och vid behov vidta lämpliga åtgärder. Utan detta kommer det inte att vara möjligt att förena automatiseringen av uppdateringsbehållare och hantering av deras livscykel, vilket i sin tur kommer att försämra mjukvarusystemets stabilitet och användbarhet.
I praktiken bör en containeriserad applikation som minimum ha ett API för olika typer av hälsokontroller: livlighetstester och beredskapstester. Om en applikation påstår sig göra mer måste den tillhandahålla andra sätt att övervaka dess tillstånd. Till exempel loggning av viktiga händelser via STDERR och STDOUT för loggaggregation med Fluentd, Logstash och andra liknande verktyg. Samt integration med spårnings- och metriksamlingsbibliotek, såsom OpenTracing, Prometheus, etc.
I allmänhet kan applikationen fortfarande behandlas som en svart låda, men den måste förses med alla API:er som plattformen behöver för att övervaka och hantera den på bästa möjliga sätt.
Livscykelöverensstämmelseprincip (LCP)
LCP är motsatsen till HOP. Medan HOP anger att behållaren måste exponera läs-API:er för plattformen, kräver LCP att applikationen ska kunna acceptera information från plattformen. Dessutom måste behållaren inte bara ta emot händelser, utan också anpassa sig, med andra ord, reagera på dem. Därav namnet på principen, som kan betraktas som ett krav för att förse plattformen med skrivande API:er.
Plattformar har olika typer av händelser som hjälper till att hantera en containers livscykel. Men det är upp till ansökan själv att avgöra vilka av dem som ska uppfattas och hur de ska reagera.
Det är klart att vissa händelser är viktigare än andra. Till exempel, om en applikation inte tolererar krascher väl, måste den acceptera signal: terminate (SIGTERM) meddelanden och initiera sin avslutningsrutin så snabbt som möjligt för att fånga signalen: kill (SIGKILL) som kommer efter SIGTERM.
Dessutom kan händelser som PostStart och PreStop vara viktiga för en applikations livscykel. Till exempel, efter att en applikation har startat kan det kräva en viss uppvärmningstid innan den kan svara på förfrågningar. Eller så måste applikationen frigöra resurser på något speciellt sätt när den stängs av.
The Image Immutability Principle (IIP)
Det är allmänt accepterat att containeriserade applikationer ska förbli oförändrade efter att de byggts, även om de körs i olika miljöer. Detta nödvändiggör behovet av att externisera datalagring vid körning (med andra ord att använda externa verktyg för detta) och att förlita sig på externa, körtidsspecifika konfigurationer, snarare än att modifiera eller skapa unika behållare för varje miljö. Efter eventuella ändringar av programmet måste behållaravbildningen byggas om och distribueras till alla miljöer som används. Förresten, när man hanterar IT-system används en liknande princip, känd som principen om oföränderlighet av servrar och infrastruktur.
Målet med IIP är att förhindra skapandet av separata behållarbilder för olika körningsmiljöer och att använda samma bild överallt tillsammans med lämplig miljöspecifik konfiguration. Genom att följa denna princip kan du implementera så viktiga metoder ur automatiseringssynpunkt av molnsystem som återställning och framrullning av applikationsuppdateringar.
Process Disposability Principle (PDP)
En av de viktigaste egenskaperna hos en behållare är dess tillfällighet: en instans av en behållare är lätt att skapa och lätt att förstöra, så den kan enkelt ersättas med en annan instans när som helst. Det kan finnas många anledningar till ett sådant byte: misslyckande i ett servicetest, skalning av applikationen, överföring till en annan värd, uttömning av plattformsresurser eller andra situationer.
Som en konsekvens måste containeriserade applikationer bibehålla sitt tillstånd med hjälp av några externa medel, eller använda interna distribuerade system med redundans för detta. Dessutom måste applikationen starta snabbt och stängas av snabbt, och vara beredd på plötsligt fatalt hårdvarufel.
En praxis som hjälper till att implementera denna princip är att hålla behållarna små. Molnmiljöer kan automatiskt välja en värd att starta en containerinstans på, så ju mindre behållaren är, desto snabbare startar den – den kopieras helt enkelt till målvärden över nätverket snabbare.
Självförslutningsprincip (S-CP)
Enligt denna princip, vid monteringsstadiet, ingår alla nödvändiga komponenter i behållaren. Behållaren bör byggas på antagandet att systemet bara har en ren Linux-kärna, så alla nödvändiga ytterligare bibliotek bör placeras i själva behållaren. Den bör också innehålla saker som körtiden för motsvarande programmeringsspråk, applikationsplattformen (om nödvändigt) och andra beroenden som kommer att krävas medan containerapplikationen körs.
Undantag görs för konfigurationer som varierar från miljö till miljö och måste tillhandahållas vid körning, till exempel genom en Kubernetes ConfigMap.
En applikation kan inkludera flera containeriserade komponenter, till exempel en separat DBMS-behållare i en containeriserad webbapplikation. Enligt S-CP-principen ska dessa behållare inte kombineras till en, utan bör göras så att DBMS-behållaren innehåller allt som behövs för driften av databasen, och webbapplikationsbehållaren innehåller allt som behövs för driften av webben applikation, samma webbserver . Som ett resultat kommer webbapplikationsbehållaren vid körning att vara beroende av DBMS-behållaren och komma åt den efter behov.
Runtime Confinement Principle (RCP)
S-CP-principen definierar hur behållaren ska byggas och vad den binära bilden ska innehålla. Men en behållare är inte bara en "svart låda" som bara har en egenskap - filstorlek. Under körningen antar behållaren andra dimensioner: mängden minne som används, CPU-tid och andra systemresurser.
Och här kommer RCP-principen väl till pass, enligt vilken behållaren måste halshugga sina krav på systemresurser och överföra dem till plattformen. Med varje containers resursprofiler (hur mycket CPU-, minnes-, nätverks- och diskresurser den behöver) kan plattformen optimalt utföra schemaläggning och autoskalning, hantera IT-kapacitet och upprätthålla SLA-nivåer för containrar.
Förutom att uppfylla containerns resurskrav är det också viktigt att applikationen inte går utanför sina egna gränser. Annars, när en resursbrist uppstår, är det mer sannolikt att plattformen inkluderar den i listan över applikationer som måste avslutas eller migreras.
När vi pratar om att vara molnet först, pratar vi om hur vi arbetar.
Ovan formulerade vi ett antal generella principer som lägger den metodologiska grunden för att bygga högkvalitativa containerapplikationer för molnmiljöer.
Observera att du förutom dessa allmänna principer också behöver ytterligare avancerade metoder och tekniker för att arbeta med containrar. Dessutom har vi några korta rekommendationer som är mer specifika och bör tillämpas (eller inte tillämpas) beroende på situationen:
- Försök att minska storleken på bilder: ta bort temporära filer och installera inte onödiga paket - ju mindre behållarestorleken är, desto snabbare sätts den ihop och kopieras till målvärden över nätverket.
- Fokusera på godtyckliga användar-ID: använd inte sudo-kommandot eller något speciellt användar-id för att starta dina behållare.
- Markera viktiga portar: Du kan ställa in portnummer vid körning, men det är bättre att ange dem med kommandot EXPOSE - det kommer att göra det lättare för andra människor och program att använda dina bilder.
- Lagra beständiga data på volymer: Data som ska finnas kvar efter att behållaren har förstörts ska skrivas till volymer.
- Skriv metadata för bilder: taggar, etiketter och kommentarer gör bilder enklare att använda - andra utvecklare kommer att tacka dig.
- Synkronisera värd och bilder: Vissa behållarapplikationer kräver att behållaren synkroniseras med värden på vissa attribut, såsom tid eller maskin-ID.
- Sammanfattningsvis delar vi mallar och bästa praxis som hjälper dig att mer effektivt implementera principerna som anges ovan:
11 juni kl 11.00
Vad du kommer att lära dig:
- Oföränderligt Red Hat Enterprise Linux CoreOS
- OpenShift servicenät
- Operatörsramverk
- Knativ ram
Källa: will.com