使用gcloud和具有“所有者”权限的服务帐户推送docker图像时,“500内部服务器错误”
我正在尝试将Docker容器图像推送到Google Container引擎registry:
$ sudo gcloud docker push gcr.io/<my_project>/node The push refers to a repository [gcr.io/<my_project>/node] (len: 1) 24c43271ae0b: Image already exists 70a0868daa56: Image already exists 1d86f57ee56d: Image already exists a46b473f6491: Image already exists a1ac8265769f: Image already exists 290bb858e1c3: Image already exists d6fc4b5b4917: Image already exists 3842411e5c4c: Image already exists 7a01cc5f27b1: Image already exists dbacfa057b30: Image already exists latest: digest: sha256:02be2e66ad2fe022f433e228aa43f32d969433402820035ac8826880dbc325e4 size: 17236 Received unexpected HTTP status: 500 Internal Server Error
我不能使命令更详细。 无论如何:
$ sudo gcloud docker push gcr.io/<my_project>/node --verbosity info
也不应该使用这个命令:
$ sudo gcloud docker --log-level=info push gcr.io/sigma-cairn-99810/node usage: gcloud docker [EXTRA_ARGS ...] [optional flags] ERROR: (gcloud.docker) unrecognized arguments: --log-level=info
根据文档(参见EXTRA_ARGS
)和--log-level=info
是一个有效的docker选项:
SYNOPSIS gcloud docker [EXTRA_ARGS ...] [--authorize-only, -a] [--docker-host DOCKER_HOST] [--server SERVER,[SERVER,...], -s SERVER,[SERVER,...]; default="gcr.io,us.gcr.io,eu.gcr.io,asia.gcr.io,b.gcr.io,bucket.gcr.io,appengine.gcr.io"] [GLOBAL-FLAG ...] ... POSITIONAL ARGUMENTS [EXTRA_ARGS ...] Arguments to pass to docker.
我正在使用GCP在我的container-vm
机器实例上安装的默认服务帐户。 我也赋予了<my_project>
所有资源的所有者权限。
更新:
运行sudo gsutil ls -bL gs://artifacts.<my_project>.appspot.com
我得到:
gs://artifacts.<my_project>.appspot.com/ : Storage class: STANDARD Location constraint: US Versioning enabled: None Logging configuration: None Website configuration: None CORS configuration: None Lifecycle configuration: None ACL: [] Default ACL: []
如果我在使用非服务帐户进行身份validation后执行同样的操作,则同时获得ACL
和Default ACL
:
ACL: [ { "entity": "project-owners-262451203973", "projectTeam": { "projectNumber": "262451203973", "team": "owners" }, "role": "OWNER" }, { "entity": "project-editors-262451203973", "projectTeam": { "projectNumber": "262451203973", "team": "editors" }, "role": "OWNER" }, { "entity": "project-viewers-262451203973", "projectTeam": { "projectNumber": "262451203973", "team": "viewers" }, "role": "READER" } ] Default ACL: [ { "entity": "project-owners-262451203973", "projectTeam": { "projectNumber": "262451203973", "team": "owners" }, "role": "OWNER" }, { "entity": "project-editors-262451203973", "projectTeam": { "projectNumber": "262451203973", "team": "editors" }, "role": "OWNER" }, { "entity": "project-viewers-262451203973", "projectTeam": { "projectNumber": "262451203973", "team": "viewers" }, "role": "READER" } ]
你可以运行sudo gsutil ls -bL gs://artifacts.<my_project>.appspot.com
并查看是否可以访问GCS存储桶。 这将validation泊坞窗图像的存储权限。
虽然我认为你应该通过被添加到所有者的权限,这将validation你是否做。
至于EXTRA_ARGS
,我认为--log-level="info"
只对命令docker daemon
有效, docker push
不能识别--log-level="info"
UPDATE
从再次查看日志,您正在推送一个大部分存在的图像,因为“图像已经存在”日志条目指示。 在第一个新的写入步骤失败。 这表明,问题似乎可能是您最初开始的实例只具有只读范围。
你可以运行这个命令并共享输出。 curl -H "Metadata-Flavor:Google" http://metadata/computeMetadata/v1/instance/service-accounts/default/scopes
我们正在寻找范围https://www.googleapis.com/auth/devstorage.read_write
。
可能发生的情况是,该实例最初并不是使用此作用域创build的,并且由于实例上的作用域不能被修改,所以它只能保持能够读取。
如果是这种情况,解决scheme可能会创build一个新的实例。
我们将提交一个bug来确保在这种情况下提供更好的消息传递。