问题描述
使用jib-gradle-plugin构建并推送到AWS ECR时，它要求我安装aws ecr credential helper，否则构建会抱怨“系统没有docker-credential-ecr-login CLI” 。
我想知道是否有一种方法可以在不安装凭证帮助程序的情况下推送到AWS ECR，或者是否可以将可移植版本的凭证帮助程序捆绑在存储库中？
安装帮助程序的问题是：
- 这需要在需要构建项目的每台机器上安装帮助程序，从而使构建流程没有我想要的自动化
- 要安装aws ecr凭据帮助程序，它需要安装Docker 。有点讽刺意味，因为jib的主要观点是在构建发生的主机上不需要Docker，因此构建可以是独立的且可移植的。
我知道这不是jib问题，但我只是希望使用jib的任何人都可能遇到类似的挑战，因此可以提供一些解决方法的见解。
解决方法
最后，全部归结为为Jib提供一个简单的用户名/密码字符串对。 Jib检索到该对后，Jib会直接将用户名和密码字符串文字传递给服务器，而无需进行任何处理。
使用Docker凭证帮助程序与通过CLI提供此字符串对没有什么不同。任何凭据帮助程序都将使用“ get”命令输出用户名和密码。例如，对于Google Container Registry，
$ docker-credential-gcr get <<<gcr.io
{"ServerURL":"","Username":"... this is the username ...","Secret":"... this is the password ..."}
因此，从理论上讲，您可以编写总是输出一些用户名/密码的哑脚本或二进制文件，将文件命名为docker-credential-my-dumb-script，并配置jib.{from|to}.credHelper='my-dumb-script'。不过我不会这样做。只是为了强调，这仅仅是向Jib提供用户名和密码对。
但是，请注意，许多凭证助手会动态生成短期凭证，这些凭证很快就会过期，这比使用静态和永久凭证安全得多。这是我们通常建议尽可能使用凭据帮助程序的原因之一。
另一个示例是docker login。例如，使用docker login chanseoktest.azurecr.io -u my-username -p my-password成功登录只会导致在my-username中记录my-password和~/.docker/config.json：
"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（也可以通过相应的{{3}进行设置）将凭据直接传递给Jib，而不是使用哑认证助手或间接jib.{from|to}.auth.{username|password}。 }，例如-Djib.from.auth.username=...）。只要您可以使用凭据帮助程序，我们也不建议这样做。请注意，如果您在命令行上传递凭据，则同一系统上的其他用户可以看到该命令（包括凭据），更不用说可以记录命令了。
有关提供用户名/密码对的方法的完整列表，请咨询官方system properties。
还请注意，您认为正确的用户名和密码对可能不是您的注册表实际接受的。例如，该AWS ECR用户FAQ可以使用“ AWS ECR关键用户”（无论使用什么）作为用户名，而实际上，docker-credential-ecr-login返回了AWS作为用户名。 （并不是您总是必须使用AWS作为用户名； ECR可能（也可能没有）具有多种形式的可接受凭据。）
最后，我将与您使用Jib的AWS ECR社区或平台社区确认，以确定哪种凭证形式最适合用作用户名和密码对，以“登录Docker”无法使用凭证助手。例如，对于GitHub Actions，以前我成功使用过mistakenly assumed。