Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to using hyphens as a separator in hostnames #229

Open
kung-foo opened this issue May 23, 2014 · 50 comments
Open

Switch to using hyphens as a separator in hostnames #229

kung-foo opened this issue May 23, 2014 · 50 comments

Comments

@kung-foo
Copy link

@kung-foo kung-foo commented May 23, 2014

The hostname format used by fig creates names that are not strictly valid.

Current pseudo-code:

name = '_'.join([project, container, instance_num])

This generates names like cluster_hadoop_1. Underscores are not valid (though in practice most components are tolerant of this).

Valid names should match [a-zA-Z0-9\-]+.

I came across this error when trying to test out some hadoop/hdfs containers and hadoop bailed with an exception saying that hdfs://flume_hadoop_1/ was not valid URI (even though it was in /etc/hosts and ping flume_hadoop_1 worked just fine).

See: http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_host_names

Changing this to dashes is easy, but it would break existing configurations that depend on hard coded container names.

@kung-foo

This comment has been minimized.

Copy link
Author

@kung-foo kung-foo commented May 24, 2014

also see: moby/moby#5418

@danburkert

This comment has been minimized.

Copy link

@danburkert danburkert commented Jul 25, 2014

This is causing pain for me as well, in pretty much the exact same scenario (the hostname being parsed by Java's standard library URI parser). Is this a fig issue, or should it be fixed in docker?

@aanand

This comment has been minimized.

Copy link
Contributor

@aanand aanand commented Jul 25, 2014

Frustratingly, underscores are invalid in hostnames, and dashes are invalid in shell variable names. So if you can't name a Docker link without either breaking one of those or smushing everything together (e.g. hadoop1). Not ideal.

However, looks like moby/moby#6270 might fix this by sanitising environment variable names, in which case Fig can switch to dashes and everything will hopefully work:

web:
  links:
    - hadoop
$ fig run web cat /etc/hosts
...
172.17.0.42 hadoop-1
...

$ fig run web env
...
HADOOP_1_PORT=tcp://172.17.0.42:5432
HADOOP_1_PORT_5432_TCP=tcp://172.17.0.42:5432
HADOOP_1_PORT_5432_TCP_ADDR=172.17.0.42
...
@aanand

This comment has been minimized.

Copy link
Contributor

@aanand aanand commented Jul 25, 2014

#349 is also relevant.

@nubs

This comment has been minimized.

Copy link
Contributor

@nubs nubs commented Jul 26, 2014

Technically speaking, I don't believe that hyphens in shell variable names are strictly forbidden. You just can't access them in the normal way:

$ env foo-bar=baz bash
$ printenv foo-bar
baz
@bfirsh

This comment has been minimized.

Copy link
Contributor

@bfirsh bfirsh commented Jul 28, 2014

👍 switching to hyphens

@bfirsh bfirsh changed the title invalid hostnames Switch to using hyphens as a separator in hostnames Jul 28, 2014
@zeeraw

This comment has been minimized.

Copy link

@zeeraw zeeraw commented Aug 12, 2014

What about writing both hyphenated and underscored to the hosts file for now?

@aanand

This comment has been minimized.

Copy link
Contributor

@aanand aanand commented Aug 12, 2014

@zeeraw that would be out of fig's scope - a job for docker itself.

@bfirsh

This comment has been minimized.

Copy link
Contributor

@bfirsh bfirsh commented Dec 5, 2014

We can do this now that moby/moby#5418 has been fixed, right?

@jamshid

This comment has been minimized.

Copy link

@jamshid jamshid commented Dec 18, 2014

Ugh java's URI is so annoying. The single-value constructor does not throw an exception for underscores in the hostname.

// Error: java.net.URISyntaxException: Illegal character in hostname at index 10: http://foo_bar:9200/path?query=1
URI u1 = new URI("http", null, "foo_bar", 9200, "/path", "query=1", null);

// works fine:
URI u2 = new URI("http://foo_bar:9200/path?query=1");
@thaJeztah

This comment has been minimized.

Copy link
Member

@thaJeztah thaJeztah commented Dec 18, 2014

Will this also be used for the container names? If so, I think moby/moby#8961 should also be taken into account.

@dnephin

This comment has been minimized.

Copy link
Contributor

@dnephin dnephin commented Nov 13, 2015

We could add aliases for dashes when we implement #2312, keep both underscores and dashes for a release or two, then drop support for underscores in hostnames.

@susu

This comment has been minimized.

Copy link

@susu susu commented Jul 13, 2016

Same here, cannot run spark cluster with docker-compose. Showstopper
for docker-compose, falling back to "manual docker".

@aanand

This comment has been minimized.

Copy link
Contributor

@aanand aanand commented Jul 13, 2016

@susu Why is this a showstopper? The problem of underscores in hostnames is easily worked around, either with link aliases or by changing service names.

@susu

This comment has been minimized.

Copy link

@susu susu commented Jul 13, 2016

Nope, because spark somehow extracts the underscored hostname of docker
container (projectname_container_1.default_network), and try to use it
(which is an invalid hostname in URI). Anyway, falling back to version 1
"solved" the issue.
On Jul 13, 2016 6:52 PM, "Aanand Prasad" notifications@github.com wrote:

@susu https://github.com/susu Why is this a showstopper? The problem of
underscores in hostnames is easily worked around, either with link aliases
or by changing service names.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#229 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AA5B7o9ixPlutkGcoBwiBnp2N5EcqBszks5qVRfQgaJpZM4B9pLe
.

@aanand

This comment has been minimized.

Copy link
Contributor

@aanand aanand commented Jul 13, 2016

spark somehow extracts the underscored hostname of docker container (projectname_container_1.default_network), and try to use it

However it's doing that, that's the wrong thing to do. Is this an image you're using from the Hub, or did you build it yourself?

Switching back to version 1 is not a future-proof solution.

@gordontyler

This comment has been minimized.

Copy link

@gordontyler gordontyler commented Jul 14, 2016

@susu The workaround I used for this was to create a network so I could control the name:

docker network create spark

Use that as an external network in my (version 2) docker-compose.yml file:

networks:
  spark:
    external: true

Connect each service to that network:

services:
  spark-master:
    image: spark
    command: org.apache.spark.deploy.master.Master --host spark-master
    networks:
      - spark

And finally override the container name and hostname in the spark worker service:

  spark-worker:
    image: spark
    container_name: "spark-worker"
    hostname: "spark-worker"
    command: org.apache.spark.deploy.worker.Worker --host spark-worker spark://spark-master:7077
    networks:
      - spark
@gordontyler

This comment has been minimized.

Copy link

@gordontyler gordontyler commented Jul 14, 2016

P.S. I determined that the spark worker is using reverse DNS lookup on its IP address to get the DNS name to register with the master.

@susu

This comment has been minimized.

Copy link

@susu susu commented Jul 14, 2016

Thanks @gordontyler ! I didn't know I can override container and hostname! Already migrated to version 2 :)

@aanand I know version 1 is not future-proof, however at the moment I'm only creating a PoC with spark, so clean, production-grade solution is not a must-have :) But anyway, using @gordontyler 's solution, I can go forward with version 2! Thank you guys!

@laugimethods

This comment has been minimized.

Copy link

@laugimethods laugimethods commented Jul 21, 2016

FYI, that issue has also been raised in Docker Forum as Underscore in domain names.

In particular, I explain there where & why Spark (from version 1.6.x) doesn't allow underscores in hostnames.

// We identify hosts on which the block is cached with this prefix. Because this prefix contains
// underscores, which are not legal characters in hostnames, there should be no potential for
// confusion. See RFC 952 and RFC 1123 for information about the format of hostnames.

@dnephin

This comment has been minimized.

Copy link
Contributor

@dnephin dnephin commented Feb 22, 2017

Services within the stack should already be aliased to their service name (the name that appears in the docker-compose.yml), so you shouldn't need any other aliases. You can ignore the names with underscores.

@stevvooe

This comment has been minimized.

Copy link

@stevvooe stevvooe commented Feb 22, 2017

Services within the stack should already be aliased to their service name (the name that appears in the docker-compose.yml), so you shouldn't need any other aliases. You can ignore the names with underscores.

This is not how things are supposed to work. The names are supposed to be the DNS names. They aren't some field that should be mangled.

@dnephin

This comment has been minimized.

Copy link
Contributor

@dnephin dnephin commented Feb 22, 2017

That is how things are supposed to work for an "isolated environment". I should be able to launch a stack from a Compose file that has service names like web and db, and not worry about them conflicting with services from another project. Each service in that stack should be able to reference the other services with this short name (web or db).

When we have a server side stack, or namespace concept we can adjust how this works, but until then it is necessary to mangle.

@stevvooe

This comment has been minimized.

Copy link

@stevvooe stevvooe commented Feb 22, 2017

@dnephin We should have gated these features on namespaces. What is the impetus to do namespaces now that we have support backwards compatible name mangling? We end up having to support two things instead of one.

@mostolog

This comment has been minimized.

Copy link

@mostolog mostolog commented Feb 23, 2017

That is how things are supposed to work for an "isolated environment". I should be able to launch a stack from a Compose file that has service names like web and db, and not worry about them conflicting with services from another project. Each service in that stack should be able to reference the other services with this short name (web or db).

@dnephin I still have to test a few things before properly answering...but how is "changing from _ to -" in project name (ie: mystack_myservice to mystack-myservice, hence achieving compatibility) against your statement?

@mostolog

This comment has been minimized.

Copy link

@mostolog mostolog commented Jun 15, 2017

I would like to confirm containers can talk to each other using its "service name" (eg: myservice), but at this point hostnames are set to mystack_myservice.
@dnephin Still wondering what's the issue not to move away from underscores "_".

@gonvaled

This comment has been minimized.

Copy link

@gonvaled gonvaled commented May 7, 2018

What is the status of this feature? I still see my containers created with underscores, which causes unexpected problems, as described in detail here

@AizeLeOuf

This comment has been minimized.

Copy link

@AizeLeOuf AizeLeOuf commented May 14, 2018

Same here, and still no fix possible with scale feature.

@scottjs

This comment has been minimized.

Copy link

@scottjs scottjs commented Jul 9, 2018

This is causing massive headaches for me as well, any updates on this? Temporary workaround is to use the internal IP addresses instead of hostname but it's becoming frustrating for our development team.

@fabianotessarolo

This comment has been minimized.

Copy link

@fabianotessarolo fabianotessarolo commented Aug 10, 2018

+1

@aaron-kunde

This comment has been minimized.

Copy link

@aaron-kunde aaron-kunde commented Aug 24, 2018

One of the bigger problems with the underscore in hostnames, which is generated by docker stack is:

It doesn't work with the default configuration of Spring Boot.
Spring Boot uses Apache Tomcat as default, which itself cannot serve HTTP-Requests, when it is addressed by its fully qualified internal service name (<stack-name>_<service-name>). Only a switch to jetty, which seems to be more relaxed, fixed my problems.

A little suggestion: Why not use dots instead of underscore and so use `subdomains' to map services to stacks?

@Rushera

This comment has been minimized.

Copy link

@Rushera Rushera commented Oct 11, 2018

Django 2.1 also rejects http header like "Host: myapp_django" if the service name is myapp_django. It's hard to avoid.
Someone suggested to create different network for each stack, so you can access a service without stack name, like django. But I have services in different stacks communicating with each other, and I can't put them all in one stack.

@nkedel

This comment has been minimized.

Copy link

@nkedel nkedel commented Oct 13, 2018

I'm seeing the same problem. While Jetty is OK with inbound requests with a host name with underscores, it uses the Java URI library for outbound proxy requests and breaks if the hostname has an underscore.

Right now, I'm able to work around the problem with explicit aliases in say, external links, but it would definitely be a plus to be able to switch the separator to hyphens with an option in the environment or in the compose file.

@arshadm

This comment has been minimized.

Copy link

@arshadm arshadm commented Nov 25, 2018

Just came across this problem with spring cloud config and docker stack deploy on docker 18.09, the error is the following:

2018-11-25 12:37:21.566  INFO 1 --- [nio-8090-exec-2] o.apache.coyote.http11.Http11Processor   : The host [tskur-ci_tskur-svc-config:8090] is not valid
 Note: further occurrences of request parsing errors will be logged at DEBUG level.

java.lang.IllegalArgumentException: The character [_] is never valid in a domain name.
	at org.apache.tomcat.util.http.parser.HttpParser$DomainParseState.next(HttpParser.java:926) ~[tomcat-embed-core-9.0.12.jar!/:9.0.12]

Is anyone able to point me to a workaround?

@blackknight36

This comment has been minimized.

Copy link

@blackknight36 blackknight36 commented Jan 28, 2019

Just got bit by this today as well. Kibana and logstash absolutely will not allow connecting to host names with an underscore in them which means you are forced to use the host IP or workarounds such as creating a service name with a dash in it to force docker to deploy a valid service name.

An option to make docker use a dash character instead of underscores in service names would be very useful to avoid these types of problems.

@shin-

This comment has been minimized.

Copy link
Contributor

@shin- shin- commented Jan 29, 2019

@blackknight36 I would recommend using network aliases, which let you assign valid hostnames while still allowing you to use whatever service name you want.

@stale

This comment has been minimized.

Copy link

@stale stale bot commented Oct 9, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Oct 9, 2019
@teutat3s

This comment has been minimized.

Copy link

@teutat3s teutat3s commented Oct 12, 2019

Not stale at all, I'd say this is still unresolved? Consul DNS also doesn't like underscores in hostnames and complains... Is it possible to make this more flexible? Like letting the user change the seperator?

@stale

This comment has been minimized.

Copy link

@stale stale bot commented Oct 12, 2019

This issue has been automatically marked as not stale anymore due to the recent activity.

@stale stale bot removed the stale label Oct 12, 2019
@suthernfriend

This comment has been minimized.

Copy link

@suthernfriend suthernfriend commented Oct 23, 2019

just ran into a problem with logstash related to this.

can somebody at docker HQ at least make a decision?
shouldn't docker-compose comply with the relevant RFCs?

@wrmay

This comment has been minimized.

Copy link

@wrmay wrmay commented Nov 25, 2019

I am having this problem as well, related to Hazelcast. I can work around it using fixed container names without underscores but it precludes the use of the docker-compose scaling mechanism since the system assigned name is mystack_myservice_n.

@aki-k

This comment has been minimized.

Copy link

@aki-k aki-k commented Jan 25, 2020

389 directory server's admin console, 389-console, is not able to handle the underscores in container DNS names, but adding a network alias hostname with no underscores resolved that. I wasn't even able to complete the directory server configuration until adding the hostname aliases with no underscores.

I had to also use "StrictHostCheck = false" in the initial-setup.inf file and "/usr/sbin/setup-ds-admin.pl --silent --file=initial-setup.inf General.StrictHostCheck=false" when installing the directory server binaries, admin server binaries and the initial directory configuration. This was because Docker DNS is a can of worms regarding reverse DNS entries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.