Fix Runner DNS resolution

[mpass99]

Closes #490

The failing DNS resolution was caused by Nomad overwriting the DNS configuration of Docker and the CNI secure bridge. To set valid Nameservers, we have to configure the according Nomad options.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.12%. Comparing base (39d25d2) to head (27200e3).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #566      +/-   ##
==========================================
- Coverage   77.13%   77.12%   -0.02%     
==========================================
  Files          41       41              
  Lines        3490     3488       -2     
==========================================
- Hits         2692     2690       -2     
  Misses        586      586              
  Partials      212      212              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[MrSerth]

Many thanks for working on this fix!

To be honest, I have mixed feelings about this PR and the changes. At first, I was very surprised by the approach to fix the secure bridge: I thought (and confirmed) that a fix is also possible by just changing the secure-bridge.conflist. The required changes are shown in the details.

Details

"type": "bridge",
"bridge":"nomad-filtered",
// More options as usual...
"dns":{
    "nameservers":[
        "8.8.8.8",
        "8.8.4.4",
        "2001:4860:4860::8888",
        "2001:4860:4860::8844",
    ],
    "domain": "poseidon.internal", // Probably, can be omitted. It didn't have any effect
    "search": [
        "poseidon.internal"
    ]
}             

Can you please elaborate why you decided to use this mechanism or where you see the advantages / disadvantages?

I think, having everything in the secure-bridge.conflist might be beneficial to have everything in one place (Routing + DNS). Nevertheless, with the config option on Poseidon, we also get some further flexibility.

---

On a second thought and playing around with this PR, I got more in favour of your changes. I clearly see the benefits to extract the network config to settings, especially on my local machine (finally allowing me to tweak the nomad.network.mode setting, so that I can use another value and get network-enabled instances. And it works even without the CNI plugins, which is also great.

Maybe do both (this PR and the secure-bridge.conflist)? Or is that bad, since we would need to update something in two locations?

[mpass99]

Can you please elaborate why you decided to use this mechanism

Thanks for bringing that up! After double-checking, it seems the main reason was a deployment issue.
I deployed a similar DNS configuration in the secure-bridge.conflist, but it didn't apply. Then I found the Nomad documentation defining exactly the observed behavior: "By default all task drivers will inherit DNS configuration from the client host. [...] if you are using a mode="cni/*, these values will override any DNS configuration the CNI plugins return". Therefore, the case was clear to me.

At this point, having both options available again, I would put the DNS configuration back to our Deployment repository underlining your argument that we have all the other Routing and DNS configurations also there.

Maybe do both (this PR and the secure-bridge.conflist)? Or is that bad, since we would need to update something in two locations?

Let's use the secure-bridge.conflist to configure the DNS. If you like this "feature" we might keep it but only configure nomad.network.mode in our deployment configuration, so we use the DNS options defined in the secure-bridge.conflist.

[MrSerth]

Alright, I agree with your proposal. And yes, I would actually like to continue having this feature, since it allows me to run the network part on my operating system, too :)

[MrSerth]

These code changes work like a charm, just tested these locally ✅