Container IP address assignment?

Currently reading
Container IP address assignment?

1,817
758
NAS
DS220+ : DS1019+ : DS216+II : DS118 : DS120j : APC Back UPS ES 700 — Mac/iOS user
Hi,

After a restart my Postgres container decided to change its IP address. Don't know why!
Of course my other container that uses the database didn't react well to that and commits suicide every time it starts because it cannot connect.

I did a quick search for an easy way to restrict a container to an IP address but couldn't find anything simple.
Any suggestions or should I go down the rabbit hole?
 
117
21
NAS
DS918+, DS414j
Operating system
  1. Linux
  2. Windows
  3. other
Mobile operating system
  1. Android
If they're on the same network you could reference it by container name, an example I have is grafana which relies on my influxdb container:
Part of my compose:
Code:
  grafana:
    image: grafana/grafana
    container_name: grafana
    restart: always
    depends_on:
      - influxdb
 
1,817
758
NAS
DS220+ : DS1019+ : DS216+II : DS118 : DS120j : APC Back UPS ES 700 — Mac/iOS user
Thank you for your reply @Akira. Can I do anything via the Docker GUI?
 
1,817
758
NAS
DS220+ : DS1019+ : DS216+II : DS118 : DS120j : APC Back UPS ES 700 — Mac/iOS user
Thanks @Rusty

It's there already under the links tab and when I start the container it knows about the Postgres container and says that it depends on it and that "we've started it for you". Of course it tries and then stops.

Yet in the log it's trying to connect to a 172.17.0.5 while Postgres is running on 172.17.0.6.
I'm not sure if it was always like this or if something changed after the restart.
Also, it could be the other way around; that the container changed (where it tries to connect) while Postgres is the same.

Database connection failure: could not connect to server: Connection refused stdout Is the server running on host "172.17.0.5" and accepting stdout TCP/IP connections on port 5432?



For Postgress
"SecondaryIPAddresses": null, "IPAddress": "172.17.0.6", "IPAddress": "172.17.0.6",

And
database system is ready to accept connections

Also for Postgres
The container port is 5432
Local port is Auto
 

fredbert

Moderator
NAS Support
Subscriber
2,158
871
NAS
DS1520+, DS218+, DS215j
Router
  1. RT2600ac
  2. MR2200ac
Operating system
  1. macOS
Mobile operating system
  1. iOS
Regarding PostgreSQL container: if you always use 'postgres:latest' then when you update the container to the latest image you will always migrate through PostgreSQL version... minor and major.

Upgrading the minor versions seems to go without a problem but you will probably have to do some [major] housekeeping when moving major versions. This is what I experienced when ':latest' moved from v12 to v13 and my FreshRSS container refused to run with the updated DB: I had just updated the image, stopped the container, and done 'clear' to refresh to the new image. I should have paid more attention.

I managed to export the PostgreSQL container XML (or had an XML already exported) and changed the image tag from 'postgres:latest' to 'postgres:12' and did a reinstall of the container and reapplied the links within the FreshRSS container. That fixed it and it's been running fine since. But I should look into how to migrate the DB v12 to v13, if for no reason except to learn.
 
117
21
NAS
DS918+, DS414j
Operating system
  1. Linux
  2. Windows
  3. other
Mobile operating system
  1. Android
From my experience the local port shouldn't matter if it's a container communicating with another container directly. However, as Rusty says, you need to get that fixed.
 

Rusty

Moderator
NAS Support
3,416
1,014
www.blackvoid.club
NAS
DS718+, DS918+, 2x RS3614RPxs+
Router
  1. RT1900ac
  2. RT2600ac
  3. MR2200ac
Operating system
  1. macOS
Mobile operating system
  1. iOS
From my experience the local port shouldn't matter if it's a container communicating with another container directly. However, as Rusty says, you need to get that fixed.
Fair point indeed. But I did kind thought this will go in the direction of looking for lost Postgres on the LAN, so just wanted to point out the Auto port potential problem.
 
1,817
758
NAS
DS220+ : DS1019+ : DS216+II : DS118 : DS120j : APC Back UPS ES 700 — Mac/iOS user
From my experience the local port shouldn't matter if it's a container communicating with another container directly. However, as Rusty says, you need to get that fixed.
That's what I thought. I'm not using Postgres for anything else. The communication occurs container to container. But I understand @Rusty point.

I'll remove both containers and create everything again soon. Not sure why it happened. The new installation might experience the same problem after a restart. But I can't go hunting through the madness of all the variables. It must be a non-persistent variable that was set during installation and gone with the restart.

I intend to test the (hopefully successful) installation with a restart (after recording the basic settings) and if it happens again and I can't figure it out easily, I think I'll delete both containers for good and tell them to install this thing (Odoo) on a Windows 95 PC or something like that.

(I still need more Docker sessions with my shrink, the cookies are not enough) 🤣
-- post merged: --

Regarding PostgreSQL container: if you always use 'postgres:latest' then when you update the container to the latest image you will always migrate through PostgreSQL version... minor and major.

Speaking of that, here’s something I came across…
 
You must have accidently used the container ip while setting up grafana. Haven't met any service so far that replaced a declared hostnames or fqdns with its resolved ip..

Rule #1 for container to container communication: never, never ever use the container ip for container to container communication or host to container communication.

In custom networks , you can directly use the service name to access another container in the same network, as the build in dns server will provide service discovery for you. In the default bridged network there is no service discovery/dns, thus alias are used (actualy injected in /etc/hosts inside the container) for container resolution.
 
1,817
758
NAS
DS220+ : DS1019+ : DS216+II : DS118 : DS120j : APC Back UPS ES 700 — Mac/iOS user
I didn't say anything about grafana, I've never touched it in my life. I'm reporting what the logs say.
 
Last edited:
Seems I mixed Akira's grafana post into yours. Just replace "grafana" in my last post with "the container"

Question is what are you looking for:
- the reason why an alias turned into an ip, or
- or a way to assign a static ipv4 address to the container?

The later is possible, though in the last 7 years, I never used it, because usualy it is just a workaround for something else gone wrong.
It can be done from the cli (either docker run or docker-compose) or portainer.
 

fredbert

Moderator
NAS Support
Subscriber
2,158
871
NAS
DS1520+, DS218+, DS215j
Router
  1. RT2600ac
  2. MR2200ac
Operating system
  1. macOS
Mobile operating system
  1. iOS
Using the Docker GUI, so can't vouch for portainer, SSH command line, etc...

Something I noticed yesterday after upgrading my PostgrSQL container to the latest v12: download the latest v12 image; stop FreshRSS and PostgreSQL containers; 'clear' PostgreSQL container; start FreshRSS container, which also starts PostgreSQL.

The FreshRSS container wouldn't start, logged as:
Start container <FreshRSS container name> failed: {"message":"Cannot link to a non running container: /<PostgreSQL container name> AS /<FreshRSS container name>/<psql link name>"}.

None of the container names had changed, but the link was failing to be established. The updated PostgreSQL container was the same configuration, as was FreshRSS. As @one-eyed-king mentioned, the link information is loaded into a container's /etc/hosts file.

Trying a few things and what worked to get the FreshRSS container running was this...
  1. Edit the container configuration and completely remove the link entry. Save and exit the configuration.
  2. Edit the container configuration and re-add the link entry. Save and exit the configuration.
  3. Run the container.
It had to be the two steps of "remove, save+exit" and "add, save+exit" for this to work. The GUI data mustn't refresh its container ID/name if the name hasn't changed: it has to completely forget the container link and then new info will be used.

Maybe this was the issue I had when upgrading the PostgreSQL 'latest' from v12 to v13? I don't recall what the logs said.
 
An orphaned link would make much sense, since the information is directly injected into the container's /etc/hosts file. If there is a possibilities that these can go stale, then links are even shittier than I thought :eek:

Another reason to create custom container networks and use them with your containers.
 
1,817
758
NAS
DS220+ : DS1019+ : DS216+II : DS118 : DS120j : APC Back UPS ES 700 — Mac/iOS user
I've removed and recreated both containers and it's working as before (contained test data so no big deal for now). I will test it with a full restart next week and see.
On the site where I followed the installation instructions, there's someone with the same experience (in the comments).

New installation:
Odoo App container log
INFO ? odoo: database: [email protected]:5432

Postgres container
docker container inspect d9b3a1646ad6 | grep -i IPADDRESS "SecondaryIPAddresses": null, "IPAddress": "172.17.0.6", "IPAddress": "172.17.0.6",

Odoo app looks for the correct IP address now (unlike the one with the error above).
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Trending threads

Top