yugabyte-db
yugabyte-db copied to clipboard
[yugabyted] --advertise_address=0.0.0.0 not change yugabyted.conf inside docker
Jira Link: DB-13177
Description
I'm using below docker-compose config to run yugabyte, it seems --advertise_address=0.0.0.0 not working on version 2.23.0.0-b710 and the advertise_address field inside yugabyted.conf still 127.0.0.1 but when I down-grade to version 2.19.3.0-b140 it work without problem.
services:
yugabyte:
image: yugabytedb/yugabyte:latest
command: ["/home/yugabyte/bin/yugabyted",
"start",
"--advertise_address=0.0.0.0",
"--base_dir=/home/yugabyte/yb_data",
"--background=false",
"--ysql_enable_auth=true",
"--use_cassandra_authentication=true"]
ports:
- "7000:7000"
- "9000:9000"
- "5433:5433"
- "9042:9042"
volumes:
- yb-data:/home/yugabyte/yb_data
Warning: Please confirm that this issue does not contain any sensitive information
- [X] I confirm this issue does not contain any sensitive information.
Can you replicate this with a fresh start? Maybe it's a bad upgrade from 2.19 -> 2.23 (upgrades aren't supported on these versions)
I can change the advertise address usually (I don't use 127.0.0.1)
I did fresh start multiple time by deleting container and volume but still having same problem
Looks like it was changed in this issue/commit:
https://github.com/yugabyte/yugabyte-db/issues/18580
https://github.com/yugabyte/yugabyte-db/commit/cade0a8688fea889f1595bfa0a15d61124849f0d
cc @FranckPachot what ip should they use in this scenario?
Hey @zeinali-ali, for Docker, you can remove --advertise_address=0.0.0.0. Without it, Docker listens to the hostname interface, which is the correct one to be exposed by ports. If you run ysqlsh within the container, then set PGHOST=$(hostname).
Before this commit, 0.0.0.0 listened to all interfaces, which should be the correct behavior. However, because the UI also uses this value, it has been replaced with listening to localhost only.
This works and if want to use FQDN then uncomment the hostname. The container_name also registered in Docker internal DNS.
services:
yugabyte:
image: yugabytedb/yugabyte:latest
restart: unless-stopped
container_name: yugabyte
#hostname: yugabyte.company.com
ports:
- 7000:7000
- 9000:9000
- 15433:15433
- 5433:5433
- 9042:9042
command: ["/home/yugabyte/bin/yugabyted", "start", "--base_dir=/home/yugabyte/yb_data", "--advertise_address=yugabyte", "--background=false"]
volumes:
- ./data:/home/yugabyte/yb_data
@alberk8 Thanks, that's the correct way. We need to --advertise_address with the hostname (and not the IP address which is the default if we don't set it explicitly) so that YugabyteDB identifies the nodes by their hostnames rather than the IP (which can change when re-restarting containers)
Guys thanks for help, but sometime(s) we need access to db out of docker by exporting port(s), without --advertise_address=0.0.0.0 I'm not able to access to db out of docker network with a local IP like 192.168.10.100
Guys thanks for help, but sometime(s) we need access to db out of docker by exporting port(s), without
--advertise_address=0.0.0.0I'm not able to access to db out of docker network with a local IP like 192.168.10.100
Docker port mapping should work with --advertise_address=$(hostname) because it maps works the container interface, not localhost. I use that in my yb-compose and expose all ports to the host.
@zeinali-ali were you able to find a workaround for this?
On 2.19.3.0-b140:
- When I run with
--advertise_address=0.0.0.0, the 15433 UI does not show up, but the 7000 and 9000 UIs work, and I can connect to the db via pgadmin. - When I run with
--advertise_address=$(hostname), I can't connect to the UI on 7000, 9000, or 15433, but I can connect to the db via pgadmin
On latest:
- When I run with
--advertise_address=0.0.0.0, I can't connect to the UI on 7000, 9000, or 15433, or via pgadmin - When I run with
--advertise_address=$(hostname), I can't connect to the UI on 7000, 9000, or 15433, but I can connect to the db via pgadmin
Ultimately, I would like to be able to connect to the database and view all the UIs from outside the docker container, or another docker container.
@lukedukeus no on latest I even unable to connect to db using localhost outside the docker