-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in 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/[email protected]
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
|
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: