写点什么

《Using Docker》书评和与作者 Adrian Mouat 的问答

  • 2016-06-15
  • 本文字数:5273 字

    阅读完需:约 17 分钟

Docker 在 2013 年三月实现了开源发布,它的出现让软件开发行业对于现代化应用的打包以及部署方式发生了巨大的变化。紧随着 Docker 的发布,各种具有竞争性、致敬性以及支持性的容器技术纷纷涌现,为这一领域带来了极大的关注度,同时也引起了人们的反思。这一系列文章将解答读者的各种困惑,对如何在企业中实际使用容器进行分析。

这一系列文章首先将对容器背后的核心技术进行观察,了解开发者目前如何使用容器,随后将分析在企业中部署容器的核心挑战,例如如何将容器技术与持续集成和持续交付管道进行集成,并对监控方式进行改进,以支持不断变化的负载,以及使用短期容器的潜在需求。本系列文章的总结部分将对容器技术的未来进行分析,并探讨无核化技术(unikernels)目前在处于技术前沿的组织中所扮演的角色。

本文是本系列文章“实际应用中的容器 —— 远离炒作”中的其中一篇。你可以通过RSS订阅该系列文章,以获取更新的通知。

InfoQ 近期与《Using Docker》的作者 Adrian Mouat 进行了一次访谈,探讨了编写本书的动机;Docker 为什么能够在这么短时间内获得整个 IT 行业关注的原因;以及在传统的软件开发生命周期中如何以最佳的方式使用容器等话题。

《Using Docker》一书共分为三个部分:背景与基础部分、在软件开发生命周期中使用 Docker,以及工具和技术部分。第一部分涵盖了 Docker 出现的历史背景以及它的发展,提供了在各种平台上进行安装的详细说明,并分析了容器背后的基础原理。本书介绍了一个用 Python 编写的 web 应用,并通过 Docker 进行部署。在本书对应的 GitHub 仓库“ using-docker ”中可以下载该示例应用的代码,读者可以按照其中的步骤对应用程序进行“Docker 化”。

第二部分专注于分析如何在传统的软件开发生命周期中使用 Docker。深入地描述了如何创建一个简单的 web 应用并完成打包和执行,并探讨了一些特定于容器的概念,例如镜像的分布、卷组的挂载以及 Docker 的网络设置。Mouat 将容器的概念与它在传统的持续集成流程中的使用进行了关联,在示例中使用了读者熟悉的工具,例如 Jenkins。本书第二部分的总结部分对容器的监控以及通过 ElasticSearch/Logstash/Kibana(ELK)技术栈进行日志记录进行了深入的讨论。

本书的最后一部分,即第三部分对工具与技术进行了详细讲述,从中级难度起逐步讲到高级难度的内容(读者需要掌握本书前两部分的知识),并涵盖了网络与服务发现方面的详细内容,以及编排与集群方面的主题,和 Docker Swarm Mesos 以及 Kubernetes 等平台的应用。本书的最后一章对于容器的安全性进行了全面的探讨,内容包括在“最小权限”下运行容器、镜像源、以及如何限制对底层 host 操作系统资源的访问。

InfoQ 与 Mouat 进行了一次访谈,所讨论的问题包括 Docker 本身、容器对于软件开发生命周期带来的影响、以及他对于 Docker 未来发展的展望。

InfoQ:Adrian,欢迎你来到 InfoQ!你能否简单地做个自我介绍,并为读者解释一下你选择编写这本《Using Docker》的原因?

Adrian Mouat:我名叫 Adrian Mouat,目前正在参与建立 Container Solutions Labs 的工作,这是 Container Solutions 的一家姐妹公司,它将专注于开发容器与微服务这一领域的产品与服务。在这之前,我一直致力于软件开发方面的工作,曾参与各种不同类型的项目,包括大型的数据处理框架,乃至小型的 web 应用。在我之前所任职的一家公司里,我首次接触到 Docker,当时我们使用它为一个小型的 Python web 应用建立了一个持续部署(CD)工作流。我对于 Docker 这一解决方案的优雅与灵活性所深深打动,促使我专门为此撰写了一篇博客文章。O’Reilly 看到了我的博客后与我取得了联系,并问我是否有兴趣为推出一本 Docker 方面的书籍写一份提议。谢天谢地,他们认可了我的提议。于是,在这之后的一年半时间里,Docker 就成为了我生活的全部!

InfoQ:你对容器的兴趣来自何处?在你看来,为什么容器技术能够获得这么大的关注度呢?

Mouat:我相信容器会成为常规的软件工作流中的一个标准组成部分,它为计算带来了许多新的可能性,例如不可变基础设施和不同环境之间的可移植性。一些在 VM 中难以实现的任务,换做容器就可以简单许多,这一点要归功于容器的速度与大小,它满足了开发者对快速反馈周期的迫切需求。组织必须对这一技术加以关注,因为如果容器能够让某个工作流的效率提高几个百分比,那么这就让该组织比其竞争者能够更快地发展。尽管它的优点如此明显,但我仍对于容器技术能够这样快地获得行业的关注感到惊讶。

InfoQ:如果某个组织已有拥抱 Docker 的打算,那么在软件开发生命周期的哪个部分是最适合引入容器技术的呢?

Mouat:这个问题问得好。Docker 可帮助组织处理各个领域中的问题。引入 Docker 的一个较好的时机是通过它搭建持续集成(CI)或测试环境,如果设置得当,那么它能够极大地加快开发管道,同时也不会造成破坏生产环境的风险。不过,要想获得最大的价值,你需要在整个生命周期中使用容器技术,让开发者创建这些镜像、通过 CI 发布这些镜像、并交付给运维团队以部署。如果一切顺利,你就能够将开发环境与生产环境之间的差异性降至最低,根除了许多可能发生的问题,例如“在我的机器上是正常的”这种问题。当然,大多数组织都不希望一次性进行太多改变。与运维人员相比,开发者更愿意开始使用 Docker,因为酷炫的新工具对于他们来说有着天然的吸引力,而运维人员更专注于如何保持产品的稳定运行。我相信,随着 Docker 证明自己是一个可信赖的技术,运维人员开始认同容器为部署工作带来的益处,这一现状将逐渐得到改变。

InfoQ:我曾看到你在 Twitter 上的一条留言,你表示 Docker 的快速发展导致相关书籍很难保证其时效性。那么你是否认为 Docker 的发展过快了,你又打算怎样跟上它的脚步呢?

Mouat:Docker 的发展确实很快。本书的第一版涵盖了 Docker 1.8 的内容,某些 Linux 分发版本上的包还落后于这个版本。而编排框架以及其他各种工具同样难以做到跟上这一发展速度,有时他们仅支持旧版本的 Docker。不过,我相信这种变化速度已经逐渐开始放缓了。因为人们最担心的是具破坏性的变更,而 API 及其格式的变更恰恰会对现有工具与代码示例造成破坏,所以目前针对此问题已经开始对基础 API 及其格式进行了固化和标准化,使之在很大程度上得到了缓解。此外,随着 Docker 代码库的逐渐庞大以及使用者数量的提高,要进行一些大规模的变更时,就必须预先进行大量的思考与咨询。

InfoQ:与 VM 相比,容器的安全性目前处于什么水平?

Mouat:这是一个很常见的问题。首先要指出一点,选择容器还是 VM 这本身就是一个伪命题,你完全可以同时使用这两种技术(而且你很可能会这么做)。

虽然如此,但很多人还是会将两者进行对比,而这一话题也非常有趣。

许多人认为 VM 更加安全,原因如下:

  1. VM 技术出现时间相对较早,是一种可信赖的技术 ;
  2. 每个 VM 都有自己的 kernel,这与主机中的 kernel 是分离的。而在 Docker 中,容器将共享主机的 kernel。

但另一方面,容器也为人们提供了许多安全特性,比方说用户可以很方便地创建一个小型容器,其中只有相对很小的受攻击面;或是在运行的容器中使用只读的文件系统,以及有限的权限集。Docker 已承诺在这一领域的持续改进,近期就包括对用户命名空间以及 seccomp 的支持。

InfoQ:对于希望保证运行容器的安全性的读者,你有什么建议?

Mouat:牢记最小权限的原则,对于容器来说,这就意味着容器应当仅能够访问为实现其功能所必需的数据与资源。有几种方式可以实现这一点,包括:

  • 将文件系统设置为只读;
  • 限制某个容器能够访问的内存大小;
  • 将网络访问与其他容器进行隔离;
  • 减少某个窗口能够执行的 kernel 调用。

如果你希望了解最小权限概念的更多相关知识,请参考由 Nathan McCauley 和 Diogo Mónica 所做的演讲“最小权限的微服务”。此外,在免费的迷你书《Docker Secrity》(需要注册)中完整地涵盖了以上各种方法乃至更多的方法,其中的内容来自于《Using Docker》一书。

InfoQ:在过去一年间,Docker 的网络与存储方面产生了很大的变化。你认为这些主题是否已经达到稳定的程度了(具体说来,libnetwork 方面的讨论正方兴未艾)?

Mouat:我认为这方面的技术还不稳定。正如你刚刚所提到的讨论,这也是为什么 Kubernetes 项目声明他们不支持 Docker 网络模型的原因。此外,值得注意的是,Weave 仍建议用户使用独立的二进制文件,它会在 Docker 客户端与 deamon 之间插入一个代理,因为在他们看来,代理能够提供一个更清晰、更简单的接口,可以减少所面对的问题。不过,这一点可能会随着时间而产生变化,我还想强调一点,即使不使用代理,也是有可能将 Weave 直接作为插件而使用的。在存储方面的不同意见似乎没有这么多,这可能是因为用于支持各种实现的钩子之间的区别并不大,不过这只是我个人的意见而已。

InfoQ:与容器相关的集群管理以及编排工具,例如 Mesos、Kubernetes、Docker Cloud,也得到了很大的发展。你对于这些技术的应用有什么想法?

Mouat:这一领域已经成为了一个真正的战场。Docker Cloud(曾命名为 Tutum)是 Docker Inc 推出的 SaaS 产品,预计将会集成对 Swarm 的支持,以实现集群及编排功能。Mesos 已经在几家大公司中得到了应用,它的发展历史也最久。Google 则力推 Kubernetes 框架,这是他们基于过去十年间在内部使用容器的经验所开发的一套非常强大的框架。现在还很难预测最终的结果会是如何,而由 Hashicorp 推出的 Nomad 也想分一杯羹。

InfoQ:你认为各公司是否已经准备好应对在使用容器过程中所面对的各种运维挑战,例如日志记录以及监控?

Mouat:使用容器技术时,监控方面的问题就会变得非常突出,尤其在你选择了微服务架构时更为明显。因为你很可能会创建上千个短期的容器,而传统的监控工具很难跟上这方面的需求。Lukasz Guminski 是我在 Container Solutions 的一位同事,他为此专门撰写了一篇深度文章。而Adrian Cockcroft 对于这一主题也撰写了大量的文章,进行了多次演讲,包括在InfoQ 上发布的这篇文章。好消息是,这一领域出现了许多新公司与新产品,例如 Ruxit Prometheus Weave Scope 。虽然目前已经出现了一些可以选择的解决方案,但我期待在这一领域会出现更多的创新与发展。对于希望向容器技术迁移的公司,我建议他们要注意这方面的问题,选择能够帮助他们的工具。

InfoQ:你对于容器技术在 2016 年的发展有什么看法?

Mouat:我对于编排方面的发展最感兴趣。如果 Kubernetes 最终能够占据编排与集群这一领域的主导地位,那么他们可能会转而选择不同的容器运行时(例如从 Docker 切换至 rkt),这对于 Docker 将是一次沉重的打击。我期待这一领域会出现许多大动作以及相关讨论。

我们还将看到更多使用 Docker API 的不同实现。由 Joyent 推出的 Triton 就是一个优秀的工具,它通过使用一个基于 SmartOS 和 LX-branded 区域所构建的自定义 Docker 引擎,能够提供对 Docker 容器的裸机托管。此外,在轻量级 VM 即容器方面也会有很大的发展,包括由 VMWare 推出的 Bonneville(现在叫做 vSphere Integrated Containers),以及 Intel 所推出的 Clear Container。最后,我们也一定会看到无核(unikernel)技术的发展,无核是指将 kernel 与 OS 进行最精简化,只提供运行某个应用所必需的功能。Docker Inc 近期对 Unikernel Systems 的收购意味着我们很快就会看到标准 API 工具中对无核的支持。无核技术面临着很多压力与争议,但对于物联网(IOT)、以及其他一些看重低资源消耗以及最小受攻击面的领域来说,无核似乎是一种很好的选择。

在 O’Reilly Media 网站上可以订购 Adrian Mouat 的著作《Using Docker》

关于受访者

Adrian Mouat是 Container Solutions 的首席科学家,这是一家跨全欧洲的服务公司,专注于 Docker 与 Mesos 方面的服务。Mouat 也是《Using Docker: Developing and Deploying Software with Containers》这本由 O’Reilly 出版的书籍的作者。他曾经参与了各种不同的软件项目的开发工作,包括小型的 web 应用乃至大规模的数据分析软件。

Docker 在 2013 年三月实现了开源发布,它的出现让软件开发行业对于现代化应用的打包以及部署方式发生了巨大的变化。紧随着 Docker 的发布,各种具有竞争性、致敬性以及支持性的容器技术纷纷涌现,为这一领域带来了极大的关注度,同时也引起了人们的反思。这一系列文章将解答读者的各种困惑,对如何在企业中实际使用容器进行分析。

这一系列文章首先将对容器背后的核心技术进行观察,了解开发者目前如何使用容器,随后将分析在企业中部署容器的核心挑战,例如如何将容器技术与持续集成和持续交付管道进行集成,并对监控方式进行改进,以支持不断变化的负载,以及使用短期容器的潜在需求。本系列文章的总结部分将对容器技术的未来进行分析,并探讨无核化技术(unikernels)目前在处于技术前沿的组织中所扮演的角色。

本文是本系列文章“实际应用中的容器 —— 远离炒作”中的其中一篇。你可以通过 RSS订阅该系列文章,以获取更新的通知。

查看英文原文“Using Docker” Book Review and Q&A with Author Adrian Mouat

2016-06-15 19:161735
用户头像

发布了 428 篇内容, 共 182.4 次阅读, 收获喜欢 39 次。

关注

评论

发布
暂无评论
发现更多内容

代码随想录Day18 - 二叉树(五)

jjn0703

华为云ROMA Connect 的智能集成 – 现代企业数字化转型的新利器

华为云PaaS服务小智

云计算 华为云 华为开发者大会

大佬带你体验华为云代码检查服务CodeArts Check

华为云PaaS服务小智

云计算 开发者 软件开发 华为云

人工智能大语言模型微调技术:SFT 监督微调、LoRA 微调方法、P-tuning v2 微调方法、Freeze 监督微调方法| 社区征文

汀丶人工智能

LoRa NLP 大模型 LLM模型 年中技术盘点 Freeze微调

新一代iPaaS全域融合集成平台ROMA Connect HDC.Cloud 2023内容值得再读!

华为云PaaS服务小智

华为 华为云 华为开发者大会2023

JMeter笔记15 | JMeter场景运行

单元测试 Jmeter 性能测试 自动化测试 接口测试

Python如何获取页面上某个元素指定区域的html源码?

Python 源码 HTML5, CSS3

每日站会如此简单,为什么总是开不好?

敏捷开发

项目管理 Scrum 敏捷开发 每日站会

我与OpenHarmony| 社区征文

坚果

年中技术盘点

少年侠客【InsCode Stable Diffusion美图活动一期】 | 社区征文

度假的小鱼

Stable Diffusion 年中技术盘点

“数字孪生”:为什么要仿真嵌入式系统?

DevOps和数字孪生

数字孪生 嵌入式系统仿真

虚拟ECU实践:汽车发动机控制器仿真

DevOps和数字孪生

软件定义汽车 虚拟ECU

从0到1:跑团小程序开发心得笔记

CC同学

Nautilus Chain NautDID NFT 将上主网,Layer3 数字身份时代开启

股市老人

CodeArts Check系统规则集还不够?带你体验如何创建、启用自定义规则集

华为云PaaS服务小智

云计算 开发者 代码质量 华为云 代码检查

华为云CodeArts Check IDE插件体验之旅

华为云PaaS服务小智

云计算 软件开发 华为云 华为开发者大会2023 代码检查

JMeter笔记14 | JMeter场景设计和设置

单元测试 Jmeter 性能测试 自动化测试 接口测试

测试工程师如何做到初级测试管理(个人思考)?

团队管理 测试 测试管理 测试部门职责

在 Go 中如何编写测试代码

江湖十年

golang 测试 后端 单元测试 go语言

红队攻防之JS攻防

权说安全

网络攻防

区块链第一代系统——比特币概念及业务流程

TiAmo

比特币 区块链

2023-07-16:讲一讲Kafka与RocketMQ中零拷贝技术的运用?

福大大架构师每日一题

福大大架构师每日一题

人工智能自然语言处理:N-gram和TF-IDF模型详解

汀丶人工智能

人工智能 自然语言处理 nlp tf-idf N-gram

领导和团队的自主权——《敏捷实战-破解敏捷落地的60个难题》读后感(二)

Bruce Talk

敏捷开发 Agile

来自内部有很多需求,如何协调处理这些需求?

Bonaparte

产品 产品设计 产品思维 产品需求 内部需求

享受云原生技术红利,大数据不应该被落下

智领云科技

云原生 Kubernetes 集群 云原生大数据平台 智领云

什么是“软件定义汽车”

DevOps和数字孪生

软件定义汽车 汽车仿真

《Using Docker》书评和与作者Adrian Mouat的问答_Book Review_Daniel Bryant_InfoQ精选文章