Skip to content
This repository has been archived by the owner on Dec 2, 2024. It is now read-only.

Issue of docker client in build container not reaching a daemon #26

Open
RomainMendez opened this issue May 24, 2024 · 6 comments
Open

Comments

@RomainMendez
Copy link

Hi everyone,
I'm troubleshooting my Drone CI pipeline using the given example, and I've found that my build container is trying to reach localhost.
And while I observe the containers being brought up on the machine (and exposing ports 2375 and 2376), the "DOCKER_IP" value in "command.sh" is empty
I'm not sure how to fix this.

@RomainMendez
Copy link
Author

RomainMendez commented May 24, 2024

type: docker
name: default

steps:
  - name: integration testing
    image: quay.io/testcontainers/dind-drone-plugin
    environment:
      CI_WORKSPACE: "/drone/src"
      INTEGRATION_TEST: "YES"
    settings:
      # This specifies the command that should be executed to perform build, test and
      #  integration tests. Not to be confused with Drone's `command`:
      cmd: ./run_test.sh
      # This image will run the cmd with your build steps
      build_image: python:3.11.7-bookworm
      # Not mandatory; enables pre-fetching of images in parallel with the build, so may save 
      #  time:
      prefetch_images:
        - "tomsquest/docker-radicale:latest"
      # Not mandatory; sets up image name 'aliases' by pulling from one registry and tagging
      #  as a different name. Intended as a simplistic mechanism for using a private registry 
      #  rather than Docker Hub for a known set of images. Accepts a dictionary of
      #  private registry image name to the Docker Hub image that it is a substitute for.
      #  Note that all images are pulled synchronously before the build starts, so this is
      #  inefficient if any unnecessary images are listed.
      image_aliases:
        tomsquest/docker-radicale:latest: tomsquest/docker-radicale:latest
    volumes:
      - name: dockersock
        path: /var/run



# Specify docker:dind as a service
services:
- name: docker
  image: docker:dind
  privileged: true
  volumes:
  - name: dockersock
    path: /var/run

volumes:
- name: dockersock
  temp: {}

@RomainMendez
Copy link
Author

image

So the IP field is empty, I've checked the machine under which it is running and I see a docker0 socket existing.

@RomainMendez
Copy link
Author

After more debugging, it appears to be a bug in how testcontainers uses the daemon, as using the docker pluging directly seems to work just fine. There's an issue about this topic on the main repo

@RomainMendez
Copy link
Author

So I found the issue, docker:dind by default uses TLS nowadays, so the plugin should in the doc force the usage of TLS and add the certs from the service, should I add a PR ?

@animavitis
Copy link

animavitis commented Jul 19, 2024

U do not have to use this plugin at all. Same this can be done by this:

kind: pipeline
name: default
steps:
  - name: integration testing
    image: python:3.11.7-bookworm
    privileged: true
    commands:
      - ./run_test.sh
    volumes:
      - name: docker
        path: /var/run/docker.sock

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

@rnorth
Copy link
Member

rnorth commented Nov 5, 2024

Sorry for the extensive delay - this repo is not under active maintenance.

As per #32 I'm proposing that this repository be formally archived; if you need to continue using it you're welcome to fork, but it's become unviable for me or the Testcontainers team to maintain.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants