這裡用個不太恰當的比方來說明。
兩種方式構建映象的主要步驟：
1.從容器構建映象(以下簡稱容器映象)
2.使用dockerfile構建映象(以下簡稱dockerfile映象)
兩種構建方式的區別：
1.容器映象的構建者可以任意修改容器的檔案系統後進行發布，這種修改對於映象使用者來說是不透明的，映象構建者一般也不會將對容器檔案系統的每一步修改，記錄進文件中，供映象使用者參考。
2.容器映象不能(更準確地說是不建議)通過修改，生成新的容器映象。
從映象執行容器，實際上是在映象頂部上加了一層可寫層，所有對容器檔案系統的修改，都在這一層中進行，不影響已經存在的層。比如在容器中刪除乙個1g的檔案，從使用者的角度看，容器中該檔案已經沒有了，但從檔案系統的角度看，檔案其實還在，只不過在頂層中標記該檔案已被刪除，當然這個標記為已刪除的檔案還會占用映象空間。從容器構建映象，實際上是把容器的頂層固化到映象中。
也就是說， 對容器映象進行修改後，生成新的容器映象，會多一層，而且映象的體積只會增大，不會減小。長此以往，映象將變得越來越臃腫。docker提供的 export 和 import 命令可以一定程度上處理該問題，但也並不是沒有缺點。
3.容器映象依賴的父映象變化時，容器映象必須進行重新構建。如果沒有編寫自動化構建指令碼，而是手工構建的，那麼又要重新修改容器的檔案系統，再進行構建，這些重複勞動其實是沒有價值的。
4.dockerfile映象是完全透明的，所有用於構建映象的指令都可以通過dockerfile看到。甚至你還可以遞迴找到本映象的任何父映象的構建指令。也就是說，你可以完全了解乙個映象是如何從零開始，通過一條條指令構建出來的。
5.dockerfile映象需要修改時，可以通過修改dockerfile中的指令，再重新構建生成，沒有任何問題。
6.dockerfile可以在github等原始碼管理**上進行託管，dockerhub自動關聯原始碼進行構建。當你的dockerfile變動，或者依賴的父映象變動，都會觸發映象的自動構建，非常方便。
** 不管是官方還是我個人，都推薦使用第二種方式構建映象。**
關於dockerfile裡面指令的詳細說明，這裡就不一一列出了，大家可以參考官方文件，或關注我之後的文章，當然網上也是一搜一大堆。
關於正則裡面的幾個不解的情況！
1.匹配包括換行符的所有字元 根據手冊上寫的 只能匹配出 n以外的所有的字元,但是用 n 或者 n.都是匹配不出任何字元來著,更是失去了原本匹配任何字元的功能,修改為 s s w w 或者 使用匹配 模式 s 最新手冊中查詢到.在代表實際的.不具有匹配功能 2.關於正則 不匹配連續字串的情況 如果說...
Python操作docker裡面的redis
使用操作命令借助subprocess模組進行操作 encoding utf 8 import subprocess defcmd command subp subprocess.popen command,shell true stdout subprocess.pipe,stderr subpro...
docker裡面的容器資料卷
講一下容器的資料卷是幹什麼的 就是為了實現主機和容器資料的共享 我們剛開始一定要先啟動docker服務 啟動docker服務 systemctl start docker建立容器資料卷 docker run it v nihaoshijie nihaoshijiecontainer centos b...