原文作者：尼克格拉斯馬托斯，F(xiàn)ICO 云服務(wù)工程高級總監(jiān)，致力如何為Docker卷和數(shù)據(jù)容器缺乏持久化存儲提供解決方案。
在容器內(nèi)運行應(yīng)用的想法并不新穎。是的，這是一個趨勢，無數(shù)人研究容器這一熱門主題，似乎發(fā)現(xiàn)了解決問題的方法。容器將解決一切。
容器的起源實際上能追溯到大型機時代，這并不是一個新技術(shù)，這一技術(shù)最終開始成熟并以驚人的速度獲得用戶關(guān)注和認可。容器使多個應(yīng)用并行運行在單個操作系統(tǒng)之上，不管其是直接部署在物理服務(wù)器還是虛擬實例之上。這個是通過提供在“用戶空間”(即應(yīng)用運行的平臺、系統(tǒng)或運行在內(nèi)核上的代碼)上執(zhí)行多次拷貝的功能來實現(xiàn)的。
容器的當前反饋來自于運行虛擬實例相關(guān)的問題和開銷，每個實例必須有專用的內(nèi)存和存儲資源。它們通常過大或不夠，當對這些資源需求迅速擴展時，它運行會變得緩慢。
虛擬實例的設(shè)計提供隔離和獨立升級每個實例的能力，但在運行類似或相同版本的操作系統(tǒng)的大環(huán)境中，每個虛擬實例都運行相同的進程，內(nèi)存占用和一個近似的啟動卷。
面向一個基于Web可擴展的網(wǎng)絡(luò)計算架構(gòu)目標時，傳統(tǒng)的虛擬化可以說是很低效的，浪費誓如內(nèi)存、處理器、存儲、機架空間、電力、冷卻系統(tǒng)和通用資源(如管理系統(tǒng)、IP地址)等的物理資源。
容器提供一定程度的分離，因為它是獨立于它的臨近容器存在的，所以它看起來似乎自擁有整個操作系統(tǒng)。這種隔離允許它們與外部進行交互。
在2014年指數(shù)級的增長趨勢下，2015年容器和整個生態(tài)系統(tǒng)在企業(yè)環(huán)境中獲得巨大發(fā)展，但是它仍然遠未普及。雖然有極少的備份軟件供應(yīng)商能夠提供容器備份的支持，但是有沒有辦法能實現(xiàn)任何備份軟件都能備份容器呢?
相比而言虛擬實例這種方式預計是短暫的。它應(yīng)用于更好的存儲分配，容器使用的功能被稱為一個覆蓋文件系統(tǒng)來實現(xiàn)一個寫副本的過程中，與存儲任何更新信息的主文件系統(tǒng)的容器相比，它是基于原始鏡像。如果容器被刪除，這些更改通常會丟失。因此容器默認不具有持久存儲能力。
然而，類似Docker這種分布式方案提供兩種特性用于訪問持久化存儲資源：Docker卷和數(shù)據(jù)容器。
一個Docker卷允許數(shù)據(jù)被存儲在啟動卷之外的容器中，在主文件系統(tǒng)中可以在幾方面實現(xiàn)。一個容器可以通過提供一個共享名傳給“-v”切換參數(shù)創(chuàng)建一個或多個卷。
Docker配置文件夾(/var/lib/docker)中創(chuàng)建一個實體代表該卷的內(nèi)容。卷上的配置數(shù)據(jù)存儲在/var/lib/docker/volumes文件夾，每個子目錄代表一個基于通用唯一標識符(UUID)卷名。數(shù)據(jù)本身存儲在/var/lib/docker/vfs/dir基于UUID命名的文件夾。
任何卷中的數(shù)據(jù)都能在主機操作系統(tǒng)中瀏覽和編輯及標準權(quán)限應(yīng)用。然而，卷的使用有利有弊。由于數(shù)據(jù)存儲在標準的文件系統(tǒng)中，它能被操作系統(tǒng)備份、復制、導入和導出。缺點還有卷的命名遵循UUID規(guī)范，這使它很難與容器名稱聯(lián)系在一起。Docker通過提供 “docker cp”命令解決了這個問題，通過指定容器的名稱，即可將文件和文件夾從主機目錄中拷貝到該容器目錄中。這與rsync類似。
它將可能通過提供外部共享存儲在一個NFS共享或LUN并通過提供卷選項來訪問外部存儲上創(chuàng)建的主機共享，雖然這是不推薦的。
一個Docker卷也可以與主機目錄有關(guān)。這里要再次用到“-v”切換，格式如下：“-v /host:/container”。這種方法允許容器訪問主機上的持久數(shù)據(jù)。
它將可能通過提供外部共享存儲在一個NFS共享或LUN，并通過提供卷選項來訪問外部存儲上創(chuàng)建的主機共享。這種方法也可以用來備份由容器訪問的數(shù)據(jù)。
Docker中管理數(shù)據(jù)的另一選擇是Docker數(shù)據(jù)容器。這個概念是指一個或多個卷在內(nèi)的一個休眠容器。這些卷可以導出到一個或多個其它容器中，當啟動附加的容器時，使用‘-volumes-from’切換。數(shù)據(jù)卷容器就像是內(nèi)部的Docker NFS服務(wù)器，從中心點提供訪問容器的支持。
這種方式的優(yōu)點是它從原始數(shù)據(jù)的位置抽象出來，讓數(shù)據(jù)容器變?yōu)橐粋€邏輯中心點。它還允許應(yīng)用程序容器訪問數(shù)據(jù)容器卷以在專用容器中保存數(shù)據(jù)持久性，并將其銷毀。
在使用卷和數(shù)據(jù)容器中有一些問題需要了解。
獨立存儲
目前在沒有刪除相關(guān)卷的情況下是可以刪除容器的。事實上，這是默認的行為，除非重寫。最終它可以很容易地清楚沒有相關(guān)引用容器中的獨立卷。
清除獨立存儲是一項很艱巨的任務(wù)，因為它需要通過在容器配置文件去對容器及其相關(guān)的卷進行匹配。
安全
對于容器卷和數(shù)據(jù)，除了標準文件權(quán)限和配置“只讀”或者“讀寫”訪問，沒有其他別的安全性問題。這意味著用戶在容器上的文件訪問權(quán)限需要匹配主機設(shè)置。
數(shù)據(jù)完整性
使用卷和數(shù)據(jù)容器共享數(shù)據(jù)，能夠保護數(shù)據(jù)的完整性。如文件鎖定需要容器本身的管理功能。這是一個額外的開銷，必須添加到應(yīng)用程序中。
容器沒有提供數(shù)據(jù)保護設(shè)施，如快照或復制，因此數(shù)據(jù)管理必須由主機或容器來處理。
外部存儲也缺乏支持。除了系統(tǒng)操作系統(tǒng)中提供的功能外，Docker并沒有在外部存儲中提供特定的支持。
容器卷默認存儲在/var/lib/dockerdirectory目錄中，這可能會成為一個性能瓶頸。然而，在Docker啟動進程中轉(zhuǎn)換容器卷默認存儲位置是可行的。
最后一個點突出了當前容器存儲的問題：無法管理在單獨的物理主機上運行的容器之間的數(shù)據(jù)共享。
數(shù)據(jù)卷可以置于外部存儲中，但是當前的設(shè)計不具備使用卷從一臺主機轉(zhuǎn)移到另一臺主機的能力。為了解決這個問題，F(xiàn)locker提供的解決方案從ClusterHQ正在嘗試解決卷移植帶來的地址問題。也有提出改變類似Docker這種分布式方案中增加更多卷管理功能。
京公網(wǎng)安備 11010502049343號