三个生产环境中使用Docker的案例

在2017年1月17日的Helsinki的首届Docker线下见面会中，Solita、Zalando和Pipedrive公司分别介绍了Docker在生产环境中的实践，包括案例及相应的输入输出。同时，也介绍了Docker在生产环境中的优点、缺点和痛点。

Solita的使用场景

首先，Solita公司的Heikki Simperi介绍了他们公司如何利用Docker来处理多种app和芬兰国家铁路管理系统（VR）的关系，以及他们在使用Docker过程中遇到的问题。

Solita在Docker上运行了多种app，包括火车司机导航系统、通知系统和交通控制app。Heikki特别提到在铁路管理系统中减少系统停机维护时间的重要性。他的原话是：“anything over a 3-5 min downtime causes delays for trains, but nobody dies.”

他们在使用Docker过程中遇到的大部分问题大致包含以下几个方面：构建镜像、创建私有仓库、移除或者启动容器以及app中存在的bug。总的来说，他们使用Docker过程中一直是稳定的，并且是零停机维护。

他们之前遇到的问题在升级Docker版本之后或减少或解决。他们正期待Docker1.12稳定版本在RedHat官方渠道上的发布。

Zalando的使用场景

随后，Rami Rantala介绍了Zalando公司的各个团队和项目中是如何使用Docker用于部署生产系统。

在Zalando Helsinki的办公地，这里有超过100多名工作人员和多个团队，他们负责不同的生产系统、相关探索研究、持续交付等工作，采用敏捷开发的方式开发他们的平台。

每个自主团队均有独立的AWS账号，而且无视了不可以在生产环境运行Docker的建议。据Rami介绍，在Zalando内，任何运行在AWS上的程序都采用了Docker运行，Docker被认为是唯一允许用于部署生产环境的工具。他们同样有独立的Docker资源库（Pierone），他们自主的Docker基础镜像和每个实例运行一个全栈容器。

有很多领域还存在改进的空间，包括如下内容：部署太慢，他们丢失了Docker中层通信的优势，每个实例运行一个容器的代价很高，导致存在数千个实例；另一个问题在于Docker经常拖垮Pierone。

他们目前正调研使用Kubernetes，它看起来可以降低成本，对AWS账号和基础设施要求更低，更高效的利用容器间通信和快速简单的部署。他们在技术周进行了技术演练，并计划在第二季度用于生产环境灰度发布。

Pipedrive的使用场景

最后，Renno Reiurm讨论了Pipedrive公司在使用Docker中的收获与痛点。这是家致力于帮助小微企业控制复杂销售流程的公司，成立于2010年，目前拥有30000家付费客户，并有200多名雇员和Tallinn、Tartu和New York有三处办公地。

Pipedrive采用Docker并感受到了随着业务增长，Chef带来的各种问题。由于很少去编写配置单，使得容易遗忘Chef的工作原理，而学习一门新的语言和工具又存在一个准入门槛。

他们最初的Docker平台是在Vagrant虚机环境中，后来他们迁移到定制化docker宿主机，最近迁移到了Docker4Mac。

Docker构建的第一个版本使用的是Codeship Docker CI beta版本，并且首次使用了Tutum（Docker Cloud）作为编排服务。

这次测试使用有很多缺点，包括Codeship的CI处理速度很慢，Docker构建本身就需要15分钟。此外，Docker Tutum集群的部署需要10分钟。有时候，他们慢得都不能确认它是否还在工作。他们还遇到了稳定性的问题，包括‘‘数据丢失’’和‘‘服务宕机’’。

由于需要提高CI过程的速度，并且提高Docker基础设施的可靠性，Docker基础设施2.0诞生了。

在运行Docker时，管道驱动的缺点包括：构建、测试和部署容器所需的时间；消费者只需要连接到健康服务；日常维护Jenkins工作，以前容器处理10,000个连接和连续的高负载。

使用Docker的好处包括：应用程序的演进--他们变得足够通用，可以再多个地区和环境中运行；从想法到上线可以从两周减少到一天；服务器与服务之间的管理是异步的。

Pipedirve容器采用持续增长：从去年10月以来，有70家公司的Docker服务，90个Docker容器镜像，500个容器运行，3200个容器部署。Pipedrive上每天有30个容器部署，1个新增容器产生。

Renno对Docker化提出的建议包括：小心对待操作系统、阅读GitHub上的问题、阅读源码、保持最新的数据和性能测试。

优点、缺点和痛点

最后，Jari Kolehmainen的想法引发了关于Docker的演讲：优点、缺点和痛点，这让人想到了如何在生产环节中使用Docker时避免“缺点和痛点”。其中一种方法是使用Kontena容器和微服务平台——就像它在任何云上工作一样，易于设置和使用。

Jari提到，在生产环境中使用Docker的第一步是“像一个过山车，有起有伏”，但它的好处超过了这个，而“最终你将会取得巨大的成功”。

对于那些还没有在生产环境中运行Docker的人来说，也许您正在测试环境中运行它，那么第一步就是选择正确的路径，这对于向生产转移是至关重要的。通常情况下，这条路是预先确定的，无论是项目限制（你必须使用数据中心或一些云服务等），但如果你可以自由选择，那么你就有三个主要的选择：DIY，租一个真正的云服务，或者你可以使用一个预制的平台，比如Kontena。

在DIY模式中，你有一个引擎，比如Docker引擎，你试着调整并与你的团队或你自己建立真正的“汽车”。

一般来说，这听起来像是一件有趣的事情，你可以控制所有的事情，而且它是有效的。花了一些时间在实际的引擎上调优后，然后你就可以把所有的东西都放在生产环境上，有时候你可能会得到一辆有引擎的汽车，有很多管道胶带、空调控制系统，但是你永远不知道它什么时候会坏。

Jari的建议是“不要做”。在生产环境中，如果你是运行Docker的新手，DIY选项可能是一个有用的学习工具，但最好不要自己动手，因为你很可能只希望通过DIY过程完成自己的工作。

云租赁服务包括AWS、Azure、Kubernetes等提供商提供的一切服务，所有这些都是不错的选择。就像坐出租车一样，你只需要支付一笔钱，你就可以让整个系统准备好，而不需要维护任何东西。这可能比其他的方案更适合于个人使用。

但是，如果您的项目需要在一个数据中心或者某个没有这些选项的地方运行，那么第三个选项很可能是正确的。

推荐的平台包括：Docker集群（新）、Kubernetes、Kontena和DCOS。当你不想自己动手的时候，所有这些都是不错的选择。你可以选择其中一种或另一种，但不推荐DIY。

像Kontena这样的平台，就像“预先准备完毕，做好开车的准备”，这让你可以把注意力集中在你的应用上，而不是在汽车的外壳上。其中包括你需要完成日常任务的大部分功能以及不同的焦点，比如Kontena专注于易用性和易于维护，其他服务可能会关注可伸缩性。

作为一个DevOps的人，这些特性意味着需要更少的维护。因为平台上有“所有的电池”和“战斗测试”，这在生产环境中都很重要。

Docker引擎

即使你使用了之前提到的一个平台，并且安装了实际的LINUX发行版，安装了docker引擎，并在上面安装了平台，还是有一些事情需要去考虑。

当您第一次重新安装Docker引擎时，您可以使用Red Hat、Ubuntu或这些发行版中的任何一个。通常来说，引擎的默认设置不适合实际的生产环境使用。您可以从Google上查看解决方案，并调整设置，以便引擎能够处理您在生产环境中需要的实际负载。Docker引擎只是运行容器，它没有配备完善，所以您需要配置日志管理、容器管理、卷等相关任务。

如果你不想改变默认的设置，Jari强烈建议你使用一个专为容器做的发行版。一个不错的选择是Core OS，它叫做容器Linux；Red Hat有自己的原子发行平台；SUSE也有自己定制的容器配置。通常，这些类型的发行版会有更好的默认值，这些默认值实际上可能在生产环境中起作用。

您必须检查的一个关键问题是图形驱动程序，如果您使用的是最近的内核版本，您可以使用Overlay2。这是“今天的热门话题”，但随着下一个内核版本的发布，这种情况可能会有所改变。它是最快的选择，你不应该使用它来解决很多问题，大多数发行版都是Overlay1。

默认的Overlay有一些缺点，但是您仍然可以在生产环境中使用它。如果你使用的是Ubuntu那么你可能会切换到Aufs，当你为核安装了额外的软件包后，可以切换到它，它也可以和Overlay2一样工作。

“最痛点”的部分是设备映射，Jari认为这仍然是来源于Red Hat且通常会引起痛点的地方。如果您知道如何配置设备映射的内部关系，那么可以使用设备映射器。

Docker引擎有一个很酷的功能叫做“插件”。插件可以用来提供Overlay网络，并为引擎提供容量存储，但是有一个缺点：你不能在一个容器中运行这些插件，尽管他们说你可以，实际上你不能。所以尽量避免它。

从Docker版本1.13开始，插件架构 v0.2 被引入进来，它应该可以解决大部分的问题。

一个好的生产规则是保持所有的东西都是最新的。这包括Docker引擎，以及内核；这不仅是针对bug，还包括安全性。

CI/CD 管道

当你在生产环境中运行容器或微服务时，通常会有一大堆你想要处理的服务，如果没有一个很好的管道，“你会发疯的”。将这些容器从不同的阶段转移到生产时，必须考虑许多步骤和许多事情，如果不将该流程自动化，那么将会非常困难。

基本上有三个阶段：构建阶段、测试阶段和部署阶段。

在构建阶段，您不应该在自己的机器上构建或运行这些映像。相反，应该有一个CI系统来构建、测试并最终将它们部署到正确的环境中。

一些有用的建议：您应该将构建到测试，再到部署的所有内容（这不是容器特定的）放入脚本中。此外，拥有的配置和脚本都应该由版本控制管理。如果您没有这样做，那么在生产环境中运行时，就会遇到麻烦。最后，不要将关键信息放入配置文件中;这不是个好实践。

您可以使用一个支持存储关键信息的平台，因为它提供了在不同的环境和不同的部署之间处理它们的方法。

一些优秀的管道工具

Jari的个人隐私工具：drone——它很好用，因为它迫使你认为一切都是一个容器。

Drone内部的整个管道都是以容器形态运行的。如果你使用了像Travis这样的工具，它是非常相似的，但是你可以在自己的数据中心里运行它。Jenkins是另一个众所周知的选择，但它更复杂一些，不是为容器设计的，但可以使用它。最后一个选择是Gitlab CI--尽管Jari没有使用这个工具的个人经验，但他已经听到了很多关于它的成功案例。

在这个管道示例中，我们构建自己的云服务时，senor开发人员正在尝试以类似于Kontena的方式使用管道。

开发人员正在打包下一件重要的事情，当他将变更推送到GitHub时，drone就会集成在那里，获取we hook，触发构建，在容器内的管道内运行测试。如果一切正常，它将把实际的Docker镜像推送到内部注册中心。最后，它将触发对Kontena的部署，取决于它是否是一个发布版本等等。通常情况下，它可能只需要几分钟的时间，就可以从Git-push部署到生产环境中。Kontena平台在此过程中充当中介，它将负责所有的滚动部署，并处理负载均衡器的配置。因此，您不需要手动地将每个部件组装起来。

安全

在生产中使用容器的前几次，您可能会很高兴有一些在生产中运行的东西，您可能不会真正考虑安全性以及应该如何处理它。但是，应该从测试和预发环境中考虑这一点。

审计跟踪

（如在Kontena中发现的）允许您跟踪系统的变更以及它们是由谁创建的。

安全补丁

值得推荐作为容器本地操作系统使用，例如，CoreOS将自动更新主机，并在更新完成时重新启动。您还可以使用配置管理工具，如Chef、Ansible或Puppet来处理安全补丁。您应该为镜像扫描服务投入一些时间，帮助识别您的Docker映像中的安全问题。例如，Docker Hub和CoreOS的Quay.io 均提供了这种功能。

一些平台提供网络安全功能（如Kontena做的）。它们可能会加密主机之间或数据中心之间的所有通信。一些平台包括的额外安全措施包括:创建网络段、定义策略，以及作为最后的手段：配置防火墙。

为混乱做准备

混乱是生活的一个真实写照，包括宿主机故障，引擎故障，容器失败，应用程序崩溃。为“混乱可控”做好准备，意味着当事情发生的时候，这将不是什么大不了的事情。

在计划生产环境时，强烈建议您这样做，这样您就可以在任何时候“杀死”任何主机、任何节点，这样至少一个主机就可以被完全的暴力所强制，而其他服务一切都还正常。另一个建议是，如果您使用前面提到的任何一个平台，请信任调度程序，使用集群数据库，并尽可能将状态开放，以尽可能流畅的运行Docker。

你可以从Jari的演讲中看到幻灯片，地址：http://dwz.cn/66bOeJ。

关于 Kontena

Kontena公司是Kontena的创始人，它是一个开源的、开发人员友好的容器和微服务平台。Kontena 通过简化在任何基础设施上的Docker化应用程序，包括在私有云、公有云或混合云，以达到最大化开发人员幸福的目的。它为任何规模的公司提供了完整的解决方案。Kontena于2015年3月成立，被认为是今年第8届年度“黑天鹅”最佳新开源项目之一。更多信息，请访问：www.kontena.io。

原文来自:Docker

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com