问题
I am trying to set up a vanilla Jboss (Wildfly-8.0.0.Final) in EC2, although I believe any application would have this problem.
On a vanilla ubuntu trusty VM in the default space, I unpack, and configureit to run on addr-any: 0.0.0.0.
At runtime, this is successfully resolved to the instance's local IP:
15:26:43,167 INFO [org.hornetq.jms.server] (ServerService Thread Pool -- 59) HQ121005: Invalid "host" value "0.0.0.0" detected for "http-connector" connector. Switching to "ip-123-45-67-8.us-my-zone.compute.internal". If this new address is incorrect please manually configure the connector to use the proper one.
Now, I kick off an AMI image of the same machine, inside a VPC. The VPC is set up with public IPs and public DNS. The routing table/security groups/etc are attached and configured such that it is possible to ssh to the new VPC instance using the public DNS. Kick off the jboss, and it can't connect to 0.0.0.0 :
16:28:47,603 WARN [org.hornetq.jms.server] (ServerService Thread Pool -- 58) HQ122017: Tried to correct invalid "host" value "0.0.0.0" for "http-connector" connector, but received an exception.: java.net.UnknownHostException: ip-123-45-67-8: ip-123-45-67-8
at java.net.InetAddress.getLocalHost(InetAddress.java:1473) [rt.jar:1.7.0_65]
at org.hornetq.jms.server.impl.JMSServerManagerImpl.correctInvalidNettyConnectorHost(JMSServerManagerImpl.java:1883) [hornetq-jms-server-2.4.1.Final.jar:]
at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateCFPOJO(JMSServerManagerImpl.java:1379) [hornetq-jms-server-2.4.1.Final.jar:]
at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateCF(JMSServerManagerImpl.java:1324) [hornetq-jms-server-2.4.1.Final.jar:]
at org.hornetq.jms.server.impl.JMSServerManagerImpl.access$1300(JMSServerManagerImpl.java:103) [hornetq-jms-server-2.4.1.Final.jar:]
at org.hornetq.jms.server.impl.JMSServerManagerImpl$5.runException(JMSServerManagerImpl.java:1187) [hornetq-jms-server-2.4.1.Final.jar:]
at org.hornetq.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1845) [hornetq-jms-server-2.4.1.Final.jar:]
at org.hornetq.jms.server.impl.JMSServerManagerImpl.createConnectionFactory(JMSServerManagerImpl.java:1173) [hornetq-jms-server-2.4.1.Final.jar:]
at org.jboss.as.messaging.jms.ConnectionFactoryService$1.run(ConnectionFactoryService.java:66) [wildfly-messaging-8.0.0.Final.jar:8.0.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
The work-around is to update the /etc/hosts file to include the hostname: Before /etc/hosts: 127.0.0.1 localhost
After /etc/hosts: 127.0.0.1 val-from-hostname-file localhost
What is different about running inside a VPC that the instance can find its hostname, but not successfully bind to it?
回答1:
This is most likely an issue with your VPC configuration.
The DHCP Options Set determines the domain name suffix your hosts are given via DHCP to use when qualifying unqualified hostnames, including their own, when they look them up. You'll see the result of this configuration in /etc/resolv.conf.
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.0.2.2
search ec2.internal
Here, ec2.internal is the default value for VPC in US-East-1. Other regions have different formats, but these are domains that exist only within your VPC for purposes of looking up internal hosts.
When an instance inside VPC (let's say 192.0.2.100) looks up its address from its hostname, it's going to look up ip-192-0-2-100.ec2.internal. This is a valid hostname according to the AWS-provided DNS servers, if you have DNS Resolution and DNS Hostnames enabled in the VPC configuration.
If you've configured your DHCP Options set to use your own example.com domain, then the hostname assigned to the instance (again, e.g. ip-192-0-2-100) has to be a valid hostname inside that domain, so ip-192-0-2-100.example.com must be a resolvable hostname, and needs to resolve to the correct address.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html
This isn't an issue in EC2-Classic because this layer of the infrastructure configuration can't be changed or disabled. Every EC2-classic instance can look up its own hostname against the internal *.internal domain that AWS provides, and get its own IP.
Another symptom of this misconfiguration issue is when you use sudo and see a sudo: unable to resolve host ip-x-x-x-x warning.
来源：https://stackoverflow.com/questions/26512723/unable-to-bind-to-0-0-0-0-inside-aws-vpc