Docker Community Forums

Share and learn in the Docker community.

Air gapped docker registry implementation - unable to see items that push to registry server

  • Issue type - Docker Image Registry Server

  • OS Version/build
    Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)

  • App version
    Operating System: Windows Server 2019 Datacenter Version 1809 (OS Build 17763.1039)

  • Steps to reproduce

On my development box, I am running Docker Enterprise for Windows and run the following commands:

docker tag 2eecb68a612f XXX.XXX.XXX.XXX:5000/uidemo/httpd:version1.0
docker push XXX.XXX.XXX.XXX:5000/uidemo/httpd:version1.0

These commands work, but I don’t see the new tagged image appear on my internal registry server when I run a docker image ls. Why don’t I see on the local registry server after I get a successful push? I see the images listed still in my local development box in its repository, but I need it to appear on the Docker Registry server as well.

Thoughts?

“docker image ls” is to list images of the docker engines image cache. Images you push to your private registry won’t be listed in the engine’s image cache… unless you pull the image beforehands.

If you are using Docker EE, are you using DTR? Its UI will list the details.

When I do the docker image ls, I’m only seeing that locally on my development server where I’m doing the docker tag and push and not on registry server. I’m not using DTR.

Explain to me the statement on cache and how the pull is related. I am expecting (maybe falsely) that when I push from the development server to the registry and it completes, I should be able to do the “docker image ls” on the registry server and it would appear for me. Is that not the case? Am I missing a step here?

Since you use the term “registry” without providing details which product is used or how it’s operated, I assume it is a container, created from the official registry2 image from dockerhub.

Now the question is, why would you expect a docker-engine to be aware of what is run inside a container, just because it happens to be a image registry? For the docker engine it is not any different than other containers.

May I suggest to move to a registry that actualy provides a ui, like harbor, JFrog Container Registry or the build in registries in Nexus3 or Gitlab…

Metin - Thanks for the feedback, I appreciate the response and will try to share what I can. I’m working in a location where I can’t share a ton of detail, but I’ll share what I can.

How I have this set up right now is the following:

Development Server
Windows Server 2019 Datacenter Version 1809 (OS Build 17763.1039)
Docker Enterprise Edition 19.03.5

Docker Registry Server
Windows Server 2019 Datacenter Version 1809 (OS Build 17763.1039)
Docker Enterprise Edition 19.03.5

That’s all I have…I have the registry service running as you describe via the official registry2 image from dockerhub.

From different pages and documentation I’ve read on Docker, it was my understanding that I should be able to at least run my “docker build” on my development server and do the tagging and push of that new image to the docker registry server. After the image is pushed, I thought I would see it listed as an available image.

I can look into harbor or other tools, but I thought at least minimally, I would be able to do the docker push of the image from the development to the registry server and see it there.

My goal is host my own internal registry server (again based on the work we do here) and want to do the push from our development machines to our own internal registry server.

Constructive feedback appreciated.

Thanks for sharing more details.

This should work right now. Try to pull the image from a different machine in your network and you will see that it works.

I aim afraid you expect to see the available images listed in the wrong place. If you realy want to see your images listed, the place to look is the rest-api of the registry2 service (running in a container). You will need to learn the api to make use of it.

I suggested other self hosted registrys, because they provide a UI that allows browsing available image repos and tags. Most of them provide authentification and authorization allong with vuln scans for the pushed images.

Does that make sense?

Thank you! That is extremely helpful. I know the pull into registry server works and will try it again.

For the registry2 API service, any recommendations / documentation to help get started with that?

Regarding your thoughts on the other UI tools, at this point I’m trying not to add yet one more tool into our environment for our team to use/manage. If you feel they provide the benefit I’ll look at these others and see. Are there additional software costs for these?

If I can go back to DTR - is that something like Docker Hub that would be outside the scope and extent of my network or is this something that can be layered on my existing internal Docker environment today? I’m reading through the documentation as I post this. Your thoughts on DTR and its abilities to work in an air gapped like environment?

Registry api: https://docs.docker.com/registry/spec/api/
Hint: The Registry-Api and DTR-Api are not identical. If you find snippets, make sure they match the product.

A Docker Enterprise subscription commes with DTR (Docker Trusted Registry).

On Linux, a Docker Enterprise environment typically consists of the ee-engine, UCP and DTR.
DTR will require a UCP installation as well. For both offline installer packages are available.

I have no idea how the subscription process works for Docker-EE on Windows.

All the regstries I listed are open source and optionaly provide subscriptions for vendor support.

This has been most helpful - I appreciate your help in responding to my initial question.