Docker头条 第4页

Docker公司（5月10日）宣布他们推出了新的安全扫描技术，此技术用于在整个软件供应链中保障容器内容。

Docker安全扫描是Docker云私有仓库计划的一个可选服务。它提供对容器镜像内的软件安全性评估。

这项服务提供的细节使得IT运营人员可以评估软件是否符合安全合规标准。 与现有的开发工作和IT工作流程无缝集成，每当有变更分发时就会触发扫描，在部署前增加一个检查点，该公司表示。

Docker的安全主管Nathan McCauley说：“扫描过程会创建一个类似汤罐内容标签的镜像签名。”

它能做什么

Docker公司说，Docker安全扫描可以涵盖任何应用程序和所有主流Linux发行版。 它提供了集成到容器即服务的工作流，通过集中IT管理的安全内容提升企业的安全态势。

作为安全增强的一部分，该公司还发布了Docker Bench的一个更新。该版本自动按照CIS基准建议验证主机的配置。通过更新，Docker用户可以采用最新的CIS Docker基准建议，以确保他们的平台配置与Docker引擎1.11版本的最佳实践是一致的，McCauley告诉LinuxInsider说。

此安全流程回答了有关计算机安全的几个关键问题。 它告诉用户Docker容器的内容。 它可以让用户知道代码来源，如何避免坏的部分以及如何基于合规和管理保持当前补丁到最新。

McCauley说“伴随着这个过程，开发人员成为安全过程的一部分。开发人员在他们部署软件之前就可以看到扫描过程的结果”。“我们做它的目的就是保护从开发，测试到生产的整个软件供应链。”

工作方式

Docker镜像扫描和漏洞检测提供颗粒层次审计镜像的容器优化的能力。根据扫描的结果，会对每个镜像提供一份包含镜像层和组成的细节清单，并且附带每个组成的安全描述。

这使得独立软件供应商、发布商和应用团队可以根据他们的安全策略进行正确的决策。 ISVs可以利用这些信息来积极修复漏洞，以保证其内容的高品质安全级别，并透明地部署到他们的最终用户。应用程序团队基于所显示的配置文件，可以决定是否要使用ISV提供的镜像并在决定部署前可以灵活的使用安全扫描检查额外的代码。

如果没有可选的增强安全性，IT从业者要依赖于各ISV对其提供内容的常见漏洞状态发布信息，披露的数据库并且手动跟踪他们的任何问题。 Docker安全扫描将自动化这个过程，当镜像中的任何内容报告发现漏洞时都会自动通知企业。

特权性能

Rackspace公司的架构师Adrian Otto说，即将推出的Docker Engine将使用multidaemon方法分离特权，使得它比以前版本中使的single-daemon设计更加安全。这也是Docker如何持续改善安全态势的一个例子。

他还告诉LinuxInside：“我们相信类似的增强会继续下去，因为开发是由用户和开发人员组成的社区推动的，由于威胁和复杂的竞争对手日趋活跃，他们越来越关注应用安全”。

不管是否使用容器技术，安全性都是所有支持云的应用程序需要关注的。对漏洞进行持续扫描肯定是安全的最佳实践。理想情况下，安全扫描应该包含在容器宿主机系统中，以保持应用程序的安全，奥托说。

安全跨越

Sungard Availability Services公司的首席安全体系技术官Scott Moore 说，对于安全问题，虽然Docker的技术还有很大的成长空间，但是现在正在大步朝前。

Docker Engine 1.10版本重点几乎全是安全。1.11版本是第一个内置runC以及Containerd 并且符合开放目录接口标准的版本。

Docker云是一个容器即服务的解决方案，允许客户可以从任何云供应商加入自己的节点。客户创建和运行节点，所以Docker不负责主机的安全性。Docker云会从节点提取信息，并将其存放在Docker云中，并且它对于从节点收集的元数据没有认证机制。

Scott Moore还说，“如果用于授权的Docker ID泄露，有人能够获得Docker云管理的任何节点的容器访问。此时，Docker Cloud没有细致的，基于权限的访问控制或者API密钥管理”。

容器化容器

Kilmon说：Docker Cloud是在云中运行容器的解决方案。即使Docker Cloud 是安全的，但这并不意味着你在之上为你的云解决方案运行的容器是安全的。

Kilmon说，Docker Cloud只是作为其组成部分是安全的。云安全在很大程度上取决于如何使用它。

例如，如果你提供一个Amazon Web Services实例或一个节点来运行容器，并且这是不安全的，那么这将是整个链条中的一个薄弱环节。

Kilmon说，“Docker Cloud无非是托管Docker基础设施的，像Docker registry，Docker engine等等，托管的基础设施是安全的，但你在基础设施上运行的Docker容器仍然可能是不安全的”。

产品供货

Docker安全扫描可用于Docker Cloud用户的私有仓库计划。在第三季度末，范围将扩大到所有的Docker Cloud仓库用户。

最初的免费试用期结束后，作为私有仓库计划的一个附加服务，定价为2$每仓库。在2016年下半年，Docker安全扫描也将做为Docker数据中心集成的功能可用。

容器还是服务？

CloudPassage的首席技术专家 Sami Laine指出，增强安全性的附加工具是一个巨大需求。大多数企业在管理复杂的环境，包括传统的裸金属服务器，虚拟化，私有云和公共云上运行的工作负载，以及可能部署在所有这些环境的容器。

他还告诉LinuxInsider，“拥有综合性工具能够对IT交付的场景提供可视化和合规控制， 包括检查容器引擎和镜像的能力，这只会变得更加重要，而不是无关紧要。”

据Bromium的CTO Simon Crosby说 ，一个问题Docker容器可以攻击它的宿主机或其他容器。Docker之间的隔离是好的，但它并没虚拟机那么好，在CPU级别强制隔离。

他还对LinuxInsider说，“基本上，Docker已经远远超过传统漏洞百出的企业级服务应用和基础设施”。

尼奥：为什么那些程序会被删除?

先知：或许发生故障了，或许有更好的程序替代它，这种事天天发生，一旦这种事情发生了，程序就会躲在母体里或是选择回到万物之源。

“重启”是一个具有哲学意义的话题，比如《黑客帝国》中特工史密斯可以随时在一个身体上重启自己；《明日边缘》中阿汤哥饰演的男主角在一次次的重启中不断进步，最终战胜了大Boss；程序员的段子中，“你重启下试试”非常经典。虽然重启不能解决所有的问题，但还是能解决大部分问题的，因为重启能清除应用的当前状态，包括任何不在正常状态的代码。对于Docker，我们可以将restart作为一种自我修复的机制。

如果把Docker容器看做生命，那必然是“向死而生”的一生：它们可能会随时被停止或删除。默认情况下，所有运行过程中产生的数据也将被清除。但就像《黑客帝国》中的特工史密斯一样，容器也可以立马以初始的状态被重启。无疑从这个角度来讲，暂时的任务是容器最常用的场景。但实际上，容器也可以完美运行web服务，还可以通过volume实现数据库和持久化数据存储。MongoDB，MySQL和Postgres都是Docker Hub上最流行的Docker镜像。

一个容器的“传记”

Containers Life Story

都有哪些因素影响了容器的平均寿命呢？我们可以通过容器的整个存在过程进行深入研究。在Docker Engine记录了容器整个生命周期的事件，还有其它的重要信息，都保存在了/var/log/docker.log 中。我们也可以通过“docker event“命令行大体看下某个容器。这个命令会向Docker Engine查询某个时间段内容器内发生的重要事件。比如我们先启动一个容器：

然后，运行“docker event”看看哪些事件会被记录下来：

哇！能在命令行看到容器启动过程幕后发生了什么！

• 首先，由于在本地未能找到镜像，Docker client通过Remote API从Docker Hub ull下镜像；
• 接下来，创建容器，添加stdout/stderr到终端；
• 然后，新容器被加入到默认的bridge网络，被engine启动；
• 最终，容器完成自己的使命后，就会被删除。在此之前，Docker Engine会将其移出默认的bridge网络中。

容器已死，容器万岁！

The container isdead, long live the container!

虽然这个容器已经“死了”，我们还是能用“docker ps -a”命令捕捉到它生前的“音容笑貌”。

看起来这个容器去得很平静，因为Exit(0)并不是每个容器都能达到的境界。

而且虽然容器停止了，我们还是能找到它的“遗产”，因为所有容器的数据存储只有在“docker rm”执行后才会被正式销毁。“docker export”命令可以将容器的文件系统存储到一个tar包中。然后可以用“docker import”将其导入到同主机上的另一个容器中，或一个新的容器中。

请注意“docker export”导出的数据中不包含容器的历史。实际上，当tar包被导入到一个镜像中，结果镜像会被压缩为一层。

如果你在运行短期的前台操作容器，这些数据堆积会额外占用很多空间。“docker run -rm”可以在容器停止后自动清理容器状态数据和镜像层。

重生？

Is there life after death?

研究发现动物的基因并不会在其身体死亡立即消失，而是会存活长达四天，甚至有一些基因会在死后变得更加活跃。对于容器的“基因”当然可以保持更长的时间，而且还可以随时“复活”。

昨日重现

Containers entirelife flashes in front of your eyes the second before they die

“docker event”不但让我们看到Docker Engine内部的工作，还能帮我们自动应对一些容器的事件。比如，类似“Registrator”的工具会在服务上线和下线时，使用这种机制向Consul自动发送注册和注销请求，可以告诉负载均衡器有新的实例进来，或有实例不能提供服务了。

生命本该如此

This is your life

来自GliderLabs的Matt Good曾用一张图描述过Docker容器整个生命周期的事件，和引发这些事件的命令。

熟悉Linux signal的人都会发现这很像Linux中进程的生命周期，因为容器本质上就是Linux进程。只是Docker Engine利用了Linux内核的特性，将容器隔离起来，但容器内的进程可以和文件系统或网络交互，就好像自己是系统内唯一的进程。Signal提供了一种处理异步事件的方式，可以用在Docker容器的进程上。

不能承受的容器之轻

The unbearable lightness of being a container

就像Linux一样，可以用kill命令停止一个不正常或空闲的容器，并且无需注销或重启底层的服务器。Kill命令会向容器中的主进程发送一个SIGKILL的Linux signal，同样stop命令会发送SIGSTOP的Linux Signal。这些在Brian DeHamer的文章中有详细的描述，本文将重点分析上图中其它的命令和事件：pause，OOM和destroy。

暂停

Making a pause

为什么要pause一个容器？好吧，你可能需要暂停一个拖慢进度的容器，或者想对这个容器做一下备份。

有人预测“docker pause”未来可以用在容器的热迁移上。理论上，容器的热迁移是没有意义的，因为它们是无状态的，一次性的，还可以随时重启，但是……

避免“拥堵”

Defending yourself from being choked

默认情况下，所有的容器都是平等的：它们享有同样的CPU周期和IO，还能自由地使用内存。但某些情况下，我们需要用一些限制参数打破这种平等的待遇。比如，为了防止某些容器一直占用内存，造成OOM（Out Of Memory）事件，“堵塞”服务器。但是，需要先去设置内存的限制。

首先我们来模拟下OOM的情景，来看下如果设置了内存限制，Docker Engine是如何发挥作用的：

这个例子基于《Docker in Practice》一书中301的一个实例，在第一种情况下，被杀死的是进程（非主进程），而第二种情况下才是容器，为什么？

健康检查

Health checks that could saveyour container

要注意Linux内核在异常情况（比如资源不足）下只会kill一个进程，可能这样做已经太迟了。为什么不在应用出现问题前，提前检查呢？

在Docker 1.12中，不但可以在运行时进行限制，还能在启动容器时添加用户自定义的健康检查探针。比如，我们可以周期性地验证一个web服务是否在正常工作，而不仅仅是避免紊乱情况或内存溢出。

可以将健康检查作为“docker run”的选项，或写在Dockerfile中，“docker ps”命令除了容器的常规状态，也会显示其“健康状况”。如下所示，第一次“docker ps”执行时，监控探针还是“starting”的状态，当第一个探针通过后变成healthy的状态。接下来我们用“docker inspect”查看容器的健康状况。我们通过删除一个配置文件制造不健康的假象，在一系列的探针失败后，最终容器被加上了“unhealthy”的标志。

在当前的Docker Engine版本（1.12r3）中，容器不会在“unhealthy”的状态下重启，所以要检测容器的状态，手动地重启容器。

重启

Reboot your life or your container

在程序员的段子中，“你重启下试试”是很经典的一个，虽然重启不能解决所有的问题，但还是能解决大部分问题的，因为重启能清除应用的当前状态，包括任何不在正常状态的代码。

对于Docker，我们可以用restart作为一种自我修复的机制（就像《明日边缘》中汤姆克鲁斯饰演的男主角）。但是，需要注意的是，默认情况下容器不会在主进程存在的情况下重新启动。我们可以强制Docker Engine任何情况下都重新发布这个容器，或者只在主进程错误退出时重启这个容器：

重置

We should just reset

小故障可能会引起整个应用的崩溃，on-failure重启的政策可以帮助我们在容器返回非0退出时就重新发布。

注意上面Docker Engine是如何提高再启动延时的，直到其达到最大的on-failure重启数。

不被打扰的容器

Untroubled containers

在Docker 1.12中，又可以运行“daemonless”的容器啦！这意味着你可以在不影响或重启容器的情况下，停止、升级、重启Docker Engine，期间服务不会受到任何影响。这个特性之前被取消过，因为会给Docker初学者造成困惑。

为了能使用这个功能，要在启动Docker Engine时添加“live-restore”的flag，保证Docker在关闭和重启的过程中，不会kill运行中的容器。如下，使用docker-machine传递live-restore的flag：

颂词

A eulogy

容器确实随时都面临着“死亡”，但是有了重启，健康检查探针和热修复机制，没有必要担心。套用马克·吐温的一句话：“对死亡的恐惧源于对生活的恐惧。完全活过的容器，随时都准备着死。”

注：

本文根据6月是18日七牛云微服务课堂-微服务容器化的挑战和解决之道演讲内容整理而成，演讲者：有容云联合创始人兼首席架构师马洪喜，与大家一起探讨了如何通过容器技术将微服务和 DevOps 落地。

嘉宾介绍：

马洪喜，此前担任 Rancher Labs 中国区技术负责人、Citrix 公司资深架构师、Oracle 公司虚拟化产品开发经理等职务，在容器云、IaaS 云、桌面云建设方面拥有丰富的经验。

单体架构 VS 微服务架构

传统单体架构存在各种各样的问题，如加载编译耗时长、代码管理复杂、横向扩展难、各模块之间的耦合程度高等，与之相比，微服务架构则具一系列优势。

微服务架构则优势：

1.  模块可以独立提供服务，边界清晰、易于维护，可以促成新的开发模式，使模块外包，未来微服务模块市场的出现成为可能。

2.  微服务可以用不同语言编写，易于引入新技术。

3.   未来可能会形成微服务应用商店模型，快速的组合和重构。

4.   模块间松耦合，不同 SLA 保障计划。

5.   更好的可扩展性和鲁棒性。

下面我们看一个微服务的架构示例 ：有容云AppHouse。

注：

本文根据6月是18日七牛云微服务课堂-微服务容器化的挑战和解决之道演讲内容整理而成，演讲者：有容云联合创始人兼首席架构师马洪喜，与大家一起探讨了如何通过容器技术将微服务和 DevOps 落地。

嘉宾介绍：

马洪喜，此前担任 Rancher Labs 中国区技术负责人、Citrix 公司资深架构师、Oracle 公司虚拟化产品开发经理等职务，在容器云、IaaS 云、桌面云建设方面拥有丰富的经验。

单体架构 VS 微服务架构

传统单体架构存在各种各样的问题，如加载编译耗时长、代码管理复杂、横向扩展难、各模块之间的耦合程度高等，与之相比，微服务架构则具一系列优势。

微服务架构则优势：

1.  模块可以独立提供服务，边界清晰、易于维护，可以促成新的开发模式，使模块外包，未来微服务模块市场的出现成为可能。

2.  微服务可以用不同语言编写，易于引入新技术。

3.   未来可能会形成微服务应用商店模型，快速的组合和重构。

4.   模块间松耦合，不同 SLA 保障计划。

5.   更好的可扩展性和鲁棒性。

下面我们看一个微服务的架构示例 ：有容云AppHouse。

上图是 AppHouse 采用的架构设计。按照服务职能的切割，每一个微服务都跑在一个或者一组容器中，迎合了微服务主流的设计思路。

微服务和容器发展不可分割，以前存在各种各样切割服务的难点，而容器技术的出现使得服务可以切割得更小，成为支撑微服务很好的平台。下面让我们看看在非容器化的传统的 IT 基础设施之上，如果尝试使用微服务会存在哪些挑战。

容器可以轻松实现微服务化后的 DevOps

Netflix 云架构总监说微服务和 Docker 的结合是一种颠覆。Docker可以为微服务提供一个完美的运行环境。

1. 独立性。一个容器就是一个完整的执行环境，不依赖外部任何的东西。

2. 细粒度。一台物理机器可以同时运行成百上千个容器，其计算粒度足够的小。

3. 快速创建和销毁。容器可以在秒级进行创建和销毁，非常适合服务的快速构建和重组。

4. 完善的管理工具。数量众多的容器编排管理工具，能够快速的实现服务的组合和调度。

微服务化与容器化，谁先谁后?

目前，许多传统企业都非常关注微服务。但是，我们需要意识到，利用容器技术将传统系统进行微服务改造不可能一步到位，并且也不是一定要把你的应用改造成微服务。

微服务改造本身是一个漫长的过程，如果你是 SOA 的应用，甚至是更传统的，那么可以考虑先将应用转到容器平台上运行，然后我们可以先体验容器带来的感受，再考虑如何将应用往微服务方向改造。

支持微服务的容器管理平台需要解决的问题

在容器上跑微服务是所有人的共识，问题在于如何支撑微服务。从管理微服务的角度看，未来微服务需要实现跨主机、跨云、跨数据中心。当系统被微服务打散后，一些功能需要放到阿里云，一些功能需要放到企业中心，如何在服务平台上实现跨云的管理，这是带给容器管理平台的挑战。另外，一部分微服务跑在阿里云，一部分微服务跑在本地，如何保证它的安全性，并且按照预想的安全策略去做也是一个挑战。

大家知道，微服务通过一组功能相同的微服务实例，对外提供统一的服务。当微服务实例扩容时，如何让它们自动的提供服务，不需要手动调整负载均衡配置，这也是容器管理平台需要考虑的问题。此外，容器管理平台还要实现服务的注册和服务的发现、微服务版本的管理和微服务的升级与降级等，这个过程需要考虑到灰度发布策略和已有会话的处理等工作。当然，这只 是一部分例子，除此之外还会涉及到生命周期管理、团队协作和应用配置管理等各个方面的功能点。

面向微服务的容器网络和存储实现架构讨论

接下来和大家分享一下使用容器进行微服务支撑的另外两个技术挑战点：

第一个挑战是微服务模式下如何使用容器网络。

大家关注容器技术，知道容器的网络发展速度很快，比如 CNI、CNM 等各类网络模型出现。在谈容器网络的时候，大家很容易会陷入一个误区，即过度追求技术的时尚性，例如 Overlay , SDN  等等，这些技术与容器配合当然是未来的方向，但今天考虑把容器技术真正落地，隧道网络不一定适合每个企业。很多企业既希望容器像虚拟机一样直接使用业务 IP ，又不希望 IP 资源过渡消耗。因此产品设计要关注用户的实际使用需求。

第二个挑战是微服务模式下的容器存储方案。

一个大的系统，不同的微服务模块，对包括存储、计算、网络都有不同的 SLA 要求，譬如做数据处理的模块与做图片归档的模块对存储要求是不一样的。是不是有一天我们定义应用对接存储的规格时，可以通过写一行配置参数，不同的存储指向和 SLA ，比如数据处理模块对接到跨多主机 SSD 盘阵的分布式存储上，图片归档可能是放在 SATA 盘阵或是公有云存储，比如七牛云上呢？这可能是未来支持微服务的平台必须具备的功能之一。

刚才提到，微服务时代似乎确实需要极强的容器管理平台，帮我们更好的管理微服务。而这样一个平台需要考虑到多方面功能点，以下是一些成熟的容器管理平台要解决的问题。

微服务的横向扩展

在产品设计上，我们在思考有没有好的方式，能够根据用户量访问情况做到对微服务模块的自动扩容( AutoScale )，这也是大家比较关心的问题。否则花了很大力气改造微服务，做完后却发现这个平台不具备根据用户的访问自动扩展服务的能力，微服务的价值也大打折扣。

微服务容器化下的安全架构考虑

每个企业都会关心信息安全。上了容器后，大家也会关心如何解决容器环境下的安全挑战。

传统的模式不太适用于新的容器时代或者微服务时代。大家想象一个场景，以前虚拟机时代，数量是有限的，对于一个企业来说，虚拟机有几百台，还是采用手动管理安全策略。现在容器数量可能一万甚至十万个，容器的创建和删减完全由系统自动决定。传统的人工策略已然不适用，因此需要新的能够适应未来容器时代和微服务时代的安全模型。

有容云的容器安全产品设计，是以应用为中心的角度考虑容器时代的安全挑战。比如整个微服务拓扑的可见度，我们能不能把容器之间的通讯完全呈现出来，让大家直观看到哪些微服务模块之间存在数据通讯及其质量。当你的一个内部微服务模块突然之间开始将大量数据发送到互联网，你需要得到一个告警，并去处理，看看是不是被黑客攻击了。还有诸如容器漏洞热补丁以及镜像扫描等功能，都是从容器安全角度考虑要去解决的问题。

微服务的日志聚合设计

传统时代，我们的日志不大会直接打印到标准输出，而一般会由团队达成一致，存于某个指定目录。

在微服务架构下，大家知道容器的玩法，对于日志收集，推荐的做法是将容器内微服务产生的日志打印到标准输出，然后通过外部收集器统一收集、处理和分析。有容云的产品可以把微服务模块日志全部集中处理。有可能一些传统组件没有办法把日志输出到标准输出，还是放在目录下的日志文件里，这时我们需要一个手段将其储存。当然有很多技术可以选择，我们的产品采用的是“日志处理伙伴容器”和“数据卷共享”技术，这种方式不是侵入式的，无需在微服务容器内注入其它组件。

私有镜像服务在 DevOps 环境的选择

在容器镜像管理中，需要对镜像权限进行管理。举个例子，镜像可以被自动化的流水线自动生成，放入镜像库的“开发”库(对应有容云AppHouse中的一个Project)时，镜像只是产生了，并未经过测试。如果运营人员一不小心把这样的镜像从镜像库拉下来，将对生产造成很大的影响。

对于我们来说，关注点在于如何将镜像和 DevOps 开发流程进行匹配。比如镜像进入开发库，只有测试人员才有权限进行测试。测试通过后，版本经理一定要做一个审批通过的动作，这样容器镜像才能在生产、运营中看到，才可以有权限把它拉进来。这是镜像设计仓库方面的一些考虑，相信我们未来在市面上会看到功能越来越丰富的产品。

容器驱动的轻量级 PaaS 解决方案架构示例

如果用容器驱动微服务开发，是不是需要有一个 PaaS 平台直接对整个开发项目的生命周期进行管理？其实 PaaS 是很多企业，包括前文提到的传统金融行业，很关注的解决方案。新的 PaaS 时代，大家更关注的问题是容器驱动的 PaaS 如何去做。大家可以想象一下，未来市场上会看到这样一些 PaaS 产品，你只要注册一个账号就能登录到这个 PaaS 平台，在上面你可以定义整个项目的生命周期，可以管理你的 Bug，管理你的项目，也可以完成协作等等。

通过灵活扩展、可配置的方式实现微服务应用商店模型

图中可能有大家熟悉的软件。在这样的平台上，我们是不是能够很容易获得这样的微服务模块？比如，需要形成大数据处理的能力时，它是不是唾手可得，不需要自己去开发？我们是不是可以形成基于微服务模块交易的市场？

大数据处理中有一个很大的难点，数据专家和业务专家中间有一个很大的鸿沟，比如说医疗数据如何建模、如何写逻辑等等，这方面我们是不是可以通过一种插件的模式，把医疗专家的经验通过数据处理模块进行封装，并通过一定形式进行分享。我想这些都是潜在的发展模式。也许未来，我们会看到蓬勃发展的微服务模块的交易市场。以上是我今天分享的内容，谢谢大家！

近两年来，微服务架构和基于容器的虚拟化技术以迅雷不及掩耳之势席卷了整个软件开发社区，微服务与Docker的结合更被视为一种“颠覆”。在与容器结合使用后，微服务架构的优点得到了进一步的放大：微服务鼓励软件开发者将整个软件解耦为较小的功能模块，并且这些功能能够应对外界的故障；而容器进一步对这种解耦性进行了扩展，它能够将软件从底层的硬件中分离出来。

这种方式所产生的结果是：应用程序能够更快地进行创建，并且更易于维护，同时又能够得到更高的质量，从而促使越来越多的产业应用容器化。如eBay、Amazon、京东、淘宝、唯品、银行、证券和运营商等许多企业均把原有应用容器化，开创了一个新的“容器时代”。

Docker是一个开源的应用容器引擎，让开发者可以将应用以及应用依赖环境打包到一个可移植的容器中，然后发布到Linux机器上。这种类似沙箱的机制，可以使容器相互之间几乎没有性能开销，可以很容易地在主机和云平台中迁移。针对容器的管理平台种类较多，质量参差不齐。今天与大家一起讨论的是关于容器管理平台AppSoar的健康检查与调度策略，这也是容器在企业落地经常关注到的问题。

当一个容器在运行的过程中难免出现由于某种原因导致容器不能正常工作的情况。针对这种情况的做法是引入健康检查机制。

健康检查

在AppSoar管理平台中，通过在它的主机上运行托管网络代理端，实现了健康监控系统用来协调容器和服务的分布式健康检查。这些网络代理端在内部使用HAProxy来验证应用的健康状态，无论单独容器还是服务的健康检查被开启后，每个容器都会被多至三个网络代理端所监控，代理端运行于不同的容器主机上。如果至少一个HAProxy实例汇报“通过”的健康检查，容器就会被认为是健康的；当所有HAProxy实例都汇报“不健康”的健康检查，就认为容器是不健康的。

这种处理网络区分并且相比基于客户端的健康检查更有效率。通过使用HAProxy来执行健康检查，允许用户跨越应用和负载均衡来指定相同的健康检查策略。

健康检查机制

健康检查机制有两种（默认无）：

第一种：确认TCP连接开启的健康检查，根据检查间隔时间和健康阈值规则，进行非健康时操作。

第二种：是HTTP 2xx/3xx响应检查，是执行一个HTTP请求并确保接受了正确的响应。容器对外提供的HTTP请求有GET、POST、HEAD等多种选择，根据HTTP的检查规则和阈值设置，进行非健康时操作。

Compose配置描述：

通过以上的健康检查机制，可以确保我们的应用或服务可以正确放心运行，保证业务的流畅性。

由于AppSoar平台中添加宿主机的配置或者业务负载各不相同，所以，我们需要根据主机配置和业务容器或服务进行合理分配，这时需要考虑到AppSoar管理平台的调度策略。

调度策略

在AppSoar管理平台中，通过服务（Service）或者通过负载均衡器（Loadbalancer）或通过容器页面（Container page）启动容器时，我们提供为容器创建标签的选项以及提供调度容器到您想要放置容器主机的能力。

调度规则为您想要在AppSoar如何挑选使用的主机提供了灵活性。我们可以使用标签来帮助定义调度规则，让您能为一个容器创建您想要的数量的标签。有了多种规则后您可以完全控制在哪台主机上创建容器，也可以请求具有特定主机标签、容器标签、名字或者特定服务的窗口在哪一台主机上启动。通过这些调试规则能帮助创建您容器托管关系的黑名间和白名单。

对于容器或服务，提供了两个选项来决定在哪台主机上启动您的容器。

1.在指定的主机上运行所有容器

通过选择该选项运行所有容器在指定的主机，容器或服务将会在指定的主机上启动。如果您的主机停止运行，那么主机上的窗口也将停止。如果您在容器页面创建一个容器，即使存在端口冲突，容器也能被启动。如果您创建的一个规模大于1的服务，存在端口冲突，您的服务可能陷入未激活状态直到您编辑服务的规模值。

2.自动选择匹配调度规则的主机

通过选择该选项自动匹配调度规则的主机，您可以灵活的选择您的调度规则。任何遵守所有规则的主机都是容器能在上面启动的主机。您能通过“添加调度策略”按钮来添加规则。

对于每个规则，您要选择规则的条件。有四个不同的条件，分别定义规则必须遵守的规则有多严格；这些字段决定您希望的规则将应用于哪些字段。具体字段和条件如下：

条件

必须或必须不：AppSoar只使用匹配或者不匹配字段和值的主机。如果AppSoar找不到一台主机符合带有这些条件的所有规则，您的服务将一直陷入正在激活状态。服务将不停为容器查找到可用的主机。你能编辑服务规模，或者添加/编辑另一台满足这些规则的主机。

应该或不应该：AppSoar试图使用匹配这些字段和值的主机。在没有主机匹配所有规则的条件下，AppSoar将一个接一个移除容器直到所有主机满足剩下的限制。

字段、键/值

主机标签：当为容器或服务选择主机时，AppSoar将会检测主机上的标签来查看是否这些标签匹配所提供的键/值对。因为每台主机能有一个或多个标签，Rancher将把键/值对和主机上所有标签做对比。当添加一台主机到AppSoar时，您就能为主机添加标签，您也能通过主机下拉菜单中的Edit选项来编辑主机上的标签。激活主机上的标签列表可从下拉菜单的键值字段获得。

带标签的容器：当选择这个字段时，AppSoar将查找主机上已经存在的标签匹配键值对的容器主机。因为每个容器能有一个或多个标签，AppSoar将把键值对和主机上的每个容器的所有标签进行比较。容器标签不能在容器启动后编辑容器的标签，为了能创建拥有同样设定的新容器，您能在容器启动前克隆容器或服务以及增加新的标签。AppSoar将检测一台主机上是否有指定服务的容器在运行。如果有相同的，需要改变服务名字或取消未激活或者已移除状态，这规则就不再有效。容器标签选择的这个字段，输入值必须为：栈名/服务名（stack_name/service_name）的格式。正在运行的服务列表可以从下拉菜单的中值中获得。

带名字的容器：AppSoar将检测一台主机上是否有指定名字的容器正在运行。如果稍后的时间里，窗口改变了名字或者处于未激活/已移除状态，整条规则便不再有效。运行中的容器列表可以从下拉菜单的值中获得。

以上是关于AppSoar的容器调度策略设置的一些使用方法，希望能够对于企业容器落地实施和应用有所帮助。本文仅供参考，旨在与大家共同完善容器生态圈！

Docker 1.12版本中将swarm内置到了Docker Engine中，网络部分也发生了一些改进，本文中将深入探讨Docker1.12版本swarm模式下的网络模型。

如下图所示Swarm模式下的集群架构，这是一个典型的master-slave的架构。每个节点都是运行着Docker Engine的Docker主机。一些节点有更高的权限，被称为Manager。下面绿色的节点是worker节点，接收来自manager组的任务指示。

下图Docker Engine的swarm模式下节点是如何工作：

如下图，创建一个有5个节点的swarm集群测试环境。

如果SSH到test-master1的话，可以看到默认的网络拓扑：

每个容器都有一个IP地址，有三种overlay的网络模式：

1. Ingress
2. docker_gwbridge
3. user-defined overlay

Ingress Networking

Swarm manager使用ingress负载均衡，将需要对外可用的服务暴露给swarm。Swarm manager可以自动给这个服务分配一个PublishedPort ，或者你可以为这个服务配置一个在30000-32767之内的PublishedPort 。实际上，集群内的ingress网络是基于节点端口模式的，每个服务被分配到集群内预留的30000-32000之间的端口。集群内的每个监听这个端口的节点，都可以为那个服务路由流量。这与一个特定的worker节点上运行的服务无关。

特别要注意的是，只有那些暴露端口的服务才需要ingress网络，不对外暴露端口的后端服务，其对应的容器也不会被加到ingress网络中。

外部组件，比如云负载均衡器，可以访问集群中的任意节点，不管这个节点是否运行着服务中的任务。Swarm集群中的所有节点都通过ingress连接到运行的任务实例。因此，ingress遵循节点网络模式，同一个服务在集群的每个节点上都有相同的端口。

docker_gwbridge

『default_gwbridge』网络只能用在非内部的网络环境下，内部的网络可以加上『-internal』的选项。连接到多主机网络的容器会自动连接到docker_gwbridge网络。这种网络模式让容器可以和集群外产生外部连接，并且在每个worker节点上创建。

Docker Engine提供了多种灵活的网络模式，既可以手动创建docker_gwbridge，也可以让daemon自动创建。除非你需要一个在指定子网的docker_gwbridge，可以用以下方式创建：

$docker network create –subnet={Your prefered subnet } -o com.docker.network.bridge.enable_icc=false -o com.docker.network.bridge.name=docker_gwbridge docker_gwbridge.

User-defined Overlay

这是用户指定的容器的overlay网络模式。在下面的例子中，我们会叫它mynet。一个容器可以在多个user-defined overlay网络中。

理论知识介绍得差不多了，下面我们来实践一下：

如下，这个swarm集群中有3个节点，其中1个是master节点，2个是worker节点。

通过下面的代码创建了一个user-defined overlay：

$ sudo docker network create -d overlay mynet

可以在swarm模式下看到新的overlay网络列表，如下：

有一个名为『frontier』的服务，服务中的3个任务分别运行在node 1，node 2和master1上 如下图：

可以分别查看在node-1和node-2下的容器：

同时，我添加了一个新的Node-3，并将其扩展到10个：

现在我们可以看到这些容器在swarm集群内被扩展了。

为了看下overlay网络是如何工作的，我们以第4个节点为目标，并将其加到swarm集群中。

现在节点列表更新如下：

向swarm集群中添加节点时，mynet的overlay网络并不会自动更新：

只有新任务被分配时，overlay网络才会被影响，而且是按需的。

下面我们扩展旧的服务，看下node-4网络布局是否会被mynet网络影响。之前我们有10个副本在运行，分别运行在master1，node1，node2和node4上，一旦我们扩展到20个实例，swarm集群的engine会跨所有节点进行扩展：

现在node-4的网络拓扑如下：

所以，一旦新的任务被指定给这个节点，Overlay网络就会被按需创建。

Self-Healing

Swarm节点是自组织（self-organizing）和自修复（self-healing）的，什么意思？只要有节点或容器宕掉，swarm engine就会尝试修复，下面我们来具体看一下。

经过上面的操作之后，我们有以下几个节点：

• Master-1上运行着4个任务；
• Node-1上运行着4个任务；
• Node-2上运行着4个任务；
• Node-3上运行着4个任务；
• Node-4上运行着4个实例；

现在我们让node-4上的容器都宕掉。

一旦node-4上所有容器停止，Docker就会试图在相同的节点上启动4个不同ID的容器。

这就是Docker Swarm Engine的self-healing功能。

Self-Organizing

现在我们让node-4整个宕掉，node-4上的容器会自动在其它节点上启动。

• Master-1上运行着5个任务；
• Node-1上运行着5个任务；
• Node-2上运行着5个任务；
• Node-3上运行着4个任务；

Docker自动将原node-4上的容器分配给了其它节点。

Global Services

这个选项让服务可以运行在所有的节点上，你可以在创建服务的时候，加上-mode-global的选项，开启这项功能：

Constraints

有些情况下，你会想要某些工作负载分离出来，运行在特定的节点上。比如在DockerCon大会上的演讲中，展示了contraints的用法：

Routing Mesh

假设在myapp:80服务上，有1个manager节点和3个worker节点。当有人想要通过暴露的端口访问myapp:80的时候，运气好的话，会被外部的负载均衡器引流到worker-2，因为worker-2有2个前端容器的副本，随时都可以提供服务；但如果不幸访问myapp:80的请求，被重定向到了没有容器副本的worker-3，就是Routing Mesh技术发挥作用的时候了。worker-3上没有容器的副本，Docker Swarm Engine就会将流量重新路由到有足够副本的worker-2上提供服务。外部的负载均衡器不需要知道容器在哪里运行。Routing Mesh是自动完成这一系列动作的。

总之，容器感知的Routing Mesh就是将流量从node-3重新路由到运行着容器的node-2。Docker Engine在集群内部分配端口，并将端口对应到服务的容器，Routing Mesh会通过为swarm中每个节点暴露一个端口，来保证流量被引到正确的容器上。