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
data:
.dockerconfigjson: $(echo -n
"{\"auths\":{\"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]> 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]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
