支持控制台（Console）开发人员开始试用联系人

3.4. Git 源

指定之后，从提供的位置获取源代码。

如果您提供内联 Dockerfile，它将覆盖 Git 存储库的 contextDir 中的 Dockerfile。

源定义是 BuildConfig 的 spec 部分的一部分： 

source:
  git: 1
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
  contextDir: "app/dir" 2
  dockerfile: "FROM openshift/ruby-22-centos7\nUSER example" 3
1
git 字段包含源代码的远程 Git 存储库的 URI (Uniform Resource Identifier)。您必须指定 ref 字段的值来签出特定的 Git 引用。有效的 ref 可以是 SHA1 标签或分支名称。ref 字段的默认值为 master。
2
contextDir 字段允许您覆盖源代码存储库中构建查找应用程序源代码的默认位置。如果应用程序位于子目录中，您可以使用此字段覆盖默认位置（根文件夹）。
3
如果提供可选的 dockerfile 字段，它应该是包含 Dockerfile 的字符串，此文件将覆盖源存储库中可能存在的任何 Dockerfile。

如果 ref 字段注明拉取请求，则系统将使用 git fetch 操作，然后 checkout FETCH_HEAD。

如果未提供 ref 值，OpenShift Container Platform 将执行浅克隆 (--depth=1)。这时，仅下载与默认分支（通常为 master）上最近提交相关联的文件。这将使存储库下载速度加快，但不会有完整的提交历史记录。要执行指定存储库的默认分支的完整 git clone，请将 ref 设置为默认分支的名称（如 main）。

警告

如果 Git 克隆操作要经过执行中间人 (MITM) TLS 劫持或重新加密被代理连接的代理，该操作不起作用。

3.4.1. 使用代理

如果 Git 存储库只能使用代理访问，您可以在构建配置的 source 部分中定义要使用的代理。您可以同时配置要使用的 HTTP 和 HTTPS 代理。两个字段都是可选的。也可以在 NoProxy 字段中指定不应执行代理的域。

注意

源 URI 必须使用 HTTP 或 HTTPS 协议才可以正常工作。 

source:
  git:
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
    httpProxy: http://proxy.example.com
    httpsProxy: https://proxy.example.com
    noProxy: somedomain.com, otherdomain.com
注意

对于 Pipeline 策略构建，因为 Jenkins Git 插件当前限制的缘故，通过 Git 插件执行的任何 Git 操作都不会利用 BuildConfig 中定义的 HTTP 或 HTTPS 代理。Git 插件将仅使用 Plugin Manager 面板上 Jenkins UI 中配置的代理。然后，在所有任务中，此代理都会被用于 Jenkins 内部与 git 的所有交互。

其他资源

  • 您可以在 JenkinsBehindProxy 上找到有关如何通过 Jenkins UI 配置代理的说明。

3.4.2. 源克隆 secret

构建器 pod 需要访问定义为构建源的任何 Git 存储库。源克隆 secret 为构建器 pod 提供了通常无权访问的资源的访问权限，例如私有存储库或具有自签名或不可信 SSL 证书的存储库。

支持以下源克隆 secret 配置：

  • .gitconfig 文件
  • 基本身份验证（Basic authentication）
  • SSH 密钥身份验证
  • 可信证书颁发机构
注意

您还可以组合使用这些配置来满足特定的需求。

3.4.2.1. 自动把源克隆 secret 添加到构建配置

创建 BuildConfig，OpenShift Container Platform 可以自动填充其源克隆 secret 引用。这会使生成的构建自动使用存储在引用的 secret 中的凭证与远程 Git 存储库进行身份验证，而无需进一步配置。

若要使用此功能，包含 Git 存储库凭证的一个 secret 必须存在于稍后创建 BuildConfig 的命名空间中。此 secret 必须包含前缀为 build.openshift.io/source-secret-match-uri- 的一个或多个注解。这些注解中的每一个值都是统一资源标识符（URI）模式，其定义如下。如果 BuildConfig 是在没有源克隆 secret 引用的前提下创建的，并且其 Git 源 URI 与 secret 注解中的 URI 模式匹配，OpenShift Container Platform 将自动在 BuildConfig 插入对该 secret 的引用。

先决条件

URI 模式必须包含：

  • 有效的方案包括： *://、git://、http://、https:// 或 ssh://
  • 一个主机：*,或一个有效的主机名或 IP 地址（可选）在之前使用 *。
  • 一个路径： /*，或 / （后面包括任意字符并可以包括 * 字符）

在上述所有内容中，* 字符被认为是通配符。

重要

URI 模式必须与符合 RFC3986 的 Git 源 URI 匹配。不要在 URI 模式中包含用户名（或密码）组件。

例如，如果使用 ssh://git@bitbucket.atlassian.com:7999/ATLASSIAN jira.git 作为 git 存储库 URL，则源 secret 必须指定为 ssh://bitbucket.atlassian.com:7999/*（而非 ssh://git@bitbucket.atlassian.com:7999/*）。 

$ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.atlassian.com:7999/*'

流程

如果多个 secret 与特定 BuildConfig 的 Git URI 匹配，OpenShift Container Platform 会选择匹配最多的 secret。这可以实现下例中所示的基本覆盖。

以下片段显示了两个部分源克隆 secret，第一个匹配通过 HTTPS 访问的 mycorp.com 域中的任意服务器，第二个则覆盖对服务器 mydev1.mycorp.com 和 mydev2.mycorp.com 的访问： 

kind: Secret
apiVersion: v1
metadata:
  name: matches-all-corporate-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
data:
  ...
---
kind: Secret
apiVersion: v1
metadata:
  name: override-for-my-dev-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
    build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
data:
  ...

  • 使用以下命令将 build.openshift.io/source-secret-match-uri- 注解添加到预先存在的 secret： 

    $ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'

3.4.2.2. 手动添加源克隆 secret

通过将 sourceSecret 字段添加到 BuildConfig 中的 source 部分，并将它设置为您创建的 secret 的名称，可以手动将源克隆 secret 添加到构建配置中。在本例中，是 basicsecret。 

apiVersion: "build.openshift.io/v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"
  source:
    git:
      uri: "https://github.com/user/app.git"
    sourceSecret:
      name: "basicsecret"
  strategy:
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "python-33-centos7:latest"

流程

您还可以使用 oc set build-secret 命令在现有构建配置中设置源克隆 secret。

  • 要在现有构建配置上设置源克隆 secret，请输入以下命令： 

    $ oc set build-secret --source bc/sample-build basicsecret

3.4.2.3. 从 .gitconfig 文件创建 secret

如果克隆应用程序要依赖于 .gitconfig 文件，您可以创建包含它的 secret。将它添加到 builder 服务帐户中，再添加到您的 BuildConfig 。

流程

  • 从 .gitconfig 文件创建 secret： 
$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>
注意

如果 .gitconfig 文件的 http 部分设置了 sslVerify=false，则可以关闭 iVSSL 验证： 

[http]
        sslVerify=false

3.4.2.4. 从 .gitconfig 文件为安全 Git 创建 secret

如果 Git 服务器使用双向 SSL 和用户名加密码进行保护，您必须将证书文件添加到源构建中，并在 .gitconfig 文件中添加对证书文件的引用。

先决条件

  • 您必须具有 Git 凭证。

流程

将证书文件添加到源构建中，并在 gitconfig 文件中添加对证书文件的引用。

  1. 将 client.crt、cacert.crt 和 client.key 文件添加到应用程序源代码的 /var/run/secrets/openshift.io/source/ 目录中。

  2. 在服务器的 .gitconfig 文件中，添加下例中所示的 [http] 部分： 

    # cat .gitconfig

    输出示例

    [user]
        name = <name>
        email = <email>
[http]
        sslVerify = false
        sslCert = /var/run/secrets/openshift.io/source/client.crt
        sslKey = /var/run/secrets/openshift.io/source/client.key
        sslCaInfo = /var/run/secrets/openshift.io/source/cacert.crt

  3. 创建 secret： 

    $ oc create secret generic <secret_name> \
--from-literal=username=<user_name> \1
--from-literal=password=<password> \2
--from-file=.gitconfig=.gitconfig \
--from-file=client.crt=/var/run/secrets/openshift.io/source/client.crt \
--from-file=cacert.crt=/var/run/secrets/openshift.io/source/cacert.crt \
--from-file=client.key=/var/run/secrets/openshift.io/source/client.key
    1
    用户的 Git 用户名。
    2
    此用户的密码。
重要

为了避免必须再次输入密码，需要在构建中指定 source-to-image（S2I）镜像。但是，如果无法克隆存储库，您仍然必须指定用户名和密码才能推进构建。

其他资源

  • 应用程序源代码中的 /var/run/secrets/openshift.io/source/ 文件夹。

3.4.2.5. 从源代码基本身份验证创建 secret

基本身份验证需要 --username 和 --password 的组合，或者令牌方可与软件配置管理（SCM）服务器进行身份验证。

先决条件

  • 用于访问私有存储库的用户名和密码。

流程

  1. 在使用 --username 和 --password 访问私有存储库前首先创建 secret: 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --type=kubernetes.io/basic-auth

  2. 使用令牌创建基本身份验证 secret： 

    $ oc create secret generic <secret_name> \
    --from-literal=password=<token> \
    --type=kubernetes.io/basic-auth

3.4.2.6. 从源代码 SSH 密钥身份验证创建 secret

基于 SSH 密钥的身份验证需要 SSH 私钥。

存储库密钥通常位于 $HOME/.ssh/ 目录中，但默认名称为 id_dsa.pub、id_ecdsa.pub、id_ed25519.pub 或 id_rsa.pub。

流程

  1. 生成 SSH 密钥凭证： 

    $ ssh-keygen -t ed25519 -C "your_email@example.com"
    注意

    使用带有密语保护的 SSH 密钥会导致 OpenShift Container Platform 无法进行构建。提示输入密语（passphrase）时，请将其留空。

    创建两个文件：公钥和对应的私钥（id_dsa、id_ecdsa、id_ed25519 或 id_rsa 之一）。这两项就位后，请查阅源代码控制管理 (SCM) 系统的手册来了解如何上传公钥。私钥用于访问您的私有存储库。

  2. 在使用 SSH 密钥访问私有存储库之前，先创建 secret： 

    $ oc create secret generic <secret_name> \
    --from-file=ssh-privatekey=<path/to/ssh/private/key> \
    --from-file=<path/to/known_hosts> \1
    --type=kubernetes.io/ssh-auth
    1
    可选：添加此字段可启用严格的服务器主机密钥检查。
    警告

    在创建 secret 时跳过 known_hosts 文件会使构建容易受到中间人 (MITM) 攻击的影响。

    注意

    确保 known_hosts 文件中包含源代码主机条目。

3.4.2.7. 从源代码可信证书颁发机构创建 secret

在 Git 克隆操作期间受信任的 TLS 证书颁发机构（CA）集合内置于 OpenShift Container Platform 基础结构镜像中。如果 Git 服务器使用自签名证书或由镜像不信任的颁发机构签名的证书，您可以创建包含证书的 secret 或者禁用 TLS 验证。

如果您为 CA 证书创建 secret，OpenShift Container Platform 会在 Git 克隆操作过程中使用它来访问您的 Git 服务器。使用此方法比禁用 Git 的 SSL 验证要安全得多，后者接受所出示的任何 TLS 证书。

流程

使用 CA 证书文件创建 secret。

  1. 如果您的 CA 使用中间证书颁发机构，请合并 ca.crt 文件中所有 CA 的证书。输入以下命令： 

    $ cat intermediateCA.crt intermediateCA.crt rootCA.crt > ca.crt

  2. 运行以下命令来创建 secret： 

    $ oc create secret generic mycert --from-file=ca.crt=</path/to/file> 1
    1
    您必须使用密钥名称 ca.crt。

3.4.2.8. 源 secret 组合

您可以组合使用不同的源克隆 secret 创建方法来满足特定的需求。

3.4.2.8.1. 使用 .gitconfig 文件创建基于 SSH 的身份验证 secret

您可以组合不同的方法开创建源克隆 secret 以满足特定的需求，例如使用 .gitconfig 文件的基于 SSH 的身份验证 secret。

先决条件

  • SSH 身份验证
  • .gitconfig 文件

流程

  • 要使用 .gitconfig 文件创建基于 SSH 的身份验证 secret，请输入以下命令： 

    $ oc create secret generic <secret_name> \
    --from-file=ssh-privatekey=<path/to/ssh/private/key> \
    --from-file=<path/to/.gitconfig> \
    --type=kubernetes.io/ssh-auth
3.4.2.8.2. 创建组合了 .gitconfig 文件和 CA 证书的 secret

您可以组合使用不同的源克隆 secret 创建方法来满足特定的需求，例如组合了 .gitconfig 文件和 CA 证书的 Secret。

先决条件

  • .gitconfig 文件
  • CA 证书

流程

  • 要创建组合了 .gitconfig 文件和 CA 证书的 secret，请输入以下命令： 

    $ oc create secret generic <secret_name> \
    --from-file=ca.crt=<path/to/certificate> \
    --from-file=<path/to/.gitconfig>
3.4.2.8.3. 使用 CA 证书创建基本身份验证 secret

您可以组合使用不同的源克隆 secret 创建方法来满足特定的需求，例如组合了基本身份验证和 CA 证书的 secret。

先决条件

  • 基本身份验证凭证
  • CA 证书

流程

  • 要使用 CA 证书创建基本身份验证 secret，请输入以下命令： 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=ca-cert=</path/to/file> \
    --type=kubernetes.io/basic-auth
3.4.2.8.4. 使用 Git 配置文件创建基本身份验证 secret

您可以组合使用不同的源克隆 secret 创建方法来满足特定的需求，例如组合了基本身份验证和 .gitconfig 文件的 secret。

先决条件

  • 基本身份验证凭证
  • .gitconfig 文件

流程

  • 要使用 .gitconfig 文件创建基本身份验证 secret，请输入以下命令： 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=</path/to/.gitconfig> \
    --type=kubernetes.io/basic-auth
3.4.2.8.5. 使用 .gitconfig 文件和 CA 证书创建基本身份验证 secret

您可以组合使用不同的源克隆 secret 创建方法来满足特定的需求，例如组合了基本身份验证、.gitconfig 文件和证书颁发机构（CA）证书的 Secret。

先决条件

  • 基本身份验证凭证
  • .gitconfig 文件
  • CA 证书

流程

  • 要使用 .gitconfig 文件和 CA 证书创建基本身份验证 secret，请输入以下命令： 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=</path/to/.gitconfig> \
    --from-file=ca-cert=</path/to/file> \
    --type=kubernetes.io/basic-auth
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.