-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Unreliable DNS during Container Builds #101
Comments
Are you using buildx? I was having this issue, but it seems to be resolved by setting |
I have been using buildx, yeah. I have tried using the |
I was dealing with basically the same issue--container builds that rely on internal resources failing to resolve dns--and the thing that finally fixed it in my case was to configure buildx with the internal dns hosts:
|
Even that is also incosistant, it works sometimes. Mostly doesn't. For some reason, it's using |
Following @henworth's example, I had to change it slightly to get it working: with:
buildkitd-config-inline: |
[dns]
nameservers=["..."]
|
Still same though @tpanum. mines looks like this - name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3.2.0
with:
buildkitd-config-inline: |
[dns]
nameservers=["100.78.xx.xx","100.78.xx.xx"] And errors out
|
We've also seen this same issue on
This way we had many issues resolving Tailscale hosts inside this container. Fortunately, we managed to fix it using the
Regards |
This also creates a scenarion where any action with
is unreliable |
I think I've discovered why this happened, to me at least. The GitHub actions runners are on
I have a subnet router that was advertising that same cidr. As soon as I connected Tailscale via actions, any docker based workload could no longer get to the DNS server inside the runner
|
@kdpuvvadi I had a similar issue and the solution was to set
|
This is not reliable at all. Hit or miss. switched to self-hosted runners and local dns worked always. |
I have a GitHub Actions pipeline that roughly process like so:
[1]: This package index is available within the Tailscale network and is discovered using DNS of an internal DNS server configured in Tailscale.
Step 2 occasionally fail due to DNS lookups for the package index failing, thus DNS resolving not working reliably.
The text was updated successfully, but these errors were encountered: