Skip to content

"kompose up" won't push to Google on Windows Subsystem for Linux #1117

Closed
@agnf

Description

"kompose up" can't push to private repository on Google on the Windows Subsystem for Linux (WSL) on Windows 10 Pro. Trying out different strategies and solutions found on Github didn't fix the problem for me.

Some output:

$ kompose version
1.18.0 (06a2e56)

$ kompose up
INFO Build key detected. Attempting to build and push image 'eu.gcr.io/0000/testalpine:latest'
INFO Building image 'eu.gcr.io/0000/testalpine:latest' from directory 'kompose'
INFO Image 'eu.gcr.io/0000/testalpine:latest' from directory 'kompose' built successfully
INFO Pushing image '0000/testalpine:latest' to registry 'eu.gcr.io'
WARN Unable to retrieve .docker/config.json authentication details. Check that 'docker login' works successfully on the command line.: Failed to read authentication from dockercfg
INFO Authentication credentials are not detected. Will try push without authentication.
INFO Attempting authentication credentials 'eu.gcr.io
ERRO Unable to push image '0000/testalpine:latest' to registry 'eu.gcr.io'. Error: unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication
FATA Error while deploying application: k.Transform failed: Unable to push Docker image for service apache: unable to push docker image(s). Check that docker login works successfully on the command line

$ docker login eu.gcr.io
Authenticating with existing credentials...
Login Succeeded

$ docker-compose push apache
Pushing apache (eu.gcr.io/0000/testalpine:latest)...
The push refers to repository [eu.gcr.io/0000/testalpine]
XXX6ee230d1a: Layer already exists
XXX2f368fe23: Layer already exists
latest: digest: sha256:XXX22f299e969d6607b7ea8049acfee81c8898215c964731909a85deff8b67e6 size: 739

$ kompose convert
INFO Kubernetes file "apache-service.yaml" created
INFO Kubernetes file "apache-deployment.yaml" created

$ kubectl create -f apache-deployment.yaml,apache-service.yaml
deployment.extensions/apache created
service/apache created

$ cat Dockerfile
FROM alpine:latest
RUN apk --no-cache add apache2 apache2-utils
RUN mkdir -p /run/apache2
EXPOSE 80
CMD ["/usr/sbin/httpd", "-DFOREGROUND"]

$ cat docker-compose.yml
version: "3"
services:
apache:
image: eu.gcr.io/0000/testalpine:latest
build: .
ports:
- "80:80"

$ cat .docker/config.json
{
"auths": {
"eu.gcr.io": {},
"gcr.io": {}
},
"HttpHeaders": {
"User-Agent": "Docker-Client/18.06.3-ce (linux)"
},
"credHelpers": {
"asia.gcr.io": "gcloud",
"eu.gcr.io": "gcloud",
"gcr.io": "gcloud",
"marketplace.gcr.io": "gcloud",
"staging-k8s.gcr.io": "gcloud",
"us.gcr.io": "gcloud"
}
}

The "config.json" is copied to these locations in an attempt to make it visible to kompose:

  • .docker/config.json
  • ~/.docker/config.json
  • /.docker/config.json
  • /root/.docker/config.json
  • /c/Users/myUsrName/Documents/IT/docker/kompose

Previously, I had problems with "docker-compose" and volumes. I have Docker for Windows installed and use the Linux Subsystem under Windows 10. Before, my yaml files resided in "~/docker/..." where volumes couldn't be used. Then I moved the files over to "/c/Users/myUsrName/Documents/IT/docker/..." and linked that folder to my Linux home for easy access. After that I was able to use volumes in my "docker-compose.yaml" successfully.

Based on that I was thinking that there is a similar problem with paths and where kompose might look for credential files. However, putting the "config.json" to different places didn't help.

Since building and pushing the image via docker, then running "kompose convert" and then creating the deployment via "kubectl create -f ..." works, I have a workaround. Still, it would be great if "kompose up" would work. Other issues I found on that regard (like #911) seem to focus on MacOS, hence I decided to open this up for Windows 10 now.

Let me know if you need further info on this!

Cheers
Andreas

Metadata

Assignees

No one assigned

    Labels

    lifecycle/rottenDenotes an issue or PR that has aged beyond stale and will be auto-closed.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions