Skip to content
GitLab
Next
Closed
Issue created by Michaël Arnauts@michael.arnauts

Support specifying a multi-level image name in Gitlab Container Registry

Description

Developers create multiple containers based on the same code base and need to be able to support storing multiple images in the registry as part of a single project. Using named tags isn't sufficient or palatable for many people.

Proposal

  • Support arbitrarily named images under the project like registry.example.com/group/project/any-image-name-I-want:optional-tag

Links

Original report

Summary

I have a project that creates 3 different containers based on the same code base. It seems that I can't push a docker image to the new registry when I specify the name of the image. It only accepts tags.

Steps to reproduce

I have a codebase that can create multiple docker images.

  • pcore
  • pfront

I want to upload every image the the new registry, under the same project. This doesn't seem to work since I can only upload a image to the url specified in the GUI, with an optional tag behind it, but not a new image.

$ docker login registry.xxx
Username: michael.arnauts@xxx
Password: 
Login Succeeded

$ docker images
REPOSITORY                                   TAG                 IMAGE ID            CREATED             SIZE
destiny/boss-pcore                           latest              9b6c7462485e        15 minutes ago      581.6 MB

This doesn't work:

$ docker tag 9b6c7462485e registry.xxx/development/boss/pcore:latest

$ docker images
REPOSITORY                                   TAG                 IMAGE ID            CREATED             SIZE
destiny/boss-pcore                           latest              9b6c7462485e        15 minutes ago      581.6 MB
registry.xxx/development/boss/pcore          latest              9b6c7462485e        15 minutes ago      581.6 MB

$ docker push registry.xxx/development/boss/pcore:latest
The push refers to a repository [registry.xxx/development/boss/pcore]
bb825c9c2edb: Preparing 
43ba1e50b3a7: Preparing 
38cb0308ef11: Preparing 
a089587d56ae: Preparing 
18b149036961: Preparing 
7d748867f244: Waiting 
2b36e0c5d4eb: Waiting 
07e9a5d13d9c: Waiting 
c58452e78f4c: Waiting 
c58058fe5e93: Waiting 
69c466046f41: Waiting 
5f70bf18a086: Waiting 
11083b444c90: Waiting 
9468150a390c: Waiting 
56abdd66ba31: Waiting 
error parsing HTTP 403 response body: no error details found in HTTP response body: "{\"message\":\"forbidden\",\"status\":\"error\",\"http_status\":403}"

This works, but then I can't upload more images:

$ docker tag 9b6c7462485e registry.xxx/development/boss:latest

$ docker images
REPOSITORY                                   TAG                 IMAGE ID            CREATED             SIZE
destiny/boss-pcore                           latest              9b6c7462485e        15 minutes ago      581.6 MB
registry.xxx/development/boss                latest              9b6c7462485e        15 minutes ago      581.6 MB

$ docker push registry.xxx/development/boss:latest
The push refers to a repository [registry.xxx/development/boss]
bb825c9c2edb: Pushed 
43ba1e50b3a7: Pushed 
38cb0308ef11: Pushed 
a089587d56ae: Pushed 
18b149036961: Pushed 
7d748867f244: Pushed 
2b36e0c5d4eb: Pushed 
07e9a5d13d9c: Pushed 
c58452e78f4c: Pushed 
c58058fe5e93: Pushed 
69c466046f41: Pushed 
5f70bf18a086: Pushed 
11083b444c90: Pushed 
9468150a390c: Pushed 
56abdd66ba31: Pushed 
latest: digest: sha256:e7b153aa359bc7fc09d6af55fedd8b541648e76b8349d7735b745c0d06c373e6 size: 3429

Expected behavior

The push should succeed, creating a image named pcore:latest in the registry under project boss. Currently, I can only create a image boss:latest, but I need more image names.

Relevant logs and/or screenshots

2016-05-24_13:20:35.56182 time="2016-05-24T15:20:35.561719858+02:00" level=warning msg="error authorizing context: authorization token required" environment=production go.version=go1.5.4 http.request.host=registry.xxx http.request.id=f6976df6-611e-4136-ad7b-ddf845ea043a http.request.method=GET http.request.remoteaddr=188.118.4.210 http.request.uri="/v2/" http.request.useragent="docker/1.11.0 go/go1.5.4 git-commit/4dc5990 kernel/4.4.0-21-generic os/linux arch/amd64 UpstreamClient(Docker-Client/1.11.0 \\(linux\\))" instance.id=851cd0b9-2d69-4423-ad21-1ae94f6a45b8 service=registry version=v2.4.0 
2016-05-24_13:20:35.56189 127.0.0.1 - - [24/May/2016:15:20:35 +0200] "GET /v2/ HTTP/1.0" 401 87 "" "docker/1.11.0 go/go1.5.4 git-commit/4dc5990 kernel/4.4.0-21-generic os/linux arch/amd64 UpstreamClient(Docker-Client/1.11.0 \\(linux\\))"

Output of checks

Results of GitLab Application Check

Checking GitLab Shell ...

GitLab Shell version >= 2.7.2 ? ... OK (2.7.2)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
hooks directories in repos are links: ... 
5/2 ... ok
5/6 ... ok
5/7 ... ok
5/8 ... ok
5/11 ... ok
5/15 ... ok
8/19 ... repository is empty
8/25 ... ok
8/26 ... ok
5/28 ... ok
10/29 ... repository is empty
5/30 ... ok
5/31 ... ok
5/32 ... ok
5/33 ... ok
5/35 ... ok
5/36 ... ok
17/37 ... ok
3/39 ... ok
3/41 ... ok
5/42 ... ok
5/43 ... ok
5/44 ... ok
3/45 ... ok
8/46 ... ok
8/47 ... ok
2/48 ... ok
2/49 ... ok
5/50 ... ok
8/51 ... ok
5/52 ... ok
5/53 ... ok
5/54 ... ok
5/55 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Check directories and files: 
	/var/opt/gitlab/git-data/repositories: OK
	/var/opt/gitlab/.ssh/authorized_keys: OK
Test redis-cli executable: redis-cli 2.8.24
Send ping to redis server: PONG
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Reply by email ...

Reply by email is disabled in config/gitlab.yml

Checking Reply by email ... Finished

Checking LDAP ...

LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab ...

Git configured with autocrlf=input? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory setup correctly? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
projects have namespace: ... 
5/2 ... yes
5/6 ... yes
5/7 ... yes
5/8 ... yes
5/11 ... yes
5/15 ... yes
8/19 ... yes
8/25 ... yes
8/26 ... yes
5/28 ... yes
10/29 ... yes
5/30 ... yes
5/31 ... yes
5/32 ... yes
5/33 ... yes
5/35 ... yes
5/36 ... yes
17/37 ... yes
3/39 ... yes
3/41 ... yes
5/42 ... yes
5/43 ... yes
5/44 ... yes
3/45 ... yes
8/46 ... yes
8/47 ... yes
2/48 ... yes
2/49 ... yes
5/50 ... yes
8/51 ... yes
5/52 ... yes
5/53 ... yes
5/54 ... yes
5/55 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.1.0 ? ... yes (2.1.8)
Your git bin path is "/opt/gitlab/embedded/bin/git"
Git version >= 2.7.3 ? ... yes (2.7.4)
Active users: 13
Elasticsearch version >= 2.0? ... yes (2.2.0)
Elasticsearch has plugin delete-by-query installed? ... no

Checking GitLab ... Finished

Results of GitLab Environment Info

System information
System:		Ubuntu 14.04
Current User:	git
Using RVM:	no
Ruby Version:	2.1.8p440
Gem Version:	2.5.1
Bundler Version:1.10.6
Rake Version:	10.5.0
Sidekiq Version:4.1.2

GitLab information
Version:	8.8.1-ee
Revision:	1bf2cfb
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
URL:		https://code.xxx
HTTP Clone URL:	https://code.xxx/some-group/some-project.git
SSH Clone URL:	git@xxx:some-group/some-project.git
Using LDAP:	no
Using Omniauth:	no

GitLab Shell
Version:	2.7.2
Repositories:	/var/opt/gitlab/git-data/repositories
Hooks:		/opt/gitlab/embedded/service/gitlab-shell/hooks/
Git:		/opt/gitlab/embedded/bin/git

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)