I’ve been able to ssh into the instance that has my drone runner, and executed a build with the following […] This builds correctly and does not have any issues resolving debian.org. Can anybody offer some insight as to why this is happening
This is not quite an apples to apples comparison because it uses the default bridge network. Drone does not use the bridge network. Instead it creates a new user-defined network for each pipeline (similar to docker-compose). Docker also handles DNS differently for user-defined networks . The following commands more closely emulate how Drone is running your container:
$ docker network create my-network
$ docker run --network=my-network ...
You can probably even further isolate the problem and reproduce without any Drone-specific code. In the below example we launch the dind container which drops us into a shell, and we then run the docker build command manually.
Hey thanks so much for this hint! It sent me down a rabbit hole, and I found a few links that were related to my issue by searching for some of the keywords in your post. For posterity, and possibly others that come across this post:
Following your instructions on creating the network, I was able to recreate my issue. It’s definitely a DNS issue from a container inside a container. For context, I’m running this on an EC2 instance, and found this documentation on How can I avoid DNS resolutions failures with EC2 Linux.
I’m currently struggling against systemd and getting dnsmasq up and running, I will update if I’m able to successfully solve the issue!
a quick workaround may be to change the network mode to bridge or host. I believe this requires trusted mode enabled in your repository settings, however, there are some ongoing discussions to have a global setting to always attach docker|ecr|gcr to the bridge network which would not require trusted mode.