众所周知，容器已经在很多互联网企业以及传统企业当中实践应用，这种新兴的技术有很多地方会被人误解，一不小心就会踩到坑，数人云今天分享的文章将讨论这些，因为Docker是被最广泛采用的容器技术，所以以它为例。

Docker的5大误区

误区1：Docker是万灵药

Docker并不解决云端所有的问题，所以在容器技术中，需要对计划目标有合理地规划，若考虑采用Docker在平台中加一些特定的东西，那么请自问：目前平台有哪些衍变？若已经有了小的应用服务，可以使用Docker去解决一些问题，但不要试图让它解决全部问题。

在评估环境是否合适容器时，经常使用牛或宠物作为比喻，想要迁移到容器，需要的环境是能像对待牲口那样简单粗暴，而不是那种娇滴滴的宠物。若有一个高强度且密集的程序，并且要不断地为服务器梳理毛发（比喻，意思为比较脆弱，需要经常维护），那么就不适合迁移到容器当中。

如果已经有了一个范围广泛且松散耦合的集合，就可以很好地运用容器去解决一些，但要是已经有了大量流程模式的挑战，并且应用管理方法都是非常传统的，就需要在尝试迁移之前将这些问题解决掉，在迁移到容器之前，需要致力于不可变的基础设施概念和实践。

误解2：Docker有明确的最佳实践

如同在其生命周期快速采用阶段的任何突破性技术一样，容器还没有一组清晰的最佳实践，本文文末将给出一个较好的实践，但仍不算最佳。

虽然并没有什么“最佳实践”，但需要知道做什么，如，早期的想法是不希望在Docker中托管一个数据库，但现在已经在Docker上运行了整个搜索引擎（又称庞大的数据库），并找到了让它工作的方法。

Docker现在充满了争议，但这不意味着要去避开它，而是做到理解前沿的新技术和所做的事情。不要害怕尝试不同的事务，需要明白它能产生的作用，如果善于思考需要解决的问题，并进行一些实践测试，可能就会学到很多适合本企业自身的知识，缺乏最佳实践可能是一种挑战，但同时也意味着可以不受限地跳出条条框框去思考，想出创造性的办法去解决老问题。

误解3：Docker总是比虚拟机便宜

从某个角度去看，运行容器确实会比虚拟机要便宜，比如，有600个AWS实例，分别是1个CPU和4-5GB的RAM，那么可以使用Docker容器将其减少到100个实例，其中有32个CPU和64G的RAM，因为实例数量的减少就可以显著地降低成本。

对于一些用例来说这是正确且可行的，至少在短期内如此，但从长远角度去看，如同其他任何技术一样，也为应用容器技术花费了不少人力、物力成本，逐渐将其复杂化也带来了成本上的问题。

当大规模地运行容器时，为了方便管理容器极其资源，不得不投资管理和编排平台，就需要一个全新的技术堆栈，由于没有明确的最佳实践，可能会遇到一些反复出现的错误，造成时间和成本上的浪费。

这笔账不能简单地去通过对比其价格计算，需要大量的时间去确定优先级，并理解在运用容器需要的成本是多少。

误解4：容器可以像虚拟机一样

容器不仅仅是更小，更离散的虚拟机，而且也是完全独立的。所以若使用的是像虚拟机那样的容器，护着打算再Docker容器中构建虚拟机，那么还是建议就此罢手，因为可能会导致一些重大问题。

将Docker想象成一台3D打印机，输入需求→Poof→出现容器，现在这是一个整体和自包含对象而并非是可以编辑或删除的对象。如果某些项不正确或需要新项，不得不进行重复性工作。

当运用Docker容器时需要自问一下如：

• 集成应用真正的含义是什么
• 是否了解依赖关系

如果能自答出这些问题，并构建适合容器的新工作流程，那么就能很便捷地实现。

误解5：Docker与虚拟机具有相同的安全模型

很多人部署了Docker后，认为它具有与虚拟机相同的安全模型，但可惜地是并非如此，Docker虽与操作系统有关，但它并不是操作系统，很多人使用名为Core OS的缩放操作系统运行容器，除了运行Docker，其无法做更多的事情。应用通常仍然需要更传统的操作系统提供一些东西，例如，从一个Linux发行版（如Ubuntu）构建容器。

一整套的安全挑战出现在迁移到容器时。其中一些是因为“一个进程一个容器”的最初目标难以执行，所以人们找到了实际上容器一个非常重要的特征捷径和方法。

若闯入容器化的环境，当发生的事件导致安全问题时，需要建立告警，比如构建了一系列容器运行的Java应用，若除了Java之外任何操作都开始运行就应该告警。

值得注意的是，容器可以让人真正了解这些类型的告警，可以缩小查找内容，但编写这些规则应用它们以及随着时间推移去进行管理则是一项挑战。

Docker的5大实践

前文说过，Docker目前并没有什么“最佳实践”，但本文仍会给出5个实践来供以参考：

实践1：基于应用的日志记录

在基于应用的方法中，容器内的应用使用日志框架来处理日志记录过程，如一个Java应用可能会用Log4j 2去格式化和发送日志文件到远程服务器，并完成绕过Docker和操作系统。

虽然基于应用的日志记录使开发这对日志事件有了最大控制，但这种方法也会在应用过程中产生大量开销，对于哪些在更传统的应用环境工作的人来说可能是有用的，因为其允许开发者继续使用应用的日志框架，无需向主机添加日志功能。

Docker实际上意味着不仅记录应用和主机操作系统，还包括Docker服务。

实践2：使用数据卷

容器本质上是临时的，因此若挂掉，里面任何文件都会丢失，相反，容器必须将日志事件转发到集中式日志记录服务（比如日志记录），或将日志事件存储在一个数据卷中（被定义为容器内的一个标记目录，该目录存在保存持久或共享的数据）。

使用数据卷记录事件的好处有：由于它们链接到主机上的一个目录，所以日志数据仍然存在，并且可以与其他容器共享，减少了容器关闭时丢失数据的可能性。（参见：https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04）

实践3：Docker日志驱动程序

在Docker中记录实践的方式是使用平台的日志记录驱动程序将日志事件转发到在主机上运行的Syslog实例。Docker日志驱动程序直接从容器的Stdout和Stderr输出入去日志事件，这消除了从日志文件读取和写入的需要，转化为性能增益。
但使用Docker日志驱动程序有一些缺点：

不允许日志解析，只能记录转发

Docker日志命令仅适用于日志驱动程序JSON文件

当TCP服务器无法访问时，容器终止。

（参见：https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04）

实践4：专用记录容器

此种方法的主要优点在于可在Docker环境中完全管理日志事件。由于专用日志记录容器能从其他容器收集日志事件，聚合它们，然后将事件存储或转发到第三方服务，因此此方法消除了对主机的依赖，附加优点有：

自动收集，监控和分析日志事件

自动缩放日志事件，无需配置

通过多个日志事件，统计信息和Docker API数据流检索日志。

实践5：侧面方法

Sidecar已成为管理微服务架构的流行方式，侧面的想法来源于摩托车侧车架如何附着在摩托车上的类比，有消息称：一个Sidecar作为第二个进程与服务一起运行，并提供了通过同类界面暴露的平台基础设施功能，例如通过HTTP的类似REST的API。从日志角度看，优点是每个容器都链接到自己的日志记录容器（应用容器保存日志事件和记录容器标签，并将其转发到Loggly的日志记录管理系统）。

总结

不得不说，Docker容器是一项非常具有潜力而且十分炫酷的新技术，实践出真知，去了解Docker如何适应应用自身整体的策略非常值得，当了解了容器这些深坑之后，就可以避开它，同时也多去技术社区和线下交流了解更多的方法模式，不断充实自身。

原文作者：Megan Rees Ahigian
原文链接：https://dzone.com/articles/5-common-myths-around-moving-to-docker?utm_source=tuicool&utm_medium=referral