`network_mode: host` Results in Service not Found in DNS

Drone Support
1

Drone CI version: 0.8.x running in GKE, i.e. Kubernetes
I don’t have access to Drone CI logs.

I want to use Toxiproxy (github.com/Shopify/toxiproxy) for disruptive testing in Drone CI. My services part of the .drone.yml:

services:
  toxiproxy:
    image: shopify/toxiproxy:2.0.0
    network_mode: host
    when:
      event: [push, tag]

The above service successfully starts with the below log message:

time="2019-02-13T17:03:22Z" level="info" msg="API HTTP server starting" host="0.0.0.0" port="8474" version="2.0.0"

Note: newer versions of shopify/toxiproxy image fail to start with the below error message:

Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/go/bin/toxiproxy\": stat /go/bin/toxiproxy: no such file or directory": unknown

That’s why I’m using image shopify/toxiproxy:2.0.0.

In test I want firstly configure a proxy for Redis connection via Toxiproxy API. The code excerpt in Golang:

toxiClient = toxiproxy.NewClient(toxiHost + ":" + toxiPort)
_, err := toxiClient.Populate([]toxiproxy.Proxy{{
    Name:     "redis",
    Listen:   toxiHost + ":" + redisToxiProxyPortNumber,
    Upstream: redisUpstream,
}})
if err != nil {
    return err
}

But the above code fails with the below error message:

Get http://toxiproxy:8474/proxies/redis: dial tcp: lookup toxiproxy on 127.0.0.11:53: no such host

The issue is that when the toxiproxy service uses the network_mode: host it cannot be looked up in DNS.
When the toxiproxy service does not use network_mode: host it’s successfully looked up in DNS, but it does not have access to host network in order to dynamically open ports for listening on the host.

So, IMHO, the fact that a service that is using network_mode: host cannot be looked up in DNS is a bug.

Please, let me know whether you agree that the above described issue is a bug. I’ll appropriate if you elaborate whether the bug is in Drone CI or in Docker or somewhere else.

2

Networking issues on Kubernetes is a known problem. Drone creates user-defined networks which, depending on your configuration, may not play nicely with Kubernetes when it comes to DNS resolution. Whether this is a bug with Docker or Kubernertes, I cannot say.

However, this is precisely why we created the native Kubernetes runtime:
https://blog.drone.io/drone-goes-kubernetes-native/

If you are using Drone 1.0 you should be using the native Kubernetes runtime (you should not be using agents). If you are using Drone 0.8 and you experience DNS issues caused by user-defined networks, you should consider moving your agents outside of Kubernetes.

3

Thank you very much for the response.

I’ll find out more about the setup and configuration settings that are being used in the issue I’ve described.