cannot deploy docker image form AWS private registry - docker

I am trying to push an app from a docker image hosted in the AWS Elastic Container Registry and am getting 500 error codes from the cloudfoundry API when trying to push. Am i doing something wrong or is there just an issue with the API currently? Any help is appreciated.
push command used (replaced real route, app and image name):
cf push dockerized-app --docker-image 300401118676.dkr.ecr.eu-central-1.amazonaws.com/my/image:latest --docker-username AWS --hostname my-dockerized-app -i 1 -m 1024M -k 1024M
cf-cli version:
cf version 6.34.1+bbdf81482.2018-01-17
This ist the standard log output i get:
Using docker repository password from environment variable CF_DOCKER_PASSWORD.
Pushing app dockerized-app to org ORG / space SPACE as someone#somewhere.ch...
Getting app info...
Creating app with these attributes...
+ name: dockerized-app
+ docker image: 300401118676.dkr.ecr.eu-central-1.amazonaws.com/my/image:latest
+ docker username: AWS
+ disk quota: 1G
+ instances: 1
+ memory: 1G
routes:
+ my-dockerized-app.scapp.io
Creating app dockerized-app...
Unexpected Response
Response code: 500
CC code: 0
CC error code:
Request ID: f0789965-19b1-4178-5cce-e42ff671a99b::6eb55c40-70de-4011-ad30-ee60aab54d82
Description: {
"error_code": "UnknownError",
"description": "An unknown error occurred.",
"code": 10001
}
FAILED
Here is the relevant log output with the -v flag set
Creating app with these attributes...
+ name: dockerized-app
+ docker image: 300401118676.dkr.ecr.eu-central-1.amazonaws.com/my/image:latest
+ docker username: AWS
+ disk quota: 1G
+ instances: 1
+ memory: 1G
routes:
+ my-dockerized-app.scapp.io
Creating app dockerized-app...
REQUEST: [2018-02-27T18:39:28+01:00]
POST /v2/apps HTTP/1.1
Host: api.lyra-836.appcloud.swisscom.com
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: cf/6.34.1+bbdf81482.2018-01-17 (go1.9.2; amd64 darwin)
{
"disk_quota": 1024,
"docker_credentials": {
"password": "[PRIVATE DATA HIDDEN]",
"username": "AWS"
},
"docker_image": "300401118676.dkr.ecr.eu-central-1.amazonaws.com/my/image:latest",
"instances": 1,
"memory": 1024,
"name": "dockerized-app",
"space_guid": "07cead83-7db5-477e-83ca-f7bbee10e557"
}
RESPONSE: [2018-02-27T18:39:28+01:00]
HTTP/1.1 500 Internal Server Error
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Length: 99
Content-Type: application/json;charset=utf-8
Date: Tue, 27 Feb 2018 17:39:28 GMT
Expires: 0
Pragma: no-cache
Server: nginx
Strict-Transport-Security: max-age=16070400; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Vcap-Request-Id: 6c6acb3a-4ead-4f88-5d2c-e7d7f846b2af::0e919224-e372-46f1-8d70-19bf30f85145
X-Xss-Protection: 1; mode=block
{
"code": 10001,
"description": "An unknown error occurred.",
"error_code": "UnknownError"
}
Unexpected Response
Response code: 500
CC code: 0
CC error code:
Request ID: 6c6acb3a-4ead-4f88-5d2c-e7d7f846b2af::0e919224-e372-46f1-8d70-19bf30f85145
Description: {
"error_code": "UnknownError",
"description": "An unknown error occurred.",
"code": 10001
}
Seems to me like the docker registry username and password get picked up just fine (and yes they work).

From an operator perspective, it looks like you're hitting CloudFoundry's password limit of 1000 characters by using the Amazon Elastic Container Registry signed tokens (which are around 2000 chars):
/var/vcap/sys/log/cloud_controller_ng/cloud_controller_ng.log.5.gz:
{"timestamp":1526311559.8367982,"message":"Request failed: 500:
{\"error_code\"=>\"UnknownError\", \"description\"=>\"An unknown
error occurred.\", \"code\"=>10001, \"test_mode_info\"=>
{\"description\"=>\"docker_password can be up to 1,000 characters\",
...
We filed the issue with the CC team: https://github.com/cloudfoundry/cloud_controller_ng/issues/1141

I'm not sure what version of Cloud Foundry your provider is running right now, but support for private docker registries (i.e. registries using HTTPS & basic auth) requires a fairly recent version of Cloud Foundry.
It definitely works in API versions 2.103 and later, as that's what we're running at Meshcloud right now and we have customer successfully using private registries ;-)
$ cf api
api endpoint: https://api.cf.eu-de-netde.msh.host
api version: 2.103.0
Disclaimer: I'm a co-founder at Meshcloud.

Related

docker registry: https instead of http

I've just deployed a docker registry.
I'm able to get access to it using:
$ curl -I chart-example.local/v2/
HTTP/1.1 200 OK
Content-Length: 2
Content-Type: application/json; charset=utf-8
Date: Tue, 28 Jan 2020 20:10:35 GMT
Docker-Distribution-Api-Version: registry/2.0
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
However, when I'm trying to push an local image to it, I'm getting this message:
$ docker push chart-example.local/feedly:latest
The push refers to repository [chart-example.local/feedly]
Get https://chart-example.local/v2/: x509: certificate has expired or is not yet valid
Why docker is trying to get access using https instead of http?
Docker uses https by default for security. You can override this setting by modifying your daemon.json file with the following content. Do not use this setting in production.
{
"insecure-registries" : ["chart-example.local"]
}
See this link for more information: https://docs.docker.com/registry/insecure/

Artifactory Docker Login to Repository Localhost

I have a local Jfrog Artifactory Pro.
I use "http://localhost:8081/artifactory/webapp/#/home" to go to my Artifactory.
I created local Docker registry:
I configured a direct reverse proxy, from Rest API:
$ curl -u admin:xxxxxx-i "http://127.0.0.1:8081/artifactory/api/system/configuration/webServer"
HTTP/1.1 200 OK
Server: Artifactory/6.2.0
X-Artifactory-Id: de89ec654198c960:3f9aa2d0:167a7c20d5e:-8000
Access-Control-Allow-Methods: GET, POST, DELETE, PUT
Access-Control-Allow-Headers: X-Requested-With, Content-Type, X-Codingpedia
Cache-Control: no-store
Content-Type: application/json
Transfer-Encoding: chunked
Date: Sun, 16 Dec 2018 13:04:52 GMT
{
"key" : "direct",
"webServerType" : "DIRECT",
"artifactoryAppContext" : "artifactory",
"publicAppContext" : "artifactory",
"serverName" : "127.0.0.1",
"serverNameExpression" : "*.localhost",
"artifactoryServerName" : "localhost",
"artifactoryPort" : 8081,
"dockerReverseProxyMethod" : "SUBDOMAIN",
"useHttps" : false,
"useHttp" : true,
"httpsPort" : 443,
"httpPort" : 8081,
"upStreamName" : "artifactory"
}
Configuration from artifactory:
I want to login to my registry "mylocaldocker" via docker client but I get an error:
$ docker login mylocaldocker.localhost -u admin -p xxxxxx
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get https://mylocaldocker.localhost/v2/: dial tcp: lookup mylocaldocker.localhost on 192.168.65.1:53: no such host
How can I log in to artifactory docker registry? and pull/push images to it!?
First: docker login related to Artifactory -> Configurations -> HTTP Settings I used "Docker access method" as "Repository path"
docker login -u admin -p **** x.x.x.x:8081
Second:
Due to a limitation in docker, we cannot use login to localhost.
we should replace "localhost" or "127.0.0.1" by real machine IP (private IP).
And add private_ip:8081 (x.x.x.x:8081) to insecure registries in docker.
See the answer in this link: Pull Artifactory Docker Images

Why does pushing to private, secured docker registry fail?

I would like to run a private, secure, authenticated docker registry on a self healing AWS ECS cluster. The cluster setup is done and works properly, but I struggled getting the registry:latest running. The problem was, that every time I push an image, pushing the blobs fails, and goes into a retry cycle unless I get a timeout.
To make sure, that my ECS setup isn’t the blocker, I tried to setup everything locally using Docker4Mac 1.12.0-a.
First, the very basic setup works. I created my own version of the registry image, where there I put my TLS certificate bundle and key as well as the necessary htpasswd file directly into the image. [I know, this is insecure, I just do that for the testing purpose]. So here is my Dockerfile:
FROM registry:latest
COPY htpasswd /etc/docker
COPY server_bundle.pem /etc/docker
COPY server_key.pem /etc/docker
server_bundle.pem has a wildcard certificate for my domain mydomain.com (CN=*.mydomain.com) as the first one, followed by the intermediate CA certificates, so clients should be happy. My htpasswd file was created using the recommended approach:
docker run --entrypoint htpasswd registry:2 -Bbn heyitsme mysupersecurepassword > htpasswd
I build my image:
docker build -t heyitsme/registry .
and afterwards I run a very basic version w/o TLS and authentication:
docker run --restart=always -p 5000:5000 heyitsme/registry
and I can actually pull, tag and re-push an image:
docker pull alpine
docker tag alpine localhost:5000/alpine
docker push localhost:5000/alpine
This works. Next I make TLS and basic auth work via environment variables:
docker run -h registry.mydomain.com --name registry --restart=always -p 5000:5000 \
-e REGISTRY_HTTP_HOST=http://registry.mydomain.com:5000 \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/etc/docker/server_bundle.pem \
-e REGISTRY_HTTP_TLS_KEY=/etc/docker/server_key.pem \
-e REGISTRY_AUTH=htpasswd \
-e REGISTRY_AUTH_HTPASSWD_REALM=Registry-Realm \
-e REGISTRY_AUTH_HTPASSWD_PATH=/etc/docker/htpasswd heyitsme/registry
For the time being I create an entry in /etc/hosts which says:
127.0.0.1 registry.mydomain.com
And then I login:
docker login registry.mydomain.com:5000
Username: heyitsme
Password: ***********
Login Succeeded
So now, let’s tag and push the image here:
docker tag alpine registry.mydomain.com:5000/alpine
docker push registry.mydomain.com:5000/alpine
The push refers to a repository [registry.mydomain.com:5000/alpine]
4fe15f8d0ae6: Retrying in 4 seconds
What happens is, that the docker clients tries to push fragments and fails. Then it retries and fails again until I get a timeout. So next check, whether the V2 API works properly:
curl -i -XGET https://registry.mydomain.com:5000/v2/
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Docker-Distribution-Api-Version: registry/2.0
Www-Authenticate: Basic realm="Registry-Realm"
X-Content-Type-Options: nosniff
Date: Thu, 15 Sep 2016 10:06:04 GMT
Content-Length: 87
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}
Ok, as expected. So let’s authenticate next time:
curl -i -XGET https://heyitsme:mysupersecretpassword#registry.mydomain.com:5000/v2/
HTTP/1.1 200 OK
Content-Length: 2
Content-Type: application/json; charset=utf-8
Docker-Distribution-Api-Version: registry/2.0
X-Content-Type-Options: nosniff
Date: Thu, 15 Sep 2016 10:06:16 GMT
{}%
Works. But pushing still fails.
The logs say:
time="2016-09-15T10:24:34Z" level=warning msg="error authorizing context: basic authentication challenge for realm \"Registry-Realm\": invalid authorization credential" go.version=go1.6.3 http.request.host="registry.mydomain.com:5000" http.request.id=6d2ec080-6824-4bf7-aac2-5af31db44877 http.request.method=GET http.request.remoteaddr="172.17.0.1:40878" http.request.uri="/v2/" http.request.useragent="docker/1.12.0 go/go1.6.3 git-commit/8eab29e kernel/4.4.15-moby os/linux arch/amd64 UpstreamClient(Docker-Client/1.12.0 \\(darwin\\))" instance.id=be3a8877-de64-4574-b47a-70ab036e7b79 version=v2.5.1
172.17.0.1 - - [15/Sep/2016:10:24:34 +0000] "GET /v2/ HTTP/1.1" 401 87 "" "docker/1.12.0 go/go1.6.3 git-commit/8eab29e kernel/4.4.15-moby os/linux arch/amd64 UpstreamClient(Docker-Client/1.12.0 \\(darwin\\))"
time="2016-09-15T10:24:34Z" level=info msg="response completed" go.version=go1.6.3 http.request.host="registry.mydomain.com:5000" http.request.id=8f81b455-d592-431d-b67d-0bc34155ddbf http.request.method=POST http.request.remoteaddr="172.17.0.1:40882" http.request.uri="/v2/alpine/blobs/uploads/" http.request.useragent="docker/1.12.0 go/go1.6.3 git-commit/8eab29e kernel/4.4.15-moby os/linux arch/amd64 UpstreamClient(Docker-Client/1.12.0 \\(darwin\\))" http.response.duration=30.515131ms http.response.status=202 http.response.written=0 instance.id=be3a8877-de64-4574-b47a-70ab036e7b79 version=v2.5.1
172.17.0.1 - - [15/Sep/2016:10:24:34 +0000] "POST /v2/alpine/blobs/uploads/ HTTP/1.1" 202 0 "" "docker/1.12.0 go/go1.6.3 git-commit/8eab29e kernel/4.4.15-moby os/linux arch/amd64 UpstreamClient(Docker-Client/1.12.0 \\(darwin\\))"
2016/09/15 10:24:34 http: TLS handshake error from 172.17.0.1:40886: tls: first record does not look like a TLS handshake
I also tested different versions of the original registry image, especially several versions above 2. All yield the same error. If someone could help me on that issue, that would be awesome.
Solved:
-e REGISTRY_HTTP_HOST=https://registry.mydomain.com:5000 \
as environment variable did the tick. Just the prior use of http instead https made the connection fail.
Thanks a lot, it's working now!
I added the variable in my kubernetes deployment manifest:
(...)
- env:
- name: REGISTRY_STORAGE_DELETE_ENABLED
value: "true"
- name: REGISTRY_HTTP_HOST
value: "https://registry.k8sprod.acme.domain:443"
(...)
For those who use nginx ingress in front, you have to set extra attribute in your ingress manifest file if you have push size errors:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ingress-registry
namespace: default
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/proxy-body-size: "8192m"
nginx.ingress.kubernetes.io/proxy-connect-timeout: "600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "600"
nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "10"
nginx.ingress.kubernetes.io/proxy-request-buffering: "off"
labels:
k8s-app: kube-registry
app: kube-registry
spec:
rules:
- host: registry.k8sprod.acme.domain
http:
paths:
- path: /
backend:
serviceName: svc-kube-registry
servicePort: 5000

Bitbucket Pipelines. Cannot specify windowsservercore docker image

Bitbucket Pipelines allows (using bitbucket-pipelines.yml) to specify a custom docker image from Dockerhub as build environment. Next image is used as default for .NET Core:
# You can specify a custom docker image from Dockerhub as your build environment
image: microsoft/dotnet:onbuild
But cause I need Windows Containers image, I am trying to change image to "windowsservercore". Based on information in microsoft/dotnet docker hub, I have tried
image: microsoft/dotnet:1.0.0-windowsservercore-core
and
image: microsoft/dotnet:1.0.0-preview2-windowsservercore-sdk
but image has not been downloaded:
+ docker pull "microsoft/dotnet:1.0.0-windowsservercore-core"
1.0.0-windowsservercore-core: Pulling from microsoft/dotnet
1239394e5a8a: Pulling fs layer
d90a2ac79ff2: Pulling fs layer
cde3fa87b2c9: Pulling fs layer
9f60be4f8205: Pulling fs layer
c4f6347ed968: Pulling fs layer
9f60be4f8205: Waiting
c4f6347ed968: Waiting
1239394e5a8a: Retrying in 5 seconds
d90a2ac79ff2: Verifying Checksum
d90a2ac79ff2: Download complete
cde3fa87b2c9: Verifying Checksum
cde3fa87b2c9: Download complete
1239394e5a8a: Retrying in 4 seconds
c4f6347ed968: Verifying Checksum
c4f6347ed968: Download complete
...
1239394e5a8a: Retrying in 3 seconds
1239394e5a8a: Retrying in 2 seconds
1239394e5a8a: Retrying in 1 second
1239394e5a8a: Downloading
unknown blob
You might not be able to use that image at all if Bitbucket pipelines doesn't support running Windows images yet...
The error you are reporting, is the error you get when a windowsservercore or nanoserver image is pulled from an unsupported host.
Additionally, my local docker does the same when running that pull.
$ docker pull microsoft/dotnet:1.0.0-windowsservercore-core`.
1.0.0-windowsservercore-core: Pulling from microsoft/dotnet
1239394e5a8a: Downloading
d90a2ac79ff2: Download complete
cde3fa87b2c9: Download complete
9f60be4f8205: Download complete
c4f6347ed968: Download complete
unknown blob
You can have a look detailed look via the Registry API at the 1.0.0-windowsservercore-core tags manifest:
curl -i -H "Authorization: Bearer $TOKEN" https://index.docker.io/v2/microsoft/dotnet/manifests/1.0.0-windowsservercore-core
HTTP/1.1 200 OK
Content-Length: 4168
Content-Type: application/vnd.docker.distribution.manifest.v1+prettyjws
Docker-Content-Digest: sha256:190e1596bf49b844f6fc3361bbedcd50c917079e5f9f305a1fe807ae4b66a6a7
Docker-Distribution-Api-Version: registry/2.0
Etag: "sha256:190e1596bf49b844f6fc3361bbedcd50c917079e5f9f305a1fe807ae4b66a6a7"
Date: Sun, 07 Aug 2016 13:25:58 GMT
Strict-Transport-Security: max-age=31536000
{
"schemaVersion": 1,
"name": "microsoft/dotnet",
"tag": "1.0.0-windowsservercore-core",
"architecture": "amd64",
"fsLayers": [
{
"blobSum": "sha256:9f60be4f8205c0d384e6af06d61e253141395d4ef7000d8bb34032d1cbd8ee98"
},
{
"blobSum": "sha256:cde3fa87b2c91c895014a6c83481b27ede659f502538c6ed416574a3abe5a7a2"
},
{
"blobSum": "sha256:d90a2ac79ff2c769b497fabddbd14ae8a66f8034dda53fd5781402ec58416989"
},
{
"blobSum": "sha256:1239394e5a8ab79fbd3b751dc5d98decf5886f14339958fdf5c1f96c89da58a7"
}
],
The manifest includes the 1239394e5a8 blob Docker is not able to retrieve. Then running a GET for that blob returns a 404.
curl -i -H "Authorization: Bearer $TOKEN" https://index.docker.io/v2/microsoft/dotnet/blobs/sha256:1239394e5a8ab79fbd3b751dc5d98decf5886f14339958fdf5c1f96c89da58a7
HTTP/1.1 404 Not Found
Content-Type: application/json; charset=utf-8
Docker-Distribution-Api-Version: registry/2.0
Date: Sun, 07 Aug 2016 13:29:02 GMT
Content-Length: 157
Strict-Transport-Security: max-age=31536000
{"errors":[{"code":"BLOB_UNKNOWN","message":"blob unknown to registry","detail":"sha256:1239394e5a8ab79fbd3b751dc5d98decf5886f14339958fdf5c1f96c89da58a7"}]}
Whereas that other blobs return the usual redirect to the data download:
curl -i -H "Authorization: Bearer $TOKEN" https://index.docker.io/v2/microsoft/dotnet/blobs/sha256:d90a2ac79ff2c769b497fabddbd14ae8a66f8034dda53fd5781402ec58416989
HTTP/1.1 307 Temporary Redirect
Content-Type: application/octet-stream
Docker-Distribution-Api-Version: registry/2.0
Location: https://dseasb33srnrn.cloudfront.net/registry-v2/docker/registry/v2/blobs/sha256/d9/d90a2ac79ff2c769b497fabddbd14ae8a66f8034dda53fd5781402ec58416989/data?Expires=1470577758&Signature=B6n1cC~fNwgeYYbA2w6peZOWM5RyV79OrBW-9nN2NdxpB60FC1sUe7e9I4kcA7Meq1SAG7z4P4gQiLvNfokHr8u0p3LTUQgk4JpqZPxqSPNtDWoSyjzyTN0sK3iZPhgxcNBVfddHyxgkAw7xb47zUg76RjZ5-O8QNl2YeEKeX24_&Key-Pair-Id=APKAJECH5M7VWIS5YZ6Q
Date: Sun, 07 Aug 2016 13:29:18 GMT
Content-Length: 432
Strict-Transport-Security: max-age=31536000
Temporary Redirect.
It's probably a registry bug and the MS dotnet team might need to rebuild that layer/image and publish again to work around the issue. Once they've fixed that you will find out if Bitbucket pipelines can run Windows images (which I've found no evidence to say they do yet).
I was able to work around this by using the mono docker image and xbuild.

Docker registry 2.0 api v2 access using auth token

I have private docker repository in quay.io and I want to get list of repositories and tags related to it.
So I use curl -IL https://quay.io/user/accountName/v2/_catalog
it returns
HTTP/1.1 401 UNAUTHORIZED
Server: nginx/1.9.5
Date: Thu, 18 Feb 2016 11:02:19 GMT
Content-Type: application/json
Content-Length: 117
Connection: keep-alive

Resources