It currently resolves containers under two name <container name>.docker and <container id>.docker.
This issue is a summary of discussions on Gitter.im Saturday between @danquah, @nlf and @arnested.
Invalid characters
DNS only allows [A-Za-z0-9-] in domain names (further restrictions apply, i.e. not starting with dash) whereas Docker also allows underscore and dot.
Docker Compose defaults to generating container names on the form <project>_<service>_<container number>.
This result is that 2.0.0-beta8 can expose invalid domain names (containing underscore). The builtin DNS server will resolve the domain names even if it contains underscores and most browsers will work with the invalid domain names as well so for a start beta8 can still be used.
We should fix this though to only do valid domain names to not break other tools or future browser version. This could be solved by substituting underscore with a dash. We should think about how to ensure the domain names to be unique names (use case: a container named my_container and one named my-container).
Other possibilities for domain names
Besides <container name>.docker and <container id>.docker some other mechanisms for generating domain names could be considered. A mix of several of the proposals could be used.
Hostname and domainname
A Docker container has a hostname and a domainname.
I have no idea how common it is to use them.
If it make sense to use them we should consider whether to use the domainname or use .docker instead. The resolver on macOS is only configured to lookup .docker in DLite (by default). It could also be <hostname>.<domainname>.docker.
Docker Compose
Docker Compose is in widespread use as mentioned above by default generates container names of the form <project>_<service>_<container number>.
It could make sense to generate DNS names as this (giving nice domain name hierarchies):
<service>-<container number>.<project>.docker and
<service>.<project>.docker (when scaling a docker-compose service to more than one instance and providing an A record for each of these containers under this name we get ourselves a DNS round robin load balancer).
I have use this approach in my homegrown solution until now and it works very well.
They lookup the domain name in an environment variable on the container (VIRTUAL_HOST). The variable can hold a comma separated list of fully qualified domain names.
Fully qualified domain names still poses a problem because macOS is still just configured to resolve .docker in DLite.
The possibility to have more than one domain name (for virtual hosts) is very useful though and cannot be addressed by the other solutions.
Release 2.0.0-beta8 has a builtin DNS server.
It currently resolves containers under two name
<container name>.dockerand<container id>.docker.This issue is a summary of discussions on Gitter.im Saturday between @danquah, @nlf and @arnested.
Invalid characters
DNS only allows
[A-Za-z0-9-]in domain names (further restrictions apply, i.e. not starting with dash) whereas Docker also allows underscore and dot.Docker Compose defaults to generating container names on the form
<project>_<service>_<container number>.This result is that 2.0.0-beta8 can expose invalid domain names (containing underscore). The builtin DNS server will resolve the domain names even if it contains underscores and most browsers will work with the invalid domain names as well so for a start beta8 can still be used.
We should fix this though to only do valid domain names to not break other tools or future browser version. This could be solved by substituting underscore with a dash. We should think about how to ensure the domain names to be unique names (use case: a container named
my_containerand one namedmy-container).Other possibilities for domain names
Besides
<container name>.dockerand<container id>.dockersome other mechanisms for generating domain names could be considered. A mix of several of the proposals could be used.Hostname and domainname
A Docker container has a hostname and a domainname.
I have no idea how common it is to use them.
If it make sense to use them we should consider whether to use the domainname or use
.dockerinstead. The resolver on macOS is only configured to lookup.dockerin DLite (by default). It could also be<hostname>.<domainname>.docker.Docker Compose
Docker Compose is in widespread use as mentioned above by default generates container names of the form
<project>_<service>_<container number>.It could make sense to generate DNS names as this (giving nice domain name hierarchies):
<service>-<container number>.<project>.dockerand<service>.<project>.docker(when scaling a docker-compose service to more than one instance and providing anArecord for each of these containers under this name we get ourselves a DNS round robin load balancer).I have use this approach in my homegrown solution until now and it works very well.
Docker-gen and friends
Another possibility is to use the approach used by docker-gen, nginx-proxy, caddy-proxy, and others.
They lookup the domain name in an environment variable on the container (
VIRTUAL_HOST). The variable can hold a comma separated list of fully qualified domain names.Fully qualified domain names still poses a problem because macOS is still just configured to resolve
.dockerin DLite.The possibility to have more than one domain name (for virtual hosts) is very useful though and cannot be addressed by the other solutions.