Hantera tillstånd och data i Docker-program
Dricks
Det här innehållet är ett utdrag från eBook, .NET Microservices Architecture for Containerized .NET Applications, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.
I de flesta fall kan du se en container som en instans av en process. En process behåller inte beständigt tillstånd. Även om en container kan skriva till sin lokala lagring, förutsatt att en instans kommer att finnas på obestämd tid, skulle det vara som att anta att en enda plats i minnet kommer att vara beständig. Du bör anta att containeravbildningar, till exempel processer, har flera instanser eller så småningom kommer att avlivas. Om de hanteras med en containerorkestrerare bör du anta att de kan flyttas från en nod eller virtuell dator till en annan.
Följande lösningar används för att hantera data i Docker-program:
Från Docker-värden som Docker-volymer:
Volymer lagras i ett område i värdfilsystemet som hanteras av Docker.
Bindningsmonteringar kan mappas till valfri mapp i värdfilsystemet, så åtkomst kan inte styras från Docker-processen och kan utgöra en säkerhetsrisk eftersom en container kan komma åt känsliga OS-mappar.
tmpfs-monteringar är som virtuella mappar som bara finns i värdens minne och som aldrig skrivs till filsystemet.
Från fjärrlagring:
Azure Storage, som tillhandahåller geo-distribuerbar lagring, ger en bra långsiktig beständighetslösning för containrar.
Fjärrrelationsdatabaser som Azure SQL Database eller NoSQL-databaser som Azure Cosmos DB eller cachetjänster som Redis.
Från Docker-containern:
- Överläggsfilsystem. Den här Docker-funktionen implementerar en kopieringsuppgift som lagrar uppdaterad information i containerns rotfilsystem. Den informationen är "ovanpå" den ursprungliga avbildningen som containern baseras på. Om containern tas bort från systemet går dessa ändringar förlorade. Även om det är möjligt att spara tillståndet för en container i den lokala lagringen, skulle designen av ett system runt detta vara i konflikt med den lokala containerdesignen, som som standard är tillståndslös.
Men att använda Docker-volymer är nu det bästa sättet att hantera lokala data i Docker. Om du behöver mer information om lagring i containrar kontrollerar du Docker-lagringsdrivrutiner och Om lagringsdrivrutiner.
Följande innehåller mer information om dessa alternativ:
Volymer är kataloger som mappas från värdoperativsystemet till kataloger i containrar. När kod i containern har åtkomst till katalogen är den åtkomsten faktiskt till en katalog i värdoperativsystemet. Den här katalogen är inte kopplad till själva containerns livslängd och katalogen hanteras av Docker och isoleras från värddatorns kärnfunktioner. Datavolymer är därför utformade för att bevara data oberoende av containerns livslängd. Om du tar bort en container eller en avbildning från Docker-värden tas inte data som sparats i datavolymen bort.
Volymer kan namnges eller vara anonyma (standardvärdet). Namngivna volymer är utvecklingen av datavolymcontainrar och gör det enkelt att dela data mellan containrar. Volymer stöder också volymdrivrutiner som gör att du kan lagra data på fjärrvärdar, bland andra alternativ.
Bindningsmonteringar är tillgängliga sedan länge och tillåter mappning av valfri mapp till en monteringspunkt i en container. Bindningsmonteringar har fler begränsningar än volymer och några viktiga säkerhetsproblem, så volymer är det rekommenderade alternativet.
tmpfs-monteringar är i princip virtuella mappar som endast finns i värdens minne och som aldrig skrivs till filsystemet. De är snabba och säkra men använder minne och är bara avsedda för tillfälliga, icke-beständiga data.
Som visas i bild 4–5 kan vanliga Docker-volymer lagras utanför själva containrarna, men inom värdserverns eller den virtuella datorns fysiska gränser. Docker-containrar kan dock inte komma åt en volym från en värdserver eller virtuell dator till en annan. Med dessa volymer går det med andra ord inte att hantera data som delas mellan containrar som körs på olika Docker-värdar, även om det kan uppnås med en volymdrivrutin som stöder fjärrvärdar.
Bild 4-5. Volymer och externa datakällor för containerbaserade program
Volymer kan delas mellan containrar, men bara i samma värd, såvida du inte använder en fjärrdrivrutin som stöder fjärrvärdar. När Docker-containrar hanteras av en orkestrerare kan containrar dessutom "flyttas" mellan värdar, beroende på vilka optimeringar som utförs av klustret. Därför rekommenderar vi inte att du använder datavolymer för affärsdata. Men de är en bra mekanism för att arbeta med spårningsfiler, temporala filer eller liknande som inte påverkar konsekvensen för affärsdata.
Fjärrdatakällor och cacheverktyg som Azure SQL Database, Azure Cosmos DB eller en fjärransluten cache som Redis kan användas i containerbaserade program på samma sätt som när de utvecklas utan containrar. Det här är ett beprövat sätt att lagra affärsprogramdata.
Azure Storage. Affärsdata måste vanligtvis placeras i externa resurser eller databaser, till exempel Azure Storage. Azure Storage tillhandahåller i konkret form följande tjänster i molnet:
Blob Storage lagrar ostrukturerade objektdata. En blob kan vara vilken typ av text eller binär data som helst, till exempel dokument- eller mediefiler (bilder, ljud- och videofiler). Blob Storage kallas även för objektlagring.
Fillagring erbjuder delad lagring för äldre program med standard-SMB-protokoll. Virtuella Azure-datorer och molntjänster kan dela fildata mellan programkomponenter via monterade resurser. Lokala program kan komma åt fildata i en resurs via REST-API:et för filtjänsten.
Table Storage lagrar strukturerade datauppsättningar. Tabelllagring är ett NoSQL-nyckelattributdatalager, vilket ger snabb utveckling och snabb åtkomst till stora mängder data.
Relationsdatabaser och NoSQL-databaser. Det finns många alternativ för externa databaser, från relationsdatabaser som SQL Server, PostgreSQL, Oracle eller NoSQL-databaser som Azure Cosmos DB, MongoDB osv. Dessa databaser kommer inte att förklaras som en del av den här guiden eftersom de är i ett helt annat ämne.
