Jib：如何在不安装的情况下使用 amazon-ecr-credential-helper？
Jib: how to use amazon-ecr-credential-helper without installing it?
当使用 jib-gradle-plugin to build and push to AWS ECR, it requires me to install aws ecr credential helper 时，否则构建会抱怨 “系统没有 docker-credential-ecr-login CLI”.
我想知道是否有一种方法可以在不安装凭证助手的情况下推送到 AWS ECR，或者是否可以在存储库中捆绑凭证助手的便携版本？
安装助手的问题是：
- 它要求在每台需要构建项目的机器上安装帮助程序，因此构建流程不像我希望的那样自动化
- 要安装 aws ecr credential helper，需要安装 Docker。这感觉有点讽刺，因为 Jib 的大部分要点是在发生构建的主机上不需要 Docker，因此构建可以是独立的和可移植的。
我知道这不是 Jib 问题，但我只是希望使用 Jib 的人可能 运行 遇到类似的挑战，因此可以提供一些关于如何解决它的见解。
最后，使用注册表进行身份验证都归结为向 Jib 提供一个简单的 username/password 字符串对。一旦 Jib 检索到这对，Jib 只是将用户名和密码字符串文字传递给服务器 as-is，根本不进行任何处理。 （顺便说一句，这个机制不是 Jib 特有的；每个 Docker 注册表都是这样工作的。）就这么简单：用户名和密码对就是最重要的。
使用 Docker 凭证助手与通过 CLI 提供此字符串对没有什么不同。任何凭证助手都将使用“get”命令输出用户名和密码。例如 Google Container Registry，
$ docker-credential-gcr get <<<gcr.io
{"ServerURL":"","Username":"... this is the username ...","Secret":"... this is the password ..."}
因此，理论上您可以编写一个始终输出一些 username/password 的哑脚本或二进制文件，将文件命名为 docker-credential-my-dumb-script，然后配置 jib.{from|to}.credHelper='my-dumb-script'。不过我不会这样做；这只是为了强调注册表验证只是向 Jib 提供用户名和密码对的问题。
但是请注意，许多凭据助手会动态生成 short-lived 即将过期的凭据，这比使用静态和永久凭据要安全得多。这是我们通常建议尽可能使用凭证助手的原因之一。也可能是某些云注册中心仅接受由其凭据助手生成的这些 short-lived 凭据。
另一个例子是docker login。例如，使用 docker login chanseoktest.azurecr.io -u my-username -p my-password 成功登录只会导致在 ~/.docker/config.json:
中记录 my-username 和 my-password
"auths": {
"chanseoktest.azurecr.io": {
# <username>:<password> in PLAIN string in base64 encoded form
"auth": "bXktdXNlcm5hbWU6bXktcGFzc3dvcmQ="
},
（如果你在 bXktdXNlcm5hbWU6bXktcGFzc3dvcmQ= 上进行 base64 解码，它会导致 my-username:my-password 为纯字符串。）这意味着，如果你可以使 docker pull/push 在某些系统上工作， Jib 也可以工作（因为 Jib 调查 ~/.docker/config.json）。因此，向 Jib 提供凭据的另一种方法是在系统上创建工作 ~/.docker/config.json（或者您可以从成功 运行 docker login 的另一个系统复制它）。这种方法，除非可以安全地完成，否则我不会这样做。
再举一个例子，除了哑凭证助手或 ~/.docker/config 间接寻址，您还可以通过 jib.{from|to}.auth.{username|password} 直接将您的凭证传递给 Jib（也可以通过相应的 system properties，例如 -Djib.from.auth.username=...)。只要您可以使用凭证助手，我们也不推荐这样做。请注意，如果您在 command-line 上传递凭据，同一系统上的其他用户可以看到该命令（包括凭据），更不用说可以将命令记录或存储在 shell 历史记录中。在某些环境中，如果您将这些凭据存储在某些环境变量中并修改您的 build.gradle 或 pom.xml 以从环境变量中读取 jib.{from|to}.auth.{username|password}，则可以减轻这种 command-line 风险。
提供username/password对的完整方法列表，可以咨询官方FAQ。
另请注意，您认为正确的用户名和密码对可能不是您的注册表实际接受的。例如，这个 AWS ECR 用户 mistakenly assumed 他们可以使用“AWS ECR 密钥用户”（无论它是什么）作为用户名，而实际上，docker-credential-ecr-login 返回 AWS 作为用户名. （并不是说您总是必须使用 AWS 作为用户名；ECR 可能（也可能不会）有多种形式的可接受凭据。）
最后，我会与 AWS ECR 社区或您使用 Jib 的平台社区确认哪种凭证形式最适合用作用户名和密码对以“登录 Docker" 如果您不能使用凭证助手。例如，对于GitHub Actions，之前我成功地使用了aws-actions/amazon-ecr-login.
当使用 jib-gradle-plugin to build and push to AWS ECR, it requires me to install aws ecr credential helper 时，否则构建会抱怨 “系统没有 docker-credential-ecr-login CLI”.
我想知道是否有一种方法可以在不安装凭证助手的情况下推送到 AWS ECR，或者是否可以在存储库中捆绑凭证助手的便携版本？
安装助手的问题是：
- 它要求在每台需要构建项目的机器上安装帮助程序，因此构建流程不像我希望的那样自动化
- 要安装 aws ecr credential helper，需要安装 Docker。这感觉有点讽刺，因为 Jib 的大部分要点是在发生构建的主机上不需要 Docker，因此构建可以是独立的和可移植的。
我知道这不是 Jib 问题，但我只是希望使用 Jib 的人可能 运行 遇到类似的挑战，因此可以提供一些关于如何解决它的见解。
最后，使用注册表进行身份验证都归结为向 Jib 提供一个简单的 username/password 字符串对。一旦 Jib 检索到这对，Jib 只是将用户名和密码字符串文字传递给服务器 as-is，根本不进行任何处理。 （顺便说一句，这个机制不是 Jib 特有的；每个 Docker 注册表都是这样工作的。）就这么简单：用户名和密码对就是最重要的。
使用 Docker 凭证助手与通过 CLI 提供此字符串对没有什么不同。任何凭证助手都将使用“get”命令输出用户名和密码。例如 Google Container Registry，
$ docker-credential-gcr get <<<gcr.io
{"ServerURL":"","Username":"... this is the username ...","Secret":"... this is the password ..."}
因此，理论上您可以编写一个始终输出一些 username/password 的哑脚本或二进制文件，将文件命名为 docker-credential-my-dumb-script，然后配置 jib.{from|to}.credHelper='my-dumb-script'。不过我不会这样做；这只是为了强调注册表验证只是向 Jib 提供用户名和密码对的问题。
但是请注意，许多凭据助手会动态生成 short-lived 即将过期的凭据，这比使用静态和永久凭据要安全得多。这是我们通常建议尽可能使用凭证助手的原因之一。也可能是某些云注册中心仅接受由其凭据助手生成的这些 short-lived 凭据。
另一个例子是docker login。例如，使用 docker login chanseoktest.azurecr.io -u my-username -p my-password 成功登录只会导致在 ~/.docker/config.json:
my-username 和 my-password
"auths": {
"chanseoktest.azurecr.io": {
# <username>:<password> in PLAIN string in base64 encoded form
"auth": "bXktdXNlcm5hbWU6bXktcGFzc3dvcmQ="
},
（如果你在 bXktdXNlcm5hbWU6bXktcGFzc3dvcmQ= 上进行 base64 解码，它会导致 my-username:my-password 为纯字符串。）这意味着，如果你可以使 docker pull/push 在某些系统上工作， Jib 也可以工作（因为 Jib 调查 ~/.docker/config.json）。因此，向 Jib 提供凭据的另一种方法是在系统上创建工作 ~/.docker/config.json（或者您可以从成功 运行 docker login 的另一个系统复制它）。这种方法，除非可以安全地完成，否则我不会这样做。
再举一个例子，除了哑凭证助手或 ~/.docker/config 间接寻址，您还可以通过 jib.{from|to}.auth.{username|password} 直接将您的凭证传递给 Jib（也可以通过相应的 system properties，例如 -Djib.from.auth.username=...)。只要您可以使用凭证助手，我们也不推荐这样做。请注意，如果您在 command-line 上传递凭据，同一系统上的其他用户可以看到该命令（包括凭据），更不用说可以将命令记录或存储在 shell 历史记录中。在某些环境中，如果您将这些凭据存储在某些环境变量中并修改您的 build.gradle 或 pom.xml 以从环境变量中读取 jib.{from|to}.auth.{username|password}，则可以减轻这种 command-line 风险。
提供username/password对的完整方法列表，可以咨询官方FAQ。
另请注意，您认为正确的用户名和密码对可能不是您的注册表实际接受的。例如，这个 AWS ECR 用户 mistakenly assumed 他们可以使用“AWS ECR 密钥用户”（无论它是什么）作为用户名，而实际上，docker-credential-ecr-login 返回 AWS 作为用户名. （并不是说您总是必须使用 AWS 作为用户名；ECR 可能（也可能不会）有多种形式的可接受凭据。）
最后，我会与 AWS ECR 社区或您使用 Jib 的平台社区确认哪种凭证形式最适合用作用户名和密码对以“登录 Docker" 如果您不能使用凭证助手。例如，对于GitHub Actions，之前我成功地使用了aws-actions/amazon-ecr-login.