业内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的容器上使用这种方法。