使用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后执行同样的操作,则同时获得ACLDefault 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来确保在这种情况下提供更好的消息传递。