Docker是一个面向开发者的分布式应用开放平台，是现在大家都在谈论的技术之一，大家对Docker和容器技术都很有热情，但是我也注意到了一点，当我问人们是否在生产中使用Docker时，热情开始减退，答案往往是"还没有"。我想和大家分享一下我们与Docker的一些经历。最好的方法也许是解释一下我们现有的环境是什么样子的，以及我们搬到Docker的潜在动机是什么。我一直坚信自动化部署和配置管理，尤其是在大规模支持云服务方面。我以前在BladeLogic工作，他是devops领域的早期先驱，对现有的配置管理工具如Chef和Puppet非常熟悉。在Fuze中，我们对Chef进行了大量投资，以实现虚拟化环境的自动配置和更新。devops集中化团队使用Chef配方来构建开发人员，QA和生产环境。同样的方法用于将应用程序更新从开发转移到生产环境。这一切对我们来说都相当好，但是随着时间的推移，一些挑战也出现了。配置管理的挑战主要的问题是，构建厨师食谱既麻烦又耗时。Devops需要大量的知识才能有效，包括Ruby、基础设施、应用程序、数据存储以及不同平台组件之间的所有相互依赖关系。另一方面，开发人员在不涉及devops的情况下无法完成他们想做的事情，并且经常感到受到限制。举个例子，我们遇到的一个实际问题是，建立一个完整的堆栈开发环境（包括基本操作系统安装和chef引导的个性化安装）可能需要长达一个小时的时间，这简直是疯狂处理自动化流程所需的时间。通常，我们发现创建/更新/修改厨师配方的需求是应用程序部署管道中的瓶颈。Docker的承诺是它能解决很多这样的问题。Docker在很多方面做得很好。它有很多开发人员友好的工具来帮助应用程序打包和容器的创建。它比Chef简单得多。按照Docker的原意使用Docker，可以重新划定开发和操作之间的界限。我们的想法是将继续使用Chef，但在管理底层基础设施方面的作用要有限得多。大多数更新将转移到Docker。这一举动将把应用程序更新控制权转移回开发组织，现有的devops团队将管理底层基础设施，并为这些开发者提供Docker服务。我们追求的主要好处是应用程序部署管道速度的提高，使我们能够比以前更快地获得更新和市场变化。我们的学习曲线在实现Docker来管理我们的应用程序更新生命周期的过程中，我们很快发现有一些重要的先决条件需要考虑并落实到位，其中一些重要的前提条件包括发现和配置服务，以及一个机密服务。我们使用consur进行服务发现和配置。我们使用consur的目的是将所有特定于环境的设置具体化，比如数据库连接字符串，当您从dev转到QA再到生产时，这些设置会发生变化。然后您从Docker容器中删除这些设置，这些值是在运行时从consur发现的。我们使用Vault存储密码、加密密钥等的机密也采用了类似的策略。Vault中有很多有趣的安全功能，有助于管理我们环境中的机密。这些系统允许相同的Docker容器在不同的环境之间移动，允许快速更新周期。在开发环境和质量保证环境中使用Docker有着明显且无可争议的好处。开发人员喜欢工具和打包工作的速度。不过需要注意的是，通过internet上的存储库找到各种事物的预构建Docker容器越来越容易了。开发人员可以收集Docker文件以快速组装服务。但是这些Docker文件是从哪里来的呢？它们内部运行的是什么代码？它们是从可靠来源获得的吗？我们发现，我们需要确保在审查添加到我们平台的代码方面仍然有一个强大的治理过程，即使它是通过Docker容器传入的。容器中的代码并不能改变我们希望确保不包含任何恶意代码的事实，或者我们对附带的软件许可证没问题。但除此之外，我们遇到的最大障碍是稳定性。Docker是一项年轻的技术，平台的核心部分仍在发生许多变化。我们经历过许多挂起的容器，尤其是网络方面的问题。根据我与其他CTO的讨论，我们的经验似乎并不独特Docker在开发和QA中，而不是在生产环境中，我们无法实现最初激励我们的应用程序更新速度的提高。唯一可以安全dockerize的生产环境是您拥有一组真正无状态群集节点的环境，其中一个节点的故障是非事件的每天都会发生这样的事情是可以的。我们对Docker的结论是，它还没有准备好投入生产。也就是说，我们仍然非常看好这项技术，只是认为它需要更多的时间来稳定和解决所有的生产问题。我们正在继续为环境的码头化做准备，我认为这是不可避免的。但是我们还没准备好扣动扳机。