在上个月波特兰的 OSCON 大会上，如果有一场会议表现出对 Docker 和容器的浓厚兴趣，那一定是 Bridget Kromhout 的 Docker in Production: Reality, Not Hype 。会议只有站着的地方，迟到的人被赶出门外。它是如此受欢迎，以至于 OSCON 组织者要求 Bridget 第二天重复她的会议。
难怪。 Docker 很火，很火，很火，Bridget 带来了 DevOps 和容器化方面的深厚经验：她是 明尼阿波利斯 DevOps Days 的运维工程师、 博主 、主持人、联合组织者，以及 Arrested DevOps 播客 的联合主持人。
Bridget 的公司 DramaFever 自 2013 年 10 月以来一直在生产环境中运行 Docker，当时 Docker 网站明确警告：“不要在生产环境中使用它！” DramaFever 流式传输视频，从韩国肥皂剧开始，现在提供其他视频服务，包括 docclub.com 和 shudder.com 。它拥有来自 70 家内容提供商的 15,000 集节目，拥有 2000 万观众。在负载高峰期，该公司每秒处理来自各种不同端点的数万个请求；观众经常在节目中间切换设备。
为了确保其基础设施能够支持所有这些并提供良好的用户体验，DramaFever 将其单一的、整体的 Python 应用程序分解为微服务。该团队在 Amazon Web Services 中运行服务，使用 Python 开发主要的 DramaFever 网站，使用 Go 开发微服务。 DramaFever 依靠 Docker 提供一致的开发环境和可重复的部署。
在此过程中，Bridget 和她的团队学到了很多关于在生产中使用 Docker 的经验教训。以下是她在 OSCON 会议上分享的五个关键点：
1.当心注册表过载
当 DramaFever 开始它的容器冒险时，Docker 没有私有注册表，但无论如何他们都不愿意将 Docker 上的注册表作为“不受我们控制”的单点故障。所以 DramaFever 依赖于其 Jenkins 实例上的单个注册服务器——但是当超过 20 个左右的实例出现时，注册就会失败。现在，DramaFever 在每个将使用 Docker 的 Amazon Elastic Compute Cloud (EC2) 实例（和笔记本电脑！）上运行一个由 AWS S3 存储 支持的私有注册表容器。该解决方案不需要很多资源，并有助于解决扩展问题。
2. 建立你的基地
为确保基础 Docker 镜像是最新的，DramaFever 的运营团队每周运行一次“基础构建”。这些构建包括不经常更改的依赖项，例如 Ubuntu 包和 Python 需求文件等。其他构建从这些基础镜像开始，因此运行得更快。
3. 防止酒后推车
没有人有资格向生产环境发出“docker push”命令。这些命令仅来自 Jenkins 服务器。这条规则可以防止任何人在周围没有其他人的情况下做出不明智的推动。
4.清理！
容器和图像会占用大量磁盘空间。如果 Docker 源存储库的根已满，“可能会发生非常非常糟糕的事情，包括奇怪的磁盘损坏，”Bridget 解释道。她建议每天运行一个脚本来删除已停止的容器和标记为“无”的图像。
5.注意你的时间
S3 非常关心您的系统时钟。不幸的是，如果您的笔记本电脑进入睡眠状态， boot2docker （一个允许您在 Windows 和 MacOS 上运行 Docker 的应用程序）将会停止，这会扭曲虚拟机中的时钟。对 AWS API 的任何请求都将导致 RequestTimeTooSkewed 错误。为了解决这个问题，所有包装器脚本提供的所有 DramaFever 实用程序都包含这行代码：
boot2docker ssh sudo date --set \"$(env TZ=UTC date '+%F %H:%M:%S')\"
这是一个 已知问题 ，boot2docker 正在修复。
Bridget 的观点对于任何考虑在生产中运行 Docker 的人来说都非常有价值。您可以 查看 OSCON 会议的幻灯片 并 阅读它所基于的博客文章 。
不过，最重要的一点是，虽然 Docker 可能很棒，但它并不神奇。容器提供了一些非常酷和引人注目的优势，但与任何新技术一样，Docker 需要尽职调查以确保它能够在您的特定环境中工作并满足您的需求。
[本文由 Tori Wieldt 撰写]
