在容器中運行應用并不是一個全新的理念。是的，這是一個熱門話題，其中許多人在討論中為了提升話題的熱度，或者是為了拋出新奇的觀點，往往都會提到容器，仿佛他們?yōu)檫@一棘手問題找到了良策一樣。聽上去似乎是這樣的——容器是***的，它能解決所有的問題。

[[150990]]

容器的起源實際上可以追溯至大型機時代，因此它并不是新的東西。這一技術已經(jīng)開始逐漸成熟，并以極快的速度獲得了用戶的關注與認可。

容器可讓應用同時運行在一個單一操作系統(tǒng)中，既可以將其直接部署在物理服務上，也可以作為一個虛擬實例部署。

這是通過提供了執(zhí)行“用戶空間”多個拷貝的功能實現(xiàn)的。在這里，應用可以運行在平臺上，系統(tǒng)或是特殊代碼可以運行在內(nèi)核上。

容器在存儲領域的短板：默認情況下沒有***性存儲

容器當前的吸引力來自與運行虛擬實例相關的問題和日常開支方面，即每個實例必須要有專用內(nèi)存和存儲資源。這些東西通常要么太多，要么太少，在需要快速擴展時，往往要花費很長的時間。

虛擬實例的設計存在孤立性，每個實例的升級都具有獨特性，但是在運行相似或相同操作系統(tǒng)版本的大環(huán)境中，每個都運行著一套相同的程序以消費內(nèi)存，保持近乎相同的啟動卷。

在向“大規(guī)模計算轉型”這一目標進發(fā)的征途中，傳統(tǒng)的虛擬化被認為效率低下，浪費內(nèi)存、CPU、存儲、機架空間、電力、冷卻等物理資源，以及浪費管理、IP地址等邏輯資源。由于它們與鄰近的看起來好像容器擁有整個操作系統(tǒng)的組件相互隔離，因此容器帶有一定程度的分離性。這種分離性允許它們與外部世界進行互動。

由于在2014年呈現(xiàn)指數(shù)增長，容器及其生態(tài)系統(tǒng)2015年在企業(yè)環(huán)境中獲得了一些推動力，但是還遠未達到大規(guī)模部署的程度。目前已經(jīng)有少量的備份軟件提供商開始提供容器備份支持，但是目前是否已經(jīng)有了一種可以通過備份軟件備份容器的方法呢?

與虛擬實例相比，這可能是非常短暫的，并且只適用于分配給它們的存儲。與以前所使用的原始鏡像相比，容器可以使用重疊式文件系統(tǒng)等功能執(zhí)行寫入時復制程序，以存儲所有升級信息到容器的根文件系統(tǒng)。如果容器被刪除了，那么這些變更也通常會丟失。因此，容器在默認情況下沒有***存儲。

Docker在存儲領域的改進：使用卷和數(shù)據(jù)容器時仍存在問題

然而，Docker提供了Docker卷和數(shù)據(jù)容器兩個功能，這兩個功能可以實現(xiàn)對更多***存儲資源的訪問。

Docker卷允許數(shù)據(jù)被存儲在啟動卷外的容器中，根文件系統(tǒng)內(nèi)，并且可以通過多種方式被執(zhí)行。通過提供一個傳遞至“-v”交換機參數(shù)的共享名，容器能夠被創(chuàng)建在一個或多個卷內(nèi)。

這擁有在Docker配置文件夾(/var/lib/docker)中創(chuàng)建一個實體，以展現(xiàn)卷中內(nèi)容的效果。卷中的配置數(shù)據(jù)被存儲在/var /lib/docker/volumes文件夾內(nèi)，通過每個子目錄展現(xiàn)基于通用唯一標識符(UUID)的卷名。數(shù)據(jù)本身將被存儲在以UUID名稱為基礎的 /var/lib/docker/vfs/dir文件夾中。

任何卷中的數(shù)據(jù)都能夠通過主機操作系統(tǒng)和標準權限申請被瀏覽和編輯。卷的使用既有優(yōu)勢也有劣勢。由于數(shù)據(jù)被存儲在標準文件系統(tǒng)中，它們可以通過操作系統(tǒng)被備份、拷貝或是移入/移出。

不足之處是卷名采用的是UUID格式，這讓人難以將它們與容器名稱聯(lián)系在一起。Docker讓許多工作變得更加輕松，它通過提供“docker cp”命令，讓文件和文件夾能夠從主機目錄拷貝至指定容器名稱的容器目錄路徑。這與rsync很相似。

這為提供對在NFS共享上的外部共享存儲或LUN的訪問帶來了可能。LUN使用卷選項訪問創(chuàng)建在外部存儲上的主機共享，不過這種方式并不推薦使用。

Docker卷也可以與主機目錄聯(lián)系在一起。這在“-v”交換機中被進行了詳細說明，它使用了一個通過冒號將主機與容器分隔起來的格式，即：“-v /host:/container”。這種方法允許容器訪問主機上的持久性數(shù)據(jù)。

因此，這使得訪問存儲在NFS共享上的外部共享存儲，或者使用卷選項訪問創(chuàng)建在外部存儲上的主機共享的LUN成為了可能。這種方式也可用于備份由容器訪問的數(shù)據(jù)。

對于管理Docker中數(shù)據(jù)的另一個選項是使用Docker數(shù)據(jù)容器。這一概念實質上是一個不活躍容器，其中創(chuàng)建有一個或多個卷。在啟動額外容器時，這些卷能夠被導出到一個或多個使用“-volumes-from”交換機的容器中。

數(shù)據(jù)卷容器實際上是作為一個內(nèi)部的Docker NFS服務器，提供對來自中央掛載點的容器的訪問。

這種方法的好處是它抽象了原始數(shù)據(jù)的位置，讓數(shù)據(jù)容器成為了一個邏輯掛載點。在保持數(shù)據(jù)長久保存一個專用容器的同時，它們還允許訪問數(shù)據(jù)容器卷的“應用”容器被創(chuàng)建和被破壞。

在使用卷和數(shù)據(jù)容器時我們會發(fā)現(xiàn)，其中存在許多問題。

孤立的存儲

目前，在不刪除相關卷的情況下，刪除容器已經(jīng)成為了可能。實際上，這是一種默認行為，除非明確進行重寫。這使得終結沒有相關容器的孤立卷變得更加容易。

清理孤立存儲是一項艱巨的任務，這需要查找與容器匹配的容器配置文件和與它們相關的卷。

安全性

除了標準文件權限和配置只讀或讀寫訪問選項外，卷或數(shù)據(jù)容器沒有額外的安全保證。這意味著容器中的用戶文件訪問權限需要與主機設置相匹配。

數(shù)據(jù)完整性

共享使用卷和數(shù)據(jù)容器的數(shù)據(jù)沒有任何數(shù)據(jù)完整性保護措施。文件鎖定等功能需要由容器自身進行管理。這是一項必須要加入到應用當中的額外開銷。

容器不提供數(shù)據(jù)保護工具，例如快照或復制，因此數(shù)據(jù)管理必須要由主機或是容器負責。

目前還缺乏對外部存儲的支持。除了主機操作系統(tǒng)提供的功能外，Docker內(nèi)部也沒有對外部存儲的一些特殊支持。

容器卷默認存儲在/var/lib/dockerdirectory下，這將成為容量和性能瓶頸。目前，在Docker后臺程序啟動中使用交換機改變這一位置已經(jīng)變成了可能。

容器和存儲目前存在的問題之一是，無法管理運行在獨立物理主機上的容器之間的數(shù)據(jù)共享。

容器卷可位于外部存儲上，但是目前的設計并不便于將來自一臺主機的卷用在另一臺主機上。為了解決這一問題，開始出現(xiàn)了類似ClusterHQ的 Flocker等解決方案，以解決卷的可移植性問題。目前，還有一些建議對Docker進行調(diào)整，增加一些關于對卷進行管理的功能。

雖然許多問題有望被快速解決，但是數(shù)據(jù)管理在短期內(nèi)仍將是一個棘手的問題。

編者注：本文編譯自superuser.openstack.org，作者為Nick Gerasimotos，編譯者Frank Chan。Nick Gerasimotos是FICO云服務工程高級總監(jiān)，目前正致力于研究容器中缺乏***性存儲的問題，以及如何通過Docker卷和數(shù)據(jù)容器解決這一問題。

原文鏈接：https://www.ustack.com/news/how-storage-works-in-containers/?belong=skill-share