I would like to pull container images from private hubs but currently there is no way to do that.
Thanks @rmb938. Do you mean private hub repositories or private registries?
Private registries would be great. Should rename issue or maybe this isn't what @rmb938 meant?
@jeffdm Initially just private registries but both would be nice
+1
For the record, what's the issue with private registries? Is there a work-around to enable? I tried just opening a cli (by clicking the whale) and doing a docker login. But it errors out.
docker login -e
-u -p my-docker-registry-url
FATA[0042] An error occurred trying to connect: Post https://192.168.59.103:2376/v1.17/auth: dial tcp 192.168.59.103:2376: i/o timeout
+1
Maybe this can shed some light on the error you're seeing, @dskyberg http://stackoverflow.com/questions/26710153/remote-access-to-a-private-docker-registry
:+1:
Focusing this issue on private registries, for private DockerHub repos, please see #232
+1 for private registries
+1
+1
+1
+1
+1
+1
+1
+1 for private registries. This is necessary for my organization.
+1 This would be a huge benefit to our organisation
Is there a workaround for pulling images from private registries ?
+1
:+1:
+1
This is the only reason I can't really use kitematic in my organization.
+1 on this. We'd love to use kitematic, but definitely not without private registry support.
+1 would love to be able to have my company use kitematic with our private registry.
+1
+1
:+1:
+1
+1
+1
+1
+1
+1
Probably should be merged with: https://github.com/kitematic/kitematic/issues/232
@FrenchBen this issue has lower number #232 then duplicate?
@KostyaSha Yup and why I commented on here- #232 should be merged here is what I meant to say :+1:
+1
For those calling to merge #232 into this issue, note that the owner of this issue specifically created #232 to separate out the two related concerns.
@dannc not sure if I follow.
How are these not related?
I believe the breakdown is like this:
I'm guessing other hosted registries (hubs) such as Quay.io and Google Container Registry would also be covered under #210 as well.
These are certainly related issues but not the same issue. I believe one could solve either of these issues separately without solving the other.
@dannc I believe the latest Kitematic currently works the private user/org repos. Should this issue be closed then?
@FrenchBen this issue is about repos hosted on private hub, not private repos hosted on docker hub. We still can't use a private hub.
@stefanhong do you have a private hub I can look at?
@FrenchBen just install https://hub.docker.com/_/registry/ on your own server
@dannc @stefanhong There is a misunderstanding here.
Hub is a CMS - Content Management System that provides auth, search, etc.
Registry is a CDS - Content Distribution System that allows you to push/pull your images (like a CDN)
Unless you know what your resource is, very much like a CDN, you can't get that resource.
For example for you to get an image from CDN you need to know the exact image name, otherwise you get nothing.
Registry is the same thing, you need to know the exact name of the image before you can pull it.
I guess I'm quite confused. This issue started out with a request that seemed a bit vague. Through a few questions @jeffdm clarified a bit more and changed the title to Ability to add private registries and private hub repos. After some time, he then further refined the title to be Ability to add private registries and his subsequent comment in this issue read:
Focusing this issue on **private registries**, for private DockerHub repos, please see #232
In #232 you created a PR ( #1076) to be able to set and use a "private Repo URL" and then subsequently closed it for not being applicable at the moment.
In the screenshot included of how the setting would look, you have a new field for "Docker Registry URL" which defaults to https://hub.docker.com/v2 (which I believe is the base URL on DockerHub from which you can search for repositories).
What I think #232 was meant to address was something different. Say I created a private repo on DockerHub for an image that I didn't want to share. Being able to access that repo would at least require that a user of KiteMatic would be able to login so that login credentials could be matched up with the permissions of the private repo there. There's probably more that needs to be done to enable access to private repos on DockerHub but I can't really speak to that as I'm not familiar enough with the code.
The concern in this issue request is now left being that I want to access my images/repositories hosted in my local registry (not hub.docker.com). Looking at your PR, it seems right on target as a potential fix for this issue! In it, I could specify 'https://localhost/v2" and I believe I would be able to search for images in my locally hosted registry and create containers with them.
That's what I think most people are asking for in the current definition of this issue. I'm sure they'd also like to be able to search for and create containers for privately repositories hosted within DockerHub, but that's what I think #232 was created to address.
@dannc is correct. Most of us host our own Registry, and want to be able to access images on that Registry. It does not have to do with accessing private images/repos on Docker Hub.
@dannc The PR you mentioned was closed as it was created without much knowledge of the CMS/CDS mentioned above. I had the exact same idea as you did regarding pointing Kitematic to the https://localhost/v2 url when the PR was created. The issues mentioned in the comparison of CMS/CDS is what makes it very difficult and makes the PR unusable.
@jbw91 @dannc maybe what would help is the current usage of your local registry? How do you 'view' images stored? Do you just 'know' what to pull?
Registry being a simple CDS, has no Auth, no Search, no list of User images. This is the 'magic' that a CMS (Hub) adds.
@FrenchBen, Docker Trusted Registry adds the same functionality as Docker Hub with users, search, etc. The old Registry didn't have all that, this is true.
@FrenchBen Now I understand the discussion about CMS/CDS better. Thanks for that.
Mostly just 'know' what to pull. I hadn't realized that search wasn't implemented in the private registry. That's unfortunate.
I have been able to list tags for a specific image:
curl -k -X GET https://localhost:5000/v2/<repo_name>/tags/list
That doesn't give you image/repository list capabilities like you'd have on docker hub but at least it would give a way for someone to search for a specific image and create a container from it using KM.
@jbw91 Now you're talking about a different product - Docker Trusted Registry vs Private Registry (discussed in this thread)
@dannc that's exactly it, glad the discussion made more sense. :)
The tags list would only show the tags for a specific image, you'd have to specify the exact image name first or get an image not found if you made a typo!
@FrenchBen In my case we know exactly what images we have on PR, and the tags we need. While being also to search from a CMS is nice, we will be very happy just being able to add images manually so we don't have to type commands all the time.
@stefanhong How do you envision Kitematic knowing about this list of available images, so they could be displayed on the Create/New page?
@FrenchBen Maybe an "Add" button under "My Repos" section to add a specific image url manually?
For knowing about the list of available images that can be displayed on the create/new page, I'd be OK with having to search for the exact image name and having an empty list if they don't specify the image name correctly.
Not ideal really but better than nothing I would think. Of course checking the specified private registry to see if it responds to e.g. /v2/_catalog (Docker Trusted Registry or some third-party registry such as Quay.io or such) would be helpful.
Our organization is actually using an Artifactory version which also serves as a docker private registry (as well as has authentication/etc). The current version doesn't have search capabilities but it doesn't mean that they wouldn't offer it in a future release...
Sorry if I am missing something, but it looks like the v2 api for the docker registry does support listing available images. https://docs.docker.com/registry/spec/api/#listing-repositories
Even just listing the local repository with something like 'docker images' would be an improvement.
@lhorne That's correct it lists the images, but you cannot search them. As an application we cannot add half-working features, as it would break the current flow.
Additionally you would also be missing the authentication part of it.
+1
+1 for Kitematic to support private registries
+1
+1 for Kitematic to support private registries.
+1
Please use the 馃憤 feature of Github - Having these +1 added all over the place does not help - Locking the conversation until a proper proposal has been drafted.
similar issue in Dockerfile. See issue #1733
+1
This issue has been open for over a year and is basically preventing enterprise from adopting kitematic as most of their registries are on premise. @FrenchBen and you will not add a "half-baked" feature? Why aren't you baking it? You would think enterprise are Docker's most important customers.
@clatko Would you accept, at the enterprise level, a half-bake product where things work only 1/2 way?
As mentioned a few comments above (https://github.com/docker/kitematic/issues/210#issuecomment-156210361 & https://github.com/docker/kitematic/issues/210#issuecomment-156252142) the issue is not with the registry but handling all of the components that go with it, such as authentication.
See:
https://docs.docker.com/registry/spec/auth/token/
ps: The best way to see it implemented is to do it yourself. Please open a PR with what you believe is the bare minimum. I'll be happy to review it and merge it if appropriate.
since i'm not trying to sell it, yes, i would take a half baked solution. i forked the repo and am trying to get authentication working. i'll probably not have the time to see this through.
Any help is appreciated @clatko - thanks for taking a shot at it :)
+1
+1
+1
+1
+1
+1
+1
+1 for private registry access
any news about this long-awaited feature ?
+1
I am in need of this feature as well. We would like to adopt this technology but need the ability to use Kitematic to access the private regitry
+1
+1
+1
+1
We spun up https://docs.docker.com/registry/, added username/password authentication (tied into an internal authentication database, which is why we cannot use DockerHub.com), but then could not work out how to make Kitematic work with it. Unfortunate.
@alankent the user/pass auth you specify are tied to a certain internal auth endpoint that may be different for each.
If you want to write up exactly what it should expect and how you're making it work and that users are happy to have that EXACT same internal auth db, I'm happy to provide the changes needed for it to work.
The biggest issue is that no-one can agree on that internal auth db thus making it very difficult for Kitematic to be flexible enough to auth against it.
Kitematic should be able to authenticate, search and pull from Docker Trusted Registry. Will it ever be possible?
+1
+1
+1
+1
+1 Any update progress with this?
+1 Absolutely :-), any alternatives available yet ? Sounds like a serious 'need' for the users
+1
+1
+2
+1
+1 Any updates on this?
+1
+1
+1
See issue #3175 for further issue (even if you manually pull from private registry, can't start container)
+1
+1
+1
There is a reason why Github added Emoji reactions. Please don't spam +1 and trigger useless notifications for watchers.
+1
+1
Second most liked feature request ever and just 4 likes below the top one (which currently has 111 likes)
+1
Need pull from private registries.
We need this feature!
+1
How is this coming along?..
4 years. Really?
+1
Any updates guys?
If you look at the repo, you will notice that this is not being developed any longer. In the last two years all changes were bumping dependencies versions and nothing else. Which means that most likely there are no updates.
Most helpful comment
There is a reason why Github added Emoji reactions. Please don't spam +1 and trigger useless notifications for watchers.