Source-to-Image 是一个极好的工具，可以以快速、灵活和可重现的方式为应用程序构建容器镜像。通常缩写为 S2I，Source-to-Image 采用一个基础的“构建器”镜像，其中包含编译应用程序或安装依赖项（如 Python 的 PIP 或 Ruby 的 Bundler）所需的所有库和构建工具，以及一组位于预定义位置的脚本，用于构建、测试和运行应用程序。创建构建器镜像后，S2I 可以从存储库中获取代码，将其注入到构建镜像中，编译或安装依赖项，并生成一个包含最终应用程序的应用镜像，随时可以运行。
我开始学习如何为用 Go（非正式地称为 Golang）编写的应用程序构建容器镜像，在接下来的两篇文章中，我们将这样做。
为什么选择 S2I
S2I 为构建可重现性的挑战提供了一个简单的解决方案，适用于用任何编程语言编写的应用程序。这意味着我可以重现一致的镜像，以便开发人员专注于他们的应用程序，而不是容器镜像和编排。而且，由于构建环境是提前创建的，因此构建所需的时间仅与应用程序编译或配置所需的时间一样长（使用Go 编译器背后的技术，速度可能非常快）。
我认为 S2I 的真正优点是能够使用构建器镜像作为模板，以便可以部署具有相似配置的相似应用程序，而无需为每个应用程序管理像 Dockerfile 这样的配置文件——为相似的应用程序提供相同的、可重现的环境。更少的模板化镜像意味着减少了管理它们更新的繁琐工作，并且更有可能让我相信它们能保持最新状态。
许多官方 Source-to-Image 构建器镜像已经存在（例如，Python S2I，Ruby S2I），但也很容易制作一个满足特定需求的镜像。
S2I 要求
要使构建成为 S2I 兼容的镜像，只需要四个文件，尽管还有一些文件可能会派上用场。以下内容直接来自 S2I README 文档
| 文件 | 必需？ | 描述 |
|---|---|---|
| Dockerfile | 是 | 定义基础构建器镜像 |
| s2i/bin/assemble | 是 | 构建应用程序的脚本 |
| s2i/bin/usage | 否 | 打印构建器用法的脚本 |
| s2i/bin/run | 是 | 运行应用程序的脚本 |
| s2i/bin/save-artifacts | 否 | 用于增量构建的脚本，保存构建的工件 |
| test/run | 否 | 构建器镜像的测试脚本 |
| test/test-app | 是 | 测试应用程序源代码 |
构建器镜像是从 Dockerfile 创建的；因此，Dockerfile 将包含编译、构建和运行源代码所需的所有包和库。Dockerfile 还需要将 s2i/bin/* 和 test/* 文件复制到生成的镜像中，以允许 S2I 使用它们。
s2i/bin/assemble 脚本包含构建应用程序或安装其依赖项的逻辑。例如，如果构建器镜像用于 Python 应用程序，则 assemble 脚本可能会运行 pip install 以从 requirements.txt 文件中安装依赖项。对于 Go，assemble 脚本将运行 go get 等命令。
s2i/bin/run 脚本应设置为 Dockerfile 中的 CMD 或 ENTRYPOINT，并负责在应用程序镜像运行时启动应用程序。在大多数情况下，此脚本是必需的，因为 S2I 构建生成的镜像就是运行应用程序的镜像。对于 Go 构建器，这不是绝对必要的，但它有助于测试应用程序。
s2i/bin/save-artifacts 脚本获取应用程序运行所需的所有工件，并通过 tar 命令将其流式传输到 stdout。这允许构建器镜像执行增量构建，或者使我们能够提取编译后的二进制文件，以便将其包含在后续构建中。
这些脚本文件可以用任何语言编写，只要它们可以在从 Dockerfile 构建的容器中执行即可。
注意： 尽管文档如此说，但 test/test-app 文件不是必需的。 如果您使用 s2i create 命令来构建新的 Source-to-Image 构建器，则会为您设置一些空白测试，但它们不是绝对必要的。 此外，run 脚本对于大多数 Source-to-Image 构建器都是必需的，但对于我们将在此系列中创建的 Golang 构建器镜像，它只是一个便利的脚本。
我们还需要 Source-to-Image 软件来构建运行时或应用程序镜像，但它不一定必须安装在本地系统上。我们可以在 OKD 或 OpenShift Container Platform 中创建整个构建管道，并在那里完成所有构建。 只是在本地安装软件来开发和测试镜像更容易。
获取适用于您平台的 最新版本的 Source-to-Image，或者使用您的发行版的软件包管理器安装它（例如，dnf install s2i）。
我们现在已经安装了 S2I，并且对开始设计构建器需要什么有了很好的了解。 在下一篇文章中，我们将介绍 Dockerfile 配置的良好实践（包括避免 root 权限），并查看一个构建示例。
随着我们继续进行四部分系列文章，我们将逐步完成使用 S2I 要求，然后为用 Go 编写的应用程序构建镜像模板，最后介绍如何将 S2I 与 OKD 或 OpenShift Container Platform buildConfigs 结合使用来自动化镜像构建管道。 您对是否应该使用 S2I 有疑问吗？ 请在评论中随意提问。
2 条评论