金融租赁合规性_使合规性在容器世界中可扩展

金融租赁合规性

软件正越来越多地作为容器映像分发。 容器映像包括支持容器中功能强大的软件所需的许多软件组件。 因此，容器映像的分发涉及许多软件组件的分发，这些软件组件通常包括GPL许可的组件。 我们不能期望每个分发容器映像的公司都能成为开源合规性专家，因此我们需要在容器技术中建立合规性。

我们应该在容器工具和流程中设计源代码的可用性，以促进高效且可移植的开源许可证合规性：

• 高效-创建容器映像后立即解决法规遵从问题。 避免依赖于以后的操作，尤其是现有容器分发工具外部的操作。
• 可移植性-将映像移至另一个注册表时，将顺应性与映像一起移动应该很简单。

可以使用本机注册表方法来获取源代码。 这不需要更新所有容器注册表以包含特定于源代码的功能。 可以利用注册表已具有的功能。 对于通过容器注册表分发的软件，我们可以使用这些相同的注册表来促进合规性。

集装箱技术

容器技术有助于应对部署和操作复杂软件系统的挑战。

“容器”一词是指运行时的体验，程序及其依赖项可以在与其他正在执行的程序提供一定隔离的环境中执行； 它正在容器中运行。

用于配置此类容器的文件集称为“容器映像”。 尽管特定容器映像的目的可能是运行一个应用程序，但该容器映像包含更多内容：该应用程序及其依赖项-运行该应用程序所需的文件，操作系统内核除外。 容器映像是可以存储和传输的那些文件的一种形式，使应用程序可以一次又一次可靠地部署，并且独立于系统中其他容器中可能正在运行和更改的许多其他程序而运行。

以容器映像形式的软件的分发正在不断增加，这些容器映像是通过称为“容器注册表”的服务分发的。 一旦人们投入资金来围绕容器组织计算，将软件打包和分发到容器映像中就变得很有价值。 那些使用容器来运行其软件的人发现，能够将软件作为预先构建的容器映像来获得，而不是自己进行所有容器组装，都非常有用。 即使定制了容器图像，从预构建的图像开始通常也很有价值。

容器图片不同

过去，通常需要单独获取每个软件组件。 相反，容器映像包括异构的软件集合-通常是数百个软件组件。 软件交付的单位正在从一种由软件的构建方式决定的单位转变为由软件的使用方式决定的单位 。 （请参阅容器映像中的内容：应对法律挑战 。）

在过去的二十多年中，包装维护者和包装管理工具在货源可用性方面的作用一直未被重视。 程序包的重点性质，程序包维护者的角色以及为支持程序包管理系统而构建的工具会导致期望某人（程序包维护者）负责确保源可用。 生成二进制文件的工具还将相应的源收集到可以与二进制文件一起交付的存档中。 结果是，大多数人不需要考虑源代码的可用性。 这些资源与可执行软件的交付单位相同，并且通过相同的分发机制提供。 对于以RPM交付的软件，相应的源可在源RPM中获得。

相反，没有约定提供与容器映像相对应的源代码。

容器映像中的许多软件组件通常都包含GPL许可的软件。 可能没有太多FOSS软件发行经验的公司可能会在开始以容器映像形式提供软件时开始发行GPL许可的软件。 让每个人（包括可能对FOSS较新的公司）都可以直接以一致的方式提供源代码。

识别相应的源代码

与容器相比，识别相应的源代码对容器映像更具挑战性。 对于软件包，源可用于构建软件包的人员（尽管如果软件包被构建为包含依赖关系，而不仅仅是引用它们，则依赖关系源可能会遇到一些挑战）。 相反，容器图像通常是使用大多数先前编译的组件来构建的。 构建容器映像时，取决于如何获取二进制文件以及如何构建二进制文件，这些软件组件的来源可能随时可用。

当然，使相应的源代码可作为容器映像的逻辑部分使用，这有利于该映像的分发中的合规性。 但是，这种做法也支持合规的生态系统。 如果有人在基础映像上构建，他们如何知道可能需要提供哪些源代码？ 如果容器映像具有相应的源映像，则解决方案很简单。 不必先弄清楚基础内容是什么。 而是，通过使用基础的源映像来启动整个映像的源可用性。

这是在工具中建立合规性的机会-当有人在基础映像上构建工具时，这些工具应使他们轻松地使相应的源以及基础内容可用。 工具应通过从基础的源图像开始并添加适用于在该基础之上构建的软件的任何源来创建与最终组合图像相对应的源图像。

交货

假设其中有一个与容器映像相对应的源代码工件列表。 该列表将在哪里托管？ 源工件将托管在哪里？ 如果容器映像托管在各个注册表中，那么如何为每个分发点提供源代码？ 在每个注册管理机构或与注册管理机构相关联的每个目录中都要做工作吗？ 某人如何从许多不同的注册表中提取容器图像，以了解这些材料在哪里？ 大规模如何运作？ 需要多少种机制？

我们应该建立一个符合法规要求的容器生态系统，该生态系统可以在各个注册表中移植。 一个人不需要从每个注册表中获取一本新指南。

如上所述，容器映像中的支持软件组件通常包括根据GPL许可的软件。 考虑通过下载实现满足商业销售软件的源代码可用性要求的各种替代方案：附带源代码的二进制文件； 二进制文件并附有书面要约； 或等效的复制权限。 至于等效的访问选项，让我们看一下GPLv2第3节的最后一段：“如果通过提供从指定位置进行复制的访问权 ，然后提供等效的访问权从同一位置复制源代码来进行可执行代码或目标代码的分发，即使不强迫第三方将源代码与目标代码一起复制，也算作源代码的分发。”

为什么要通过容器注册表交付源代码？ 等效的访问，效率和可移植性。

• 等效访问 -使用注册表本机方法来访问源（将容器映像的源作为容器映像提供）是提供对源等效访问的好方法。
• 高效合规性-在构建可执行映像时创建源可用性“包”（源映像），然后使用相同的工具使源可用，避免了维护使源可用的其他过程和机制的效率低下的情况。
• 法规遵从性的可移植性 –用于移动可执行映像的相同工具可用于在所有托管注册表上移动，存储和提供源映像。

本地注册方法可获取源代码

通过容器注册中心传送源利用了容器映像格式的设计以及容器注册中心的某些相关特征。

容器映像包括（请参见下面链接的两个示例中的容器映像详细信息）：

• 图像清单，标识图像的其他元素；
• 配置数据，包括关于图像的元数据，包括用于配置图像以在容器中执行的信息；
• 许多“层”（每个层都是tar归档文件），用于存储用于配置容器的文件系统。

考虑使相应的源代码可用的挑战，即我们希望服务器使之可用的源代码工件（RPM，zip文件，tarball等）的集合。 容器映像是注册表可用的组件列表。 如果源工件列表以图像清单的形式排列，那么容器注册表可以像处理其他容器图像部分一样为源代码工件提供服务。 而且，可以直接应用用于移动容器映像的工具来移动该合规性软件包（清单以及引用的源工件）。

源图像（也称为源容器）只是一个容器图像。 每层都是源工件，而不是图像中的层是文件的压缩文件，以提供执行容器。

从容器注册表传递非文件系统内容的概念也引起了容器注册表的其他目的，而不仅仅是源代码。 容器注册表提供的非层内容的一个示例是Helm图表（用于描述一组Kubernetes资源）。 通过容器注册表传送非层内容是开放容器倡议的工件项目的主题 。

重复数据删除

容器注册表将图像作为部分而不是单个数字对象进行存储和传递。 这是很有价值的，因为容器映像极其冗余。 许多图像的内容差异很小。 容器映像通过将运行特定程序所需的所有组件打包在一起，可以简化数据中心的操作。 结果，容器映像很大，并且每个容器映像都包含许多与注册表中其他映像相同的内容。 一个映像中可能有100-300个软件组件，其中大多数都存在于许多其他容器映像中。 同样，图像是不可变的。 当需要更新映像时，将创建一个与先前版本几乎相同的新映像。 通过将容器文件系统的归档文件分成多个层并使用内容可寻址存储，可以缓解此大小挑战。

重复数据删除功能在源代码中也是有利的。 利用此注册表功能的关键是不要在单个blob中存储图像的所有相应源。 如果针对构建映像所用的数百个或更多软件组件中的每一个，使用单独的源工件的粒度存储源代码，则可以轻松实现100：1以上的重复数据删除。

实作

红帽已经开始采用两阶段方法中的第一个方法来实现注册表本地交付源代码。

在第一阶段，红帽首先开始制作可托管在现有注册表中的源映像，并且不会混淆那些期望所有映像都可执行的工具。 在这种方法中，源工件伪装成常规图层-每个源工件都包装在tar存档中； 图层的媒体类型与常规可执行映像的媒体类型相同。 通过命名约定，源映像与相应的可执行映像相关联。

第二阶段涉及利用某些OCI图像格式功能。

容器映像应通过映像索引链接到相应的可执行映像，而不是使用标签命名约定。 容器映像格式使源映像实际上可以成为整个映像的一部分，而可执行映像是该映像的一部分。 与源代码无关，将针对不同处理器体系结构构建的图像作为单个整体图像的一部分很有用。 该整体图像可以作为单个对象进行管理，并且图像的使用者可以选择要下载图像的哪个版本和/或部分（例如，amd64或arm64或源）。 因此，应该通过图像索引列出源图像清单，而不是通过标签约定将源与相应的可执行图像相关联。

另外，将来，源工件不应伪装成可执行层的tar文件。 应该消除tar归档中源工件的额外包装，并应使用适当的媒体类型标识源工件。 成功的重复数据删除需要仔细，一致的tar存档。 简单地直接存储源工件（并用适当的介质类型对其进行标记）可以减少由于不一致的tarball包装器而造成的潜在重复数据删除损失。

最后，注册表中的源工件应与注册表中其他非层内容（例如Helm图表）的方法一致。 提供一致的方式来提供此类内容是“开放容器计划”内“工件”项目的主题。 源的注册表本地分布可以是该项目的受益者。

综上所述

当前方法（请参阅当前方法示例 ）：

• 源工件伪装成常规图层-将每个源工件包装在tarball中，并用常规层媒体类型进行标记。
• 标识tar包装器内的源工件的名称。
• 使用标记名称约定将源图像和可执行图像相关联-将源图像清单与标记为“ -source”扩展的相应可执行图像的标记一起使用。

未来方法（请参阅未来方法示例 ）：

• 无需伪装-将源工件直接存储在注册表中（通过哈希摘要命名为其他注册表内容），并为它们提供非分层媒体类型。
• 使用清单中的图层注释来标识源工件的名称。
• 使用映像索引将源映像和可执行映像相关联-在映像索引中列出源清单，以及每种计算机体系结构的清单。
• 使用独特的配置。 源清单中的媒体类型（如OCI工件项目中所建议）。

我们现在在哪？

现在，UBI图像的源“容器”实际上是图像，现在在Red Hat注册表中。 这些源图像是使用生产工具构建的。 下一步是将其推广到其他图像。

我们去哪？

我们需要一种行业范围内一致的方法来使源代码可用于容器图像。 让我们在OCI的工件项目中共同努力，并就无化装方法的细节达成一致。

商机

包含源代码会带来机会。 使完整的相应源代码可用作相应的源映像，不仅可以解决GPL源的可用性问题：

• 开源软件的确切许可可能很复杂（请参阅开源软件许可是否被破坏？ ）。 但是，有了完整的源代码，人们就可以确定对他们而言重要的细节（请参阅源代码是license ）。
• 许可通知如何？ 您可以尝试提取所有它们。 或者，您可以通过源代码直接提供通知（请参阅经济有效的模型以符合开放源代码软件许可证要求 ）。

翻译自: https://opensource.com/article/20/7/compliance-containers

金融租赁合规性