Why `services: docker:dind` is needed while already having `image: docker`?

pavelhoral · November 22, 2021, 5:01pm

I would add one important fact - docker (here as the name of the image *docker*:latest) images are setting DOCKER_HOST to a remote daemon running in container resolvable under the name docker.

github.com

docker-library/docker/blob/d45051476babc297257df490d22cbd806f1b11e4/docker-entrypoint.sh#L22

    
      
          	set -- docker "$@"
          fi
          
          
_should_tls() {
          	[ -n "${DOCKER_TLS_CERTDIR:-}" ] \
          	&& [ -s "$DOCKER_TLS_CERTDIR/client/ca.pem" ] \
          	&& [ -s "$DOCKER_TLS_CERTDIR/client/cert.pem" ] \
          	&& [ -s "$DOCKER_TLS_CERTDIR/client/key.pem" ]
          }
          
          
# if DOCKER_HOST isn't set and we don't have the default unix socket, let's set DOCKER_HOST to a sane remote value
          if [ -z "${DOCKER_HOST:-}" ] && [ ! -S /var/run/docker.sock ]; then
          	if _should_tls || [ -n "${DOCKER_TLS_VERIFY:-}" ]; then
          		export DOCKER_HOST='tcp://docker:2376'
          	else
          		export DOCKER_HOST='tcp://docker:2375'
          	fi
          fi
          if [ -n "${DOCKER_HOST:-}" ] && _should_tls; then
          	export DOCKER_TLS_VERIFY=1
          	export DOCKER_CERT_PATH="$DOCKER_TLS_CERTDIR/client"

So the correct Docker daemon (run by dind service) is automagically picked up by the job container because GitLab CI assigns name docker to the service container based on the image name. That is IMO not that obvious on the first glance.