OK, thanks, that gives me something to experiment with. Alan.
> On 9 Apr 2018, at 23:00, Graham Dumpleton <[email protected]> wrote: > > You are possibly hitting a bug with oc where it was generating the > dockerconfig json in wrong format in 3.7. > > If you used 3.6 oc client with 3.7 backend just when creating the secret it > will work, if this is the issue I am thinking of. > > If want confirmation, perhaps try with a 3.6 client. > > Graham > >> On 10 Apr 2018, at 7:45 am, Alan Christie <[email protected] >> <mailto:[email protected]>> wrote: >> >> Ah ha! >> >> OK, the first approach did not work but your second suggestion worked!! >> Phew, thanks … although I had to remove the “-w0" argument (they’re not >> recognised on OSX). So the following allowed me to pull from gitlab: - >> >> oc create -f - <<EOF >> apiVersion: v1 >> kind: Secret >> metadata: >> name: pullsecret >> type: kubernetes.io/dockerconfigjson <http://kubernetes.io/dockerconfigjson> >> data: >> .dockerconfigjson: $(echo -n "{\"auths\":{\"registry.gitlab.com >> <http://registry.gitlab.com/>\":{\"auth\":\"`echo -n >> "$GITLAB_USER:$GITLAB_PASSWORD" | base64`\"}}}"|base64) >> EOF >> >> Thank you. >> >> I am still intrigued to know why my previous secret (which works with 3.6) >> does not work and in 3.7 I have to resort to this new approach. >> >> Alan. >> >>> On 9 Apr 2018, at 21:29, Pavel Gashev <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Alan, >>> >>> Just try the following: >>> >>> # docker login registry.gitlab.com <http://registry.gitlab.com/> >>> # oc create secret generic >>> --from-file=.dockerconfigjson=.docker/config.json >>> --type=kubernetes.io/dockerconfigjson >>> <http://kubernetes.io/dockerconfigjson> pullsecret >>> >>> another way: >>> >>> # GITLAB_USER=user >>> # GITLAB_PASSWORD=password >>> # oc create -f - <<EOF >>> apiVersion: v1 >>> kind: Secret >>> metadata: >>> name: pullsecret >>> type: kubernetes.io/dockerconfigjson <http://kubernetes.io/dockerconfigjson> >>> data: >>> .dockerconfigjson: $(echo -n "{\"auths\":{\"registry.gitlab.com >>> <http://registry.gitlab.com/>\":{\"auth\":\"`echo -n >>> "$GITLAB_USER:$GITLAB_PASSWORD" | base64 -w0`\"}}}"|base64 -w0) >>> EOF >>> >>> From: <[email protected] >>> <mailto:[email protected]>> on behalf of Alan >>> Christie <[email protected] >>> <mailto:[email protected]>> >>> Date: Monday, 9 April 2018 at 01:57 >>> To: Gaurav P <[email protected] <mailto:[email protected]>> >>> Cc: users <[email protected] >>> <mailto:[email protected]>> >>> Subject: Re: Help using ImageStreams, DCs and ImagePullSecrets templates >>> with a GitLab private registry (v3.6) >>> >>> Sorry Guys, but I’m getting nowhere here. >>> >>> A long time has passed and I have been doing other things but keep >>> returning to this and trying every single combination of URL that I can but >>> nothing is working for me with GitLab. >>> >>> The good news is that I have simplified the problem… >>> >>> My simple setup, which is perfectly able to pull images from GitLab in >>> v3.6, uses just one secret and does not need the “oc secrets link […]” >>> command. This simple setup does not work with OpenShift v3.7. Instead I get >>> image pull errors (shown in attached screenshot). Is there anyone who’s >>> pulled an image from GitLab? And can someone explain why my single secret >>> setup works in 3.6 but does not in 3.7? >>> >>> Alan. >>> >>> <image001.png> >>> >>> >>> On 19 Jan 2018, at 15:56, Gaurav P <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Louis, >>> >>> In our case, it is Artifactory. Relevant headers: >>> >>> HTTP/1.1 401 Unauthorized >>> Server: Artifactory/5.4.5 >>> X-Artifactory-Id: xxxx >>> X-Artifactory-Node-Id: xxxx >>> WWW-Authenticate: Basic realm="Artifactory Realm" >>> >>> Note however that in the case of Artifactory, Docker registries have to be >>> fronted by haproxy, so the Basic auth might be coming from there... >>> >>> - Gaurav >>> >>> On Fri, Jan 19, 2018 at 3:03 AM, Louis Santillan <[email protected] >>> <mailto:[email protected]>> wrote: >>> Gaurav, Alan, >>> >>> What is the full (redact if necessary for artifactory) output of `curl -kv >>> https://<registry address>/v2/<namespace>/<image>`? >>> >>> I get the following headers when I naively hit >>> `https://registry.gitlab.com/v2/myproject/myimage/manifests/latest` >>> <https://registry.gitlab.com/v2/myproject/myimage/manifests/latest> >>> >>> 1. >>> Content-Length: >>> >>> >>> 160 >>> >>> >>> 2. >>> Content-Type: >>> >>> >>> application/json; charset=utf-8 >>> >>> >>> 3. >>> Date: >>> >>> >>> Fri, 19 Jan 2018 07:58:26 GMT >>> >>> >>> 4. >>> Docker-Distribution-Api-Version: >>> >>> >>> registry/2.0 >>> >>> >>> 5. >>> Www-Authenticate: >>> >>> >>> Bearer realm="https://gitlab.com/jwt/auth >>> <https://gitlab.com/jwt/auth>",service="container_registry",scope="repository:myproject/myimage:pull" >>> >>> >>> 6. >>> X-Content-Type-Options: >>> >>> >>> nosniff >>> >>> Looks like `https://gitlab.com/jwt/auth` <https://gitlab.com/jwt/auth> is >>> the auth URL Maciej is speaking of. >>> >>> The docs also mention having to `link` the secret to the namespace's >>> `:default` service account for pod image pulling [0]. There's a step or >>> two extra there that Maciej had not yet mentioned. >>> >>> [0] >>> https://docs.openshift.com/container-platform/3.7/dev_guide/managing_images.html#allowing-pods-to-reference-images-from-other-secured-registries >>> >>> <https://docs.openshift.com/container-platform/3.7/dev_guide/managing_images.html#allowing-pods-to-reference-images-from-other-secured-registries> >>> >>> ___________________________________________________ >>> LOUIS P. SANTILLAN >>> ARCHITECT, OPENSHIFT, MIDDLEWARE & DEVOPS >>> Red Hat Consulting, <https://www.redhat.com/> Container and PaaS Practice >>> [email protected] <mailto:[email protected]> M: 3236334854 >>> <tel:3236334854> >>> Error! Filename not specified. <https://red.ht/sig> >>> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> >>> >>> >>> >>> On Thu, Jan 18, 2018 at 2:01 PM, Gaurav P <[email protected] >>> <mailto:[email protected]>> wrote: >>> Maciej, >>> >>> I have a similar problem, however with a private authenticated Artifactory >>> registry fronted by haproxy. >>> >>> Tried the curl you suggested, but the WWW-Authenticate header in the >>> response only contains 'Basic realm="Artifactory Realm"'. >>> >>> Struggling to find what that 2nd url should be. >>> >>> - Gaurav >>> >>> On Mon, Jan 8, 2018 at 6:20 AM, Maciej Szulik <[email protected] >>> <mailto:[email protected]>> wrote: >>> In short, there are two possible use-cases here. >>> >>> The first, in which the authorization is performed under the same URL as >>> the pull: >>> >>> 1. IS stays the same, no need to modify anything. >>> 2. Create a secret, eg: >>> oc secrets new-dockercfg <secret_name> \ >>> --docker-server=<server> \ >>> --docker-username=<username> \ >>> --docker-password=<password> \ >>> --docker-email=<email> >>> >>> 3. Re-run the import: >>> oc import-image <IS name> >>> >>> >>> The second, in which authorization is delegated to a different URL: >>> 1. IS stays the same, no need to modify anything. >>> 2. Create a secret as previously. >>> 3. Create a 2nd secret again the authorization url. You can get it by >>> trying to curl the image >>> data, eg. curl -v https://<registry address>/v2/<namespace>/<image> in >>> return you should >>> see the HTTP/1.1 401 Unauthorized with information where to >>> authenticate, eg: >>> WWW-Authenticate: Bearer realm="<auth URL>",service="docker-registry" >>> use that auth URL for docker-server when creating the second secret. >>> 4. Re-run import. >>> >>> Hope that helps, >>> Maciej >>> >>> >>> >>> >>> >>> On Thu, Jan 4, 2018 at 2:53 PM, Alan Christie >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>> Thanks for your guidance so far Maciej but none of this is working for me. >>> [1] doesn’t really help as I’m past that and, sadly the 1,500 lines and >>> numerous of posts in issue 9584 [2] are exhausting to trawl though and >>> still leave me with an inability to pull from GitLab using an image stream. >>> >>> Again, I have a working DC/IPS solution. I understand secrets, DCs and IPS >>> but I still cannot get ImageStreams to work. I just get… >>> >>> Internal error occurred: Get https://registry.gitlab.com/v2/myproject/ >>> <https://registry.gitlab.com/v2/myproject/>myimage.manifests/latest: >>> denied: access forbidden. >>> >>> I’m just about exhausted. >>> >>> So, if my setup is: >>> OpenShift 3.6.1 >>> An image that's: myproject/myimage:latest >>> A registry that’s: registry.gitlab.com <http://registry.gitlab.com/> >>> A pull secret that works for DC/IPS - i.e. I can pull the image from the >>> private repo with my DC and the installed secret. >>> What... >>> would my ImageStream yaml template or json look like? >>> would I need to change in my working DC yaml? >>> if any, are the crucial roles my OC user needs? >>> >>> On 3 Jan 2018, at 11:03, Maciej Szulik <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Have a look at [1] which should explain how to connect the IS with the >>> secret. Additionally, >>> there's [2] which explains problems when auth is delegated to a different >>> uri. >>> >>> Maciej >>> >>> >>> [1] >>> https://docs.openshift.org/latest/dev_guide/managing_images.html#private-registries >>> >>> <https://docs.openshift.org/latest/dev_guide/managing_images.html#private-registries> >>> [2] https://github.com/openshift/origin/issues/9584 >>> <https://github.com/openshift/origin/issues/9584> >>> >>> On Wed, Jan 3, 2018 at 10:34 AM, Alan Christie >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>> Hi all, >>> >>> I’m successfully using a DeploymentConfig (DC) and an ImagePullSecret (IPS) >>> templates with OpenShift Origin v3.6 to spin-up my application from a >>> container image hosted on a private GitLab registry. But I want the >>> deployment to re-deploy when the GitLab image changes and to do this I >>> believe I need to employ an ImageStream. >>> >>> I’m, comfortable with each of these objects and have successfully used >>> ImageStreams and DCs with public DockerHub images (that was easy because >>> there are so many examples). But I’m stuck trying to pull an image using an >>> ImageStream from a private GitLab-hosted docker registry. >>> >>> The IPS seems to belong to the DC, so how do I get my ImageStream to use >>> it? My initial attempts have not been successful. All I get, after a number >>> of attempts at this, is the following error on the ImageScreen console... >>> >>> Internal error occurred: Get >>> https://registry.gitlab.com/v2/myproject/myimage/manifests/latest >>> <https://registry.gitlab.com/v2/myproject/myimage/manifests/latest>: >>> denied: access forbidden. Timestamp: 2017-12-28T14:27:12Z Error count: 2. >>> >>> Where “myproject” and “myimage” are my GitLab project and image names. >>> >>> My working DC/IPS combo looks something like this… >>> >>> […] >>> imagePullSecrets: >>> - name: gitlab-myproject >>> containers: >>> - image: registry.gitlab.com/myproject/myimage:stable >>> <http://registry.gitlab.com/myproject/myimage:stable> >>> name: myimage >>> […] >>> >>> But what would my DC/IPS/ImageStream objects look like? >>> >>> Thanks in advance. >>> >>> Alan Christie. >>> >>> >>> _______________________________________________ >>> users mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>> <http://lists.openshift.redhat.com/openshiftmm/listinfo/users> >>> >>> >>> >>> >>> _______________________________________________ >>> users mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>> <http://lists.openshift.redhat.com/openshiftmm/listinfo/users> >>> >>> >>> _______________________________________________ >>> users mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>> <http://lists.openshift.redhat.com/openshiftmm/listinfo/users> >>> >>> >>> >> >> _______________________________________________ >> users mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
