docker-compose version 1.6.0, build d99cad6
docker-py version: 1.7.0
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
I'm trying to pull down a context from my private Github repository, and keep running into this error:
ERROR: compose.cli.main.main: Error trying to use git: exit status 128 (Cloning into '/var/lib/docker/tmp/docker-build-git991276936'...
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
)
When I run docker-compose -v up
I get this:
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=apiccomposed', u'com.docker.compose.service=eula_server', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.service.execute_convergence_plan: apiccomposed_redis_1 is up-to-date
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- (u'apiccomposed_eula_server')
compose.service.build: Building eula_server
compose.cli.verbose_proxy.proxy_callable: docker build <- (pull=False, stream=True, nocache=False, tag=u'apiccomposed_eula_server', buildargs=None, rm=True, forcerm=False, path='[email protected]:apimesh/apimc-eula-server.git#docker', dockerfile='./EULA_Dockerfile')
docker.api.build._set_auth_headers: Looking for auth config
docker.api.build._set_auth_headers: No auth config in memory - loading from filesystem
docker.auth.auth.load_config: File doesn't exist
docker.api.build._set_auth_headers: No auth config found
compose.cli.verbose_proxy.proxy_callable: docker build -> <generator object _stream_helper at 0x7f5dc2602e10>
I assume it's because it can't find the auth config.
The docker-compose.yml
:
version: '2'
services:
application:
build:
context: '[email protected]:apimesh/application.git'
dockerfile: ./APP_Dockerfile
This works when I do docker build [email protected]:apimesh/application.git
The output of docker-compose version
would be great as well.
Do you have a docker.cfg that it's not finding?
Don't know about docker.cfg
just doing my initial muddlings.
As mentioned in #2542, I'm seeing this issue as well. If it matters, I'm actually running docker-compose
inside a docker container.
@dnephin I couldn't find any docs on docker.cfg
; do you have any links?
Here is the output from docker-compose version
:
# docker-compose version
docker-compose version 1.6.2, build 4d72027
docker-py version: 1.7.2
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
I think the docs are: https://docs.docker.com/engine/reference/commandline/cli/#configuration-files (docker.cfg might be the old name, I think the new path is ~/.docker/config.json
).
If you're running from a container you'll have to either authorize that hostname, or mount in the ssh config files from the host I think.
It does not seem like hostname authorization or missing ssh config files is the issue.
Here is a simple test case:
Launch this docker container:
docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock:ro saulshanabrook/docker-compose bash
Then, run this script (insert your $private_repo and $SSH_PRIVATE_DEPLOY_KEY)
# disable host key checking in containers
mkdir -p ~/.ssh
grep -q docker /proc/1/cgroup && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
[email protected]:project/name#branch:path-to-dockerfile-directory
# this fails as expected; we don't have SSH access yet
docker build -t test $private_repo
SSH_PRIVATE_DEPLOY_KEY="your private deploy key here"
eval $(ssh-agent -s)
ssh-add <(echo "${SSH_PRIVATE_DEPLOY_KEY}")
# now this works
docker build -t test $private_repo
cd $(mktemp -d)
cat << EOF > docker-compose.yml
---
version: '2'
services:
a:
build: $private_repo
EOF
# This fails
docker-compose build
The attempt at running docker-compose build
at the end fails with
Building a
ERROR: Error trying to use git: exit status 128 (Cloning into '/var/lib/docker/tmp/docker-build-git148106783'...
Host key verification failed.
fatal: The remote end hung up unexpectedly
)
I have the same issue and can reproduce in the same way.
docker-compose version 1.6.0, build d99cad6
docker-py version: 1.7.0
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1j 15 Oct 2014
After playing with this for a while, I believe I see the problem.
When running docker build
, the git clone happens _locally_, using this code. The build context is passed to the daemon as a tarball.
When running docker-compose build
, the git clone happens _in the docker daemon_, using this code. A remote
parameter is passed and the daemon attempts to clone the repo and create the build context.
The code that is eventually run is the same (cloning the repo). The difference is the environment it is run in: for docker
it is local, for docker-compose
it is the docker-machine
VM (or wherever the daemon is running).
I am not sure why in some instances the error is Could not read from remote repository
and in other instances is Host key verification failed
.
Nevertheless, the issue seems to be that docker-py
(used by docker-compose
) performs the build using the daemon instead of using the same method as docker
. See here.
@apeace thanks for looking into this!
This is a problem for me too. Any advice on how to handle it?
FWIW I found that specifying my github username and an API token in the repo URL worked:
# docker-compose.yml
version: '2'
services:
example-service:
build:
context: "https://${GITHUB_USERNAME}:${GITHUB_AUTH_TOKEN}@github.com/org/repo.git"
I have the same issue. What would be the easiest way to expose the keys to the docker-machine and get this working?
@robertherber see this issue. I have been hoping to implement a fix, but sadly have not had the time yet!
@wmadden see the above-linked issue. The solution you posted is the only one available for now, AFAIK.
What about ssh git URLs? My problem is that my repo is in a non-default ssh port and I have to specify the port in the repo URL. The only way I know to do it is by using a ssh URL:
ssh://[email protected]:2222/reponame
I am also getting this error when trying to add our company's gitlab instance as a context:
ERROR: "Error trying to use git: exit status 128 (Cloning into '/var/lib/docker/tmp/docker-build-git601395189' ...
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights\nand the repository exists.)"
Output of docker-compose version
:
docker-compose version 1.8.0, build 94f7016
docker-py version: 1.9.0
CPython version: 3.5.2
OpenSSL version: OpenSSL 1.0.2h 3 May 2016
FYI to anyone reporting: this is a known issue. As noted by @apeace in https://github.com/docker/docker-py/issues/980, the solution is to do the git clone
on the client side. We don't consider it high-priority, but PRs are always welcome.
You can work around it by cloning the repo yourself to a predetermined path and using that path for the build context.
By default, Atlassian's BitBucket (edit: self hosted version) SSH daemon runs on port 7999
it would be great if a custom ssh port could be specified for a git address. Doing a git clone
on client side or configuring port forwarding, yes, are workarounds, but far from ideal in my opinion
Most helpful comment
After playing with this for a while, I believe I see the problem.
When running
docker build
, the git clone happens _locally_, using this code. The build context is passed to the daemon as a tarball.When running
docker-compose build
, the git clone happens _in the docker daemon_, using this code. Aremote
parameter is passed and the daemon attempts to clone the repo and create the build context.The code that is eventually run is the same (cloning the repo). The difference is the environment it is run in: for
docker
it is local, fordocker-compose
it is thedocker-machine
VM (or wherever the daemon is running).I am not sure why in some instances the error is
Could not read from remote repository
and in other instances isHost key verification failed
.Nevertheless, the issue seems to be that
docker-py
(used bydocker-compose
) performs the build using the daemon instead of using the same method asdocker
. See here.