Správa stavu a dat v aplikacích Dockeru
Tip
Tento obsah je výňatek z eBooku, architektury mikroslužeb .NET pro kontejnerizované aplikace .NET, které jsou k dispozici na .NET Docs nebo jako zdarma ke stažení PDF, které lze číst offline.
Ve většině případů si kontejner můžete představit jako instanci procesu. Proces neudržuje trvalý stav. Kontejner sice může zapisovat do místního úložiště, ale za předpokladu, že instance bude po neomezenou dobu, by se líbilo za předpokladu, že bude odolné jedno umístění v paměti. Měli byste předpokládat, že image kontejnerů, jako jsou procesy, mají více instancí nebo se nakonec ukončí. Pokud jsou spravované pomocí orchestrátoru kontejnerů, měli byste předpokládat, že se můžou přesunout z jednoho uzlu nebo virtuálního počítače do jiného.
Ke správě dat v aplikacích Dockeru se používají následující řešení:
Z hostitele Dockeru jako svazky Dockeru:
Svazky se ukládají v oblasti systému souborů hostitele spravovaného Dockerem.
Připojení vazby se můžou mapovat na libovolnou složku v systému souborů hostitele, takže přístup nelze řídit z procesu Dockeru a může představovat bezpečnostní riziko, protože kontejner by mohl přistupovat k citlivým složkám operačního systému.
Připojení tmpfs jsou podobná virtuálním složkám, které existují pouze v paměti hostitele a nikdy se nezapisují do systému souborů.
Ze vzdáleného úložiště:
Azure Storage, která poskytuje geograficky distribuovatelné úložiště, poskytuje dobré dlouhodobé řešení trvalosti kontejnerů.
Vzdálené relační databáze, jako jsou databáze Azure SQL Database nebo NoSQL, jako je Azure Cosmos DB, nebo služby mezipaměti, jako je Redis.
Z kontejneru Dockeru:
- Překryvný systém souborů. Tato funkce Dockeru implementuje úlohu kopírování při zápisu, která ukládá aktualizované informace do kořenového systému souborů kontejneru. Tyto informace jsou "nahoře" původní image, na které je kontejner založen. Pokud se kontejner odstraní ze systému, tyto změny se ztratí. I když je tedy možné uložit stav kontejneru v rámci místního úložiště, návrh systému kolem toho by byl v konfliktu s místním návrhem kontejneru, který je ve výchozím nastavení bezstavový.
Použití svazků Dockeru je teď ale upřednostňovaným způsobem zpracování místních dat v Dockeru. Pokud potřebujete další informace o úložišti v kontejnerech, zkontrolujte ovladače úložiště Dockeru a ovladače úložiště.
Další podrobnosti o těchto možnostech najdete v následujících částech:
Svazky jsou adresáře mapované z hostitelského operačního systému na adresáře v kontejnerech. Když má kód v kontejneru přístup k adresáři, je tento přístup skutečně k adresáři v hostitelském operačním systému. Tento adresář není svázaný s životností samotného kontejneru a tento adresář spravuje Docker a je izolovaný od základních funkcí hostitelského počítače. Objemy dat jsou proto navrženy tak, aby uchovávaly data nezávisle na životnosti kontejneru. Pokud odstraníte kontejner nebo image z hostitele Dockeru, data uložená v datovém svazku se neodstraní.
Svazky můžou být pojmenované nebo anonymní (výchozí). Pojmenované svazky jsou vývojem kontejnerů svazků dat a usnadňují sdílení dat mezi kontejnery. Svazky také podporují ovladače svazků, které umožňují ukládat data na vzdálených hostitelích, mimo jiné možnosti.
Připojení vazby jsou k dispozici již dávno a umožňují mapování jakékoli složky na přípojný bod v kontejneru. Připojení vazby mají větší omezení než svazky a některé důležité problémy se zabezpečením, takže doporučujeme svazky.
Připojení tmpfs jsou v podstatě virtuální složky, které žijí pouze v paměti hostitele a nikdy se nezapisují do systému souborů. Jsou rychlé a bezpečné, ale používají paměť a jsou určené pouze pro dočasná, ne trvalá data.
Jak je znázorněno na obrázku 4 až 5, běžné svazky Dockeru se dají ukládat mimo samotné kontejnery, ale ve fyzických hranicích hostitelského serveru nebo virtuálního počítače. Kontejnery Dockeru ale nemají přístup ke svazku z jednoho hostitelského serveru nebo virtuálního počítače do jiného. Jinými slovy, s těmito svazky není možné spravovat data sdílená mezi kontejnery, které běží na různých hostitelích Dockeru, i když lze dosáhnout ovladačem svazku, který podporuje vzdálené hostitele.
Obrázek 4–5 Svazky a externí zdroje dat pro aplikace založené na kontejnerech
Svazky lze sdílet mezi kontejnery, ale pouze ve stejném hostiteli, pokud nepoužíváte vzdálený ovladač, který podporuje vzdálené hostitele. Kromě toho, když jsou kontejnery Dockeru spravované orchestrátorem, můžou se kontejnery přesouvat mezi hostiteli v závislosti na optimalizacích provedených clusterem. Proto se nedoporučuje používat objemy dat pro obchodní data. Jsou ale dobrým mechanismem pro práci se soubory trasování, dočasnými soubory nebo podobnými soubory, které nebudou mít vliv na konzistenci obchodních dat.
Vzdálené zdroje dat a nástroje mezipaměti , jako je Azure SQL Database, Azure Cosmos DB nebo vzdálená mezipaměť, jako je Redis, je možné použít v kontejnerizovaných aplikacích stejným způsobem jako při vývoji bez kontejnerů. Jedná se o osvědčený způsob ukládání dat obchodních aplikací.
Azure Storage Obchodní data se obvykle musí umístit do externích prostředků nebo databází, jako je Azure Storage. Azure Storage v konkrétním příkladu poskytuje v cloudu následující služby:
Blob Storage ukládá nestrukturovaná data objektů. Objekt blob může být libovolný typ textových nebo binárních dat, jako jsou soubory dokumentů nebo médií (obrázky, zvukové soubory a videosoubory). Blob Storage se taky může říkat Úložiště objektů.
Úložiště souborů nabízí sdílené úložiště pro starší verze aplikací pomocí standardního protokolu SMB. Virtuální počítače a cloudové služby Azure můžou sdílet data souborů mezi komponentami aplikace prostřednictvím připojených sdílených složek. Místní aplikace mají přístup k datům souborů ve sdílené složce prostřednictvím rozhraní REST API souborové služby.
Tabulkové úložiště slouží k ukládání strukturovaných datových sad. Table Storage je úložiště dat typu klíč-atribut NoSQL, které umožňuje rychlý vývoj a rychlý přístup k velkým objemům dat.
Relační databáze a databáze NoSQL Existuje mnoho možností pro externí databáze, od relačních databází, jako jsou SQL Server, PostgreSQL, Oracle nebo NoSQL databáze, jako jsou Azure Cosmos DB, MongoDB atd. Tyto databáze nebudou vysvětleny jako součást této příručky, protože jsou zcela jiné.