linux 容器与外部网络

有人说Linux发行版不再与容器有关。 诸如一次性容器和临时容器之类的替代方法似乎风行一时。 似乎我们正在考虑和做出技术决策时更多地基于时尚感和即时的情感满足，而不是通过选择的次要影响来进行思考。 我们应该问类似的问题：这些选择将如何影响未来六个月的维护？ 什么是工程上的权衡？ 这种范式转变如何大规模影响我们的构建系统？

看着真令人沮丧。 如果我们忘记了工程是一个零和博弈，需要进行权衡取舍-优缺点，以及各种方法的成本和收益-我们会损害自己的利益，我们会损害雇主的利益，我们也会损害我们的同事编写损害代码。 最后，由于不了解他们所做的工作，我们使所有维护人员（称赞维护人员！ ）都蒙受了损害。

了解问题

为了理解这个问题，我们必须调查为什么我们首先开始使用Linux发行版。 我将原因分为两个主要的方面：内核和其他软件包。 实际上，编译内核相当容易。 Slackware和Gentoo（我仍然对我有好感）教会了我们这一点。

另一方面，需要为可用的Linux系统打包大量的开发和运行时软件，这可能令人生畏。 此外，确保旧版本的软件包可以安装并协同工作的数百万种方法，唯一的方法是使用旧的范例：将其编译并作为事物一起交付（即Linux发行版）。 那么，为什么Linux发行版将内核和所有软件包一起编译？ 简单：确保事情协同工作。

首先，让我们谈谈内核。 内核是特殊的。 在没有编译内核的情况下引导Linux系统是一个挑战。 它是Linux操作系统的核心，也是系统启动时我们所依赖的第一件事。 内核在编译时有许多不同的配置选项，它们可能对硬件和软件在其上的运行方式产生巨大影响。 此存储桶中的第二个问题是，必须针对内核中内置的选项对系统软件（如编译器，C库和解释器）进行调整。 Gentoo通过内在的方式教给我们这一点，这使每个人都变成了微型发行维护者。

令人尴尬的是（因为过去五年来我一直在使用容器），我必须承认我最近才编译了内核。 我必须在RHEL 7上使用嵌套的KVM，以便可以在OpenStack虚拟机，笔记本电脑上的KVM虚拟机以及我们的容器开发套件（CDK ）中运行OpenShift 。 #justsayin可以说，我当时在一个全新的4.X内核上启动了RHEL7。 像任何出色的系统管理员一样，我有点担心我错过了一些重要的配置选项和补丁。 而且，当然，我已经错过了一些东西。 睡眠模式无法正常工作，我的扩展坞也无法正常工作，并且还有许多其他小的随机错误。 但是，对于在笔记本电脑上的单个KVM虚拟机中进行OpenStack上的OpenShift的实时演示来说，它的运行效果很好。 来吧，那还挺有趣的，对吗？ 但是我离题了……

现在，让我们谈谈所有其他软件包。 尽管内核和相关的系统软件很难编译，但是从工作负载的角度来看，更大，更大的问题是编译成千上万的软件包以提供给我们一个可用的Linux系统。 每个软件包都需要主题专业知识。 有些软件只需要运行三个命令： ./configure ， make和make install 。 其他需要大量的专业技能，从添加用户和等 ，以运行后安装脚本，并添加systemd单元文件配置特定的默认值。 您可能要使用的成千上万种不同软件所需的技能对每个人来说都是艰巨的。 但是，如果您希望有一个可用的系统能够随时随地尝试新软件，则必须学习如何编译和安装新软件，然后才能开始学习使用它。 那是没有Linux发行版的Linux。 这就是您放弃Linux发行版时要同意的工程问题。

关键是您必须将所有内容组合在一起，以确保它们可以与任何合理的可靠性水平一起使用，并且需要大量的知识来构建可用的软件包组。 这是比任何单个开发人员或sysadmin都要合理学习和保留的知识。 我描述的每个问题都适用于您的容器主机 （内核和系统软件）和容器映像 （系统软件和所有其他软件包）。 容器映像中也有编译器，C库，解释器和JVM。

解决方案

您已经知道这一点，但是Linux发行版是解决方案。 停止阅读并发送最近的包裹维护者（再次，称赞维护者！）电子贺卡（等待，我只是给我年龄了吗？）。 但是，认真地讲，这些人做了很多工作，而且确实被低估了。 Kubernetes，Istio，Prometheus和Knative：我在看着你。 当您处于维护模式，过度使用和低估时，您的时间也将过去。 我将在大约七到十年内再次写这篇文章，大概是关于Kubernetes的。

容器构建的首要原则

从头开始构建和从基础图像构建需要权衡。

从基础图像构建

从基本映像进行构建的优势在于，大多数构建操作只不过是软件包的安装或更新。 它依赖于Linux发行版中软件包维护人员的大量工作。 它还具有一个优势，即从现在开始六个月甚至十年（通过RHEL）的补丁事件是操作/系统管理员事件（yum更新），而不是开发人员事件（需要通过代码来找出为什么某些原因）。函数参数不再有效）。

让我们双击一下。 应用程序代码依赖于许多库，从JSON munging库到对象关系映射器。 与Linux内核和Glibc不同，这些类型的库更改时很少考虑破坏API兼容性。 这意味着从现在开始的三年后，您的修补事件可能会变成代码更改事件，而不是yum更新事件。 知道了，让它沉没。开发人员，如果安全团队找不到防火墙黑客来阻止漏洞利用，那么您将在凌晨2点得到通知。

从基础映像构建并不完美； 有一些缺点，例如被拖入的所有依赖项的大小。这几乎总是使您的容器映像大于从头开始构建的映像。 另一个缺点是您将无法始终访问最新的上游代码。 对于开发人员而言，这可能会令人沮丧，尤其是当您只想发布一些东西时，却没有像分页浏览您从未想到的库那样沮丧，因为上游维护者一直在改变，这已经是三年了。

如果您是一名Web开发人员并且对我不屑一顾，那么我为您提供一个词：DevOps。 我的朋友，这意味着您正在携带传呼机。

从头开始构建

临时版本的优点是体积很小。 当您不依赖容器中的Linux发行版时，您将拥有很多控制权，这意味着您可以根据需要自定义所有内容。 这是同类最佳的模型，在某些用例中有效。 另一个优点是您可以访问最新的软件包。 您无需等待Linux发行版更新任何内容。 一切尽在您的掌握之中，因此您可以选择何时进行工程工作以集成新软件。

记住，控制一切都是有代价的。 通常，使用新功能更新到新库会导致不必要的API更改，这意味着要修复代码中的不兼容性（换句话说，就是剃毛 ）。 当应用程序无法正常工作时，在凌晨2点刮牛是不好玩的。 幸运的是，有了容器，您可以在下一个工作日回滚并刮除牛，但是仍然会浪费您的时间为企业带来新的价值，为应用程序提供新功能。 欢迎来到sysadmin的生活。

好的，也就是说，有时候从头开始构建是有意义的。 我将完全承认，静态编译的Golang程序和C程序是草稿/非发行版构建的两个不错的候选人。 使用这些类型的程序，每个容器构建都是一个编译事件。 您仍然需要担心三年后API的损坏，但是如果您是Golang商店，则应该具备随着时间推移修复问题的技能。

结论

基本上，Linux发行版在常规的Linux系统上或在容器上进行了大量工作以节省您的时间。 维护人员拥有的知识非常丰富，并且在没有真正被赞赏的情况下利用了很多知识。 容器的采用使问题变得更加严重，因为它甚至被进一步抽象了。

借助容器主机，Linux发行版使您可以访问广泛的硬件生态系统，从小型ARM系统到巨型的128 CPU x86盒，再到云提供商的VM。 它们开箱即用地提供了可用的容器引擎和容器运行时，因此您可以启动容器，而让其他人担心使事情起作用。

对于容器映像，Linux发行版使您可以轻松访问大量项目软件。 即使您是从头开始构建的，您也可能会看一看包装维护者如何构建和运输东西（好的画家就是好贼），因此，请不要低估这项工作。

因此，感谢Fedora，RHEL（Frantisek，您是我的英雄），Debian，Gentoo和所有其他Linux发行版中的所有维护人员。 我很欣赏您所做的工作，即使我是个“集装箱佬”。

翻译自: https://opensource.com/article/19/2/linux-distributions-still-matter-containers

linux 容器与外部网络