DaoCloud道客博客
汇总一周容器圈热点资讯，让开发者了解最 in 的容器技术，让企业熟知最实时的国内外容器行业动态。
来自 SDXCentral 的调查，一年之内部署容器的量级增长了562%
来自 SDXCentral 的2017年集装箱和云计算报告的重要发现之一是，对于容器技术的部署在过去两年中稳步增长，并且将在应用平台领域超越虚拟机（VM）。在 2016 年，只有 8％的受访者部署容器，而今年有 45 ％已经在使用。
该报告着重于云计算和自动化领域，关注了企业和其他受访者面临的挑战。其中，有 62% 的受访者采用容器技术的主要原因是因为其使用的效率；有 58%的受访者是因为其比虚拟机的开销更低；同时有 47%的受访者是因为其更易于管理。通过将应用程序从底层基础结构中分离出来, 以及标准化的升级机制, 这些特性让应用程序的测试和部署速度更快, 同时具备更高的应用程序可移植性和更好的安全性。
同时，最受欢迎的编排平台是 Kubernetes 占比为 64％，Docker Swarm 占比为36％，Apache Mesos / Mesosphere 占比为18％。最初在 Google 开发的 Kubernetes 具有良好的行业支持，并且是 CNCF 项目的一部分。Docker 公司开发的 Docker Swarm 针对Docker Engine 进行了优化，并在 Docker Swarm 之上建立了一个管理堆栈。Docker 还与微软合作，支持内置于 Windows Server 2016 和 Microsoft Azure 。
Kubernetes 1.8.0 alpha.3 测试版本发布
Kubernetes 距离 alpha2 发布过去1个多月后，Kubernetes 1.8 第 3 个测试版 alpha.3 已经发布了，此次相比 alpha2 更新的内容较多主要一些变化有：
-
删除无用的 kubectl 命令 apiversions, clusterinfo, resize, rollingupdate, run-container, update
-
从 kube – controller – manager 中删除无用的 flags : replication-controller-lookup-cache-size, replicaset-lookup-cache-size, and daemonset-lookup-cache-size
-
Beta 版的 Annotations service.beta.kubernetes.io/external-traffic 和service.beta.kubernetes.io/healthcheck-nodeport 已删除。（请使用 service.spec.externalTrafficPolicy 和 service.spec.healthCheckNodePort 代替）
-
使用AWS提供的群集需要使用 ClusterID 标记 nodes 和 resources 。
-
RBAC：该 system:node Role 不再自动授予新集群的 system:nodes Group。建议使用 Node 授权模式授权节点。
-
StatefulSet：删除 pod.alpha.kubernetes.io/initialized Annotation 。
-
从 kube-apiserver 中删除 –insecure-allow-any-token 。
-
将默认的 kubeadm bootstrap token TTL 从无限时长更改为 24 小时。如果依旧希望使用之前的 TTL，请使用 kubeadm init –token-ttl 0/ kubeadm token create –ttl 0。
Docker 小贴士：拆分 Dockerfile 中的长指令行
拆分 Dockerfile 中的长指令行能够使 Dockerfile 更容易阅读。让我们来看看这是如何做的。
就我来说，在编码或处理配置文件时，我尽量限制每行79个字符。它不仅仅是一个标准，而且也恰好是我在2560×1440显示器上的Sublime中舒适地打开3个窗口的完美宽度。
在编写Dockefile的时候，你可能会将命令高效的连接在一起。但是，这样做会导致指令行变的相当长。
举例来说，看看这个122字符的命令：
RUN wget -O myfile.tar.gz http://example.com/myfile.tar.gz && tar -xvf myfile.tar.gz -C /usr/src/myapp && rm myfile.tar.gz
在代码编辑器中，这将全部在1行中显示。水平浏览这一整行命令是相当费力的。
然而，我们可以把它拆分开来
RUN wget -O myfile.tar.gz http://example.com/myfile.tar.gz \ && tar -xvf myfile.tar.gz -C /usr/src/myapp \ && rm myfile.tar.gz
这样看起来是不是清楚多了？
反斜杠是在类Unix操作系统上将长行分解成多行的标准方法。由于大多数Docker镜像是使用某种形式的Linux基本镜像构建的，所以反斜杠在这里也适用。赶紧在你的Dockerfile中尝试一下吧！
容器监控简介
容器让我们的工作变的更加轻松容易，无论是对于开发或者生产。然而，与之前的开发模式相比，容器化也带来了新的问题。容器监控是一个完全不同的“猛兽”，让我们来看看原因所在。
容器监控的不同之处
您现在已经创建并部署了两个容器。现在需要做什么呢？我需要在我的容器中安装一个监视代理来监控容器内部的情况？
不！容器的优点之一是部署的容器的大小。我们只安装保证容器正常运行的那些必须的东西。不多不少。
容器的寿命比虚拟机要短得多。根据最新的DataDog Container调查，容器的平均寿命为2.5天。如此高的变化率，我们的监控软件完全不能跟上我们修改应用的速度。
此外，容器使应用的横向扩展和恢复变的非常容易。我们需要了解容器状态的更改和所有应用运行实例的位置。我们监控系统必须能够应对这些变化，并且在应用扩展和恢复时进行快速跟踪。
监控容器
容器的监控是无代理的。也就是说，我们不会在监视器中安装监控代理。通常，我们在每个主机上的容器的workload旁边的附加容器中运行监视软件来监视容器。这些监视容器用于监视主机和容器。
在这一点上，许多人混淆头脑，问“另一个容器是如何监视主机和主机上运行的容器的？” 大多数监视容器将根目录从主机挂载到容器。通过挂载根目录，监视应用将在进程状态发生改变时更新，反之亦然。我们为什么要关注进程而不是容器？容器就是进程，这是监控应用程序通过了解进程何时转换为统计信息以及进程与应用程序之间的关联的神奇之处。
哪个是最好的监控解决方案？
选择正确的监控解决方案不仅仅是开源 vs. 商业产品。选择解决方案时要谨慎考虑的问题–解决方案是否与容器协调器集成在一起，是否基于云，是否运行内部部署，是否应用集成，以及社区是否支持。这些主题中的每一个本身都可以成为选择解决方案的决定性因素。如果您想进一步探索这些主题，请了解 Docker 容器的监控和管理。
为了更好地协助您的决策过程，我创建了一个监控解决方案 Spider Graph Google 电子表格，以帮助您将目标与不同的产品进行可视化。
监控解决方案图说明：
值范围从 1(最不重要)到 5(最重要)。
-
“监控目标”行是每个类别的基准
-
填写 Coloumn A 中的名称，并与监控解决方案进行比较
-
使用 Spider Graph 来确定不同解决方案的功能
-
将目标基准值与不同的解决方案进行比较
您可以将监视解决方案 Spider 图进行比较。
总结
经过比较，您应该更加了解哪个监控解决方案最适合您的项目了。
这一期的『航海日志』就到这里，下期再浪～
参考链接
-
https://www.infoq.com/news/2017/08/containers-sdxcentral-survey
-
https://www.kubernetes.org.cn/2581.html
-
https://nickjanetakis.com/blog/docker-tip-17-breaking-up-long-lines-in-your-dockerfile
-
https://www.brianchristner.io/introduction-to-container-monitoring/
作者介绍
莫非 Beck：DaoCloud 微服务攻城狮，吃饱了就困的一流段子手。刘玺元 Boring：DaoCloud 市场部门（伪）萌新程序猿。
未经允许不得转载：DaoCloud道客博客 » 来自 SDXCentral 的调查：一年之内部署容器的量级增长了562%｜航海日志 Vol.26
