page title icon Datacontainerarchitectuur: antwoorden en uitdagingen

Datacontainers zijn een recente stap in de evolutie van de cloud. Hun doel is om betrouwbaar te werken terwijl ze van de ene computeromgeving naar de andere worden overgebracht. Ze zijn geïsoleerd, verbeteren de beveiliging en zijn ‘meestal’ gemakkelijk om mee te werken. Containers promoten overdraagbaarheid van applicaties door hun nieuwe gebruik van verpakkingen en de filosofie van ‘eenmalig ontwikkelen, overal implementeren’. Containers bevinden zich nog in de beginfase van hun groei, hoewel veel problemen kunnen worden opgelost met de juiste containerarchitectuur.

Renat Zubairov, CEO van Elastic.io (een leverancier van hybride integratieplatforms), zei:

“Het levenscyclusbeheer voor containers brengt uitdagingen met zich mee. Wanneer mensen besluiten om containers te gaan gebruiken, gaan ze er meestal van uit dat dit hetzelfde is als, of in ieder geval vergelijkbaar met, het gebruik van virtuele machines. In werkelijkheid verschillen containers aanzienlijk van virtuele machines. “

Terwijl virtuele machines hebben hun eigen sterke puntenis het belangrijkste voordeel van het gebruik van containers hun kleine formaat, gecombineerd met de capaciteit om meerdere containers tegelijkertijd op een server te laten draaien. Een ander voordeel van containers is hun indrukwekkende modulariteit. Een app kan bijvoorbeeld worden verdeeld over verschillende containers, met behulp van een technologie genaamd microservices. Containers en microservices zijn ontworpen om goed samen te werken. Deze sterke punten zijn de redenen waarom DevOps-technici de voorkeur geven aan containers bij het ontwikkelen, testen en bouwen van apps in de cloud.

Containers hebben gemaakt met behulp van de cloud gemakkelijker. Een container is in wezen een op zichzelf staand pakket algoritmen dat in verschillende computersystemen kan worden geïnstalleerd. Door hun ontwerp bevorderen containers het gebruik van private en hybride clouds. Een private cloud biedt beduidend meer beveiliging dan een publieke cloud, maar laat desnoods toe om de container te delen. Hybride clouds maken het gebruik van privéclouds mogelijk om het bulkwerk te doen, en het gebruik van tools die beschikbaar zijn op openbare clouds voor fijnafstemming.

Veel organisaties werken mee hybride wolken en containers om de levenscyclus van het ontwikkelen van applicaties te verbeteren door de juiste tools te gebruiken, zoals continue integratie en continue levering. Bovendien ondersteunen containers de Agile en DevOps-filosofieën van efficiënte en continue softwareleveringspraktijken.

Containers benadrukken gemakkelijke portabiliteit en beheer ten koste van persistentie. Ze zijn, door hun ontwerp, bedoeld om zowel geïsoleerd als gemakkelijk wegwerpbaar te zijn. Deze combinatie is zowel hun kracht als hun zwakte.

Gegevenspersistentie

Wanneer een container gegevens naar een schijf schrijft, gebruikt deze een virtueel bestandssysteem dat “bestaat” in de container zelf. De inhoud verdwijnt meestal nadat de container is beëindigd… of is gecrasht. Een container, als een geïsoleerd systeem, ondersteunt geen ‘persistentie’. Algoritmen in de container schrijven geen gegevens rechtstreeks naar het hostbestand. Containers zijn geïsoleerd en deel geen opslag met andere containers. Ze delen ook geen opslagruimte met lokale applicaties, daemons, enz. Die in het hostbesturingssysteem bestaan.

De isolatie van containers staat lijnrecht tegenover het concept van persistentie, hoewel er manieren zijn om de persistentie van gegevens voor containers te beheren. Elke methode brengt echter afwegingen met zich mee, vooral met betrekking tot draagbaarheid en isolatie. Het configureren van een container voor persistentie maakt het proces van het beveiligen en implementeren ervan moeilijker.

Docker’s volume plug-ins en Kubernetes ‘persistente volumes framework van orchestrators ondersteunen het gebruik van externe volumes voor het opslaan en benaderen van data. U kunt de termen “stateless” en “stateful” tegenkomen – stateless containers slaan geen gegevens op, terwijl stateful containers een vorm van back-upopslag nodig hebben.

Hostgebaseerde persistentie

Hostgebaseerde persistentie is een vroege vorm van dataduurzaamheid voor containers, die volwassen is geworden en ondersteuning biedt voor verschillende situaties. Dit type architectuur gebruikt de onderliggende host voor persistentie en opslag en omzeilt de backends van het union-bestandssysteem om toegang te krijgen tot het native bestandssysteem van de host. De gegevens worden buiten de container opgeslagen, waardoor ze beschikbaar zijn wanneer een container wordt verwijderd.

De architectuur die hostgebaseerde persistentie ondersteunt, zorgt ervoor dat meerdere containers volumes kunnen delen. Gegevensbeschadiging kan echter optreden wanneer meerdere containers naar één gedeeld volume (in dit geval lijkt ‘volume’ meer op deel vier van een boekenreeks dan op de hoeveelheid gegevens die door het systeem beweegt). Ontwikkelaars moeten ervoor zorgen dat de applicaties zijn ontworpen om naar deze gedeelde gegevensopslag te schrijven.

Hoewel dit betekent dat de volumes kunnen worden gelezen en geschreven met “normale” Linux-tools, zou dit over het algemeen niet moeten worden gedaan. Het loopt het risico gegevensbeschadiging te veroorzaken als de containers en applicaties niet zijn voorbereid voor directe toegang.

Docker-oplossingen

Er zijn drie architectonische Docker-oplossingen voor het bieden van op de host gebaseerde persistentie, elk met subtiele verschillen in hoe ze worden geïmplementeerd. Zij zijn:

  • Impliciete opslag per container: Creëert opslag “sandbox” voor de container die om hostgebaseerde persistentie vraagt. Een map kan standaard worden geopend (met / var / lib / docker / volumes) op de host bij het maken van de container.

Helaas, wanneer de container is verwijderd, wordt de map automatisch verwijderd door de Docker Engine. Deze mappen kunnen ook verdwijnen als de Docker Engine crasht. Opgemerkt moet worden dat de gegevens die zijn opgeslagen in het zandbak is niet toegankelijk voor andere containers, met uitzondering van degene die erom vraagt.

  • Expliciete gedeelde opslag (in Docker “Datavolumes” genoemd): Deze tweede techniek wordt gebruikt om gegevens te delen met meerdere containers die op dezelfde host draaien. Deze situatie vereist een expliciete locatie van het hostbestandssysteem om te worden gebruikt als een mount in een of meer van de containers. Deze techniek is handig bij meerdere containers die lees- en schrijftoegang nodig hebben voor dezelfde directory. Omdat de directory op de host buiten de context van Docker Engine wordt gemaakt, is deze zelfs beschikbaar nadat elke container is verwijderd of zelfs Docker Engine is gestopt. Deze techniek is de meest populaire die wordt gebruikt door DevOps-teams. Datavolumes is rechtstreeks toegankelijk vanaf de Docker-host.

Het probleem met deze techniek is dat de containers niet langer draagbaar zijn – persistentie heeft de draagbaarheid vervangen. De gegevens bevinden zich nu bij de host en worden niet overgedragen met de container.

  • Gedeelde multi-host opslag: Combineert een gedistribueerd bestandssysteem met expliciete opslag. Gecontaineriseerde workloads in productie worden vaak uitgevoerd in een clusteromgeving, waarbij meerdere hosts de benodigde computer-, netwerk- en opslagmogelijkheden bieden. Hierin hebben alle knooppunten het koppelpunt beschikbaar en kunnen ze het gebruiken om een ​​gedeeld koppelpunt voor containers te bouwen.

Docker, gecombineerd met hostgebaseerde persistentie voor specifieke gebruiksscenario’s, heeft zijn toepassingen, maar beperkt ook ernstig de overdraagbaarheid van containers, gekoppeld aan een specifieke host. Bovendien maakt dit systeem geen gebruik van de gespecialiseerde opslagbackends die zijn ontworpen voor gegevensintensieve workloads. In een poging om deze beperkingen op te lossen, heeft Docker volumeplug-ins toegevoegd die de mogelijkheden van de container uitbreiden met verschillende soorten opslagbackends, zonder de implementatiearchitectuur of het toepassingsontwerp te wijzigen.

  • OpslagOS: Deze product is gebaseerd voornamelijk op Kubernetes-bewerkingen via het orkestratieplatform. Het kan on-premise en in hybride cloudsituaties werken. Het werkt tussen containers en de opslag en kan in de cloud of on-premise worden gebruikt. Het biedt opslag voor containers in Red Hat Openshift, Kubernetes en Docker, en wordt geleverd met functies die opslag automatiseren en beschermen.

Een gratis versie van StorageOS is beschikbaar op de Docker Hub, als je het wilt bekijken.

Kubernetes beheert de levensduur van het volume

Kubernetes biedt een ander soort ‘volume’. In Docker zijn volumes mappen op een schijf of in een andere container. Het volume van een Kubernetes werkt daarentegen een beetje anders. Het is omsloten met een pod. (Voorbeelden van pods zijn een peapod, of een pod met walvissen, of een groep containers die binnen een netwerk worden gedeeld.) Een Kubernetes-volume zal alle containers die in de pod draaien overleven en de gegevens blijven bewaard, zelfs nadat de container opnieuw is opgestart. Kubernetes-pods ondersteunen ook een verscheidenheid aan volumes, en kunnen alle of sommige tegelijk gebruiken.

Wanneer de pod echter ophoudt te bestaan, verdwijnt het volume en verdwijnt ook de geschiedenis van wat er heeft plaatsgevonden.

Container Orchestration

“Containerorkestratie” beschrijft het automatische proces van het organiseren of plannen van individuele containers voor applicaties met behulp van microservices binnen meerdere clusters. Als acht containers vier applicaties draaien, is het niet zo moeilijk om de processen en inzet van de containers te organiseren en in te richten, dus automatisering is niet nodig. Als echter 800 containers en 400 applicaties draaien, wordt het beheer moeilijker. Hoewel op schaal wordt gewerkt, wordt de orkestratie van containers – automatisering van implementatie, schaalbaarheid, netwerken en beschikbaarheid – een noodzaak.

Containerorkestratie beheert de levenscyclus van de container en is vooral handig in grote, gecompliceerde omgevingen. Containerindeling controleert en automatiseert:

  • Containers inrichten en inzetten
  • Containers verplaatsen wanneer er een tekort aan middelen is binnen de host, of als de host overlijdt
  • Load balancing tussen containers
  • Containers schalen of verwijderen om de applicatiebelasting te verdelen en te verdelen over de infrastructuur van de host
  • Redundantie en de beschikbaarheid van containers
  • Toewijzing van middelen over containers
  • Applicatieconfiguraties volgens de containers die het uitvoeren
  • Monitoring van de containers en hun hosts

Herstructurering van personeel voor containers

Zoals eerder vermeld, ondersteunen containers de Agile- en DevOps-filosofieën van efficiënte en continue softwareleveringspraktijken. Doorgaans is het Operations Team (Ops) verantwoordelijk voor de infrastructuur (computers, het netwerk, opslag enz.) En systeembronnen (het bestandssysteem, runtime-bibliotheken, enz.). Het Development Team (Dev) werkt samen bij het ontwikkelen van producten en / of diensten. Overschakelen naar een containersysteem houdt in dat de verantwoordelijkheden van de Ops en Dev-teams worden samengevoegd. Reorganiseren het technische personeel is nodig bij het overschakelen naar een containersysteem, en kan betrekking hebben op het inhuren van tijdelijke medewerkers / aannemers voor specifieke projecten.

Afbeelding gebruikt onder licentie van Shutterstock.com

Plaats een reactie