harshavardhanj/docker-buildx

支持的标签及对应Dockerfile链接

• https://github.com/HarshaVardhanJ/docker_files/blob/master/docker-cloud-builder/Dockerfile
• https://github.com/HarshaVardhanJ/docker_files/blob/testing/docker-cloud-builder/Dockerfile
• https://github.com/HarshaVardhanJ/docker_files/blob/non-root/docker-cloud-builder/Dockerfile
• https://github.com/HarshaVardhanJ/docker_files/blob/master/docker-cloud-builder/Dockerfile - 此镜像不供他人使用，仅用于内部测试。

快速参考

• 获取帮助: https://github.com/HarshaVardhanJ/docker_files/issues
• 提交问题: https://github.com/HarshaVardhanJ/docker_files/issues
• 维护者: https://github.com/HarshaVardhanJ/docker_files
• 支持架构: amd64, arm32v6, arm32v7, arm64v8, i386, ppc64le, s390x
• 描述来源: https://github.com/HarshaVardhanJ/docker_files/blob/master/docker-cloud-builder/README.md

什么是docker-buildx？

docker-buildx是基于Alpine Linux构建的容器镜像，已安装Docker并添加了buildx支持。buildx是Docker CLI的扩展插件，提供BuildKit的增强构建能力，支持使用同一Dockerfile构建多架构镜像。更多关于buildx功能的信息，请点击https://github.com/docker/buildx%E3%80%82

如何使用此镜像

使用docker-buildx构建多架构镜像

最简便的方式是使用Google Cloud Platform的Cloud Build，该镜像作为工具构建器调用docker buildx命令。传递给此构建器的参数将直接传递给docker buildx，允许调用者运行任何docker buildx命令。

目前没有官方镜像提供此特定用途（即利用Docker的buildx命令构建多架构镜像），下面给出一个cloudbuild.yaml示例，用于在GCP Cloud Build上自动化构建。

yaml
# 示例cloudbuild.yaml文件
steps:
  - name: 'harshavardhanj/docker-buildx:latest'
    args: ['build', '-t', '[IMAGE_NAME:IMAGE_TAG]', '-f', '/path/to/Dockerfile', '.']

示例

以下示例展示了使用此构建器的构建请求：

构建并推送镜像到Google Container Registry（GCR）

此cloudbuild.yaml调用docker buildx并将结果镜像推送到GCR。

yaml
steps:
  - name: 'harshavardhanj/docker-buildx:latest'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/image_name', '.']
images: ['gcr.io/$PROJECT_ID/image_name']

就buildx的功能而言，其主要优势是无需修改Dockerfile即可构建多架构支持的镜像。

构建并推送镜像到Docker Hub

使用GCP Secrets Manager

通用步骤：建议在Docker Hub创建访问令牌，避免暴露账户密码，且可随时创建/撤销令牌。

需启用GCP的Secrets Manager API，设置步骤见此处。启用后创建两个密钥：Docker Hub用户名和访问令牌。

创建密钥后，授予Cloud Build服务账户访问这两个密钥的权限，参考此页面（步骤类似，适用于Secrets Manager）。权限授予后，即可创建cloudbuild.yaml及所需文件。

以下是用于Cloud Build构建并推送镜像到Docker Hub的简化cloudbuild.yaml：

yaml
steps:
  # 获取Docker Hub用户名和访问令牌，并保存到后续步骤可访问的文件
  - name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: "bash"
    args: ["./docker-cloud-builder/getCredentials.sh"]

  # 使用前一步获取的凭据登录Docker Hub
  - name: 'gcr.io/cloud-builders/docker'
    entrypoint: "bash"
    args: ["-c", "docker login --username=$(cat ./UserID) --password=$(cat ./AccessToken)"]

  # 拉取buildx镜像并构建多架构镜像
  - name: 'harshavardhanj/docker-buildx:latest'
    args:
      - 'build'
      - '-t'
      - 'harshavardhanj/docker-buildx:latest'
      - '--platform'
      - 'linux/amd64,linux/arm64,linux/386,linux/arm/v7,linux/arm/v6'
      - '-f'
      - './docker-cloud-builder/Dockerfile'
      - '--push'
      - './docker-cloud-builder/.'

getCredentials.sh脚本：

sh
#!/usr/bin/env sh
#
#: 标题        : getCredentials.sh
#: 日期         : 2020-02-17
#: 作者       : "Harsha Vardhan J" <vardhanharshaj@gmail.com>
#: 版本      : 0.1
#: 描述  : 用于Cloud Build获取凭据以登录Docker Hub的脚本
#: 选项      : 无
#: 使用        : 该脚本适用于GCP Cloud Build
################


# 封装gcloud命令以访问密钥
getCreds() {

  # 如果提供两个参数且第二个参数非空
  if [[ $# -eq 2 && -n ${2} ]] ; then
    # 用于访问密钥的gcloud命令
    gcloud beta secrets versions access ${1} --secret="${2}"
  else
    exit 1
  fi

}

# 调用getCreds函数，传入密钥版本和密钥名称
getCreds 1 DockerHubUserID > ./UserID
getCreds 1 DockerHubAccessToken > ./AccessToken

# 脚本结束

需修改的内容：最终步骤中的镜像标签和Dockerfile路径。以下是通用模板，可用于构建多架构镜像：

yaml
steps:
  # 获取Docker Hub用户名和访问令牌
  - name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: "bash"
    args: ["./path/to/getCredentials.sh/from/repo/root"]

  # 登录Docker Hub
  - name: 'gcr.io/cloud-builders/docker'
    entrypoint: "bash"
    args: ["-c", "docker login --username=$(cat ./UserID) --password=$(cat ./AccessToken)"]

  # 构建并推送多架构镜像
  - name: 'harshavardhanj/docker-buildx:latest'
    args:
      - 'build'
      - '-t'
      - '[dockerHub用户名]/[镜像名称]:[镜像标签]'
      - '-t'
      - '[dockerHub用户名]/[镜像名称]:[额外标签]'
      - '--platform'
      - 'linux/amd64,linux/arm64,linux/s390x,linux/386,linux/arm/v7,linux/arm/v6'
      - '-f'
      - './path/to/Dockerfile/from/repo/root'
      - '--push'
      - './path/to/Dockerfile/directory/.'

--platform参数可根据需要调整，若某些架构构建失败（日志可见），可移除对应的架构。

使用GCP密钥管理服务（KMS）

此方法需更多步骤以验证Docker Hub身份，详细步骤见GCP Cloud Build文档。

注意事项

在Secrets Manager或KMS中存储和访问密钥会产生费用（虽然较低），需注意成本。

cloudbuild.yaml的额外选项

timeout

Cloud Build默认10分钟后终止构建，可通过timeout选项覆盖：

yaml
steps:
  - name: ...
  
  - name: ...
  
timeout: "1200s"

timeout值以秒为单位，示例中为20分钟。若构建时间较长，建议设置此选项。

machineType

Cloud Build支持使用更强大的CPU，通过options下的machineType指定：

yaml
steps:
  - name: ...
  
  - name: ...
  
options:
  machineType: 'N1_HIGHCPU_8'

支持的类型：

• N1_HIGHCPU_8（8核CPU）
• N1_HIGHCPU_32（32核CPU）

注意：使用此选项会产生费用，且构建启动可能较慢（资源 provisioning）。

镜像变体

docker-buildx镜像提供以下变体/标签：

docker-buildx:stable

该镜像也可用以下标签访问：

• latest
• 19.03.5-r0
• 19.03.5
• 19.03

如标签所示，此镜像经过充分测试，推荐使用。版本号对应镜像中安装的Docker版本。

docker-buildx:testing

所有新功能或变更会先在此镜像中引入，测试后再合并到stable镜像。有时可能与stable镜像相同，不建议生产环境使用。

docker-buildx:non-root

该镜像以非root用户（当前为docker）运行buildx可执行文件。无stable标签不代表不稳定，其稳定性与stable镜像一致，适合不希望以root身份运行容器的场景。

docker-buildx:untested

此镜像不供公开使用，仅用于内部测试。使用此镜像可能导致失败或错误，甚至无法启动容器。

许可证

目前，镜像仓库中的软件未应用特定许可证。与所有Docker镜像一样，其中可能包含其他受不同许可证约束的软件（如基础发行版中的Bash等，以及包含的主要软件的任何直接或间接依赖项）。对于任何预构建镜像的使用，镜像用户有责任确保其使用符合所有包含软件的相关许可证。