document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-13 22:30:37 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #5553 from geekpi/master

Browse Source 
translated
This commit is contained in:
geekpi 2017-05-11 12:50:19 +08:00 committed by GitHub
commit b82b36fc2c
2 changed files with 132 additions and 134 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

134
sources/tech/20170501 Containers running Containers.md
View File

@ -1,134 +0,0 @@
translating---geekpi
Containers running Containers
============================================================
Some genuinely exciting news piqued my interest at this year’s DockerCon, that being the new Operating System (OS), LinuxKit, which was announced and is immediately on offer from the undisputed heavyweight container company, Docker. 
The container giant has announced a flexible, extensible Operating System where system services run inside containers for portability. You might be surprised to hear that even includes the Docker runtime daemon itself.
In this article we’ll have a quick look at what’s promised in LinuxKit, how to try it out for yourself and at ever-shrinking, optimised containers.
**Less Is More**
There’s no denying that users have been looking for a stripped-down version of Linux to run their microservices upon. With containerisation you’re trying your hardest to minimise each application so that it becomes a standalone process which sits inside a container of its own. However constantly shifting containers around because you’re patching the host that the containers reside on causes issues. In fact without an orchestrator like Kubernetes or Docker Swarm that container-shuffling is almost always going to cause downtime.
Needless to say that’s just one reason to keep your OS as miniscule as possible; one of many.
A favourite quote I’ve repeated on a number of occasions, comes from the talented Dutch programmer, Wietse Zweitze, who brought us the e-mail stalwart Postfix and TCP Wrappers amongst other renowned software.
The Postfix website ([Postfix TLS_README][10]) states that even if you’re as careful with your coding as Wietse that for “every 1000 lines [you] introduce one additional bug into Postfix.” From my professional DevSecOps perspective by the mention of “bug” I might be forgiven for loosely translating that definition into security issues too.
From a security perspective it’s precisely for this reason that less-is-more in the world of code. Simply put there’s a number of benefits to using less lines of code; namely security, administration time and performance. For starters there’s less security bugs, less time updating packages and faster boot times.
**Look deeper inside**
Think about what runs your application from inside a container.
A good starting point is Alpine Linux ([https://alpinelinux.org/downloads][1]) which is a low-fat, boiled-down, reduced OS commonly preferred over the more bloated host favourites, such as Ubuntu or CentOS. Alpine also provides a miniroot filesystem (for use within containers) which comes in at a staggering 1.8MB at the last check. Indeed the ISO download for a fully-working Linux Operating System comes in at a remarkable 80MB in size.
If you decide to utilise a Docker base image from Alpine Linux then you can find one on the Docker Hub ([https://hub.docker.com/_/alpine][2]) where Alpine Linux describes itself as: “A minimal Docker image based on Alpine Linux with a complete package index and only 5 MB in size!”.
It’s been said, and I won’t attempt to verify this meme, that the ubiquitous Window Start Button is around the same filesize! I’ll refrain from commenting further.
In all seriousness hopefully that gives you an idea of the power of innovative Unix-type OSs like Alpine Linux.
**Lock everything up**
What’s more, it goes on to explain that Alpine Linux is (not surprisingly) based on BusyBox ([BusyBox][3]), the famous set of Linux commands neatly packaged which many people won’t be aware sits inside their broadband router, smart television and of course many IoT devices in their homes as they read this.
Comments on the the About page ([Alpine Linux][4]) of the Alpine Linux site states:
“Alpine Linux was designed with security in mind. The kernel is patched with an unofficial port of grsecurity/PaX, and all userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and other vulnerabilities.”
In other words the boiled-down binaries bundled inside the Alpine Linux builds which offers the system its functionality have already been sieved through clever industry-standard security tools in order to help mitigate buffer overflow attacks.
**Odd socks**
Why do the innards of containers matter when we’re dealing with Docker’s new OS you may quite rightly ask?
Well, as you might have guessed, when it comes to containers their construction is all about losing bloat. It’s about not including anything unless it’s absolutely necessary. It’s about having confidence so that you can reap the rewards of decluttering your cupboards, garden shed, garage and sock drawer with total impunity.
Docker certainly deserve some credit for their foresight. Reportedly, early 2016 Docker hired a key driving force behind Alpine Linux, Nathaniel Copa, who helped switch the default, official image library away from Ubuntu to Alpine. The bandwidth that Docker Hub saved from the newly-streamlined image downloads alone must have been welcomed.
And, bringing us up-to-date, that work will stand arm-in-arm with the latest container-based OS work; Docker’s LinuxKit.
For clarity LinuxKit is not ever-likely destined to replace Alpine but rather to sit underneath the containers and act as a stripped-down OS that you can happily spin up your runtime daemon (in this case the Docker daemon which spawns your containers) upon.
**Blondie's Atomic**
A finely-tuned host is by no means a new thing (I mentioned the household devices embedded with Linux previously) and the evil geniuses who have been optimising Linux for the last couple of decades realised sometime ago that the underlying OS was key to churning out a server estate fulls of hosts brimming with containers.
For example the mighty Red Hat have long been touting Red Hat Atomic ([https://www.redhat.com/en/resources/red-hat-enterprise-linux-atomic-host][5]) having contributed to Project Atomic ([Project Atomic][6]). The latter goes on to explain:
“Based on proven technology either from Red Hat Enterprise Linux or the CentOS and Fedora projects, Atomic Host is a lightweight, immutable platform, designed with the sole purpose of running containerized applications.”
There’s good reason that the underlying, immutable Atomic OS is forwarded as the recommended choice with Red Hat’s OpenShift PaaS (Platform as a Service) product. It’s minimal, performant and sophisticated.
**Features**
The mantra that less-is-more was evident throughout Docker’s announcement regarding LinuxKit. The project to realise the vision of LinuxKit was apparently no small undertaking and with the guiding hand of expert Justin Cormack, a Docker veteran and master with unikernels ([https://en.wikipedia.org/wiki/Unikernel][7]), and in partnership with HPE, Intel, ARM, IBM and Microsoft LinuxKit can run on mainframes as well as IoT-based fridge freezers.
The configurable, pluggable and extensible nature of LinuxKit will appeal to many projects looking for a baseline upon which to build their services. By open-sourcing the project Docker are wisely inviting input from every man and their dog to contribute to its functionality which will mature like a good cheese undoubtedly over time.  
**Proof of the pudding**
Having promised to point those eager to get going with this new OS, let us wait no longer. If you want to get your hands on LinuxKit you can do so from the GitHub page here: [LinuxKit][11]
On the GitHub page there’s instructions on how to get up and running along with some features.
Time permitting I plan to get my hands much dirtier with LinuxKit. The somewhat-contentious Kubernetes versus Docker Swarm orchestration capabilities will be interesting to try out. I’d like to see memory footprints, boot times and diskspace-usage benchmarking too.
If the promises are true then pluggable system services which run as containers is a fascinating way to build an OS. Docker blogged ([https://blog.docker.com/2017/04/introducing-linuxkit-container-os-toolkit][12]) the following on its tiny footprint: “Because LinuxKit is container-native, it has a very minimal size – 35MB with a very minimal boot time. All system services are containers, which means that everything can be removed or replaced.”
I don’t know about you but that certainly whets my appetite.
**Call the cops**
Features aside with my DevSecOps hat on I will be in seeing how the promise of security looks in reality.
Docker quotes from NIST (the National Institute of Standards and Technology: [https://www.nist.gov][8]) and claims on their blog that:
“Security is a top-level objective and aligns with NIST stating, in their draft Application Container Security Guide: “Use container-specific OSes instead of general-purpose ones to reduce attack surfaces. When using a container-specific OS, attack surfaces are typically much smaller than they would be with a general-purpose OS, so there are fewer opportunities to attack and compromise a container-specific OS.”
Possibly the most important container-to-host and host-to-container security innovation will be the fact that system containers (system services) are apparently heavily sandboxed into their own unprivileged space, given just the external access that they need.
Couple that functionality with the collaboration of the Kernel Self Protection Project (KSPP) ([https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project][9]) and with a resounding thumbs-up from me it looks like Docker have focussed on something very worthwhile. For those unfamiliar KSPP’s raison d’etre is as follows:
“This project starts with the premise that kernel bugs have a very long lifetime, and that the kernel must be designed in ways to protect against these flaws.”
The KSPP site goes on to state admirably that:
“Those efforts are important and on-going, but if we want to protect our billion Android phones, our cars, the International Space Station, and everything else running Linux, we must get proactive defensive technologies built into the upstream Linux kernel. We need the kernel to fail safely, instead of just running safely.”
And, initially, if Docker only take baby steps with LinuxKit the benefit that it will bring over time through maturity will likely make great strides in the container space.
**The End is far from nigh**
As the powerhouse that is Docker continues to grow arms and legs there’s no doubt whatsoever that these giant-sized leaps in the direction of solid progress will benefit users and other software projects alike.
I would encourage all with an interest in Linux to closely watch this (name)space...
--------------------------------------------------------------------------------
via: http://www.devsecops.cc/devsecops/containers.html
作者：[Chris Binnie ][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者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

132
translated/tech/20170501 Containers running Containers.md Normal file
View File

@ -0,0 +1,132 @@
容器中运行容器
============================================================
一些令人振奋的消息引发了我对今年 DockerCon 的兴趣，在会议中宣布了一个新的操作系统（OS）LinuxKit，并由无可争议的容器巨头公司 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