TranslateProject/translated/tech/20170501 Containers running Containers.md
2017-05-11 12:49:30 +08:00

133 lines
9.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

容器中运行容器
============================================================
一些令人振奋的消息引发了我对今年 DockerCon 的兴趣在会议中宣布了一个新的操作系统OSLinuxKit并由无可争议的容器巨头公司 Docker 提供。
容器巨头已经宣布了一个灵活的、可扩展的操作系统,为了可移植性系统服务在其内运行。当你听到包括 Docker 运行时也在内时,你可能会感到惊讶。
在本文中,我们将简要介绍一下 LinuxKit 中承诺的内容,以及如何自己尝试并不断缩小优化容器。
**少即是多**
不可否认的是,用户一直在寻找一个被剥离版本的 Linux 来运行他们的微服务。通过容器化,你会尽可能地减少每个应用程序,使其成为一个位于其自身容器内的独立进程。但是,由于你对那些驻留容器主机的修补导致的问题,因此你不断地移动容器。实际上如果没有像 Kubernetes 或 Docker Swarm 这样的协调者,容器编排几乎总是会导致停机。
不用说,这只是让你保持操作系统尽可能小的原因之一。
我曾多次在不同场合重复过的最喜爱的名言,来自荷兰的天才程序员 Wietse Zweitze他为我们提供了 email 中的 Postfix 和 TCP Wrappers 等知名软件。
Postfix 网站([Postfix TLS_README][10])指出,即使你编码和 Wietse 一样小心,“每 1000 行[你]就会在 Postfix 中引入一个额外的错误”。从我的专业的 DevSecOps 角度提到我可以被原谅的 “bug” 可以不严谨地说成安全问题。
从安全的角度来看,正是由于这个原因,代码世界中“少即是多”。简单地说,使用较少的代码行有很多好处,即安全性、管理时间和性能。对于初学者来说,安全漏洞较少,更新软件包的时间更短,启动时间更快。
**深入观察**
考虑下从容器内部运行你的程序。
一个好的起点是 Alpine Linux[https://alpinelin.org.org/downloads][1]),它是一个精简化的操作系统,通常比那些笨重的系统更受喜欢,如 Ubuntu 或 CentOS 等。Alpine 还提供了一个 miniroot 文件系统(用于容器内),最后一次检测是惊人的 1.8M。事实上,完整的 Linux 操作系统下载后有 80M。
如果你决定使用 Alpine Linux 作为 Docker 基础镜像那么你可以在Docker Hub[https://hub.docker.com/_/alpine][2])上找到一个,其中 Alpine Linux 将自己描述为:“一个基于 Alpine Linux 的最小 Docker 镜像具有完整的包索引大小只有5 MB
据说无处不在的 “Window Start Button” 也是大致相同的大小!我不会尝试去验证,也不会进一步评论。
严肃地希望能让你了解创新的类 Unix 操作系统(如 Alpine Linux的强大功能。
**锁定一切**
再说一点Alpine Linux 是(并不惊人)基于 BusyBox[BusyBox][3]),一套著名的打包了 Linux 命令的集合,许多人不会意识到他们的宽带路由器、智能电视,当然还有他们家庭中的物联网设备就有它。
Alpine Linux 站点的“关于”页面([Alpine Linux][4])的评论中指出:
“Alpine Linux 的设计考虑到安全性。内核使用非官方的 grsecurity/PaX 移植进行修补所有用户态二进制文件都编译为具有堆栈保护的地址无关可执行文件PIE。 这些主动安全特性可以防止所有类别的零日和其他漏洞利用”
换句话说Alpine Linux 中的二进制文件捆绑在一起,提供了那些通过行业安全工具筛选的功能,以帮助缓解缓冲区溢出攻击。
**奇怪的袜子**
你可能会问,为什么当我们处理 Docker 的新操作系统时,容器的内部结构很重要?
那么,你可能已经猜到,当涉及容器时,他们的目标是精简。除非绝对必要,否则不包括任何东西。所以有信心的是,你可以在清理橱柜、花园棚子、车库和袜子抽屉后获得回报而没有惩罚。
Docker 的确因为它们的先见而获得声望。据报道2 月初Docker 聘请了 Alpine Linux 的主要推动者 Nathaniel Copa他帮助将默认的官方镜像库从 Ubuntu 切换到 Alpine。Docker Hub 从新近精简镜像节省的带宽受到了欢迎。
并且最新的情况是这项工作将与最新的基于容器的操作系统相结合Docker 的 LinuxKit。
要说清楚的是 LinuxKit 不会注定代替 Alpine而是位于容器下层并作为一个完整的操作系统你可以高兴地启动你的运行时守护程序在这种情况下在容器中产生 Docker 守护程序)。
**Blondie Atomic **
经过精心调试的主机绝对不是一件新事物(以前提到过嵌入式 Linux 的家用设备)。在过去几十年中一直在优化 Linux 的天才在某个时候意识到底层的操作系统是快速生产含有大量容器主机的关键。
例如,强大的红帽长期以来一直在出售已经贡献给 Project Atomic ([Project Atomic][6]) 的 Red Hat Atomic[https://www.redhat.com/en/resources/red-hat-enterprise-linux-atomic-host][5])。后者继续解释:
“基于 Red Hat Enterprise Linux 或 CentOS 和 Fedora 项目的成熟技术Atomic Host 是一个轻量级的、不可变的平台,其设计目的仅在于运行容器化应用程序。
有一个很好理由将底层的、不可变的 Atomic OS 作为 Red Hat OpenShift PaaS平台即服务产品推荐。它最小化、高性能、尖端。
**特性**
在 Docker 关于 LinuxKit 的公告中,少即是多的口号是显而易见的。实现 LinuxKit 愿景的项目显然是不小的事业,它由 Docker 老将和 Unikernels[https://en.wikipedia.org/wiki/Unikernel][7])的主管 Justin Cormack 指导,并与 HPE、Intel、ARM、IBM 和 Microsoft LinuxKit 合作,可以在大型机以及基于物联网的冰柜中运行。
LinuxKit 的可配置、可插拔和可扩展性质将吸引许多项目寻找建立其服务的基准。通过开源项目Docker 明智地邀请每个男人和他们的狗投入其功能开发,随着时间的推移,它会像好的奶酪那样成熟。
**布丁的证明**
有承诺称那些急于使用新系统的人不用再等待了。如果你准备着手 LinuxKit你可以从 GitHub 中开始:[LinuxKit][11]
在 GitHub 页面上有关于如何启动和运行一些功能的指导。
时间允许的话我准备更加深入 LinuxKit。有争议的 Kubernetes 与 Docker Swarm 编排功能对比会是有趣的尝试。我还想看到内存占用、启动时间和磁盘空间使用率的基准测试。
如果承诺是真实的则作为容器运行的可插拔系统服务是构建操作系统的迷人方式。Docker 在博客([https://blog.docker.com/2017/04/introducing-linuxkit-container-os-toolkit][12])中提到:“因为 LinuxKit 是原生容器,它有一个非常小的尺寸 - 35MB引导时间非常小。所有系统服务都是容器这意味着可以删除或替换所有的内容。“
我不知道你怎么样,但这非常符合我的胃口。
**呼叫警察**
除了站在我 DevSecOps 角度看到的功能,我将看到承诺的安全在现实中的面貌。
Docker 引用来自 NIST国家标准与技术研究所[https://www.nist.gov] [8]),并在他们的博客上声称:
安全性是最高目标,这与 NIST 在其“应用程序容器安全指南”草案中说明的保持一致:“使用容器专用操作系统而不是通用操作系统来减少攻击面。当使用专用容器操作系统时,攻击面通常比通用操作系统小得多,因此攻击和危及专用容器操作系统的机会较少。”
可能最重要的容器到主机和主机到容器的安全创新将是系统容器(系统服务)被完全地沙箱化到自己的非特权空间中,而只给它们需要的外部访问。
通过内核自我保护项目KSPP[https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project][9])的协作来实现这一功能,我很满意 Docker 开始专注于一些非常值得的东西上。对于那些不熟悉的 KSPP 的人而言,它存在理由如下:
“启动这个项目的的假设是内核 bug 的存在时间很长,内核必须设计成防止这些缺陷。”
KSPP 网站继续表态:
“这些努力非常重要并还在进行,但如果我们要保护我们的十亿 Android 手机、我们的汽车、国际空间站,还有其他运行 Linux 的产品,我们必须在上游的 Linux 内核中建立积极的防御性技术。我们需要内核安全地错误,而不只是安全地运行。”
而且,如果 Docker 最初只能在 LinuxKit 前进一小步,那么随着时间的推移,成熟度带来的好处可能会在容器领域中取得长足的进步。
**离终点还远**
像 Docker 这样不断发展壮大的集团无论在哪个方向上取得巨大的飞跃都将会用户和其他软件带来益处。
我鼓励所有对 Linux 感兴趣的人密切关注这个领域。
--------------------------------------------------------------------------------
via: http://www.devsecops.cc/devsecops/containers.html
作者:[Chris Binnie ][a]
译者:[geekpi](https://github.com/geekpi)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]:http://www.devsecops.cc/
[1]:https://alpinelinux.org/downloads/
[2]:https://hub.docker.com/_/alpine
[3]:https://busybox.net/
[4]:https://www.alpinelinux.org/about/
[5]:https://www.redhat.com/en/resources/red-hat-enterprise-linux-atomic-host
[6]:http://www.projectatomic.io/
[7]:https://en.wikipedia.org/wiki/Unikernel
[8]:https://www.nist.gov/
[9]:https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
[10]:http://www.postfix.org/TLS_README.html
[11]:https://github.com/linuxkit/linuxkit
[12]:https://blog.docker.com/2017/04/introducing-linuxkit-container-os-toolkit