创建构建输入

构建输入为构建提供源内容。您可以使用以下构建输入在 AWS 上的 Red Hat OpenShift Service 中提供源，按优先级顺序排列：

您可以在单个构建中组合多个输入。但是，由于内联 Dockerfile 优先，它可以覆盖由其他输入提供的任何其他名为 Dockerfile 的文件。二进制（本地）输入和 Git 仓库是互斥的输入。

当您不想在构建过程中使用的某些资源或凭据在构建生成的最终应用程序镜像中可用，或者想要使用在密钥资源中定义的值时，可以使用输入密钥。外部工件可用于提取作为其他构建输入类型之一不可用的其他文件。

运行构建时

以下源定义示例包含多种输入类型以及如何组合它们的说明。有关如何定义每种输入类型的更多详细信息，请参阅每种输入类型的特定部分。

提供 `dockerfile` 值时，此字段的内容将写入磁盘，文件名命名为 `dockerfile`。这在处理其他输入源后完成，因此，如果输入源仓库在根目录中包含 Dockerfile，则此内容将覆盖它。

源定义是 `BuildConfig` 中 `spec` 部分的一部分。

您可以使用镜像向构建过程添加其他文件。输入镜像的引用方式与定义 `From` 和 `To` 镜像目标的方式相同。这意味着可以引用容器镜像和镜像流标签。结合镜像，您必须提供一个或多个路径对，以指示要复制镜像的文件或目录的路径以及将其放置在构建上下文中的目标位置。

源路径可以是指定镜像内的任何绝对路径。目标必须是相对目录路径。在构建时，加载镜像并将指示的文件和目录复制到构建过程的上下文目录中。这与克隆源仓库内容的目录相同。如果源路径以 `/.` 结尾，则复制目录的内容，但不会在目标位置创建目录本身。

镜像输入在 `BuildConfig` 的 `source` 定义中指定。

使用需要拉取密钥的输入镜像时，可以将拉取密钥链接到构建使用的服务帐户。默认情况下，构建使用 `builder` 服务帐户。如果密钥包含与托管输入镜像的仓库匹配的凭据，则会自动将拉取密钥添加到构建中。要将拉取密钥链接到构建使用的服务帐户，请运行：

从镜像注册表使用输入镜像时，如果收到 `build error: failed to pull image` 消息，您可以使用以下任一方法解决此错误：

指定后，将从提供的地址获取源代码。

如果提供内联 Dockerfile，它将覆盖 Git 仓库 `contextDir` 中的 Dockerfile。

源定义是 `BuildConfig` 中 `spec` 部分的一部分。

如果 `ref` 字段表示拉取请求，则系统使用 `git fetch` 操作，然后签出 `FETCH_HEAD`。

如果未提供ref值，AWS上的Red Hat OpenShift Service将执行浅克隆（--depth=1）。在这种情况下，仅下载与默认分支（通常为master）上的最新提交关联的文件。这将使仓库下载速度更快，但不会包含完整的提交历史记录。要执行指定仓库默认分支的完整git clone，请将ref设置为默认分支的名称（例如main）。

将内容从本地文件系统流式传输到构建器称为 Binary 类型构建。这些构建的 BuildConfig.spec.source.type 的对应值为 Binary。

这种源类型是独一无二的，因为它仅基于您对 oc start-build 的使用。

要使用二进制构建，请使用以下选项之一调用 oc start-build：

在前面列出的每种情况下：

您可以将具有 HTTP 或 HTTPS 架构的 URL 传递给 --from-file 和 --from-archive，而不是文件名。当使用 URL 与 --from-file 时，构建器镜像中文件的名称由 Web 服务器发送的 Content-Disposition 标头确定，如果标头不存在，则由 URL 路径的最后一个组件确定。不支持任何形式的身份验证，并且无法使用自定义 TLS 证书或禁用证书验证。

使用 oc new-build --binary=true 时，该命令确保强制执行与二进制构建相关的限制。生成的 BuildConfig 的源类型为 Binary，这意味着运行此 BuildConfig 的构建的唯一有效方法是使用 oc start-build 以及其中一个 --from 选项来提供所需的二进制数据。

Dockerfile 和 contextDir 源选项对二进制构建具有特殊含义。

Dockerfile 可用于任何二进制构建源。如果使用 Dockerfile 并且二进制流是存档，则其内容将替换存档中任何 Dockerfile。如果将 Dockerfile 与 --from-file 参数一起使用，并且文件参数名为 Dockerfile，则来自 Dockerfile 的值将替换来自二进制流的值。

对于封装提取的存档内容的二进制流，contextDir 字段的值被解释为存档中的子目录，如果有效，则构建器在执行构建之前将更改到该子目录。

在某些情况下，构建操作需要凭据或其他配置数据才能访问依赖资源，但将这些信息放入源代码控制中是不可取的。为此，您可以定义输入密钥和输入配置映射。

例如，在使用 Maven 构建 Java 应用程序时，您可以设置 Maven Central 或 JCenter 的私有镜像，该镜像通过私钥访问。要从此私有镜像下载库，您必须提供以下内容：

出于安全原因，您不希望在应用程序镜像中公开您的凭据。

此示例描述的是 Java 应用程序，但您可以使用相同的方法将 SSL 证书添加到/etc/ssl/certs目录、API 密钥或令牌、许可证文件等等。

不建议在源代码库中存储二进制文件。因此，您必须定义一个构建，在构建过程中提取其他文件，例如Java.jar依赖项。如何操作取决于您使用的构建策略。

对于Source构建策略，您必须将相应的shell命令放入assemble脚本中。

对于Docker构建策略，您必须修改Dockerfile并使用RUN指令调用shell命令。

实际上，您可能希望对文件位置使用环境变量，以便可以使用在BuildConfig上定义的环境变量自定义要下载的特定文件，而不是更新Dockerfile或assemble脚本。

您可以选择不同的环境变量定义方法：

您可以为构建提供包含私有容器注册表有效凭据的.docker/config.json文件。这允许您将输出镜像推送到私有容器镜像注册表，或从需要身份验证的私有容器镜像注册表中拉取构建器镜像。

您可以为同一注册表中的多个存储库提供凭据，每个存储库都具有特定于该注册表路径的凭据。

.docker/config.json文件默认位于您的主目录中，并具有以下格式：

您可以定义多个容器镜像注册表，或在同一注册表中定义多个存储库。或者，您也可以通过运行docker login命令将身份验证条目添加到此文件中。如果文件不存在，则会创建它。

Kubernetes提供Secret对象，可用于存储配置和密码。

与 Pod 环境变量一样，构建环境变量也可以使用向下 API 定义为对其他资源或变量的引用。有一些例外情况，已注明。

您还可以使用 oc set env 命令管理在 BuildConfig 中定义的环境变量。

服务提供证书密钥旨在支持需要开箱即用证书的复杂中间件应用程序。它与管理员工具为节点和主节点生成的服务器证书具有相同的设置。

要保护与您的服务的通信安全，请让集群将已签名的服务证书/密钥对生成到您命名空间中的密钥中。

其他 Pod 可以通过使用自动挂载在其 Pod 中的 /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt 文件中的证书颁发机构 (CA) 捆绑包来信任集群创建的证书，这些证书仅针对内部 DNS 名称进行签名。

此功能的签名算法为 x509.SHA256WithRSA。要手动轮换，请删除生成的密钥。将创建一个新的证书。

要使用密钥，Pod 需要引用该密钥。密钥可以通过三种方式与 Pod 一起使用：

卷类型密钥使用卷机制将数据作为文件写入容器。imagePullSecrets 使用服务帐户将密钥自动注入命名空间中的所有 Pod。

当模板包含密钥定义时，模板使用提供的密钥的唯一方法是确保验证密钥卷源，并且指定的 Object 引用实际上指向 Secret 类型的对象。因此，在任何依赖它的 Pod 之前都需要创建密钥。确保这一点最有效的方法是通过使用服务帐户将其自动注入。

密钥 API 对象位于命名空间中。它们只能被同一命名空间中的 Pod 引用。

单个密钥的大小限制为 1MB。这是为了避免创建会耗尽 apiserver 和 kubelet 内存的大型密钥。但是，创建许多较小的密钥也可能会耗尽内存。