rancher: generated /etc/resolv.conf in containers not compatible with alpine:3.4

Rancher Version: 1.0.2 Docker Version: 1.11.2 OS and where are the hosts located? (cloud, bare metal, etc): Ubuntu 16.04 on digital ocean Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB) single node, internal DB Environment Type: (Cattle/Kubernetes/Swarm/Mesos) Cattle Steps to Reproduce:

  • Add a service with image = alpine:3.4, CMD = ping rancher-metadata.rancher.internal, using default for all other options.
  • Execute Shell from the container.
  • run ping rancher-metadata

Results: ping: bad address 'rancher-metadata'

Expected: pingable to rancher-metadata, similar to rancher-metadata.rancher.internal:

PING rancher-metadata.rancher.internal (169.254.169.250): 56 data bytes
64 bytes from 169.254.169.250: seq=0 ttl=64 time=0.220 ms
64 bytes from 169.254.169.250: seq=1 ttl=64 time=0.236 ms

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 9
  • Comments: 19 (2 by maintainers)

Commits related to this issue

Most upvoted comments

My workaround:

I manually set “internal.rancher” as a search domain for my services, and it is now the first search domain, with the ping now working.

It works by changing the configuration in Networking Tab of the UI, or including in your docker-compose file this:

alpine:
  image: alpine:3.4
  dns_search:
  - rancher.internal

Just my two cents …

It seems that it is still an issue with Alpine when services are in different stacks.

The problem seems to be that rancher’s dns is returning “name exists but has no RRs of the requested type” (RCODE=0, Success) instead of “name does not exist” (RCODE=3, NxDomain), for nonexistent names. Fixing this should solve all compatibility problems with musl libc/Alpine.

Tested with network-services: v0.2.0 and rancher/dns:v0.15.0 Able to ping rancher-metadata from within containers deployed with image = alpine:3.4 and command ping rancher-metadata.rancher.internal.

screen shot 2017-04-20 at 10 38 56 am

Was able to reproduce this issue with 1.2.4 rancher server which has network-services: v0.0.8 and rancher/dns:v0.13.0

screen shot 2017-04-20 at 10 40 33 am