有限的工具和库 虽然Docker 有一个四个月前发布的稳定版本，围绕它的一些工具仍然不稳定。采用Docker生态圈中的大部分工具意味着需要投入更多的精力。为了使用最新的功能、修复bug，你团队中需要有人熬夜加班对这些功能，频繁的进行一些修改.也就是说，我们很高兴有一些Docker 周边的工具在开发，而且很期待能够有一个工具在其中脱颖而出。我们对etcd,fleet, kubernetes比较看好。 战胜困难接下来根据我们的经验，更深入的讲我们讲我们遇到的问题和我们的解决方法。问题列表主要来自我们Ironworker的首席开发兼工程运营总监Roman Kononov和一直在调试和规范化我们Docker操作的Sam Ward。
Debug时的一个异常 说明一下，当我们遇到和Docker相关或者其它系统相关的问题，我们可以自动的重新执行任务，对用户没有任何影响（重试是平台的内置功能）。 删除操作时间长 起初删除容器时间长，需要太多的磁盘I/O操作。这导致我们的系统速度明显变慢，形成了瓶颈。我们不得不增加可用的内核数目，而这个数量远远超出我们所需的。 快速删除Docker容器的解决方案 通过研究使用devicemapper（一个Docker的文件系统驱动），我们发现设置一个选项有作用`--storage-optdm.blkdiscard=false`，这个选项告诉Docker 删除容器时跳过花费时间长的磁盘操作,大大加速了容器的关闭过程。当修改好删除脚本后，这个问题就没了。 卷无法卸载 由于Docker没有可靠地卸载卷，容器不能正确地停止。这导致容器永远在运行，即使已经完成了任务。解决办法就是显示地调用用户自己写得一些列脚本来卸载卷，删除文件夹。幸运的时，这个问题是之前我们使用Docker v0.7.6版本时遇到的，当Docker v0.9.0解决这个问题后我们就删除了那些冗长的脚本。 内存限制开关 Docker其中的一个发布的版本中突然新增了内存限制选项，删除了LXC中的选项。其结果是一些工作进程到达内存界限，然后了整体不响应。这弄得我们措手不及，因为即使使用了它不支持的设置，Docker也没有出错。解决方法很简单，即在Docker内部设置内存限制，但是这种变化让我们措手不及 未来计划 正如你所看到的，我们对Docker投入非常的多，我们在接下得每天会继续投入。除了用它来隔离用户在IronWorker中运行的代码，我们也准备在其他的一些领域使用它。 这些领域包括： IronWorker 后台 除了使用Docker作为任务的容器，我们也在使用它来管理每个服务器上运行的用来管理和启动任务的进称。每一进程着的主要任务是从队列中拿一个任务，把它放到合适的Docker容器中，运行，监测，运行完后删除环境。有趣的是同一台机器上我们有容器化的代码来管理其它容器。把我们所有的基础设施环境放到Docker的容器中让我们在CoreOS上的运行相当容易。 IronWorker, IronMQ,以及 IronCache APIs 我们和其他的ops团队一样，没有人喜欢部署。能够把我们的所有的服务打包Docker容器中，然后简单、确定地部署，我们非常地激动。不用再配置服务器。我们需要的就只是能够运行Dokcer容器的服务器。我们正在替换我们的服务器搭建，使用Docker容器在服务器上为我们发布的产品搭建环境。变得的灵活、简单，有更可靠的协议栈。 生成和加载程序 我们也在用Docker容器在IronWorker中生成和加载程序。一个显著的进步是为用户改进了，大规模、特定任务负载和工作流的创建、上传、运行任务的过程。还有一个好处是用户可以在本地测试程序，而测试环境和我们的生产服务一致。 企业内部部署版 使用Docker作为主要分发方法，IronMQ企业内部部署版简化了我们的分发工作，并且提供了一个简单通用的在几乎任何云环境中都能部署的方法。就像我们在共有云上运行的服务，客户需要的就是可以运行Docker容器的服务器，同时他们可以相对容易的获得在测试或生产环境中运行的多台服务器的云服务。 原文链接：Docker in Production — What We’ve Learned Launching Over 300 Million Containers（编译/王晓冉 审校/周小璐） |
