Status en gegevens beheren in Docker-toepassingen

Tip

Deze inhoud is een fragment uit het eBook, .NET Microservices Architecture for Containerized .NET Applications, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

In de meeste gevallen kunt u een container beschouwen als een exemplaar van een proces. Een proces behoudt geen permanente status. Hoewel een container naar de lokale opslag kan schrijven, ervan uitgaande dat een exemplaar voor onbepaalde tijd rondkomt, ervan uitgaande dat één locatie in het geheugen duurzaam is. U moet ervan uitgaan dat containerinstallatiekopieën, zoals processen, meerdere exemplaren hebben of uiteindelijk worden gedood. Als ze worden beheerd met een containerorchestrator, moet u ervan uitgaan dat ze van het ene knooppunt of de VM naar het andere worden verplaatst.

De volgende oplossingen worden gebruikt voor het beheren van gegevens in Docker-toepassingen:

Vanuit de Docker-host, als Docker-volumes:

  • Volumes worden opgeslagen in een gebied van het hostbestandssysteem dat wordt beheerd door Docker.

  • Bindingskoppelingen kunnen worden toegewezen aan elke map in het hostbestandssysteem, zodat de toegang niet kan worden beheerd vanuit het Docker-proces en een beveiligingsrisico kan vormen omdat een container toegang heeft tot gevoelige besturingssysteemmappen.

  • tmpfs-koppelingen zijn vergelijkbaar met virtuele mappen die alleen in het geheugen van de host bestaan en nooit naar het bestandssysteem worden geschreven.

Vanuit externe opslag:

  • Azure Storage, dat geografisch gedistribueerde opslag biedt, biedt een goede langetermijnpersistentieoplossing voor containers.

  • Externe relationele databases, zoals Azure SQL Database - of NoSQL-databases, zoals Azure Cosmos DB, of cacheservices zoals Redis.

Vanuit de Docker-container:

  • Overlay-bestandssysteem. Met deze Docker-functie wordt een copy-on-write-taak geïmplementeerd waarin bijgewerkte informatie wordt opgeslagen in het hoofdbestandssysteem van de container. Deze informatie bevindt zich bovenaan de oorspronkelijke installatiekopieën waarop de container is gebaseerd. Als de container uit het systeem wordt verwijderd, gaan deze wijzigingen verloren. Hoewel het mogelijk is om de status van een container in de lokale opslag op te slaan, zou het ontwerpen van een systeem eromheen conflicteren met de locatie van het containerontwerp, wat standaard staatloos is.

Het gebruik van Docker Volumes is nu echter de voorkeurswijze voor het afhandelen van lokale gegevens in Docker. Als u meer informatie nodig hebt over opslag in containers, controleert u op Docker-opslagstuurprogramma's en over opslagstuurprogramma's.

Hieronder vindt u meer informatie over deze opties:

Volumes zijn mappen die vanuit het hostbesturingssysteem zijn toegewezen aan mappen in containers. Wanneer code in de container toegang heeft tot de map, is die toegang eigenlijk tot een map in het host-besturingssysteem. Deze map is niet gekoppeld aan de levensduur van de container zelf en de map wordt beheerd door Docker en geïsoleerd van de kernfunctionaliteit van de hostcomputer. Daarom zijn gegevensvolumes ontworpen om gegevens onafhankelijk van de levensduur van de container te behouden. Als u een container of installatiekopie verwijdert uit de Docker-host, worden de gegevens die in het gegevensvolume zijn opgeslagen, niet verwijderd.

Volumes kunnen worden benoemd of anoniem zijn (de standaardinstelling). Benoemde volumes zijn de evolutie van Data Volume Containers en maken het eenvoudig om gegevens tussen containers te delen. Volumes ondersteunen ook volumestuurprogramma's waarmee u gegevens kunt opslaan op externe hosts, onder andere opties.

Bindingskoppelingen zijn sinds lange tijd beschikbaar en staan de toewijzing van een map toe aan een koppelpunt in een container. Bindingskoppelingen hebben meer beperkingen dan volumes en enkele belangrijke beveiligingsproblemen, dus volumes zijn de aanbevolen optie.

tmpfs-koppelingen zijn in feite virtuele mappen die alleen in het geheugen van de host wonen en nooit naar het bestandssysteem worden geschreven. Ze zijn snel en veilig, maar gebruiken geheugen en zijn alleen bedoeld voor tijdelijke, niet-permanente gegevens.

Zoals wordt weergegeven in afbeelding 4-5, kunnen normale Docker-volumes buiten de containers zelf worden opgeslagen, maar binnen de fysieke grenzen van de hostserver of VM. Docker-containers hebben echter geen toegang tot een volume van de ene hostserver of vm naar een andere. Met andere woorden, met deze volumes is het niet mogelijk om gegevens te beheren die worden gedeeld tussen containers die worden uitgevoerd op verschillende Docker-hosts, hoewel dit kan worden bereikt met een volumestuurprogramma dat externe hosts ondersteunt.

Diagram showing volumes and external data sources for container-based apps.

Afbeelding 4-5. Volumes en externe gegevensbronnen voor toepassingen op basis van containers

Volumes kunnen worden gedeeld tussen containers, maar alleen in dezelfde host, tenzij u een extern stuurprogramma gebruikt dat externe hosts ondersteunt. Wanneer Docker-containers worden beheerd door een orchestrator, kunnen containers bovendien worden 'verplaatst' tussen hosts, afhankelijk van de optimalisaties die door het cluster worden uitgevoerd. Daarom wordt het afgeraden om gegevensvolumes te gebruiken voor zakelijke gegevens. Maar ze zijn een goed mechanisme om te werken met traceringsbestanden, tijdelijke bestanden of soortgelijke bestanden die geen invloed hebben op de consistentie van bedrijfsgegevens.

Externe gegevensbronnen en cachehulpprogramma's zoals Azure SQL Database, Azure Cosmos DB of een externe cache, zoals Redis, kunnen op dezelfde manier worden gebruikt in toepassingen in containers als bij het ontwikkelen zonder containers. Dit is een bewezen manier om zakelijke toepassingsgegevens op te slaan.

Azure Storage. Bedrijfsgegevens moeten meestal worden geplaatst in externe resources of databases, zoals Azure Storage. Azure Storage biedt in concrete vorm de volgende services in de cloud:

  • In Blob Storage worden ongestructureerde objectgegevens opgeslagen. Een blob kan elk type tekst of binaire gegevens zijn, zoals document- of mediabestanden (afbeeldingen, audio- en videobestanden). U kunt Blob Storage zien als een vorm van objectopslag.

  • File Storage biedt gedeelde opslag voor verouderde toepassingen met behulp van het standaard SMB-protocol. Virtuele Azure-machines en cloudservices kunnen bestandsgegevens delen tussen toepassingsonderdelen via gekoppelde shares. On-premises toepassingen hebben toegang tot bestandsgegevens in een share via de REST API van de bestandsservice.

  • Met Table Storage worden gestructureerde gegevenssets opgeslagen. Table Storage is een NoSQL-sleutelkenmerkgegevensarchief, waarmee snelle ontwikkeling en snelle toegang tot grote hoeveelheden gegevens mogelijk is.

Relationele databases en NoSQL-databases. Er zijn veel opties voor externe databases, van relationele databases zoals SQL Server, PostgreSQL, Oracle of NoSQL-databases zoals Azure Cosmos DB, MongoDB, enzovoort. Deze databases worden niet uitgelegd als onderdeel van deze handleiding omdat ze zich in een totaal ander onderwerp bevinden.