-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
connection refused to Consul UI unless -client option is public address. #599
Comments
You need to configure the HTTP address to listen on a public IP. By default it uses loopback. The -client flag does this, but also changes the IP of all the listeners (RPC, HTTP, DNS). You can do more fine grained configuration with a configuration file however. |
That works perfectly; thanks! |
@petemounce Could you share exactly what you did to make it work? I am also having the same problem. |
@saulshanabrook I used the configuration file to set the http interface to listen on the NIC instead of the default loopback address. ...
"addresses" : {
"http": "10.10.10.257" // obviously made up ;)
}
... Here's the consul agent upstart task from my cloudformation: "/etc/init/consul.conf": {
"content": {
"Fn::Join": [
"",
[
"description \"Consul agent\"\n",
"\n",
"start on runlevel [2345]\n",
"stop on runlevel [!2345]\n",
"\n",
"respawn\n",
"\n",
"script\n",
" # Make sure to use all our CPUs, because Consul can block a scheduler thread\n",
" export GOMAXPROCS=`nproc`\n",
"\n",
" # Get the public IP\n",
" BIND=`ifconfig eth0 | grep \"inet addr\" | awk '{ print substr($2,6) }'`\n",
"\n",
" export CLUSTER_SIZE=$(aws autoscaling describe-auto-scaling-groups | jq -c -M -r '.AutoScalingGroups[] | {name: .AutoScalingGroupName, desired_capacity: .DesiredCapacity}' | grep je-",
{
"Ref": "FeatureName"
},
"-",
{
"Ref": "EnvironmentName"
},
"-",
{
"Ref": "Tenant"
},
".*ConsulCluster | jq -c -M -r '.desired_capacity' | tr -d \"\\n\")\n",
" exec /usr/local/bin/consul agent \\\n",
" -bootstrap-expect $CLUSTER_SIZE \\\n",
" -config-dir=\"/etc/consul.d\" \\\n",
" -bind=$BIND \\\n",
" >>/var/log/consul.log 2>&1\n",
"end script\n",
"\n"
]
]
}
}
...
"022_configure_http_api_interface": {
"command": "BIND=`ifconfig eth0 | grep \"inet addr\" | awk '{ print substr($2,6) }'` && sed -i \"s/http\\\": \\\"\\\"/http\\\": \\\"${BIND}\\\"/\" /etc/consul.d/consul.json"
},
|
@petemounce thank you! Would With it set up like that I still get this:
But works with
This is my config:
|
Yes, think so. My pleasure :-) Sent from my phone. Please excuse typos and brevity, but never text speak.
|
[root@localhost ~]# consul agent -h | grep client we can see : the default ip is 127.0.0.1 ,modify this val change client visit ip eg: consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul/ -ui-dir /root/software/consul-ui/ -client=192.168.23.154 |
Hello. I'm trying to solve similar task. Is it possible? Cause I tried different options with my consul.json config. But outside the machine http://10.3.0.1:8500/v1/kv/myKey can be opened. I checked I can open http://10.2.10.19:8500/v1/kv/myKey (which consul server ip). So is it possible to connect to consul client agent using HTTP API? |
I am running consul 0.4.1 in EC2, on Amazon Linux
ami-607bd917
(eu-west-1
,t2.micro
, naked; no yum updates), and I cannot reach the consul UI externally from the instance. My cluster bootstraps fine.$ curl http://10.10.10.98:8500/ui/dist/ curl: (7) Failed to connect to 10.10.10.98 port 8500: Connection refused $ curl http://127.0.0.1:8500/ui/dist/ # correct HTML response
I am using an upstart job like:
and
/etc/consul.d/consul.json
asI can work around this by, in my upstart, invoking
consul agent .... -client=$BIND ...
but then that forces me to specify the-rpc-addr=<external IP>
on eachconsul
command (in the server cluster, anyhow) thereafter; rather not do that since it complicates things a bit.I can also work around this by running another consul cluster of agents whose only job is to join the cluster and host the UI - but I'd rather not do that, since it seems like it shouldn't be necessary and will cost more in terms of $ and management.
Is there a way to make this work without my workarounds?
The text was updated successfully, but these errors were encountered: