On my local dev machine I use docker.from_env(version=auto) (docker-py) to get a docker client without any issues. If I run the same statement inside a gitlab-ci job which run inside a docker container (or with gitlab-runner exec docker ... during local debugging) to get a docker client I get a DockerException: Error while fetching server API version: ('Connection aborted.', error(2, 'No such file or directory')). How can I get a docker client with docker-py inside a gitlab-ci job which runs inside a docker container?
I think you'll need to build and deploy your own runner with the following binding '/var/sock/docker.sock:/var/sock/docker.sock.
Related
I am a newbie in gitlabci. I want to understand why do we need docker dind image in order to build a docker image in GitLab CI jobs. Why can't we use the docker executor and run docker commands under scripts?
When we register docker executor gitlab runner, we choose one image..
Again inside gitlabci, we choose an image under image: or services: fields. So does that mean this GitLab CI job container runs inside the docker executor container?
why do we need docker dind image in order to build a docker image in GitLab CI jobs. Why can't we use the docker executor and run docker commands under scripts?
This partly depends on how you have configured your GitLab runner.
Why docker doesn't work inside containers
When you invoke docker commands, they are really talking to a docker daemon which is needed to perform builds and carry out other docker commands. Typically, jobs running under the docker executor do not have access to any docker daemon by default. It's the same kind of problem you would face if you tried to run docker inside of a docker container you started locally.
Even if I can run docker successfully on my host:
$ docker run --rm docker /bin/sh -c 'hello from container $HOSTNAME'
hello from container 2b51479b11b1
I cannot run docker inside the container
$ docker run --rm docker /bin/sh -c 'docker info'
errors pretty printing info
Client:
Context: default
Debug Mode: false
Server:
ERROR: error during connect: Get "http://docker:2375/v1.24/info": dial tcp: lookup docker on 192.168.65.5:53: no such host
The same error would happen trying to run any other significant docker command like build, run, etc.
An exception to this would be if you configured your GitLab runner to run containers in privileged mode and mount /var/run/docker.sock to all your jobs (this would not be advisable) in which case all your jobs could talk directly to the docker daemon on the host. Another exception might be if you use the shell executor instead and you have docker installed on the host where the runner is running.
How the dind service fixes this
The docker:dind service is a daemon that is created just for your job. This is incredibly important because it can prevent concurrent jobs from stepping on one another or being able to escalate access where they might not otherwise have it.
When the build starts, the GitLab runner will create two containers: your job container and the docker:dind container; they are linked together. When your job invokes docker commands, your job connects to the docker:dind container, which then carries out the requested commands.
Any containers created by your job (say, by invoking docker run or docker build as part of your job) are managed by the daemon running on the docker:dind container, not the host daemon. If you run docker ps inside the job, you'll notice that none of the containers run on the host daemon are listed, despite the fact that if you ran docker ps on the host, you would see the job container, the dind container, and any other running containers.
To clarify your other questions:
When we register docker executor gitlab runner, we choose one image
The image specified in your runner configuration is simply the default docker image to be used if a job doesn't declare any image: key. It does not affect how the runner runs in any way.
inside gitlabci, we choose an image under image: or services: fields
When the docker executor runs your job, it uses docker run to do so. The image: key determines which image is used to run your job. Similarly, services: define the image used for service containers -- service containers are siblings to the job container and are connected with links.
So does that mean this GitLab CI job container runs inside the docker executor container?
No. I'd also like to clear up: the runner/executor doesn't run in a container, necessarily. Runners might be installed as a Windows service, or simply even a process running directly on a system. You can use runners that happen to be inside containers, but it doesn't materially affect how jobs are run.
In any case, the containers where your job run are generally always going to be run directly by the host docker daemon.
I've got Gitlab installed on Kubernetes using Helm and try to get Auto DevOps working but I'm getting the following issue from the Auto DevOps pipeline:
Executing "step_script" stage of the job script 00:01
$ if [[ -z "$CI_COMMIT_TAG" ]]; then # collapsed multi-line command
$ /build/build.sh
Logging in to GitLab Container Registry with CI credentials...
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
Building Dockerfile-based application...
Attempting to pull a previously built image for use with --cache-from...
Cannot connect to the Docker daemon at tcp://localhost:2375. Is the docker daemon running?
Cannot connect to the Docker daemon at tcp://localhost:2375. Is the docker daemon running?
No previously cached image found. The docker build will proceed without using a cached image
Cannot connect to the Docker daemon at tcp://localhost:2375. Is the docker daemon running?
Cleaning up file based variables 00:00
ERROR: Job failed: command terminated with exit code 1
I've read abt the issues with Docker-in-Docker, but I couldn't get it to work.
I also tried setting the DOCKER_HOST: tcp://docker:2375/ variable, but I still get the same error.
Cannot connect to the Docker daemon at tcp://docker:2375/. Is the docker daemon running?
My Gitlab Runner Helm values looks like this:
gitlabUrl: https://gitlab.mydomain.com
privileged: true
rbac:
create: true
runnerRegistrationToken: mytoken
runners:
config: |
[[runners]]
executor = "docker"
privileged = true
environment = ["DOCKER_TLS_CERTDIR="]
[runners.docker]
tls_verify = false
privileged = true
I tried using the Auto-DevOps .gitlab-ci.yml template.
My cluster is integrated into Gitlab using the cluster certificate method and running simple CI/CD like
test_project:
stage: test
script:
- npm run test
Works fine
I tried docker:18.09.7, docker:19.03.1 and docker:latest (and the corresponding -dind services, with or without setting DOCKER_HOST: tcp://docker:2375/)
I don't know what I'm missing.
// Update
I got this issue resolved with help from the Gitlab Support.
My issue was that I had to use [runners.kubernetes] config and set privileged to true there. I was only setting it in [runners.docker] as I thought that Kubernetes Gitlab Runners would that config.
I am trying to get selenium side runner to run some tests using docker, to include in our CI.
I am able to run the tests locally in my machine by running:
selenium-side-runner C:\path-to-tests\tests-selenium.side
This is windows host.
I am trying to do the same using docker locally, so afterwards I will migrate this to our Teamcity.
First I am running the selenium server container:
docker run -d -p 4444:4444 --name chromedriver selenium/standalone-chrome:3.4.0
Afterwards I run the selenium side runner container:
docker run -v C:\path-to-tests:/sides --link chromedriver:chromedriver nixel2007/docker-selenium-side-runner
I have to link the containers otherwise I get an error saying that the container can't connect to chromedriver:4444
I also have to mount the volume where my tests are.
When I do this and run, I get the following error:
Test suite failed to run
WebDriverError: Unable to parse new session response
What am I missing here?
UPDATE:
I also tried different versions of the selenium/standalone-chrome container, selenium/standalone-chrome:3.4.0, selenium/standalone-chrome:3.141.59-xenon and selenium/standalone-chrome:latest
All fail with different errors.
SECOND UPDATE:
I have been able to get the tests to run, both locally and in teamcity. One of the issues that I am facing right now is that docker-compose seems to hang. Not sure if this is container related, or docker-compose related.
When I run the tests, the selenium side runner container exits with code 1 and I do not get back to the host console prompt, it stays forever waiting for something to happen.
The error is this:
selenium_selenium-side-runner_1 exited with code 1
I have gotten the docker-compose file from here:
https://github.com/nixel2007/docker-selenium-side-runner/blob/master/docker-compose.yml
Any clues on what I might be missing?
I am running “dev mode” by leveraging pre-generated orderer and channel artifacts for a sample dev network
here cli require image: hyperledger/fabric-tools by default it is trying to pull latest tag image and showing errorlatest image. and it throwing error
Error response from daemon: manifest for hyperledger/fabric-tools:latest not found
so I pull image hyperledger/fabric-tools:x86_64-1.0.0, and rename it with hyperledger/fabric-tools:latest( not sure it is proper way or not ) by :
docker pull hyperledger/fabric-tools:x86_64-1.0.0
docker tag hyperledger/fabric-tools:x86_64-1.0.0 hyperledger/fabric-tools
My network is running successfully but unfortunately cli container is stopped running.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d10d170cd2fa hyperledger/fabric-tools:x86_64-1.0.0 "/bin/bash -c ./sc..." 29 seconds ago Exited (1) 27 seconds ago cli
163f494bb85f hyperledger/fabric-ccenv "/bin/bash -c 'sle..." 59 minutes ago Up About a minute chaincode
e96e86930d94 hyperledger/fabric-peer "peer node start -..." 59 minutes ago Up About a minute 0.0.0.0:7051->7051/tcp, 0.0.0.0:7053->7053/tcp peer
c568480e30d2 hyperledger/fabric-orderer "orderer" 59 minutes ago Up About a minute 0.0.0.0:7050->7050/tcp
You can use the tools container as the cli container.
docker exec -it d10d170cd2fa /bin/bash
Can you post logs of cli container by issuing command docker logs <containerId>? cli container exit doesn't necessarily mean there's any error about the e2e test.
If you started the services using docker-compose, you can run either of: docker-compose restart -f docker-compose-simple.yaml cli or docker-compose up -f docker-compose-simple.yaml cli.
However, if you started your network AFTER having tagged the fabric-tools image as above, you should examine the logs of your exited container with docker logs cli, to determine why it exited.
It can be because of previously running docker containers. In my case first time it worked correctly but it gave error in second time. Killing and removing created docker containers using
docker rm container_name
and starting containers again, solved the problem.
I have a docker image 'redis_image' that installed redis in it. After I run a container as:
docker run --name test_redis -it redis_image bash
the redis server can start normally in the container using '/etc/init.d/redis start'.
But if I run the container with --net=host option, the redis server will fail to start in the container, it says "Starting redis-server: could not open session [Failed]". Is the problem related to the --net=host configuration when I run the container? Thanks.