容器映像_容器映像中的内容：应对法律挑战

容器映像

多年来， 容器技术一直在改变数据中心工作负载的管理方式，并加快了应用程序开发和部署的周期。

docker 容器和镜像的关系。 另外，容器映像越来越多地用作分发格式，而容器注册则是一种用于软件分发的机制。 这不就是使用软件包管理工具分发的软件包吗？ 不完全的。 尽管容器映像分发类似于RPM，DEB和其他包管理系统（例如，存储和分发文件档案），但容器映像分发的含义更为复杂。 这不是容器技术本身的错。 而是因为容器分发的使用与包管理系统的使用不同。

在谈到容器映像的许可证合规性挑战时，VMware的首席开源官Dirk Hohndel指出，容器映像的内容比大多数人期望的更为复杂，并且许多易于使用的映像以令人惊讶的轻巧方式构建。 。 （请参阅Jake Edge在LWN.net上发表的有关Dirk在四月发表的讲话的文章 。）

预定义注释键之一是“ 开放容器图像格式规范 ”，它是“ org.opencontainers.image.licenses”，它被描述为“许可证”，根据该许可证，所包含的软件作为SPDX许可证表达式进行分发。 但这并没有考虑到容器映像的复杂性-尽管非常简单的映像是由数十个组件构建的，但是映像通常是由数百个组件构建的。 SPDX许可表达最常用于传达单个源文件的许可。 这样的表达式可以处理多个许可证，例如“ GPL-2.0或BSD-3-Clause”（例如，参见SPDX规范2.1版的附录IV ）。 但是，典型容器映像的许可通常要复杂得多。

在谈论与容器相关的技术时，术语“ 容器 ”可能导致混乱。 容器不引用用于存储或传输的文件的包含。 相反，它指的是使用内核内置的功能（例如cgroup和名称空间）为内核上运行的代码提供一种“包含”的体验。 换句话说，“容器”所指的遏制是执行经验，而不是分发经验。 通常在称为“容器映像”的文件中分发要在文件系统中作为执行容器基础的文件集，有时将其简单地称为容器，从而笨拙地使术语“容器”超载。 ”

在了解通过容器映像进行软件分发时，我认为考虑两个单独的因素很有用：

• 内容的多样性：与典型的软件分发机制中的基本分发单位相比，软件分发的基本单位（容器映像）包含的内容数量和多样性更大。
• 使用模型：广泛使用的工具的性质促进了典型工作流程中注册表的使用，该注册表通常是公开可用的。

内容的多样性

在谈论特定的容器映像时，通常将注意力集中在特定的软件组件（例如，数据库或实现一项特定服务的代码）上。 但是，容器映像包含大量的软件。 实际上，即使是创建图像的开发人员也可能只对图像中的大多数组件有肤浅的了解和/或感兴趣。 使用其他分发机制，这些其他软件将被识别为依赖项，并且该软件的用户可能会被定向到其他地方寻求有关这些组件的专业知识。 在容器中，获取容器图像的人员不知道那些对功能部件起辅助作用的附加部件。

分配单位：用户驱动与工厂驱动

对于容器图像， 分发单元是用户驱动的，而不是工厂驱动的 。 容器映像是减轻软件使用者负担的好工具。 使用容器图像，图像的使用者可以专注于感兴趣的应用程序； 映像的构建器可以处理依赖关系和配置。 这种简化可以带来巨大的好处。

当软件单元由“工厂”驱动时，用户将承担更大的责任来构建一个平台，在该平台上运行所需的软件，组装正确的依赖关系版本以及正确获取所有配置详细信息。 软件包管理系统中的分发单位是模块化单位，而不是完整的解决方案。 该单元有助于构建和保持足够灵活的组件流，以组装成多种解决方案。 请注意，由于有了这个单元，与维护容器的人员相比，软件包维护者通常对软件包的内容要熟悉得多。 建造容器的人员可能对容器的特征部件有详细的了解，但对图像的支撑部件的了解有限。

程序包，程序包管理系统工具，程序包维护过程和程序包维护者的价值令人难以置信的低估。 在过去的二十年中，它们一直是交付各种软件的核心。 尽管容器映像扮演着越来越重要的角色，但我并不认为包装管理系统的重要性会很快消失。 实际上，容器映像中的大部分内容都受益于从此类程序包中构建。

在理解容器图像时，重要的是要了解通过此类图像进行的分发与包裹的分发相比如何具有不同的属性。 图像中的大部分内容都是从包装中构建的，但是图像的使用者可能不知道其中包含哪些包装或其他包装级别的信息。 将来，可以使用多种技术来构建容器，例如直接从源头构建容器，而无需包装维护者的参与。

使用模型

那么关于这么多容器映像构建不良的报告呢？ 临时生成的图像的数量部分是由于容器工具可简化工作流以使图像公开可用。 在尝试使用容器工具并转移到笔记本电脑以外的工作流程时，这些工具会期望您拥有一个存储库，多台计算机可以在其中存储容器映像（容器注册表）。 您可以自己动手。 只要图像是公开可用的，一些广泛使用的工具就可以轻松使用免费提供的现有注册表。 这使许多随意构建的图像可见，甚至那些原本不打算维护或更新的图像也可见。

相比之下，您看到开发人员多久发布一次早期探索的RPM？ 由随机开发人员进行实验而产生的RPM并未最终出现在主要软件包存储库中。

或者考虑有人尝试最新的机器学习框架。 过去，研究人员可能只共享分析结果。 现在，他们可以通过发布容器映像来共享完整的分析软件配置。 这对其他研究人员可能是一个巨大的好处。 但是，那些浏览容器注册表的人可能会被此类图像的随时运行性质所迷惑。 重要的是要区分为一个人的探索而构建的图像和经过广泛考虑而组装和测试的图像。

请注意，容器映像不仅包括支持软件，还包括支持软件。 容器映像分发软件的集合。 如果您是在构建或使用其他人构建的图像，请注意该图像是如何构建的，并考虑您对图像来源的信心。

翻译自: https://opensource.com/article/18/7/whats-container-image-meeting-legal-challenges

容器映像