Docker官方論壇中回複最多的一個文章“在資料容器内更新資料”Docker官方論壇中回複最多的一個文章“在資料容器内更新資料”

matlehmann

我有一個含資料的容器，它有一個卷（比如在/var/data）中的持久性資料。該容器包含持久性資料對另一個容器的軟體。

對于該軟體的新版本，需要更新所述永久資料（結構或布局改變等）。其結果是，我想與在相同的位置已更新的資料的另一資料容器（在/var/data）和仍保留舊資料容器與它的資料不變。

這樣一來，我可以用舊的資料容器與舊版本的軟體，萬一出了差錯。

但是，我怎麼能做到這一點？以實作所期望的結果所需要的步驟對我來說是不明顯的。

我可以運作一個指令來更新容器像docker run -i -t --name temp --volumes-from data -v /upgraded image /upgrade_script.sh

但後來，我怎麼将更新的資料恢複到原來的位置而沒有覆寫舊的資料？如果我運作docker run -i -t --volumes-from temp image cp /upgraded /var/data，它将覆寫我的舊資料。我必須使用主機安裝的卷為更新的資料，或者是有一些更好的解決方案？

sam

隻是猜測，因為這裡一般我更喜歡使用直主機安裝卷和我苦苦尋找資料容器的效用。

但是......你能不能送出你的資料容器，然後儲存映像等？

sven

哦，也請考慮使用docker commit快照容器SAM的建議迷死人了

keeb

我實際使用的資料容器，如UNIX管道;我覺得他們适合更自然在範式

docker run -name some_pipe_storage some_container_which_generates_data

docker run --volumes-from some_pipe_storage something_that_operates_on_data

文法，相當繁瑣。非常強大卻比較原始。

有一些有趣的工作，關于加入卷的管理工具docker是怎麼回事 - 我認為他們是前往1.4，我會做一些調查。 （有将是一個docker卷清單和操縱的東西）

我可能會做一個backup_data卷的容器中，然後運作一個資料遷移的形象，我想運作連接配接到資料和backup_data - 它可能做的第一件事是複制了從資料到backup_data，然後它會做的資料遷移。

然後你就可以運作舊的和新的，連接配接到每個各自databackend（與可能附着隻讀的備份？）

這樣做，如果你使用的主機安裝的應幾乎是一樣的，無論是直接或通過資料容器的風格代表。

您的建議是我的第一個想法行，但它并不符合我的預期，因為該過程後，遷移資料和原始資料将根據不同的路徑，我看不出有什麼辦法改變這種狀況，因為非主機卷不能被重新安裝到不同的路徑。從一個資料容器的體積的路徑是靜态的 - 即使對于由“--volumes-from”繼承卷容器。

這是主機體積不同，因為我可以在每個docker運作調用改變這些的挂載位置。

我認為這些卷管理工具，你說說是非常必要的。對于我來說，這個資料容器docker成語感覺更像是一個變通。

請問您在闡述“docker commit迷死人了”，因為我看不到它，然而。至少在用例在手。據我所知，一個docker送出給我，其中包含一個容器的目前狀态的新形象。這樣将包括除持久資料我感興趣的所有OS資料。

哦crud。你說得對，卷路徑是目前靜态的。是以你需要一個步驟

1.你有在/資料中的現有的資料容器

2.遷移到位于/遷移的臨時資料容器（如你有原始安裝）

3./遷移資料遷移到安裝在新更新的資料容器/資料（第二遷移映像就不需要原來的資料容量裝

@ cpuguy83也許能告訴你更多關于新工具的微笑

WRT docker commit - 當你commit，你是不是在一個單一的包含圖像層的一切，你正在做一個新的圖像層，包含所有容器中所做的更改（與圖像容器啟動時使用）。

是以，如果你使用的容器，而不是卷的持久性資料和卷掉之類的東西日志，你可以使用docker承諾快照/備份隻是你的持久性資料 - 和docker的出口可能讓你存儲這些層。

cpuguy83

是啊，我不會信賴“commit”，因為你将被限制在127送出的，除非你拼合映像出來。

@matlehmann看到github.com/cpuguy83/docker-volumes

這離完美的解決方案還遠着呢，但在此期間工作相當不錯

@Sven感謝您的答複，并了解更多資訊。我還是不明白第3步的“/遷移資料遷移到安裝在/資料的新更新的資料容器（第二次遷移映像就不需要原來的資料容量裝”，因為它目前是（與docker1.2和無特殊卷指令），我不看我怎麼可以有一個容器與另一個容器體積 - 他們的一部分安裝的，其中一部分沒有安裝就我所看到的，它要麼全有或全無，要麼以"--volumes-from other_container"或沒有。是以，如果遷移容器from步驟2具有原始資料裝入，該容器在步驟3它已安裝，也是以在複制操作從 /mifrated到/data将覆寫原始資料。還是我失去了一些東西？

有關“commit”指令謝謝您的提示，我需要思考這個多一點準備。

@keeb這是一個很好的模式，但據我看到的，它并沒有解決這個問題，我在說什麼。所有這些“管道”容器仍然會以“some_pipe_storage”的體積而不能建立一個不同的容器中，在一個給定的路徑不同的資料，而不會覆寫原有的資料。但是，也許我想念你的觀點？

嗯，讓我們看看，如果我能作出這樣的解釋是一個例子：

假設有人已經創造了一些Docker 映像，webappv10，webappv11，webapp_migratorv10_to_v11。

最初，你會已經運作的基于1.0系統

docker run -v /data --name datav10 busybox true

docker run -p 80:80 --volumes-from datav10 --name webv10 webappv10

然後更新，要求你的資料給我更新了，你會做第2步（正如你指出，我們不能有兩個卷在相同目錄）

docker run -v /migration --name datav10-to-v11 busybox true

docker run --volumes-from datav10-to-v11 --volumes-from datav10 --name migration webapp_migratorv10_to_v11

然後步驟3，對複制的資料遷移到一個新的資料容器，在/資料目錄中的資料，準備使用

docker run -v /data --volumes-from datav10-to-v11 --name datav11 busybox cp -r /migration /data

然後運作1.1版Web應用程式

docker run -p 80:80 --volumes-from datav11 --name webv11 webappv11

而額外的信用，你最好腳本化這一切。

更新到datav10到V11卷容器一步增加是由于下面的讨論

@sven 再次感謝您詳細的解答。我很欣賞你的思想和時間。

但是，您勾勒的程式不起作用。它叫裝有“-v”卷推翻一個體積繼承“"--volumes-from”同一路徑的假設。我剛再次測試它，以確定，但這種情況并非如此。這就是為什麼docker run -v /data --volumes-from migration --name datav11 busybox cp -r /migration /data将覆寫我的原始資料的容器datav10。

它有你喜歡一個資料容器在一個簡單磁碟區一個特别的原因（也就是更容易通過感覺意會/處理）

我很困惑。精心制作的步驟，以便有永不2卷從包含/資料迪爾斯語句。我們使用遷移一個緩沖區，然後我們将其複制到新的資料V11容器。

@sam - 有一個綁定安裝的量和體積容器之間這麼一點概念上的差異 - 你還在做同樣的3個步驟 - 對我來說最大的差別是，綁定坐騎隻能在本地，并且假設你有磁盤空間為它（不是我做的），而體積容器方法假定您Docker ，資料分區是大到足以運作Docker 的容器，和作品一樣的本地遠端。

如果你改變了docker run -v /data ... lines to docker run -v /local/data:/data ..., 那麼你使用bind mounts綁定安裝，代表。

@SAM我現在切換到使用bind-mounted 綁定安裝的（或任何官方用語是"-v /host:/container") 卷，而不是使用資料容器，因為在這個線程中列出的缺點。我開始使用資料容器，因為成語的使用和推薦的所有在網際網路上，似乎是“官方方式”。

@sven

•"datav10" has ◦"/data" (via -v /data)

•"migration" has ◦"/data" (via --volumes from datav10)

◦"/migration" (via `-v /migration')

•"datav11" has ◦"/data" (via -v /data)

◦"/migration" (via --volumes from migration)

◦"/data" (via --volumes-from migration)

是以，我們有“/data”容器“datav11”兩卷定義 - 對我來說它看起來就像從--volumes-from 勝利之一。

@sven我想我隻是在努力找出你将存儲在AUFS資料的原因，這似乎是一種錯誤的檔案系統用于這個問題。 BTRFS将是确定的，但似乎aufs的日志檔案，一個奇怪的選擇，Postgres資料庫用的等等。我誤解資料容器的機制？

@matlehmann我們用“卷”廣泛。

•我們店外容器的主機安裝卷，便于旋轉和持久性的所有日志。 （這裡是另一種選擇是将流出來的容器，但機制是不平凡的，想想說的NGINX的容器，你用日志呢？）

•我們存儲一些配置一個安裝GlusterFS卷上，是以我們能吸收的東西橫跨農場

@sven這将是另一個線程的話題：我真的很希望聽到你的GlusterFS設定。有沒有準備好使用可用的映像，可以作為GlusterFS内像一個代表卷或你怎麼做呢？

@supermathie将是最适合我們的GlusterFS設定的詳細資訊，但它是在一個非常傳統的方式，所有的設定，我們不使用受信任的docker容器上電Gluster的。

OH（*＆^，你說得對。

我想我是如此聰明删除一步。

你需要把/遷移檔案夾到自己的資料容器，這樣就可以避免你在最後一步注意的問題。

我已經更新一步的例子步驟，以反映這一

是的，有一些東西WRT檔案系統待解決 - 我docker的大多是BTRFS運作。

我認為，使用綁定，安裝工程量太 - 但我仍然會做連結到它們，然後使用相同的過程，以上資料體積的容器。

@sven謝謝。我沒有嘗試這個，但它是有道理的。這是一個尴尬的瘋狂雞起舞，但它可能工作...翹首等待的卷指令。

是的，我專注在笨拙的雞 - 期待與這些版本，和烤雞腿來饞嘴