drone-docker: Drone doesn't seem to cache layers

@bradrydzewski @leshik

I might be missing something, but the reason despite loading a cached tar as an image isn’t working is due to pull=true always being part of the build command. If I knew any go I would create a pull request, which accepted no_pull or something like that to the drone-docker yml args, unfortunately I don’t.

/usr/bin/docker build --pull=true --rm=true -f Dockerfile.build -t org/project:dev .

Help? 😄

Ok so this is what i needed to get this puppy running:

build:
  image: alpine:3.2
  commands:
    - apk --update add docker
    - "export DOCKER_HOST=unix:///var/run/host.sock"
    - docker login -u registry -p $$REGISTRY_PASSWORD -e fake@fake.fk registry.XX.com
    - docker build -t registry.XX.com/ok .
    - docker push registry.XX.com/ok
  volumes:
    - /var/run/docker.sock:/var/run/host.sock:ro

Not very hard as you can see 😃

In the newest syntax, something like the following worked for me:

# New syntax
kind: pipeline
name: production

steps:
- name: docker  
  image: docker:18.06.1-ce-dind
  privileged: true
  environment:
    Salt:
      from_secret: Salt
    DOCKER_LAUNCH_DEBUG:
      true
    DOCKER_HOST:
      unix:///var/run/host.sock
    docker_username:
      from_secret: docker_username
    docker_password:
      from_secret: docker_password
  commands:
    - echo $Salt
    # - /usr/local/bin/dockerd-entrypoint.sh
    - docker login -u $docker_username -p $docker_password
    - apk add git
    - sh ./docker-build.sh
  volumes:
  - name: cache
    path: /var/run/host.sock

volumes:
- name: cache
  host:
    path: /var/run/docker.sock

@emilebosch, @chuyskywalker use official Docker in Docker image. It is based on Alpine linux.

build:
  image: docker
  commands:
    - docker login -u "$DOCKER_LOGIN" -p "$DOCKER_PASSWORD" -e "$DOCKER_EMAIL"
    - docker build -t <image> .
    - docker push <image>
  environment:
    - DOCKER_LOGIN=$$DOCKER_LOGIN
    - DOCKER_PASSWORD=$$DOCKER_PASSWORD
    - DOCKER_EMAIL=$$DOCKER_EMAIL
  volumes:
    - /var/run/docker.sock:/var/run/docker.sock

@chuyskywalker there is an open PR to improve this at https://github.com/drone-plugins/drone-docker/pull/36

I totally understand that, for publicly hosted instance (drone.io, etc) this is a non-starter for a lot of reasons, but for privately run drones this feels a lot saner too me.

The current solution works great for certain languages, such as Go, Rust and others that compile binaries and don’t need layer caching. Drone is optimized for these language because I spend most of my time writing Go code, and that bias is reflected in the initial design. I fully acknowledge for other languages (python, php, ruby) we still have a lot of work to do.

Note that I described this as the initial design. Plugins were just introduced in this latest version of Drone and this is by no means the final implementation. If you have suggestions to improve we are definitely open. Also remember that you can write your own plugins, incubate them, and suggest they be included in the official plugin list.

Lastly there are situations, even for private installations, that you don’t want the host machines Docker daemon exposed. Some users of Drone operate in highly regulated environments and want their build servers locked down. Some teams run 10+ builds per server and have run into race conditions (tagging and pushing images) when running multiple builds concurrently for the same repository.

We just need to take the above into consideration as we move forward. There are a lot of different use cases we need to consider. And, the good news is, we can have multiple docker plugins for different use cases if we need to optimize for specific languages or workflows.

I also hit this same issue where the docker daemon (in the build container) simply refuses to use the imported cached layers. I also went the route through host socket mounting. I totally understand that, for publicly hosted instance (drone.io, etc) this is a non-starter for a lot of reasons, but for privately run drones this feels a lot saner too me. Better cached usage, less “weird” of a setup. It’d be much appreciate if the docker plugin could support this, but the workaround above leads down a working path.

Don’t forget to mark the repo as “trusted” in drone so volume mounts are allowed. Otherwise, I ended up doing this:

build:
  image: centos:7
  environment:
    - DOCKER_HOST=unix:///tmp/host.sock
    - IMAGEID=USERNAME/REPONAME:$$BUILD_NUMBER-$$COMMIT
    - DOCKERHUB_USER=$$DOCKERHUB_USER
    - DOCKERHUB_PASS=$$DOCKERHUB_PASS
    - DOCKERHUB_EMAIL=$$DOCKERHUB_EMAIL
  volumes:
    - /var/run/docker.sock:/tmp/host.sock:rw
  commands:
    - |
      cat <<'EOF' > /etc/yum.repos.d/docker.repo
      [dockerrepo]
      name=Docker Repository
      baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/
      enabled=1
      gpgcheck=1
      gpgkey=https://yum.dockerproject.org/gpg
      EOF
    - yum install -y docker-engine
    - docker build -t "$IMAGEID" .
    - docker login -u "$DOCKERHUB_USER" -p "$DOCKERHUB_PASS" -e "$DOCKERHUB_EMAIL"
    - docker push "$IMAGEID"

So that user/pass/email don’t leak through the build log.

@lewistaylor I came across the exact same issue, and I’ve made a PR which allows you to now set it as an option, if you want to try it out!

use official Docker in Docker image

@budjizu What you described is not “Docker in Docker”: it’s using the docker cli command to “call out” to a daemon back on the host. This is, essentially, exactly what I and others have done.

“Docker in Docker”, which Drone does by default, is actually running a docker daemon inside your container. That new daemon is where we’re having trouble getting layers to be cached. This is an issue for us because, without layer caching, many docker build flows are not tenable. (As to why layer caching doesn’t work with the load/save trick documented elsewhere, I don’t know…)