På något sätt, historiskt sett, är IT-branschen uppdelad i två villkorade läger av någon anledning: de som är "för" och de som är "emot". Dessutom kan ämnet för tvister vara helt godtyckligt. Vilket OS är bättre: Win eller Linux? På en Android- eller iOS-smartphone? Ska man förvara allt i molnen eller lägga det på kall RAID-lagring och sätta skruvarna i ett kassaskåp? Har PHP-personer rätt att kallas programmerare? Dessa tvister är ibland uteslutande existentiella och har ingen annan grund än sportintresse.
Det råkade bara vara så att med tillkomsten av containrar och allt detta älskade kök med docker och villkorade k8s började debatterna "för" och "emot" användningen av nya funktioner i olika delar av backend. (Låt oss reservera i förväg att även om Kubernetes oftast kommer att indikeras som en orkestrator i denna diskussion, är valet av just detta verktyg inte av grundläggande betydelse. Istället kan du ersätta vilket som helst annat som verkar bekvämast och bekant för dig .)
Och det verkar som om detta skulle vara en enkel tvist mellan två sidor av samma mynt. Lika meningslös och skoningslös som den eviga konfrontationen mellan Win vs Linux, där adekvata människor finns någonstans i mitten. Men när det gäller containerisering är inte allt så enkelt. Vanligtvis i sådana tvister finns det ingen höger sida, men i fallet med "använd" eller "använd inte" behållare för att lagra databaser, vänds allt upp och ner. För i en viss mening har både anhängare och motståndare till detta synsätt rätt.
Ljusa sidan
Ljussidans argument kan kort beskrivas i en fras: "Hej, 2k19 är utanför fönstret!" Det låter förstås som populism, men om man fördjupar sig i situationen i detalj har det sina fördelar. Låt oss reda ut dem nu.
Låt oss säga att du har ett stort webbprojekt. Det kunde ursprungligen ha byggts på basis av en mikrotjänstmetod, eller någon gång kom det till det genom en evolutionär väg - detta är faktiskt inte särskilt viktigt. Du spred vårt projekt i separata mikrotjänster, satte upp orkestrering, lastbalansering och skalning. Och nu, med gott samvete, smuttar du på en mojito i en hängmatta under habraeffekter istället för att höja fallna servrar. Men i alla handlingar måste du vara konsekvent. Mycket ofta är det bara själva applikationen – koden – som är containeriserad. Vad mer har vi förutom kod?
Det stämmer, data. Hjärtat i alla projekt är dess data: detta kan antingen vara en typisk DBMS - MySQL, Postgre, MongoDB eller lagring som används för sökning (ElasticSearch), nyckel-värdelagring för cachning - till exempel redis, etc. För närvarande är vi inte det vi kommer att prata om krokiga backend-implementeringsalternativ när databasen kraschar på grund av dåligt skrivna frågor, och istället kommer vi att prata om att säkerställa feltoleransen för just denna databas under klientbelastning. När allt kommer omkring, när vi containeriserar vår applikation och låter den skalas fritt för att behandla valfritt antal inkommande förfrågningar, ökar detta naturligtvis belastningen på databasen.
Faktum är att kanalen för åtkomst till databasen och servern som den körs på blir nålsögat i vår vackra containeriserade backend. Samtidigt är det huvudsakliga motivet för containervirtualisering strukturens mobilitet och flexibilitet, vilket gör att vi kan organisera fördelningen av topplaster över hela den tillgängliga infrastrukturen så effektivt som möjligt. Det vill säga, om vi inte containeriserar och rullar ut alla befintliga delar av systemet över klustret, gör vi ett mycket allvarligt misstag.
Det är mycket mer logiskt att klustera inte bara själva applikationen utan också de tjänster som ansvarar för att lagra data. Genom att klustra och distribuera webbservrar som fungerar självständigt och fördelar belastningen sinsemellan i k8s löser vi redan problemet med datasynkronisering – samma kommentarer på inlägg, om vi tar någon media- eller bloggplattform som exempel. I alla fall har vi en intra-kluster, till och med virtuell, representation av databasen som en ExternalService. Frågan är att själva databasen ännu inte är klustrad - webbservrarna som är utplacerade i kuben tar information om ändringar från vår statiska stridsdatabas, som roterar separat.
Känner du en fångst? Vi använder k8s eller Swarm för att fördela belastningen och undvika att krascha huvudwebbservern, men vi gör inte detta för databasen. Men om databasen kraschar, då är hela vår klustrade infrastruktur meningslös - vad hjälper tomma webbsidor som returnerar ett databasåtkomstfel?
Det är därför det är nödvändigt att klustera inte bara webbservrar, som man brukar göra, utan även databasinfrastrukturen. Endast på detta sätt kan vi säkerställa en struktur som fungerar fullt ut i ett team, men samtidigt oberoende av varandra. Dessutom, även om hälften av vår backend "kollapsar" under belastning, kommer resten att överleva, och systemet för att synkronisera databaserna med varandra inom klustret och möjligheten att oändligt skala och distribuera nya kluster kommer att hjälpa till att snabbt nå den nödvändiga kapaciteten - om det bara fanns rack i datacentret.
Dessutom låter databasmodellen distribuerad i kluster dig ta just denna databas dit den behövs; Om vi pratar om en global tjänst så är det ganska ologiskt att snurra upp ett webbkluster någonstans i San Francisco-området och samtidigt skicka paket när man kommer åt en databas i Moskva-regionen och tillbaka.
Dessutom låter containerisering av databasen dig bygga alla delar av systemet på samma abstraktionsnivå. Vilket i sin tur gör det möjligt att hantera just detta system direkt från kod, av utvecklare, utan aktiv inblandning av administratörer. Utvecklarna tyckte att det behövdes ett separat DBMS för det nya delprojektet - enkelt! skrev en yaml-fil, laddade upp den till klustret och du är klar.
Och naturligtvis är den interna driften avsevärt förenklad. Säg mig, hur många gånger har du blundat när en ny lagmedlem lagt händerna i stridsdatabasen för jobbet? Vilken är faktiskt den enda du har och snurrar just nu? Naturligtvis är vi alla vuxna här, och någonstans har vi en ny backup, och ännu längre bort - bakom hyllan med mormors gurkor och gamla skidor - ytterligare en backup, kanske till och med i kylförvaring, eftersom ditt kontor redan brann en gång. Men ändå, varje introduktion av en ny lagmedlem med tillgång till stridsinfrastrukturen och, naturligtvis, till stridsdatabasen är en hink med validol för alla runt omkring. Tja, vem känner honom, en nybörjare, han kanske är korsad? Det är läskigt, du håller med.
Containerisering och faktiskt den distribuerade fysiska topologin i ditt projekts databas hjälper till att undvika sådana validerande ögonblick. Litar du inte på en nybörjare? ok! Låt oss ge honom ett eget kluster att arbeta med och koppla bort databasen från de andra klustren - synkronisering endast genom manuell push och synkron rotation av två nycklar (en för teamledaren, den andra för admin). Och alla är glada.
Och nu är det dags att byta till motståndare till databasklustring.
Mörk sida
Genom att argumentera varför det inte är värt att behålla databasen och fortsätta att köra den på en central server, kommer vi inte att böja oss för retoriken om ortodoxier och uttalanden som "farfäder körde databaser på hårdvara, och det kommer vi också att göra!" Låt oss istället försöka komma på en situation där containerisering faktiskt skulle ge påtaglig utdelning.
Håller med, de projekt som verkligen behöver en bas i en container kan räknas på ena handen av inte den bästa fräsmaskinsoperatören. För det mesta är till och med användningen av k8s eller Docker Swarm i sig överflödig - ganska ofta tillgrips dessa verktyg på grund av den allmänna hypen av teknologier och attityderna hos den "allsmäktige" i personen av könen för att driva in allt i moln och containrar. Jo, för nu är det på modet och alla gör det.
I minst hälften av fallen är det överflödigt att använda Kubernetis eller bara Docker på ett projekt. Problemet är att inte alla team eller outsourcingföretag som anlitas för att underhålla kundens infrastruktur är medvetna om detta. Det är värre när containrar påtvingas, eftersom det kostar en viss mängd mynt för kunden.
I allmänhet finns det en åsikt att hamnarbetare/kubmaffian dumt krossar kunder som lägger ut dessa infrastrukturproblem. När allt kommer omkring, för att arbeta med kluster behöver vi ingenjörer som är kapabla till detta och generellt förstår arkitekturen i den implementerade lösningen. Vi beskrev redan en gång vårt fall med Republic-publikationen - där utbildade vi kundens team att arbeta i Kubernetis verklighet, och alla var nöjda. Och det var anständigt. Ofta tar k8s "implementerare" kundens infrastruktur som gisslan - för nu förstår bara de hur allt fungerar där; det finns inga specialister på kundens sida.
Föreställ dig nu att vi på detta sätt lägger ut inte bara webbserverdelen utan även databasunderhållet. Vi sa att BD är hjärtat och att förlusten av hjärtat är dödlig för alla levande organismer. Kort sagt, utsikterna är inte de bästa. Så, istället för att hype Kubernetis, borde många projekt helt enkelt inte bry sig om den normala tariffen för AWS, vilket kommer att lösa alla problem med belastningen på deras webbplats/projekt. Men AWS är inte längre på modet, och show-offs är värda mer än pengar – tyvärr även i IT-miljön.
OK. Kanske behöver projektet verkligen klustring, men om allt är klart med tillståndslösa applikationer, hur kan vi då organisera en anständig nätverksanslutning för en klustrad databas?
Om vi pratar om en sömlös ingenjörslösning, vilket är vad övergången till k8s är, så är vår huvudsakliga huvudvärk datareplikering i en klustrad databas. Vissa DBMS är till en början ganska lojala mot distributionen av data mellan sina individuella instanser. Många andra är inte så välkomnande. Och ganska ofta är huvudargumentet för att välja ett DBMS för vårt projekt inte förmågan att replikera med minimala resurs- och ingenjörskostnader. Särskilt om projektet från början inte var planerat som en mikrotjänst, utan helt enkelt utvecklats i denna riktning.
Vi tror att det inte finns något behov av att prata om hastigheten på nätverksenheter - de är långsamma. De där. Vi har fortfarande inte en riktig möjlighet, om något händer, att starta om en DBMS-instans någonstans där det finns mer, till exempel processorkraft eller ledigt RAM. Vi kommer mycket snabbt att stöta på prestandan för det virtualiserade diskundersystemet. Följaktligen måste DBMS spikas på sin egen personliga uppsättning maskiner som är placerade i närheten. Eller så är det nödvändigt att på något sätt separat kyla ner tillräckligt snabb datasynkronisering för de förmodade reserverna.
Fortsätter ämnet virtuella filsystem: Docker-volymer är tyvärr inte problemfria. I allmänhet, i en sådan fråga som långsiktig tillförlitlig datalagring, skulle jag vilja nöja mig med de mest tekniskt enkla scheman. Och att lägga till ett nytt abstraktionslager från behållarens FS till FS för modervärden är en risk i sig. Men när driften av stödsystemet för containerisering också stöter på svårigheter med att överföra data mellan dessa lager, då är det verkligen en katastrof. För närvarande verkar de flesta av de problem som den progressiva mänskligheten känner till ha utrotats. Men du förstår, ju mer komplex mekanismen är, desto lättare går den sönder.
I ljuset av alla dessa "äventyr" är det mycket mer lönsamt och lättare att hålla databasen på ett ställe, och även om du behöver behålla applikationen, låt den köras på egen hand och genom distributionsgatewayen få samtidig kommunikation med databas, som endast kommer att läsas och skrivas en gång och på ett ställe. Detta tillvägagångssätt minskar sannolikheten för fel och desynkronisering till ett minimum.
Vad leder vi till? Dessutom är databascontainerisering lämplig där det finns ett verkligt behov av det. Du kan inte fylla i en databas med full app och snurra den som om du hade två dussin mikrotjänster - det fungerar inte så. Och detta måste förstås tydligt.
Istället för produktion
Om du väntar på en tydlig slutsats "att virtualisera databasen eller inte", kommer vi att göra dig besviken: den kommer inte att vara här. För när man skapar en infrastrukturlösning måste man inte vägledas av mode och framsteg, utan först och främst av sunt förnuft.
Det finns projekt för vilka principerna och verktygen som följer med Kubernetis passar perfekt, och i sådana projekt råder ro åtminstone i backend-området. Och det finns projekt som inte behöver containerisering, utan en normal serverinfrastruktur, eftersom de i grunden inte kan skala om till mikrotjänstklustermodellen, eftersom de kommer att falla.
Källa: will.com