Request: Map the internal SQL IP address to something like my.sql.domain.tld
-
-
@nebulon said in Request: Map the internal SQL IP address to something like my.sql.domain.tld:
the mysql IP is actually mapped to mysql as the hostname.
That only works in a "docker specific" context a la:
docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mysql
-> 172.18.0.8we don't really see exposing the addons to the public as a big use-case, what is the purpose for you to require the internal mysql IP?
Okay, so I don't want or need it to be public. I just need internal SSH to be able to access the container via DNS since the IP address changes every restart it seems. Making my SQL Client fail to connect without doing a
docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mysql
to get the IP address after SSHing in every time.I checked
/etc/hosts
and/etc/resolv.conf
and neither of them could help. And neither canmysql.internal.docker
which I was hoping would work. So I have to find and change this IP address all the time. -
Thinking about it, maybe @girish might have an answer for me. He taught me the tunneling technique that it appears all SQL Clients have that I just never knew about - last fall: https://forum.cloudron.io/post/13959
So maybe, Girish, do you have a solution that doesn't involve me manually changing the IP address of the "Internal MySQL Host" in my Remote SQL client every time
mysql
gets a new IP address (often)? -
Good request. The only way I can think of is to give static IPs to all the addon containers. This is entirely doable and we haven't had a reason to hard code IPs so far. I will let this sit a bit to understand the implications of hardcoding the IPs.
-
from here - save me swearing at DBeaver periodically.
-
@girish said in Request: Map the internal SQL IP address to something like my.sql.domain.tld:
Good request. The only way I can think of is to give static IPs to all the addon containers. This is entirely doable and we haven't had a reason to hard code IPs so far. I will let this sit a bit to understand the implications of hardcoding the IPs.
Perhaps hardcoding isn't necessary, but simply using an internal DNS mapping, internal resolver for known service containers like you have in docker
OR
If you do hardcode it, use xip.io as explained here
https://forum.cloudron.io/topic/3574/xip-io-access-any-dev-app-via-internal-ip-using-a-magic-domainAlternatively, see here:
https://sslip.io/which includes a noteworthy mention of LocalTLS
-
Not 100% sure but I don't think the DNS resolution will work from inside the SSH tunnel. For example, you cannot add an entry in /etc/hosts (on Cloudron server) and don't think the connection will pick that up.
-
@Lonkle The internal IP addresses are now hardcoded in 7.4 - https://docs.cloudron.io/networking/#internal-network for exactly this reason.