配置您的 GitHub Actions 构建器

此页面包含在使用我们的 设置 Buildx 操作时配置 BuildKit 实例的说明。

版本固定

默认情况下,操作将尝试使用 GitHub Runner(构建客户端)上可用的最新版本的 Buildx 以及 BuildKit(构建服务器)的最新版本。

要固定到特定版本的 Buildx,请使用 version 输入。例如, 要固定到 Buildx v0.10.0:

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3
  with:
    version: v0.10.0

要固定到特定版本的 BuildKit,请在 driver-opts 输入中使用 image 选项。例如,要固定到 BuildKit v0.11.0:

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3
  with:
    driver-opts: image=moby/buildkit:v0.11.0

构建工具包容器日志

在使用 docker-container 驱动程序时显示 BuildKit 容器日志, 您必须启用 步骤调试日志记录, 或在 Docker Setup Buildx 操作中设置 --debug buildkitd 标志:

name: ci

on:
  push:

jobs:
  buildx:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
        with:
          buildkitd-flags: --debug
      
      - name: Build
        uses: docker/build-push-action@v6

作业结束时将提供日志:

BuildKit container logs

构建工具守护程序配置

如果您使用的是默认的 docker-container 驱动程序,可以为构建器提供 BuildKit 配置,使用 configbuildkitd-config-inline 输入:

镜像仓库

您可以使用 buildkitd-config-inline 输入在工作流程中直接使用内联块配置注册表镜像:

name: ci

on:
  push:

jobs:
  buildx:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
        with:
          buildkitd-config-inline: |
            [registry."docker.io"]
              mirrors = ["mirror.gcr.io"]            

有关使用注册表镜像的更多信息,请参阅 注册表镜像

最大并行度

您可以限制 BuildKit 求解器的并行性,这对于低功耗机器特别有用。

您可以使用与上一个示例相同的buildkitd-config-inline输入,或者如果您需要,可以使用仓库中专用的 BuildKit 配置文件,使用config输入:

# .github/buildkitd.toml
[worker.oci]
  max-parallelism = 4
name: ci

on:
  push:

jobs:
  buildx:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
        with:
          config: .github/buildkitd.toml

将附加节点添加到构建器

Buildx 支持在多台机器上运行构建。这对于在原生节点上构建 多平台镜像很有用,适用于 QEMU 无法处理的更复杂情况。在原生节点上构建通常性能更好,并允许您将构建分布在多台机器上。

您可以使用append选项将节点附加到您正在创建的构建器中。 它以YAML字符串文档的形式接收输入,以消除与GitHub Actions固有相关的限制:您只能在输入字段中使用字符串。

名称类型描述
namestring节点名称. 如果为空,它将是所属构建器的名称,并带有一个索引号后缀。如果您想修改/删除工作流底层步骤中的节点,这将很有用。
endpointstring要添加到构建器的节点的 Docker 上下文或端点
driver-opts列表附加选项的列表 驱动程序特定选项
buildkitd-flagsstring用于 buildkitd 守护程序的标志
platformsstring固定 平台 为节点。如果不为空,值优先于检测到的值。

这是一个使用远程节点的示例,采用 remote 驱动程序TLS 身份验证

name: ci

on:
  push:

jobs:
  buildx:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
        with:
          driver: remote
          endpoint: tcp://oneprovider:1234
          append: |
            - endpoint: tcp://graviton2:1234
              platforms: linux/arm64
            - endpoint: tcp://linuxone:1234
              platforms: linux/s390x            
        env:
          BUILDER_NODE_0_AUTH_TLS_CACERT: ${{ secrets.ONEPROVIDER_CA }}
          BUILDER_NODE_0_AUTH_TLS_CERT: ${{ secrets.ONEPROVIDER_CERT }}
          BUILDER_NODE_0_AUTH_TLS_KEY: ${{ secrets.ONEPROVIDER_KEY }}
          BUILDER_NODE_1_AUTH_TLS_CACERT: ${{ secrets.GRAVITON2_CA }}
          BUILDER_NODE_1_AUTH_TLS_CERT: ${{ secrets.GRAVITON2_CERT }}
          BUILDER_NODE_1_AUTH_TLS_KEY: ${{ secrets.GRAVITON2_KEY }}
          BUILDER_NODE_2_AUTH_TLS_CACERT: ${{ secrets.LINUXONE_CA }}
          BUILDER_NODE_2_AUTH_TLS_CERT: ${{ secrets.LINUXONE_CERT }}
          BUILDER_NODE_2_AUTH_TLS_KEY: ${{ secrets.LINUXONE_KEY }}

远程构建器的身份验证

以下示例展示了如何为远程构建器处理身份验证, 使用SSH或TLS。

SSH 身份验证

为了能够使用 docker-container 驱动程序 连接到 SSH 终结点, 您需要在 GitHub Runner 上设置 SSH 私钥和配置:

name: ci

on:
  push:

jobs:
  buildx:
    runs-on: ubuntu-latest
    steps:
      - name: Set up SSH
        uses: MrSquaare/ssh-setup-action@2d028b70b5e397cf8314c6eaea229a6c3e34977a # v3.1.0
        with:
          host: graviton2
          private-key: ${{ secrets.SSH_PRIVATE_KEY }}
          private-key-name: aws_graviton2
      
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
        with:
          endpoint: ssh://me@graviton2

TLS 身份验证

你还可以使用远程驱动程序设置远程 BuildKit 实例。为了简化在你的工作流程中的集成,你可以使用环境变量,该变量使用 BuildKit 客户端证书为 tcp:// 设置身份验证:

  • BUILDER_NODE_<idx>_AUTH_TLS_CACERT
  • BUILDER_NODE_<idx>_AUTH_TLS_CERT
  • BUILDER_NODE_<idx>_AUTH_TLS_KEY

<idx> 占位符是节点在节点列表中的位置。

name: ci

on:
  push:

jobs:
  buildx:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
        with:
          driver: remote
          endpoint: tcp://graviton2:1234
        env:
          BUILDER_NODE_0_AUTH_TLS_CACERT: ${{ secrets.GRAVITON2_CA }}
          BUILDER_NODE_0_AUTH_TLS_CERT: ${{ secrets.GRAVITON2_CERT }}
          BUILDER_NODE_0_AUTH_TLS_KEY: ${{ secrets.GRAVITON2_KEY }}

独立模式

如果你在 GitHub Runner 上没有安装 Docker CLI,将直接调用 Buildx Binaries,而不是将其作为 Docker CLI 插件调用。如果你希望在自托管的 runner 中使用 kubernetes 驱动程序,这可能会很有用:

name: ci

on:
  push:

jobs:
  buildx:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
        with:
          driver: kubernetes
      
      - name: Build
        run: |
          buildx build .          

隔离构建器

以下示例展示了如何为不同的作业选择不同的构建器。

一个可能有用的示例场景是,当你使用单体仓库时, 你希望将不同的包指定给特定的构建器。例如, 某些包的构建可能特别耗费资源,需要更多的计算能力。或者它们需要具备特定功能或硬件的构建器。

有关远程构建器的更多信息,请参阅 remote 驱动程序 以及 追加构建器节点示例

name: ci

on:
  push:

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - name: Set up builder1
        uses: docker/setup-buildx-action@v3
        id: builder1
      
      - name: Set up builder2
        uses: docker/setup-buildx-action@v3
        id: builder2
      
      - name: Build against builder1
        uses: docker/build-push-action@v6
        with:
          builder: ${{ steps.builder1.outputs.name }}
          target: mytarget1
      
      - name: Build against builder2
        uses: docker/build-push-action@v6
        with:
          builder: ${{ steps.builder2.outputs.name }}
          target: mytarget2