1 Reply Latest reply on Nov 19, 2019 3:32 PM by detroit_doc

Wildfly 17 Docker issue related to hostname

detroit_doc Nov 19, 2019 2:45 PM

Short version - Wildfly under docker doesn't set it's jboss.host.name property correctly which causes it to break.

Long version -

I'm just trying to get Wildfly up in a Docker image. As a baseline I created an AWS EC2 image with CentOS. I installed Java 11 and Wildfly 17. I startup Wildfly by running standalone.sh. I'm able to get to the Wildfly welcome page successfully at http://localhost:8080.

I create a docker image that starts with CentOS. The Dockerfile uses the same exact commands I used when building my EC2 image to install Java 1 and Wildfly 17. I set the CMD to start Wildfly the same way I was starting it on my EC2 instance (running standalone.sh).

In the Docker container I'm getting this error...

2019-11-19 18:44:52,316 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 73) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "undertow")]) - failure description: "WFLYCTL0113: '' is an invalid value for parameter instance-id. Values must have a minimum length of 1 characters"

I went through the logs on my EC2 instance and compared them line for line with the logs from the docker container. What I noticed was at the beginning of the logs where it outputs the system properties the Docker container has this:

jboss.host.name =

Where my EC2 instance had the hostname specified, similar to this...

jboss.host.name = some_short_hostname

I think that jboss.host.name is ultimately used to set jboss.node.name, jboss.qualified.host.name and ultimately jboss.server.name. I suspected that is ultimate used as the "instance-id" when undertow is started and probably causing my problem. I proved this out by changing standalone.xml to set the server name in my docker image like this....

And that resolved the issue. However, that's not ideal and I'd really like to get to the bottom of why Wildfly cannot detect the hostname in a running docker container. Comparing my Docker container to my EC2 instance I checked that...

/etc/hostname - On the EC2 instance it was the fully qualified domain name. On the docker container it's the container ID (not fully qualified)
HOSTNAME environmental variable - it's set on both the EC2 instance and on the docker container
hostname command (which uses gethostname()) - On both the EC2 instance and the docker container it returns the hostname
Java's InetAddress.getLocalHost() - Thinking maybe Wildfly is using this, I wrote a little class and tested it in both environments. In both environments it's returning the hostname.

So the question is, why isn't wildfly setting the jboss.host.name property under Docker? Any clues or ideas what else I could possibly look at?

Thanks!

Doc

1. Re: Wildfly 17 Docker issue related to hostname

detroit_doc Nov 19, 2019 3:32 PM (in response to detroit_doc)

OK go figure, after 4 days of banging my head against the wall on this one I finally post the question and then figure it out.

First it appears that Wildfly is using the HOSTNAME environmental variable to set jboss.host.name. If that's not set, Wildfly fails with this very unfortunately error message that gives you no clue that it's related to the HOSTNAME variable not being set...
2019-11-19 18:44:52,316 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 73) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "undertow")]) - failure description: "WFLYCTL0113: '' is an invalid value for parameter instance-id. Values must have a minimum length of 1 characters"

Even though it appeared to me like the HOSTNAME environmental variable was set in my docker container, I decided to change the command in my Dockerfile to write out all the environmental variable just before running standalone.sh so I could confirm if it was set at that point:
CMD su -s /bin/bash - wildfly -c "set > /tmp/set.out 2>&1 && /opt/wildfly/bin/standalone.sh"

That showed me at the time the container starts up and runs this command that HOSTNAME was not set.   HOSTNAME is typically set in /etc/profile.   In the CentOS image it's set like this...
HOSTNAME=`/usr/bin/hostname 2>/dev/null`

The problem was that in the base CentOS image I used to build the Docker image, /usr/bin/hostname was not included. So that explains why HOSTNAME wasn't being set in /etc/profile

What I cannot explain is why when I connect to my container like this...
docker exec -it <container_id> /bin/bash

And then check HOSTNAME it's set.
[root@e20a04a50658 etc]# set | grep HOSTNAME
HOSTNAME=e20a04a50658

That's what threw me off the trail.   I cannot figure out how it's getting set when I connect to the container. /etc/profile can't set it because /usr/bin/hostname is missing. /etc/bashrc isn't setting it.   /root/.bashrc isn't setting it. /root/.bash_profile isn't setting it.

Anyway the easy fix was to add /usr/bin/hostname to the docker image and everything works correctly.   I just wanted to share in case anyone else gets burned by this one.

Doc
Actions