优维科技EASYOPS | 只有考虑这些关键因素，才能跟上Docker为代表的容器时代！

好像一夜之间好多组织机构都突然投靠Docker了，毕竟现在这个技术就是那么火爆。如果你现在才想着跟上Docker大势？先恭喜你，拥抱了新IT时代的技术变革，其次确实你有很多细节要考虑。我们综合来看看Docker部署方面的宗师级经验，探讨下容器技术现阶段的实施落地，也顺手把不可变部署和部署工具的改造计划搞懂。 - Tomer Ben David

容器时代

你为什么会想到用Docker？

这个有很多方面的思考。在LivePerson的评估过程中我就很清楚，倘若对外分享一些对Docker方案的见解，一定能给很多人以启示。这样一种基础架构发生巨大变化的方式，对开发人员，CI，CD，配置，监控，打包，安全以及软件开发和交付的几乎任何方面都有很大的影响。所以在这改造发生之前，负责人就应该先去仔仔细细的趟一遍雷，总结好最佳实践，形成框架项目和模板，这才有助于在转换新项目时对解决方案的侧重执行。将其与现有部署工具集成到现有服务中的挑战不容小觑。所以，如果你还在踌躇不动，甚至刚开始趟雷，我则非常希望你看到接下来的系列文字，因为它很有可能启示你接下来的步骤。

当下，Docker和kubernetes是容器化部署的主流技术，正是我们评估和执行过的技术。但是场景等有一些差异，但对于任何容器类的解决方案来说，许多见解具备通用性。好了，我们开始深入流程细节。

回顾你青睐容器的原因

这当然最好是从必要动机开始。不过要是你已经为部署使用了配置工具，而且很满意，那就该问清楚自己：为什么要替换现有方式而采用基于容器化部署的方法？

这样吧，我先给你总结两个理由：

1. 你是一个开发者，推崇不变性和功能编排的概念。这种情况下，容器允许你把这些思维糅合到部署文件中，即容器化部署允许你以更容易和有意思的方式得到不可变部署。而且容器如果设置只读，更接近纯部署概念，该换换，修改都省了。

2. 采用基于容器化的部署方式可以让你更接近持续部署的实现。在容器火起来之前的好书《持续交付：通过构建，测试和部署自动化发布可靠的软件》里，作者眼中成功的持续部署就有许多组件在基于容器的部署里出现过，这包括：自动化构建的所有方面，部署管道，开发人员测试者之间的协同操作，管理基础架构，依赖关系，审计等。这里面就有许多都是Docker基础设施或周边项目的一部分。

不过，任何技术都不存在所谓的多面完美。你用容器，就得试着接受一些容器技术在某个阶段难以克服的短板。可能有人认为用了Docker牌神油就能提高服务器性能，真的吗？我举个栗子，如果一个容器表现不好（差的意思），那么这个容器就会耗着你的process，然后死循环。在这种不太多见的情况下，由于虚拟机们耗了大量物理机器内存，导致“Docker牌神油万能论”的高调破产。不过，如果此时如果跑的是更轻量级的进程，在资源共享上表现就会更好一些，也能减少一些不必要的尴尬。

是否在准备开展不可变部署？

综合上文，我们现在有了采取容器部署的动机。那么现在我们来检查下你是否已准备好搬家到容器。这里得先透彻若干问题以评估准备情况：

1. 你是从头开始安装应用程序的吗？生产环境中呢？

2. 如果没有，你是否已应用部署到虚拟机，或者更好的云虚拟机？

3. 部署/生产团队在不联系相关团队的情况下能添加你的应用新实例吗？

4. 如果有人要重启你的应用，它会照常运行吗（这点通常没有问题）？

如果你针对上面的问题答过“是”，那么开始容器化部署就没太大阻力；反之就不是，而你那时应首先查看更新你的部署，或者在准备基于容器做部署时就要做更多的工作。

这里注意下，如果你打算用容器化部署来更改环境，那这个方向/想法本身就不靠谱了。

唠叨一句，你对现有工具有什么想法或计划？

大多数情况下，如果你已经用了像puppet，rpm等部署工具…

这很好，意味着你现有的部署很接近完全自动化（或已经实现完全自动化）。也意味着你可以做出选择。转储它们并使用单个容器包构建器（Dockerfile），或者继续使用rpm脚本和Docker脚本，以及puppet脚本。

个人建议，如果你可以使用单一脚本语言，那把整件事简单化。如果已经有了很多基础架构，rpm的去留问题就多琢磨琢磨。毕竟，如果继续用rpm做大部分打包任务，这至少意味你在即使没有Docker的情况下也应该还是希望能够正常执行安装。对于puppet，你应该要倾向于考虑通过Docker脚本及外设脚本（即k8s）全部替换。

想看更多内容，还请添加微信公众号（ID：MornNews，或搜索DevOps研究院）