Please let me know if there is a way to delete an image from the registry.

Hi,

I have no response when I try to connect through localhost. How reproduce:

docker service create --name my-registry --publish 5000:5000 registry:2.5
curl http://localhost:5000/v2/_catalog

Result is no answer and timeout.

I've written a more complete script for testing:

MY_IP=127.0.0.1
# VERBOSE=-v

request()
{
	curl --max-time 5 $VERBOSE http://$1:5000/v2/_catalog && echo Ok
}

# Start the container
docker run -d --publish 5000:5000 --name my-registry registry:2.5
until docker ps | grep registry >/dev/null; do sleep 1; done
docker ps

# Make the requests
echo "----------------------------------"
request $MY_IP
request localhost
echo "----------------------------------"

# Remove the container
docker stop my-registry
while docker ps | grep registry >/dev/null; do sleep 1; done
docker rm my-registry
echo "==================================================="

# Start the service
docker service create --name my-registry --publish 5000:5000 registry:2.5
until docker service ls | grep -E '1/1 +registry' >/dev/null; do sleep 1; done
docker service ls

# Make the requests
echo "----------------------------------"
request $MY_IP
request localhost
echo "----------------------------------"

# Remove the service
docker service rm my-registry

Response:

2bf6c26796c6544acc39a083a5d2521ae8de2958465b06615d6db09e1e4df55b
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                  PORTS                    NAMES
2bf6c26796c6        registry:2.5        "/entrypoint.sh /etc/"   1 seconds ago       Up Less than a second   0.0.0.0:5000->5000/tcp   my-registry
----------------------------------
{"repositories":[]}
Ok
{"repositories":[]}
Ok
----------------------------------
my-registry
my-registry
===================================================
54x68oyrgqh8ws5th9x21t5jr
ID            NAME         REPLICAS  IMAGE         COMMAND
54x68oyrgqh8  my-registry  1/1       registry:2.5  
----------------------------------
{"repositories":[]}
Ok
curl: (28) Operation timed out after 5001 milliseconds with 0 bytes received
----------------------------------
my-registry

Running environment (on Virtualbox):

$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
$ docker version 
Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 21:39:14 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 21:39:14 2016
 OS/Arch:      linux/amd64

Thanks.

Moved from distribution/distribution#2655

Somewhat related to distribution/distribution#2623 and distribution/distribution#2641, I was looking at the images on the Docker hub: https://hub.docker.com/r/library/registry/tags/
No release has been made on Github since 20 Jul 2017, yet the images are only 25 days old. The Circle CI definitions do not seem to do any push on release, so I assume this is done manually? Could we get some details on what has changed on 2.6.2 and 2.5.2 between their Github releases and the images that were pushed on 6 Jul 2018?

There's been a number of credential hijacks recently, which makes this a bit worrying.

Pinging some people who seem to possibly be able to answer this: @stevvooe @dmcgowan

I am trying to install registry on a Raspberry Pi 3 B + running the arm64v8 version of hypriot. The registry will not run.

Docker info

Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 1
Server Version: 18.04.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.14.37-hypriotos-v8
Operating System: Debian GNU/Linux 9 (stretch)
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 969MiB
Name: black-pearl
ID: xxxx
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
 os=linux
 arch=arm64
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support

I first tried to run:

docker run -d -p 5000:5000 --restart always --name registry registry
Unable to find image 'registry:latest' locally
latest: Pulling from library/registry
docker: no matching manifest for linux/arm64 in the manifest list entries.
See 'docker run --help'.

Noticed on hub.docker.com that there is a registry for aarch64 and tried:

docker run --platform linux/aarch64 -d -p 5000:5000 --restart always --name registry registry
Unable to find image 'registry:latest' locally
docker: Error response from daemon: invalid platform: invalid platform architecture "aarch64".
See 'docker run --help'.

This should work on nanoserver, I think.

Please add tzdata package to Dockerfile, without it timezones do not work correctly:

$ docker run -it --rm -e TZ=Europe/Moscow registry:2.6.2 date
Tue Mar 20 14:08:40 GMT 2018

The code change is in the master branch of the registry source. Any plans for a 2.6.3 or even a 2.7??

registry still runs as root user. (as of 2.6.0-rc.1)

"If a service can run without privileges, use USER to change to a non-root user."
https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#/user

I'm trying to deploy registry image on DC/OS but I'm getting always:

{
  "errors": [
  {
    "code": "UNAVAILABLE",
    "message": "service unavailable",
    "detail": "health check failed: please see /debug/health"
  }
 ]
}

Any help?

Description

I've created docker registry and trying to make it work with StartSSL certificate. It works ok on Windows machines, but if I try to docker login from Linux it fails with x509: certificate signed by unknown authority.

Steps to reproduce the issue:

1. Have a clean Ubuntu 16.10 installation with installed docker
2. Get certificate for domain from StartSSL
3. Run docker registry from official image:
   docker run -d -p 443:5000 --restart=always --name registry -v /home/docker-host/.docker/:/certs -v /home/docker-host/.docker/auth/:/auth -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/docker.crt -e REGISTRY_HTTP_TLS_KEY=/certs/docker.key registry:2
4. Try to docker login <myhost> from Windows
5. Try to docker login <myhost> from Linux

Received results:

On Windows it works fine and Login Succeeded message returned.

On Linux it returns Error response from daemon: Get https://<myhost>/v1/users/: x509: certificate signed by unknown authority

Additional information you deem important (e.g. issue happens only occasionally):

I also tried to curl registry URL from the same linux machine and it works fine, without certificate validation failures.

If I try to run sudo dpkg-reconfigure ca-certificates I see StartSSL's authority in the list.

Docker logs for registry container:

time="2016-11-19T02:00:57Z" level=info msg="listening on [::]:5000, tls" go.version=go1.6.3 instance.id=5662e6ff-c481-4e30-9e8f-784c400366cc version=v2.5.1
2016/11/19 02:01:44 http: TLS handshake error from 192.168.1.18:37014: remote error: bad certificate
2016/11/19 02:01:44 http: TLS handshake error from 192.168.1.18:37016: remote error: bad certificate
2016/11/19 02:05:15 http: TLS handshake error from 192.168.1.18:37020: remote error: bad certificate
2016/11/19 02:05:15 http: TLS handshake error from 192.168.1.18:37022: remote error: bad certificate

I also tried to use --insecure-registry flag mentioned here, but it seems removed?

Output of docker version:

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 22:01:48 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 22:01:48 2016
 OS/Arch:      linux/amd64

Output of docker info:

Containers: 1
 Running: 1
 Paused: 0
 Stopped: 0
Images: 3
Server Version: 1.12.3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 13
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 4.8.0-27-generic
Operating System: Ubuntu 16.10
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 414.1 MiB
Name: docker-host
ID: 3ZU5:YEMB:FMJW:SVLC:HAD6:IBEB:WOOI:S4BV:HSIF:JHBH:PWTE:65GB
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: docker-user
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 127.0.0.0/8

Is there way to mirror some insecure registry from private network via proxy setting?

proxy:
  remoteurl: https://docker.artifactory.infra.local

Now I'm getting

Get https://docker.artifactory.infra.local/v2/: x509: certificate signed by unknown authority

It would appear that the registry version doesn't support ECS task roles, so it can't be hosted within ECS without hard-coding keys (or using the machine / instance credentials).

It'd be nice if the binary available on hub.docker.com/registry:2 was rebuilt with a newer aws-sdk.

Is there any chance to get a registry container running on s390x architecture?

Port 80 is normal, not port 80 returns 404

im missing daemon.json need help where should i get it?

Hi all !

I'm trying to download an image that I have in Docker Repository, but I have a response error :

root@fernandotest:/# docker pull fermenreq/docker-whale
Using default tag: latest
Error response from daemon: manifest for fermenreq/docker-whale:latest not found

Im using an Ubuntu 14.04 Image Running on a fiware cloud VM. Requierements docker

I'm working on Windows 7 Enterprise and I connect to VM using cygwin.

Bests regards ! ****

I'm running this with:

docker run \
  --name=docker \
  -d \
  -e DEBUG=True \
  -e LOGLEVEL=debug \
  -e REGISTRY_STORAGE_S3_BUCKET="my_bucket" \
  -e REGISTRY_STORAGE=s3 \
  -e SETTINGS_FLAVOR=s3 \
  -e REGISTRY_STORAGE_S3_REGION="eu-west-1" \
  -e REGISTRY_STORAGE_S3_ROOTDIRECTORY="/" \
  -e SEARCH_BACKEND=sqlalchemy \
  -e REGISTRY_HTTP_TLS_CERTIFICATE="/path/to/my_cert.crt" \
  -e REGISTRY_HTTP_TLS_KEY="/path/to/my_key.key" \
  -e REGISTRY_AUTH_HTPASSWD_REALM=secure \
  -e REGISTRY_AUTH_HTPASSWD_PATH="my_auth_file" \
  -v /host/path/to/certs:/path/to/certs \
  -v /host/path/to/password_file:/path/to/password_file \
  -p 443:5000 \
  registry

This has all been working great, except for the _catalog endpoint which results in:

invalid path: /docker/registry/v2/repositories/" err.message="unknown error"

That path certainly exists in my bucket (I don't think the registry would be working if it wasn't). I've tried changing the REGISTRY_STORAGE_S3_ROOTDIRECTORY to various paths, and setting STORAGE_PATH too.

As far as I can see you guys are pushing images up to Docker hub without tagging the corresponding git rev here. That makes it impossible to know what rev any image came from.

From many documents,I know we can access the service on any node in the swarm by using localhost:$PORT.
for example,I start a service by the command "docker service create --name registry --publish 5000:5000 registry:2". According to what is said--https://guai.im/2016/08/08/docker-swram-in-aciton-03/,
we can get result by command "curl localhost:5000/v2/_catalog",but I failed,sometimes,I can get result by the command "curl 127.0.0.1:5000/v2/_catalog",but not all nodes.

$ docker run --rm -it registry:2.6.1 --help
/entrypoint.sh: exec: line 10: registry: not found

/bin/registry is missing. 😞

registry:2.6.0 works.

The currently used alpine 3.4 base image has a known CVS/vulnerability.

Security fix for at least CVE-2016-8859 (see Scan result for registry:2.6.2)

See PR: #62

HI,
I am trying to deploy the docker registry as an ECS service with S3 storage. I am running my service inside an ECS cluster which has an IAM role. When I attach an IAM role to the ECS task with S3 permissions, I get s3aws: Access Denied when trying push an image. When I attach the IAM role to the EC2 machines in the ECS cluster, it works as expected.
I have seen this issue in the past with different applications and this usually happens because of an old aws sdk. in the newer versions of the SDK they can handle these kind of things - but in the older versions it doesn't work.

Thanks,
Daniel Ezer

I am currently running a v1 registry and am looking to migrate to the v2. I've read through all the documentation, in particular this portion:

NOTE: It is highly recommended to create a base configuration file with which environment variables can be used to tweak individual values. Overriding configuration sections with environment variables is not recommended.

Ideally; however, I would like to run the v2 registry with S3 as my persistent storage and without having to create my own custom registry image. The reason for this thinking is, if I create a custom image based on the official image, then I have to store my image in my registry (the one I'm attempting to define with the image), which creates a circular dependence that makes me uncomfortable. If my registry is down for some reason I may no longer be able to re-publish a fixed image and get it back up and running.

This would seem to indicate I need to run the registry and be able to define the configuration exclusively with the ENV variables (the way I had with v1). When I try to do this; however, it fails to launch b/c the config example that is used by default already contains a local storage driver, so it throws an error.

Is there any way for me to run the official image and specify an S3 storage location without creating my own custom image?

I got following error when I run customized registry image:

/entrypoint.sh: exec: line 10: registry: not found

I used following way to build my customized registry image:

• build the v2.7.0 registry binary from https://github.com/docker/distribution
• copy to https://github.com/docker/distribution-library-image/tree/master/amd64

cd amd64
docker build --no-cache -t andyzhangx/registry:v2.7.0-nottl -f ./Dockerfile .

• docker run --rm -it andyzhangx/registry:v2.7.0-nottl --help, and then got following error:

/entrypoint.sh: exec: line 10: registry: not found

While if I use the original registry binary to build a image, it works well. Any steps I am missing?
@manishtomar

I just migrated a v1 registry to v2.5 on CoreOS. I used the following command to start the registry:

/usr/bin/docker run --name registry -e STORAGE_PATH=/registry -v /mnt/docker_registry_data/registry:/registry -e SEARCH_BACKEND=sqlalchemy -p 50000:5000 registry:2.5

however, nothing is being written to the /mnt/docker_registry_data/registry directory on the host machine and upon inspection of the running container:

 docker exec -i -t registry sh

/ # ps -fea
PID   USER     TIME   COMMAND
    1 root       0:24 registry serve /etc/docker/registry/config.yml
   30 root       0:00 sh
   33 root       0:00 ps -fea
/ # cat /etc/docker/registry/config.yml 
version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
/ # ls -l /var/lib/registry/docker/registry/v2/
total 16
drwxr-xr-x    3 root     root          4096 Aug  2 14:34 blobs
drwxr-xr-x    4 root     root          4096 Aug  2 14:39 repositories
/ # ls -l /registry/
total 0

you can notice that everything is being stored in /var/lib/registry which is an internal directory of the container.

Am I doing something wrong? I essentially followed the instructions in the docker-hub page. Thank you!

I've set in the config.....
storage:
cache:
blobdescriptor: inmemory
filesystem:
rootdirectory: /data/registry
delete:
enabled: true

I'm finding the sha, and performing delete, it either just details the manifest with a get, when I delete it says... {"errors":[{"code":"UNSUPPORTED","message":"The operation is unsupported."}]}

I've tried setting the environment variable for enabled delete, I've updated the config as shown above, and no matter what I try, it does not work.

I want to be able to purge images that have not been accessed so that proxy will not fill up. Currently we delete all the images, which causes the proxy to have to pull from artifactory again.

I have version 2.6.0 of the registry installed, and it proxies correctly, but no way to Delete.

Thanks
hite77

I am trying to push a huge image to my own repository which is using registry:2 docker image

➜  ~  docker push myownregistry.com/example/bigimage:1.4
The push refers to a repository [myownregistry.com/example/bigimage]
13da38f5bd3a: Pushing [>                                                  ]  3.879MB/12.46GB
1b300224ce7d: Layer already exists
219f1f90cdc8: Layer already exists
114c7a208a5d: Layer already exists
ccc9ad7b611c: Layer already exists
d2ee642ec2bc: Layer already exists
cf516324493c: Layer already exists

While pushing seems working, but at the end it shows "Retrying in ## seconds..."

In logs I see these errors

2017-11-27T23:18:18.382673683Z time="2017-11-27T23:18:18Z" level=error msg="unknown error reading request payload: unexpected EOF" auth.user.name=user go.version=go1.7.3 http.request.host=myownregistry.com http.request.id=9b4e1d3a-b2ca-4545-95e1-4301d15a09e2 http.request.method=PATCH http.request.remoteaddr=8.8.8.8 http.request.uri="/v2/example/bigimage/1.4/blobs/uploads/b1c328c2-504d-4d50-ae97-9ff4b18f8fe6?_state=71SePYthKB1qTm5g_02Nj61HjrftaUffkR6GPWnNwcx7Ik5hbWUiOiJhdXJlYS9maXJzdHJhaW4vc3lzdGVtLXJjIiwiVVVJRCI6ImIxYzMyOGMyLTUwNGQtNGQ1MC1hZTk3LTlmZjRiMThmOGZlNiIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxNy0xMS0yN1QyMzoxODoxMy42Mzc5NDkxMjZaIn0%3D" http.request.useragent="docker/17.09.0-ce go/go1.8.3 git-commit/afdb6d4 kernel/4.9.0-4-amd64 os/linux arch/amd64 UpstreamClient(Docker-Client/17.09.0-ce \\(linux\\))" instance.id=f168404c-05b4-4703-a144-d81387d69b1d vars.name="example/bigimage/1.4" vars.uuid=b1c328c2-504d-4d50-ae97-9ff4b18f8fe8 version=v2.6.1

2017-11-27T23:18:18.596515045Z time="2017-11-27T23:18:18Z" level=error msg="response completed with error" auth.user.name=user err.code=unknown err.detail="unexpected EOF" err.message="unknown error" go.version=go1.7.3 http.request.host=myownregistry.com http.request.id=9b4e1d3a-b2ca-4545-95e1-4301d15a09e2 http.request.method=PATCH http.request.remoteaddr=8.8.8.8 http.request.uri="/v2/example/bigimage/1.4/blobs/uploads/b1c328c2-504d-4d50-ae97-9ff4b18f8fe6?_state=71SePYthKB1qTm5g_02Nj61HjrftaUffkR6GPWnNwcx7Ik5hbWUiOiJhdXJlYS9maXJzdHJhaW4vc3lzdGVtLXJjIiwiVVVJRCI6ImIxYzMyOGMyLTUwNGQtNGQ1MC1hZTk3LTlmZjRiMThmOGZlNiIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxNy0xMS0yN1QyMzoxODoxMy42Mzc5NDkxMjZaIn0%3D" http.request.useragent="docker/17.09.0-ce go/go1.8.3 git-commit/afdb6d4 kernel/4.9.0-4-amd64 os/linux arch/amd64 UpstreamClient(Docker-Client/17.09.0-ce \\(linux\\))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=3.73857483s http.response.status=500 http.response.written=70 instance.id=f168404c-05b4-4703-a144-d81387d69b1d vars.name="example/bigimage/1.4" vars.uuid=b1c328c2-504d-4d50-ae97-9ff4b18f8fe8 version=v2.6.1

It seems it's not able to handle a big payload, I don't know if could be related to limited resources

root@docker:~# docker inspect registry
...
            "Memory": 17179869184,
            ...
            "CpuQuota": 400000,

This is the image size

➜  ~  docker images myownregistry.com/example/bigimage
REPOSITORY                           TAG                 IMAGE ID            CREATED             SIZE
myownregistry.com/example/bigimage   1.4                 d4540cf1c492        6 days ago          13.6GB

it works if I upload it to hub.docker.com

Does anyone knows what could be happening?

Title says all :)

because they turn off their ACMEv1 API .

I use

docker run -d -p 443:5000 --name registry \
  -v `pwd`:/etc/docker/registry/ \
  -v registry:/var/lib/registry \
  -e REGISTRY_HTTP_ADDR=0.0.0.0:5000 \
  -e REGISTRY_HTTP_HOST=https://docker.example.com \
  -e REGISTRY_HTTP_TLS_LETSENCRYPT_CACHEFILE=/etc/docker/registry/letsencrypt.json \
  -e [email protected] \
  registry:2

and get this error:

FATA[0001] register: acme: Error 403 - urn:acme:error:unauthorized - Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.

so I guess the registry:2 images needs to support ACMEv2

Hi, I use the latest (2.5.1) version of the image to create a registry server and use AWS S3 as the backend. However the image data is still saved under /var/lib/registry of the container. Nothing was uploaded to AWS S3. What might be the problem?

The run command as below:

sudo docker run \
         -e SETTINGS_FLAVOR=s3 \
         -e AWS_REGION=us-west-2 \
         -e AWS_BUCKET=my-docker \
         -e STORAGE_PATH=/registry \
         -e AWS_KEY=******** \
         -e AWS_SECRET=*********** \
         -e SEARCH_BACKEND=sqlalchemy \
         -e DEBUG=True \
         -p 5000:5000 \
         --name docker_registry \
         --restart=always \
         registry

Running something like this (credentials vars are omitted since my instance has an instance profile in AWS):

docker run \
         --name=docker \
         -d \
         -e DEBUG=True \
         -e LOGLEVEL=debug \
         -e SETTINGS_FLAVOR=s3 \
         -e AWS_REGION="eu-west-1" \
         -e AWS_BUCKET=[BUCKET_NAME] \
         -e STORAGE_PATH=/registry \
         -e SEARCH_BACKEND=sqlalchemy \
         -p 5000:5000 \
         registry:2

should write data to the specified S3 bucket. Instead it writes to the filesystem /var/lib/registry. Overriding the storage engine with REGISTRY_STORAGE_S3_BUCKET=[BUCKET_NAME] tells me that 2 engines were specified in the config file.

Likely, that I can override this properly by mounting a complete config file, but according the docs, the point of the SETTINGS_FLAVOR variable seems to be to conveniently set up S3 storage without doing that.

Running registry v2.5.1 inside Red Hat 7.2 docker server 1.10.3.

I have common base image and four images is built simultaneously on top of that.

Sometimes the push command for these four images breaks the images inside registry. I notice it when I'm pulling any of those four images, the pulling fails for 1 layer of each image and docker tries repeatable to pull without success. When problem occurs it is same for two different registry instance in two different machine. It might occure more often for one registry but I don't notice that because of HA solution for registries.

The dirty fix is to restart registry server with docker restart command and push again all four images to private repository. The push command finish quickly because the first unique layer for images are only needed to be updated to the registry. Then the other machine can run docker pull command and it finish normally.

On 2018-01-18 LetsEncrypt disabled TLS_SNI method,
so current LE-clients cannot issue new certificates anymore (but still can renew existing certificates for a while).

https://community.letsencrypt.org/t/tls-sni-challenges-disabled-for-most-new-issuance/50316

I setup a private registry with Aliyun OSS as the backend storage, and to save cost, I use internal Aliyun OSS endpoint instead of public endpoint, because it does not cost money to read/write object from/to oss in internal network.

The private registry works fine when pushing an image (through internet or internal network), because registry helps pushing image data to OSS.

However, when pulling an image (through internet), it does not work, because registry just tells docker client the URL of the objects in OSS, so that the docker client can directly pull the image object from Aliyun OSS. Since the URL given by registry is an internal URL, it is unreachable from internet, so the pull will fail.

The problem can be solved if we configure public OSS endpoint as storage driver for registry. However, this will bring additional cost, because Aliyun OSS costs money for in/out data through internet, and does not cost any if the data in/out through internal network.

So I think this is a bug of registry v2.6. when pulling, registry should also act like a delegator, who should pull image data from OSS to registry, and then pass through the data to docker client.

Hello,

I've a port binding with 443:5000. When I access it with curl --insecure -v https://127.0.0.1/ everything looks good.
But curl --insecure -v https://[::1]/ isn't working.

It gets stuck at this output:

• Trying ::1...
• TCP_NODELAY set
• Connected to ::1 (::1) port 443 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• successfully set certificate verify locations:
• CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
• TLSv1.2 (OUT), TLS handshake, Client hello (1):

A similar configuration with e. g. an Apache container works with IPv6.

Do I have an error in reasoning?

Thanks, webracer999

Would it be possible to get a license for this repository? There is a license file in the distribution project but the contents of this repository are needed to build a copy of the official image.

Is it possible to get the tag out of the event object when using notifications? The pull events contain the tag but not the push events, and I was reading in some discussions that this is because you don't necessarily know if this is the correct image for the tag, if I understand correctly. But it also sounded like it was possible to get the information based on how you configure the registry.

I'm trying to set up a system where I have workflows building container images, pushing them, and then another workflow will get notified of this and fire off some other steps. Sort of a CI system. I'm trying to use argo workflows, and as far as I can see I cannot do any advanced operations like extracting the tag from the information in the event information when the webhook is activated, I can just read the fields as they are. I'm setting up the registry with the docker registry helm repo. What I'm getting now is something like this (based on the notification docs example):

   "events": [
      {
         "id": "asdf-asdf-asdf-asdf-0",
         "timestamp": "2006-01-02T15:04:05Z",
         "action": "push",
         "target": {
            "mediaType": "application/vnd.docker.distribution.manifest.v1+json",
            "length": 1,
            "digest": "sha256:fea8895f450959fa676bcc1df0611ea93823a735a01205fd8622846041d0c7cf",
            "repository": "library/test",
            "url": "http://example.com/v2/library/test/manifests/sha256:c3b3692957d439ac1928219a83fac91e7bf96c153725526874673ae1f2023f8d5"
         },
...

So I'm basically wondering if I can set the registry up to include the tag field somehow in the event message?

Tried to setup a mirror registry and run into the following issues:

• the mirror feature is fantastic but getting it to work takes some doing. Finding https://github.com/docker/distribution/blob/master/docs/mirror.md took a number of hops on the internet, which indicated that a configuration file inside the container should be modified. It would be more desirable to have a run time environment variable to achieve the same effect given the effort involved with modifying a configuration file within a container. In addition, the docker daemon also needs the proxy information, thus it is possible for the daemon to pass such information and eliminating a second copy inside of the registry container.
• the Dockerfile for the registry at https://github.com/docker/distribution-library-image/blob/5cbbc8d1e6046cef5938e3380fd2a5fbd854f921/Dockerfile probably is a good place to expose the configuration files (e.g., comments and volumes) and environment variables but it currently have none.

there is 504 error when curl registry/v2/_catalog?n=1000. and the response time is long,some time up to about 2 minutes

when i create a local docker registry with ceph swift storage ,i find that the contianer is working but i cannot push any images to the registry,and when i check the logs of registry contauner and ceph rgw, i find lots of message like that
2017-08-10 00:04:30.744809 7f0c037fe700 1 ====== starting new request req=0x7f0c037f8710 =====
2017-08-10 00:04:30.748852 7f0c037fe700 1 ====== req done req=0x7f0c037f8710 op status=0 http_status=200 ======
2017-08-10 00:04:30.748922 7f0c037fe700 1 civetweb: 0x7f0bd80008c0: 172.16.3.92 - - [10/Aug/2017:00:04:30 +0800] "GET /swift/v1/docker_registry HTTP/1.1" 200 0 - distribution/v2.6.2
2017-08-10 00:04:30.749833 7f0c037fe700 1 ====== starting new request req=0x7f0c037f8710 =====
2017-08-10 00:04:30.751815 7f0c037fe700 1 ====== req done req=0x7f0c037f8710 op status=0 http_status=404 ======
2017-08-10 00:04:30.751869 7f0c037fe700 1 civetweb: 0x7f0bd80008c0: 172.16.3.92 - - [10/Aug/2017:00:04:30 +0800] "HEAD /swift/v1/docker_registry/files HTTP/1.1" 404 0 - distribution/v2.6.2

and when i check registry container by swiftclient ,i can find the contianer which is used by docker registry
swift -A http://172.16.3.122:7480/auth/v1 -U sccc:swift -K 'uUACqbU7S7BoOWCwwv8TcHugrCbUjlImSYTjSk0y' list
docker_registry

i am a fresher , if anybody can help me , i'll be very appreciation

When registry 2.6.3 is coming out? As I can see 2.6.2 is released 6 months ago. However, there are quite much commits after that in master branch. Could we have new minor version of registry @stevvooe

Docker Info
Containers: 4
Running: 4
Paused: 0
Stopped: 0
Images: 148
Server Version: 18.03.0-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfd04396dc68220d1cecbe686a6cc3aa5ce3667c
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.16.0-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.789GiB
Name: ip-10-227-81-147
ID: SHVB:UU7A:23FQ:KZ7N:2XFH:NW22:OQIR:OP7A:GYTI:HCBP:6BVY:SNOV
Docker Root Dir: /docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
dsg.infra
127.0.0.0/8
Live Restore Enabled: false

Registry config.yml
version: 0.1

storage:
filesystem:
rootdirectory: /registry
delete:
enabled: true

http:
addr: 0.0.0.0:443
tls:
certificate: /certs/my-registry.crt
key: /certs/my-registry.key

auth:
htpasswd:
realm: Registry Realm
path: /auth/htpasswd-file

log:
level: debug

I ran:
docker run --rm --entrypoint htpasswd registry:2.6 -Bbn username pass$word > /var/lib/registry/auth/htpasswd-file

Then started registry like this:
registry:
restart: always
image: registry:2.6
ports:
- 443:443
volumes:
- /var/lib/registry/conf/config.yml:/etc/docker/registry/config.yml
- /var/lib/registry/certs:/certs
- /var/lib/registry/auth:/auth

And when I do:
docker login https://localhost
Username: username
Password:
Error response from daemon: login attempt to https://localhost/v2/ failed with status: 401 Unauthorized

Recreate the htpasswd file with 'username' 'password'
and it works. Tried with 2.7 as well, same behavior

The multi-arch image for docker registry, https://hub.docker.com/_/registry, doesn't have the reference to ppc64le image.

We will like to add the support for ppc64le architecture as well for this image.

Hi all,

I'm trying to delete repo from registry to free up storage space in my system
please take a look at this
Issues with docker registry API and garbage-colle
https://forums.docker.com/t/issues-with-docker-registry-api-and-garbage-collect/77510

Thanks,
Hoang Nguyen

Hi. Maybe it would be good idea to add healthcheck (https://docs.docker.com/engine/reference/builder/#healthcheck)? So that if something happens, container can be automatically restarted?

Maybe something like:

[[ "$(curl -o /dev/null -w '%{http_code}' https://127.0.0.1:5000/v2/)" == 401 ]] && exit 0 || exit 1

(curl would have to be installed in the image)
?

I've tried asking on Docker Forums, but nobody seems to know the answer.

distribution/registry's page on DockerHub says:

WARNING: NOT the registry official image!!! What you LIKELY want is docker pull registry

But I can see that registry simply builds distribution/registry image, takes the binary out of it, then builds it again. What’s the deal?

And now that I look at it, there's also docker-library/official-images repository. Okay, one might guess that the development is done in docker/distribution, but the images are released by docker-library/official-images. But then what is docker/distribution-library-image repository for? Can you elaborate on the process by which docker/distribution becomes a package?

I was modify the Dockerfile the first line in order to support arm64.
Change "From alpine:3.5" to "From aarch64/alpine:3.5" that would support arm64 system. So How to use one Dockerfile to support different syatem than x86 and arm64.

Running the registry container and try to upload an image to it results in a http 500.

Steps to reproduce:
Server 2019 install edge channel docker for windows, upgrade dockerd to nightly and set to experimental.
run: docker run -it -p 5000:5000 -e DEBUG=true --name registry registry:2

Run docker push on an client (dockerd get the server-host as unsecure registry) and get the error.

Docker Info
Client:
Debug Mode: false

Server:
Containers: 22
Running: 0
Paused: 0
Stopped: 22
Images: 24
Server Version: master-dockerproject-2019-03-12
Storage Driver: windowsfilter (windows) lcow (linux)
Windows:
LCOW:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics l2bridge l2tunnel nat null overlay transparent
Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: process
Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
Operating System: Windows Server 2019 Standard Evaluation Version 1809 (OS Build 17763.348)
OSType: windows
Architecture: x86_64
CPUs: 4
Total Memory: 32GiB
Name: SERVERHOST
ID: 3932400c-ee07-44d5-a769-922e15029e4b
Docker Root Dir: C:\ProgramData\Docker
Debug Mode: true
File Descriptors: -1
Goroutines: 26
System Time: 2019-03-13T15:15:51.4471111+01:00
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
SERVERHOST:5000
127.0.0.0/8
Live Restore Enabled: false

Docker Version

Client:
Version: master-dockerproject-2019-03-12
API version: 1.40
Go version: go1.11.5
Git commit: 81ac432c
Built: Tue Mar 12 23:51:56 2019
OS/Arch: windows/amd64
Experimental: false

Server:
Engine:
Version: master-dockerproject-2019-03-12
API version: 1.40 (minimum version 1.24)
Go version: go1.11.5
Git commit: 258edd7
Built: Tue Mar 12 23:59:36 2019
OS/Arch: windows/amd64
Experimental: true

Output

WARN[0000] No HTTP secret provided - generated random secret. This may cause problems with uploads if multiple registries are behind a load-balancer. To provide a shared secret, fill in http.secret in the configuration file or set the REGISTRY_HTTP_SECRET environment variable. go.version=go1.11.2 instance.id=4a203afe-2d78-42cd-8f46-e7094c70b9ea service=registry version=v2.7.1
INFO[0000] redis not configured go.version=go1.11.2 instance.id=4a203afe-2d78-42cd-8f46-e7094c70b9ea service=registry version=v2.7.1
INFO[0000] Starting upload purge in 31m0s go.version=go1.11.2 instance.id=4a203afe-2d78-42cd-8f46-e7094c70b9ea service=registry version=v2.7.1
INFO[0000] using inmemory blob descriptor cache go.version=go1.11.2 instance.id=4a203afe-2d78-42cd-8f46-e7094c70b9ea service=registry version=v2.7.1
INFO[0000] listening on [::]:5000 go.version=go1.11.2 instance.id=4a203afe-2d78-42cd-8f46-e7094c70b9ea service=registry version=v2.7.1
INFO[0022] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=3f7e45a6-53b2-46f0-85f8-198d9052bdc6 http.request.method=GET http.request.remoteaddr="10.0.0.2:49695" http.request.uri="/v2/" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=1.3286ms http.response.status=200 http.response.written=2
10.0.0.2 - - [13/Mar/2019:14:05:51 +0000] "GET /v2/ HTTP/1.1" 200 2 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
ERRO[0023] response completed with error err.code="blob unknown" err.detail=sha256:d2dd05621072711d90e0ca1ae4bac0f201edcf4ed8c120d5e5d35d0de570c736 err.message="blob unknown to registry" go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=f160a3a4-7043-427a-8677-edf7e3f66888 http.request.method=HEAD http.request.remoteaddr="10.0.0.2:49698" http.request.uri="/v2/hello-world/blobs/sha256:d2dd05621072711d90e0ca1ae4bac0f201edcf4ed8c120d5e5d35d0de570c736" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=3.1626ms http.response.status=404 http.response.written=157 vars.digest="sha256:d2dd05621072711d90e0ca1ae4bac0f201edcf4ed8c120d5e5d35d0de570c736" vars.name=hello-world
10.0.0.2 - - [13/Mar/2019:14:05:51 +0000] "HEAD /v2/hello-world/blobs/sha256:d2dd05621072711d90e0ca1ae4bac0f201edcf4ed8c120d5e5d35d0de570c736 HTTP/1.1" 404 157 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
ERRO[0023] response completed with error err.code="blob unknown" err.detail=sha256:bdcb489a87baede63d00535be023ca8ab2e4291d081e2d6cdd037d23cefbae89 err.message="blob unknown to registry" go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=79a4c36a-2e21-4d5b-8ddb-09017f8ac030 http.request.method=HEAD http.request.remoteaddr="10.0.0.2:49699" http.request.uri="/v2/hello-world/blobs/sha256:bdcb489a87baede63d00535be023ca8ab2e4291d081e2d6cdd037d23cefbae89" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=2.1262ms http.response.status=404 http.response.written=157 vars.digest="sha256:bdcb489a87baede63d00535be023ca8ab2e4291d081e2d6cdd037d23cefbae89" vars.name=hello-world
10.0.0.2 - - [13/Mar/2019:14:05:51 +0000] "HEAD /v2/hello-world/blobs/sha256:bdcb489a87baede63d00535be023ca8ab2e4291d081e2d6cdd037d23cefbae89 HTTP/1.1" 404 157 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0023] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=a73d4dd4-d0a0-457f-ad21-9ff4fd722d29 http.request.method=POST http.request.remoteaddr="10.0.0.2:49701" http.request.uri="/v2/hello-world/blobs/uploads/" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.duration=107.7403ms http.response.status=202 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:52 +0000] "POST /v2/hello-world/blobs/uploads/ HTTP/1.1" 202 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0023] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=3b405fd4-4cca-4a8d-9ffa-c08ee3f16399 http.request.method=POST http.request.remoteaddr="10.0.0.2:49700" http.request.uri="/v2/hello-world/blobs/uploads/" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.duration=132.6731ms http.response.status=202 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:51 +0000] "POST /v2/hello-world/blobs/uploads/ HTTP/1.1" 202 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0023] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=c089075f-00e7-42f9-b2b2-61d3e43d0423 http.request.method=PATCH http.request.remoteaddr="10.0.0.2:49704" http.request.uri="/v2/hello-world/blobs/uploads/ebd3d1f1-38b2-4d96-8f29-57b56662a45f?_state=5zXxtglENvUOxEAxHKC5kMZHEUhec7EsthL57wzkEhB7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJlYmQzZDFmMS0zOGIyLTRkOTYtOGYyOS01N2I1NjY2MmE0NWYiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMTktMDMtMTNUMTQ6MDU6NTIuMDAxNTExOFoifQ%3D%3D" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.duration=87.1482ms http.response.status=202 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:52 +0000] "PATCH /v2/hello-world/blobs/uploads/ebd3d1f1-38b2-4d96-8f29-57b56662a45f?_state=5zXxtglENvUOxEAxHKC5kMZHEUhec7EsthL57wzkEhB7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJlYmQzZDFmMS0zOGIyLTRkOTYtOGYyOS01N2I1NjY2MmE0NWYiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMTktMDMtMTNUMTQ6MDU6NTIuMDAxNTExOFoifQ%3D%3D HTTP/1.1" 202 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0023] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=eeb02b58-a0f3-45bf-958e-7a3970628a3a http.request.method=PATCH http.request.remoteaddr="10.0.0.2:49703" http.request.uri="/v2/hello-world/blobs/uploads/bacf1302-cd28-46fd-8ae6-cd9473b0c63c?_state=hS1G5rgcI6OV-VPEZvHw7ZDSpU-1-k1zxRx3f12VGlZ7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJiYWNmMTMwMi1jZDI4LTQ2ZmQtOGFlNi1jZDk0NzNiMGM2M2MiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMTktMDMtMTNUMTQ6MDU6NTIuMDE0MDQ5OFoifQ%3D%3D" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.duration=111.3323ms http.response.status=202 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:52 +0000] "PATCH /v2/hello-world/blobs/uploads/bacf1302-cd28-46fd-8ae6-cd9473b0c63c?_state=hS1G5rgcI6OV-VPEZvHw7ZDSpU-1-k1zxRx3f12VGlZ7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJiYWNmMTMwMi1jZDI4LTQ2ZmQtOGFlNi1jZDk0NzNiMGM2M2MiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMTktMDMtMTNUMTQ6MDU6NTIuMDE0MDQ5OFoifQ%3D%3D HTTP/1.1" 202 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0023] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=96b945e7-97e5-43b3-9344-eccaac4f75f0 http.request.method=PUT http.request.remoteaddr="10.0.0.2:49706" http.request.uri="/v2/hello-world/blobs/uploads/bacf1302-cd28-46fd-8ae6-cd9473b0c63c?_state=3cDeoFSdfi1eXd0_SrNuRJXN8u5uyUY-UG4oQbKImRt7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJiYWNmMTMwMi1jZDI4LTQ2ZmQtOGFlNi1jZDk0NzNiMGM2M2MiLCJPZmZzZXQiOjE2NTUsIlN0YXJ0ZWRBdCI6IjIwMTktMDMtMTNUMTQ6MDU6NTJaIn0%3D&digest=sha256%3Ad2dd05621072711d90e0ca1ae4bac0f201edcf4ed8c120d5e5d35d0de570c736" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.duration=374.032ms http.response.status=201 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:52 +0000] "PUT /v2/hello-world/blobs/uploads/bacf1302-cd28-46fd-8ae6-cd9473b0c63c?_state=3cDeoFSdfi1eXd0_SrNuRJXN8u5uyUY-UG4oQbKImRt7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJiYWNmMTMwMi1jZDI4LTQ2ZmQtOGFlNi1jZDk0NzNiMGM2M2MiLCJPZmZzZXQiOjE2NTUsIlN0YXJ0ZWRBdCI6IjIwMTktMDMtMTNUMTQ6MDU6NTJaIn0%3D&digest=sha256%3Ad2dd05621072711d90e0ca1ae4bac0f201edcf4ed8c120d5e5d35d0de570c736 HTTP/1.1" 201 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0023] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=fe1ef99b-1092-4007-aaa8-e338a3fe6f43 http.request.method=PUT http.request.remoteaddr="10.0.0.2:49705" http.request.uri="/v2/hello-world/blobs/uploads/ebd3d1f1-38b2-4d96-8f29-57b56662a45f?_state=3IRrXvgXWcoYXzap1fhNUBQNIEXeNB7YeBOE2alXzVF7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJlYmQzZDFmMS0zOGIyLTRkOTYtOGYyOS01N2I1NjY2MmE0NWYiLCJPZmZzZXQiOjkyNCwiU3RhcnRlZEF0IjoiMjAxOS0wMy0xM1QxNDowNTo1MloifQ%3D%3D&digest=sha256%3Abdcb489a87baede63d00535be023ca8ab2e4291d081e2d6cdd037d23cefbae89" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.duration=401.0992ms http.response.status=201 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:52 +0000] "PUT /v2/hello-world/blobs/uploads/ebd3d1f1-38b2-4d96-8f29-57b56662a45f?_state=3IRrXvgXWcoYXzap1fhNUBQNIEXeNB7YeBOE2alXzVF7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJlYmQzZDFmMS0zOGIyLTRkOTYtOGYyOS01N2I1NjY2MmE0NWYiLCJPZmZzZXQiOjkyNCwiU3RhcnRlZEF0IjoiMjAxOS0wMy0xM1QxNDowNTo1MloifQ%3D%3D&digest=sha256%3Abdcb489a87baede63d00535be023ca8ab2e4291d081e2d6cdd037d23cefbae89 HTTP/1.1" 201 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0024] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=ca0623eb-b37e-4489-8354-73bfd7b08d72 http.request.method=HEAD http.request.remoteaddr="10.0.0.2:49707" http.request.uri="/v2/hello-world/blobs/sha256:d2dd05621072711d90e0ca1ae4bac0f201edcf4ed8c120d5e5d35d0de570c736" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/octet-stream" http.response.duration=3.6585ms http.response.status=200 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:52 +0000] "HEAD /v2/hello-world/blobs/sha256:d2dd05621072711d90e0ca1ae4bac0f201edcf4ed8c120d5e5d35d0de570c736 HTTP/1.1" 200 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0024] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=3a703d4c-3e97-4137-a86e-733c976db33f http.request.method=HEAD http.request.remoteaddr="10.0.0.2:49708" http.request.uri="/v2/hello-world/blobs/sha256:bdcb489a87baede63d00535be023ca8ab2e4291d081e2d6cdd037d23cefbae89" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/octet-stream" http.response.duration=1.4183ms http.response.status=200 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:52 +0000] "HEAD /v2/hello-world/blobs/sha256:bdcb489a87baede63d00535be023ca8ab2e4291d081e2d6cdd037d23cefbae89 HTTP/1.1" 200 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
ERRO[0024] response completed with error err.code="blob unknown" err.detail=sha256:eb68d2e2f59a9e5ea880ccc5715672ba5238c3f03d0ad596689564c675a986b4 err.message="blob unknown to registry" go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=1da40815-757f-4050-b6b0-6897fb37d475 http.request.method=HEAD http.request.remoteaddr="10.0.0.2:49710" http.request.uri="/v2/hello-world/blobs/sha256:eb68d2e2f59a9e5ea880ccc5715672ba5238c3f03d0ad596689564c675a986b4" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=19.452ms http.response.status=404 http.response.written=157 vars.digest="sha256:eb68d2e2f59a9e5ea880ccc5715672ba5238c3f03d0ad596689564c675a986b4" vars.name=hello-world
10.0.0.2 - - [13/Mar/2019:14:05:52 +0000] "HEAD /v2/hello-world/blobs/sha256:eb68d2e2f59a9e5ea880ccc5715672ba5238c3f03d0ad596689564c675a986b4 HTTP/1.1" 404 157 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0024] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=22be23b5-e929-4fdd-ad52-727a6dafbf71 http.request.method=POST http.request.remoteaddr="10.0.0.2:49711" http.request.uri="/v2/hello-world/blobs/uploads/" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.duration=148.1601ms http.response.status=202 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:52 +0000] "POST /v2/hello-world/blobs/uploads/ HTTP/1.1" 202 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0024] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=4070a50c-a1ac-4f02-bcca-9a0ac6cbfb5a http.request.method=PATCH http.request.remoteaddr="10.0.0.2:49712" http.request.uri="/v2/hello-world/blobs/uploads/c8597299-fa71-4232-8536-f3f87d0d7190?_state=0Y58NYJuW_I_rdlkU19Y0PI5sBbZ8HRO53ShZKeCKTp7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJjODU5NzI5OS1mYTcxLTQyMzItODUzNi1mM2Y4N2QwZDcxOTAiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMTktMDMtMTNUMTQ6MDU6NTIuOTk3MjI4OFoifQ%3D%3D" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.duration=145.3174ms http.response.status=202 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:53 +0000] "PATCH /v2/hello-world/blobs/uploads/c8597299-fa71-4232-8536-f3f87d0d7190?_state=0Y58NYJuW_I_rdlkU19Y0PI5sBbZ8HRO53ShZKeCKTp7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJjODU5NzI5OS1mYTcxLTQyMzItODUzNi1mM2Y4N2QwZDcxOTAiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMTktMDMtMTNUMTQ6MDU6NTIuOTk3MjI4OFoifQ%3D%3D HTTP/1.1" 202 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0025] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=e44e753d-38d3-426c-992d-42e976cfa7f8 http.request.method=PUT http.request.remoteaddr="10.0.0.2:49713" http.request.uri="/v2/hello-world/blobs/uploads/c8597299-fa71-4232-8536-f3f87d0d7190?_state=ymRwlR7joQYkZXGjGZCW64u9nzUqQnLv1GBddvczsFl7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJjODU5NzI5OS1mYTcxLTQyMzItODUzNi1mM2Y4N2QwZDcxOTAiLCJPZmZzZXQiOjE4ODUsIlN0YXJ0ZWRBdCI6IjIwMTktMDMtMTNUMTQ6MDU6NTJaIn0%3D&digest=sha256%3Aeb68d2e2f59a9e5ea880ccc5715672ba5238c3f03d0ad596689564c675a986b4" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.duration=826.3638ms http.response.status=201 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:53 +0000] "PUT /v2/hello-world/blobs/uploads/c8597299-fa71-4232-8536-f3f87d0d7190?_state=ymRwlR7joQYkZXGjGZCW64u9nzUqQnLv1GBddvczsFl7Ik5hbWUiOiJoZWxsby13b3JsZCIsIlVVSUQiOiJjODU5NzI5OS1mYTcxLTQyMzItODUzNi1mM2Y4N2QwZDcxOTAiLCJPZmZzZXQiOjE4ODUsIlN0YXJ0ZWRBdCI6IjIwMTktMDMtMTNUMTQ6MDU6NTJaIn0%3D&digest=sha256%3Aeb68d2e2f59a9e5ea880ccc5715672ba5238c3f03d0ad596689564c675a986b4 HTTP/1.1" 201 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
INFO[0025] response completed go.version=go1.11.2 http.request.host="HOSTNAME:5000" http.request.id=6b6a65e9-7b85-48f2-a014-daa3b162e2f9 http.request.method=HEAD http.request.remoteaddr="10.0.0.2:49715" http.request.uri="/v2/hello-world/blobs/sha256:eb68d2e2f59a9e5ea880ccc5715672ba5238c3f03d0ad596689564c675a986b4" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/octet-stream" http.response.duration=1.7966ms http.response.status=200 http.response.written=0
10.0.0.2 - - [13/Mar/2019:14:05:54 +0000] "HEAD /v2/hello-world/blobs/sha256:eb68d2e2f59a9e5ea880ccc5715672ba5238c3f03d0ad596689564c675a986b4 HTTP/1.1" 200 0 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"
ERRO[0025] response completed with error err.code=unknown err.message="unknown error" go.version=go1.11.2 http.request.contenttype="application/vnd.docker.distribution.manifest.v2+json" http.request.host="HOSTNAME:5000" http.request.id=09c06ff1-dd51-48d0-9545-e7ca6a13a026 http.request.method=PUT http.request.remoteaddr="10.0.0.2:49716" http.request.uri="/v2/hello-world/manifests/latest" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=2.5447ms http.response.status=500 http.response.written=523 vars.name=hello-world vars.reference=latest
ERRO[0025] response completed with error err.code=unknown err.message="invalid URL on layer" go.version=go1.11.2 http.request.contenttype="application/vnd.docker.distribution.manifest.v2+json" http.request.host="HOSTNAME:5000" http.request.id=09c06ff1-dd51-48d0-9545-e7ca6a13a026 http.request.method=PUT http.request.remoteaddr="10.0.0.2:49716" http.request.uri="/v2/hello-world/manifests/latest" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=3.2014ms http.response.status=500 http.response.written=523 vars.name=hello-world vars.reference=latest
ERRO[0025] response completed with error err.code="manifest blob unknown" err.detail=sha256:e46172273a4e4384e1eec7fb01091c828a256ea0f87b30f61381fba9bc511371 err.message="blob unknown to registry" go.version=go1.11.2 http.request.contenttype="application/vnd.docker.distribution.manifest.v2+json" http.request.host="HOSTNAME:5000" http.request.id=09c06ff1-dd51-48d0-9545-e7ca6a13a026 http.request.method=PUT http.request.remoteaddr="10.0.0.2:49716" http.request.uri="/v2/hello-world/manifests/latest" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=3.263ms http.response.status=500 http.response.written=523 vars.name=hello-world vars.reference=latest
ERRO[0025] response completed with error err.code=unknown err.message="unknown error" go.version=go1.11.2 http.request.contenttype="application/vnd.docker.distribution.manifest.v2+json" http.request.host="HOSTNAME:5000" http.request.id=09c06ff1-dd51-48d0-9545-e7ca6a13a026 http.request.method=PUT http.request.remoteaddr="10.0.0.2:49716" http.request.uri="/v2/hello-world/manifests/latest" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=3.314ms http.response.status=500 http.response.written=523 vars.name=hello-world vars.reference=latest
ERRO[0025] response completed with error err.code=unknown err.message="invalid URL on layer" go.version=go1.11.2 http.request.contenttype="application/vnd.docker.distribution.manifest.v2+json" http.request.host="HOSTNAME:5000" http.request.id=09c06ff1-dd51-48d0-9545-e7ca6a13a026 http.request.method=PUT http.request.remoteaddr="10.0.0.2:49716" http.request.uri="/v2/hello-world/manifests/latest" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=3.5069ms http.response.status=500 http.response.written=523 vars.name=hello-world vars.reference=latest
ERRO[0025] response completed with error err.code="manifest blob unknown" err.detail=sha256:f493dc3e1d73855439ead197cc94d3bdac81372c5cb171f12b1f29ba58cdc9d9 err.message="blob unknown to registry" go.version=go1.11.2 http.request.contenttype="application/vnd.docker.distribution.manifest.v2+json" http.request.host="HOSTNAME:5000" http.request.id=09c06ff1-dd51-48d0-9545-e7ca6a13a026 http.request.method=PUT http.request.remoteaddr="10.0.0.2:49716" http.request.uri="/v2/hello-world/manifests/latest" http.request.useragent="docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 (windows))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=3.5566ms http.response.status=500 http.response.written=523 vars.name=hello-world vars.reference=latest
10.0.0.2 - - [13/Mar/2019:14:05:54 +0000] "PUT /v2/hello-world/manifests/latest HTTP/1.1" 500 523 "" "docker/18.09.2 go/go1.10.6 git-commit/6247962 os/windows arch/amd64 UpstreamClient(Docker-Client/18.09.2 \(windows\))"