mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
Merge pull request #20728 from Chao-zhi/translate-MjAxOTAyMjAgRG8gTGludXggZGlzdHJpYnV0aW9ucyBzdGlsbCBtYXR0ZXIgd2l0aCBjb250YWluZXJzLm1kCg==
translate done: 20190220 Do Linux distributions still matter with con…
This commit is contained in:
geekpi
GitHub
commit
03160d1ddb
@ -1,87 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (Chao-zhi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Do Linux distributions still matter with containers?)
|
||||
[#]: via: (https://opensource.com/article/19/2/linux-distributions-still-matter-containers)
|
||||
[#]: author: (Scott McCarty https://opensource.com/users/fatherlinux)
|
||||
|
||||
Do Linux distributions still matter with containers?
|
||||
======
|
||||
There are two major trends in container builds: using a base image and building from scratch. Each has engineering tradeoffs.
|
||||
|
||||
|
||||
Some people say Linux distributions no longer matter with containers. Alternative approaches, like distroless and scratch containers, seem to be all the rage. It appears we are considering and making technology decisions based more on fashion sense and immediate emotional gratification than thinking through the secondary effects of our choices. We should be asking questions like: How will these choices affect maintenance six months down the road? What are the engineering tradeoffs? How does this paradigm shift affect our build systems at scale?
|
||||
|
||||
It's frustrating to watch. If we forget that engineering is a zero-sum game with measurable tradeoffs—advantages and disadvantages, with costs and benefits of different approaches— we do ourselves a disservice, we do our employers a disservice, and we do our colleagues who will eventually maintain our code a disservice. Finally, we do all of the maintainers ([hail the maintainers!][1]) a disservice by not appreciating the work they do.
|
||||
|
||||
### Understanding the problem
|
||||
|
||||
To understand the problem, we have to investigate why we started using Linux distributions in the first place. I would group the reasons into two major buckets: kernels and other packages. Compiling kernels is actually fairly easy. Slackware and Gentoo (I still have a soft spot in my heart) taught us that.
|
||||
|
||||
On the other hand, the tremendous amount of development and runtime software that needs to be packaged for a usable Linux system can be daunting. Furthermore, the only way you can ensure that millions of permutations of packages can be installed and work together is by using the old paradigm: compile it and ship it together as a thing (i.e., a Linux distribution). So, why do Linux distributions compile kernels and all the packages together? Simple: to make sure things work together.
|
||||
|
||||
First, let's talk about kernels. The kernel is special. Booting a Linux system without a compiled kernel is a bit of a challenge. It's the core of a Linux operating system, and it's the first thing we rely on when a system boots. Kernels have a lot of different configuration options when they're being compiled that can have a tremendous effect on how hardware and software run on one. A secondary problem in this bucket is that system software, like compilers, C libraries, and interpreters, must be tuned for the options you built into the kernel. Gentoo taught us this in a visceral way, which turned everyone into a miniature distribution maintainer.
|
||||
|
||||
Embarrassingly (because I have worked with containers for the last five years), I must admit that I have compiled kernels quite recently. I had to get nested KVM working on RHEL 7 so that I could run [OpenShift on OpenStack][2] virtual machines, in a KVM virtual machine on my laptop, as well as [our Container Development Kit (CDK][3]). #justsayin Suffice to say, I fired RHEL7 up on a brand new 4.X kernel at the time. Like any good sysadmin, I was a little worried that I missed some important configuration options and patches. And, of course, I had missed some things. Sleep mode stopped working right, my docking station stopped working right, and there were numerous other small, random errors. But it did work well enough for a live demo of OpenShift on OpenStack, in a single KVM virtual machine on my laptop. Come on, that's kinda' fun, right? But I digress…
|
||||
|
||||
Now, let's talk about all the other packages. While the kernel and associated system software can be tricky to compile, the much, much bigger problem from a workload perspective is compiling thousands and thousands of packages to give us a useable Linux system. Each package requires subject matter expertise. Some pieces of software require running only three commands: **./configure** , **make** , and **make install**. Others require a lot of subject matter expertise ranging from adding users and configuring specific defaults in **etc** to running post-install scripts and adding systemd unit files. The set of skills necessary for the thousands of different pieces of software you might use is daunting for any single person. But, if you want a usable system with the ability to try new software whenever you want, you have to learn how to compile and install the new software before you can even begin to learn to use it. That's Linux without a Linux distribution. That's the engineering problem you are agreeing to when you forgo a Linux distribution.
|
||||
|
||||
The point is that you have to build everything together to ensure it works together with any sane level of reliability, and it takes a ton of knowledge to build a usable cohort of packages. This is more knowledge than any single developer or sysadmin is ever going to reasonably learn and retain. Every problem I described applies to your [container host][4] (kernel and system software) and [container image][5] (system software and all other packages)—notice the overlap; there are compilers, C libraries, interpreters, and JVMs in the container image, too.
|
||||
|
||||
### The solution
|
||||
|
||||
You already know this, but Linux distributions are the solution. Stop reading and send your nearest package maintainer (again, hail the maintainers!) an e-card (wait, did I just give my age away?). Seriously though, these people do a ton of work, and it's really underappreciated. Kubernetes, Istio, Prometheus, and Knative: I am looking at you. Your time is coming too, when you will be in maintenance mode, overused, and underappreciated. I will be writing this same article again, probably about Kubernetes, in about seven to 10 years.
|
||||
|
||||
### First principles with container builds
|
||||
|
||||
There are tradeoffs to building from scratch and building from base images.
|
||||
|
||||
#### Building from base images
|
||||
|
||||
Building from base images has the advantage that most build operations are nothing more than a package install or update. It relies on a ton of work done by package maintainers in a Linux distribution. It also has the advantage that a patching event six months—or even 10 years—from now (with RHEL) is an operations/systems administrator event (yum update), not a developer event (that requires picking through code to figure out why some function argument no longer works).
|
||||
|
||||
Let's double-click on that a bit. Application code relies on a lot of libraries ranging from JSON munging libraries to object-relational mappers. Unlike the Linux kernel and Glibc, these types of libraries change with very little regard to breaking API compatibility. That means that three years from now your patching event likely becomes a code-changing event, not a yum update event. Got it, let that sink in. Developers, you are getting paged at 2 AM if the security team can't find a firewall hack to block the exploit.
|
||||
|
||||
Building from a base image is not perfect; there are disadvantages, like the size of all the dependencies that get dragged in. This will almost always make your container images larger than building from scratch. Another disadvantage is you will not always have access to the latest upstream code. This can be frustrating for developers, especially when you just want to get something out the door, but not as frustrating as being paged to look at a library you haven't thought about in three years that the upstream maintainers have been changing the whole time.
|
||||
|
||||
If you are a web developer and rolling your eyes at me, I have one word for you: DevOps. That means you are carrying a pager, my friend.
|
||||
|
||||
#### Building from scratch
|
||||
|
||||
Scratch builds have the advantage of being really small. When you don't rely on a Linux distribution in the container, you have a lot of control, which means you can customize everything for your needs. This is a best-of-breed model, and it's valid in certain use cases. Another advantage is you have access to the latest packages. You don't have to wait for a Linux distro to update anything. You are in control, so you choose when to spend the engineering work to incorporate new software.
|
||||
|
||||
Remember, there is a cost to controlling everything. Often, updating to new libraries with new features drags in unwanted API changes, which means fixing incompatibilities in code (in other words, [shaving yaks][6]). Shaving yaks at 2 AM when the application doesn't work is not fun. Luckily, with containers, you can roll back and shave the yaks the next business day, but it will still eat into your time for delivering new value to the business, new features to your applications. Welcome to the life of a sysadmin.
|
||||
|
||||
OK, that said, there are times that building from scratch makes sense. I will completely concede that statically compiled Golang programs and C programs are two decent candidates for scratch/distroless builds. With these types of programs, every container build is a compile event. You still have to worry about API breakage three years from now, but if you are a Golang shop, you should have the skillset to fix things over time.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Basically, Linux distributions do a ton of work to save you time—on a regular Linux system or with containers. The knowledge that maintainers have is tremendous and leveraged so much without really being appreciated. The adoption of containers has made the problem even worse because it's even further abstracted.
|
||||
|
||||
With container hosts, a Linux distribution offers you access to a wide hardware ecosystem, ranging from tiny ARM systems, to giant 128 CPU x86 boxes, to cloud-provider VMs. They offer working container engines and container runtimes out of the box, so you can just fire up your containers and let somebody else worry about making things work.
|
||||
|
||||
For container images, Linux distributions offer you easy access to a ton of software for your projects. Even when you build from scratch, you will likely look at how a package maintainer built and shipped things—a good artist is a good thief—so, don't undervalue this work.
|
||||
|
||||
So, thank you to all of the maintainers in Fedora, RHEL (Frantisek, you are my hero), Debian, Gentoo, and every other Linux distribution. I appreciate the work you do, even though I am a "container guy."
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/2/linux-distributions-still-matter-containers
|
||||
|
||||
作者：[Scott McCarty][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[Chao-zhi](https://github.com/Chao-zhi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/fatherlinux
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://aeon.co/essays/innovation-is-overvalued-maintenance-often-matters-more
|
||||
[2]: https://blog.openshift.com/openshift-on-openstack-delivering-applications-better-together/
|
||||
[3]: https://developers.redhat.com/blog/2018/02/13/red-hat-cdk-nested-kvm/
|
||||
[4]: https://developers.redhat.com/blog/2018/02/22/container-terminology-practical-introduction/#h.8tyd9p17othl
|
||||
[5]: https://developers.redhat.com/blog/2018/02/22/container-terminology-practical-introduction/#h.dqlu6589ootw
|
||||
[6]: https://en.wiktionary.org/wiki/yak_shaving
|
||||
@ -0,0 +1,89 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (Chao-zhi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Do Linux distributions still matter with containers?)
|
||||
[#]: via: (https://opensource.com/article/19/2/linux-distributions-still-matter-containers)
|
||||
[#]: author: (Scott McCarty https://opensource.com/users/fatherlinux)
|
||||
|
||||
容器开发仍然要考虑 Linux 发行版吗？
|
||||
======
|
||||
|
||||
容器构建有两大趋势：使用基本镜像和从头开始构建。每个都有工程上的权衡。
|
||||
|
||||
|
||||
|
||||
有人说 Linux 发行版不再与容器有关。像 distroless 和 scratch containers 等可替代的方法，似乎是风靡一时。看来，我们在考虑和做出技术决策时，更多的是基于时尚感和即时的情感满足，而不是考虑我们选择的次要影响。我们应该问这样的问题：这些选择将如何影响未来六个月的维护？工程权衡是什么？这种范式转换如何影响我们的大规模构建系统？
|
||||
|
||||
这真让人沮丧。如果我们忘记了工程是一个零和游戏，有可测量的利弊权衡，有不同方法的成本和收益——我们伤害了我们自己，我们伤害了我们的雇主，我们伤害了我们的同事，他们最终将维护我们的代码。最后，我们所有的维护人员（[向维护人员致敬！][1] ）会因为他们所做的工作不被赞赏，而受到伤害。
|
||||
|
||||
### 理解问题所在
|
||||
|
||||
为了理解这个问题，我们必须首先研究为什么我们使用 Linux 发行版。我将把原因分为两大类：内核和其他包。编译内核实际上相当容易。Slackware 和 Gentoo（ 我的小心脏还是有点害怕）教会了我们这一点。
|
||||
|
||||
另一方面，为了一个可用的 Linux 系统需要打包大量的开发软件和应用软件，这可能会让人望而生畏。此外，确保数百万个程序包可以一起安装和工作的唯一方法是使用旧的范例：即编译它并将它作为一个玩意（即 Linux 发行版）一起发布。那么，为什么 Linux 发行版要将内核和所有包一起编译呢？很简单：确保事情协调一致。
|
||||
|
||||
首先，我们来谈谈内核。内核很特别。在没有编译内核的情况下引导 Linux 系统有点困难。它是 Linux 操作系统的核心，也是我们在系统启动时首先依赖的。内核在编译时有很多不同的配置选项，这些选项会对硬件和软件如何在一个内核上运行产生巨大影响。这个 bucket 中的第二个问题是，系统软件（如编译器 、C 库和解释器）必须针对内核中内置的选项进行调优。Gentoo 的 wiki 以一种发自内心的方式教我们这一点，它把每个人都变成了一个微型的开发版维护者。
|
||||
|
||||
令人尴尬的是（因为我在过去五年里一直在使用容器），我必须承认我最近编译过内核。我必须让嵌套的 KVM 在 RHEL7 上工作，这样我才能在笔记本电脑上的 KVM 虚拟机中运行 [OpenShift on OpenStack][2] 虚拟机，以及我的 [Container Development Kit（CDK][3]）。我只想说，当时我在一个全新的 4.X 内核上启动了 RHEL7。和任何优秀的系统管理员一样，我有点担心自己错过了一些重要的配置选项和补丁。当然，我也的确错过了一些东西。比如睡眠模式停止正常工作，我的扩展底座停止正常工作，还有许多其他小的随机错误。但它在我的笔记本电脑上的一个 KVM 虚拟机上，对于 OpenStack 上的 OpenShift 的实时演示来说已经足够好了。来吧，这很有趣，对吧？但我离题了……
|
||||
|
||||
现在，我们来谈谈其他的软件包。虽然内核和相关的系统软件可能很难编译，但从工作负载的角度来看，更大的问题是编译成千上万的包，以提供一个可用的 Linux 系统。每个软件包都需要专业知识。有些软件只需要运行三个命令：**。/configure**、**make** 和 **make install**。另一些则需要大量的专业知识，从在 **etc** 中添加用户和配置特定的默认值到运行安装后脚本和添加 systemd 单元文件。对于任何一个人来说，调试好你可能用得到的成千上万种不同软件所需要的一套技能都是令人望而生畏的。但是，如果你想要一个可以随时尝试新软件的可用系统，你必须学会如何编译和安装新软件，然后才能开始学习使用它。这就是没有 Linux 发行版的 Linux。当您放弃使用 Linux 发行版时，那么你就得自己编译软件。
|
||||
|
||||
关键是，您必须将所有内容构建在一起，以确保它能够以任何合理的可靠性级别协同工作，而且构建一个可用的包队列需要大量的知识。这是任何一个开发人员或系统管理员都无法合理地学习和保留的知识。我描述的每个问题都适用于您的 [container host][4]（ 内核和系统软件）和 [container image][5]（ 系统软件和所有其他包）——请注意；在容器镜像中还包含有编译器 、C 库、解释器和 JVM。
|
||||
|
||||
### 解决方案
|
||||
|
||||
所以你也看到了，其实使用 Linux 发行版就是解决方案。不要再去阅读和发送给最新的包维护人员（再次向维护人员致敬！）一张电子卡（等等，我是不是把我的年龄告诉别人了？）。但说真的，这些人做了大量的工作，这真的是被低估了。Kubernetes，Istio，Prometheus，还有 Knative：我在看着你们。你们的时代要来了，你们在维护模式下过渡操劳并且被低估。大约七到十年后，我将再次写这篇文章，可能是关于 Kubernetes 的。
|
||||
|
||||
### 容器构建的首要原则
|
||||
|
||||
从零开始构建和从基础镜像构建之间存在权衡。
|
||||
|
||||
#### 从基础镜像构建
|
||||
|
||||
从基本镜像构建的优点是，大多数构建操作只不过是安装或更新包。它依赖于 Linux 发行版中包维护人员所做的大量工作。它还有一个优点，即六个月甚至十年后的修补事件（使用 RHEL） 是操作/系统管理员事件 （yum update），而不是开发人员事件（这需要通过代码找出某些函数参数不再工作的原因）。
|
||||
|
||||
你想想，应用程序代码依赖于许多库，从 JSON mung 库到对象关系映射器。与 Linux 内核和 Glibc 不同，这些类型的库很少改变 API 兼容性。这意味着三年后您的修补事件可能会变成代码更改事件，而不是 yum 更新事件。因此让他自己深入下去吧。开发人员，如果安全团队找不到防火墙黑客来阻止攻击，您将在凌晨 2 点收到呼叫。
|
||||
|
||||
从基础镜像构建不是完美的；还有一些缺点，比如所有被拖入的依赖项的大小。这几乎总是会使容器镜像比从头开始构建的镜像更大。另一个缺点是您不总是能够访问最新的上游代码。这可能会让开发人员感到沮丧，尤其是当你只想使用依赖项中的一部分功能时，但是你仍然不得不将你更本用不着的东西一起打包带走，因为上游的维护人员一直在改变这个库。
|
||||
|
||||
如果你是一个 web 开发人员，对我睁大眼睛，我有一个词可以形容你：DevOps。那意味着你带着寻呼机，我的朋友。
|
||||
|
||||
#### Scratch 构建
|
||||
|
||||
Scratch 构建的优点是镜像非常小。当您不依赖容器中的 Linux 发行版时，您有很多控制权，这意味着您可以根据需要定制所有内容。这是一个同类最佳的模型，在某些用例中是很有效的。另一个优势是您可以访问最新的软件包。您不必等待 Linux 发行版更新任何内容。是你自己在控制，所以你自行选择什么时候去费功夫纳入新的软件。
|
||||
|
||||
记住，控制一切都是有代价的。通常，更新到具有新特性的新库会拖累不必要的 API 更改，这意味着修复代码中的不兼容（换句话说，这就像[给牦牛剪毛 ][6]）。在凌晨 2 点应用程序不起作用的时候给牦牛剪毛是不好玩的。幸运的是，使用容器，您可以在下一个工作日回滚并给牦牛剪毛，但它仍会占用您为业务提供新价值、为应用程序提供新功能的时间。欢迎来到系统管理员的生活。
|
||||
|
||||
好吧，也就是说，有些时候，白手起家是有意义的。我完全承认，静态编译的 Golang 程序和 C 程序是 scratch/distorless 构建的两个不错的候选程序。对于这些类型的程序，每个容器构建都是一个编译事件。三年后你仍然需要担心 API 的损坏，但是如果你是一个 Golang 商店，你应该有能力随着时间的推移修复问题。
|
||||
|
||||
### 结论
|
||||
|
||||
基本上，Linux 发行版做了大量工作来节省您在常规 Linux 系统或容器上的时间。维护人员所拥有的知识是巨大的，而且没有得到真正的赏识。容器的采用使得问题更加严重，因为它被进一步抽象了。
|
||||
|
||||
通过容器主机，Linux 发行版可以让您访问广泛的硬件生态系统，从微型 ARM 系统到 128 核 CPU x86 巨型机箱，再到云提供商虚拟机。他们提供可工作的容器引擎和开箱即用的容器运行时间，所以你只需启动你的容器，让其他人担心事情的进展。
|
||||
|
||||
对于容器镜像，Linux 发行版为您的项目提供了对大量软件的轻松访问。即使您从头开始构建，您也可能会看到一个包维护人员是如何构建和运送东西的——一个好的艺术家是一个好的小偷，所以不要低估这项工作的价值。
|
||||
|
||||
所以，感谢 Fedora、RHEL（Frantisek，你是我的英雄 ）、Debian、Gentoo 和其他 Linux 发行版的所有维护人员。我很感激你所做的工作，尽管我是个“容器工人”
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/2/linux-distributions-still-matter-containers
|
||||
|
||||
作者：[Scott McCarty][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[Chao-zhi](https://github.com/Chao-zhi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/fatherlinux
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://aeon.co/essays/innovation-is-overvalued-maintenance-often-matters-more
|
||||
[2]: https://blog.openshift.com/openshift-on-openstack-delivering-applications-better-together/
|
||||
[3]: https://developers.redhat.com/blog/2018/02/13/red-hat-cdk-nested-kvm/
|
||||
[4]: https://developers.redhat.com/blog/2018/02/22/container-terminology-practical-introduction/#h.8tyd9p17othl
|
||||
[5]: https://developers.redhat.com/blog/2018/02/22/container-terminology-practical-introduction/#h.dqlu6589ootw
|
||||
[6]: https://en.wiktionary.org/wiki/yak_shaving
|
||||
Loading…
Reference in New Issue
Block a user