support per-Run DNS options#3062
Conversation
tonistiigi
left a comment
tonistiigi
left a comment
There was a problem hiding this comment.
Add a capability for this and make sure it is set in client side https://github.com/moby/buildkit/blob/master/solver/pb/caps.go
vito
force-pushed
the
run-dns
branch
2 times, most recently
from
ffecd71 to
2e3ed0c
Compare
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
|
Capability added. |
| } | ||
| } | ||
|
|
||
| resolvConf, err := oci.GetResolvConf(ctx, w.root, w.idmap, dns) |
There was a problem hiding this comment.
It doesn't look like GetResolvConf is safe to be called like this. Looks like it does bunch of internal caching atm and can return a cached result for incorrect dns value.
There was a problem hiding this comment.
Oh, good catch, that makes things a bit trickier but I took a swing at it. Now it'll use a hashed filename derived from the DNS config.
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
vito
force-pushed
the
run-dns
branch
2 times, most recently
from
086fceb to
968affe
Compare
the cleanup is broken here since it'll be removed for any concurrent dynamic config. hmm. Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
cleanup isn't safe because many containers may require the same config, and we don't want it to be removed until they're _all_ done with it. so just let them stick around, since there probably won't be that many over time anyway (...right?) alternatively we could do what we do for /etc/hosts: make a new distinct file if alternative config is specified and clean it up after. however the range of resolv.conf values should be much more limited so I would guess there's more value in sharing a single file across all of them rather than creating and deleting them all the time. keeping this a separate commit so it's easy to revert if we want to do that anyway. Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
vito
force-pushed
the
run-dns
branch
2 times, most recently
from
6a6b096 to
81a1d8e
Compare
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
|
I don't need this anymore, but I'm happy to keep going if it seems worthwhile. Otherwise feel free to close. 🙂 I didn't really like the tight coupling this introduced between the client and the server, and I ended up finding a way to avoid host networking altogether. Now I just add the CNI |
|
Let's close this then until there is a case that actually needs it. Compared to the daemon config this also has different behavior concerning the build cache. |
builder: return error if a node fails to boot
2 participants
Adds support for configuring DNS on a per-Run basis rather than relying on a single global DNS config.
The existing global DNS config is still supported. When both are present the per-Run DNS config takes precedence.
My use case is related to #3044. I want to support running things either in the bridge network (+ custom DNS) or in the host network when needed.1 For this to work I need to be able to set the bridge DNS server only for things that use the bridge network and let things that run in the host network inherit the host-level DNS config.
I considered a few other options before landing on this. Writing this partly for my own memory:
dnsnameonly runsdnsmasqwhen needed.1.1.1.1) everything works fine, but I would rather not require the user to configure DNS; I would prefer to just have Buildkit inherit the host's/etc/resolv.conf. Relying on DNS failover also feels spooky.llb.Image, and this is much easier to support by running the registry in the host network since that's where the image puller runs. (Also using an address other thanlocalhost/127.0.0.1will require TLS.)Footnotes
Example: running a registry in Buildkit on
127.0.0.1:1234and using it for other Buildkit runs. I can't use a bridge network for this because Buildkit's image fetching runs in the host network and doesn't respect a custom DNS config, plus having a non-localhsot/127.0.0.1address requires TLS. ↩