I have two versions of pretty much the same container (based upon the same base image, doing much the same changes), the principal difference that I can see is that they are, being for different projects, pushed to different Docker registries.
One has always worked just fine. The other, whenever started up, gets an /etc/resolv.conf file the same as the host, whilst the other gets a Rancher specific one pointing at the Rancher DNS server. Clearly, the first one will fail at using Rancher’s service discovery.
Any ideas why /etc/resolv.conf might not be getting set in one of them?
It sounds like the first (with the host’s /etc/resolve) has been started using host mode networking.
If that is the case, you can still make use of the Rancher service discovery using this label in compose:
some_name:
labels:
io.rancher.container.dns: true
...
I’ve confirmed, it shows ‘managed’ in the network tab in the UI, and has the label io.rancher.container.network=true. I added the io.rancher.container.dns label as you suggested. Still no luck. There’s nothing obvious in the logs on the Rancher host, but inside the rancher/agent there’s lots going on, but I cannot yet interpret it - it seems something may be different about my new Docker registry.
…
I tracked it down to my private registry. Restarting it, and repushing my image seemed to have fixed it. Not sure exactly what was wrong though.
Hmmm, the io.rancher.container.network=true
label suggests this container has been started/run outside of Rancher which probably means the label I suggested simply won’t work. How are you bringing the container up?
I was doing it with rancher-compose - the same way as I was doing it with my other container (another version of the same app - Solr). But as I say, having restarted my Registry, that issue seems to have gone away. Now my issue is that I must push the image to the registry before running it on the boot2docker VM on which I created it. That’s really annoying, and now how it was on my other environment. Grrr.