業内docker技巧和最佳實踐的想法業内docker技巧和最佳實踐的想法

這裡有一些技巧，可能符合或可能不符合最佳實踐，回複評論将不勝感激。

•保持映像小：使用--no-install-recommends選項的apt-get，安裝真正的依賴性，而不是大的中繼資料包（如的texlive-full）。

•避免結合RUN指令，等建立更多的AUFS層？ （限為一次42，但現在是至少127）。

•可以使用Run git clone......将資料添加到一個容器到ADD位置，這緩存無效。

•使用自動化建構連結到Github上，基于Dockerfiles而不是push本地映像生成。這不僅使Dockerfile透明地提供，并提供一個連結，人們可以送出問題庫，但它也有助于確定可在Hub上的映像從Hub（從入口點），而不是本地地從任何可用獲得的基礎映像。這可以幫助避免非同步的各種可能而出現的錯誤。

不幸的是，Docker似乎用這個詞标記都是指應用到映像标簽（例如，在docker build -t imagelabel。在-t參數“tags”的形象為“imagelabel'，是以我們不必記住它的哈希）而且還使用标簽來指代一個冒号，如後應用到映像名稱的末尾的串，Ubuntu：latest中的latest。後者是作為Docker Hub的“标簽”頁籤下的“tags”的定義。對于這種标簽（我将随意稱之為一種“版本标記”來區分）的最佳做法還不清楚。

一種情況是清楚的标注特定版本。Docker的自動建構讓使用者無論是“版本标記”連結到一個分支或git的曆史标簽。在這種情況下的“分支”可以指任一個不同的GIT中分支或僅僅是一個不同的子目錄。比對一個Git标簽提供了最明确的使用docker版本标簽;提供相對靜态版本穩定連結。 （我說“相對”靜态的，因為即使我們不改變Dockerfile，如果我們重新建構Dockerfile我們可能會得到應有的較新版本包括了軟體存在的新形象，這可以很好的相對于固定的安全漏洞，而且還可能會打破先前有效環境）。

用例是不太清楚的是使用Docker，這些“版本tags”，表示相關的圖像之間的其他差異，如eddelbuettel/docker-ubuntu-r:add-r和eddelbuettel/docker-ubuntu-r:add-r-devel。為什麼這些不同tags，而不是不同的根源還不清楚，除非它是多個docker檔案在一個單一的存儲庫Github上的便利。不過，這是完全可以配置自動建構指向同一個Github上repo，而不是增加額外的完全獨立的docker hub建構的tags在同一個docker樞紐repo。

Docker語言從git術語學習借用，但它解釋這些過于誇張是相當危險的。

•運作互動式容器--rm标志，以避免之後将其删除。

•删除所有停止容器：

•清理未标記的圖像docker：

•停止并删除所有容器（包括運作容器！）

docker容器内，我們不能直接安裝docker。我們可以解決這個問題，加入一個完整的虛拟化層 - 如docker中的Vagrant運作/ VirtualBox的運作在docker。

我相信這隻是工作，如果我們運作與--privileged權限外docker的映像，如我們不能用像Shippable的伺服器這會把我們帶入一個預置的docker的容器上使用這種方法。