Update containers with custom network fails

[michielvv]

Hi all!

 

First of all: unraid rules. I enjoy using it every day and most 'challenges' I solve myself (and learn more tech as a bonus). Not so this one. I have setup gluetunvpn for a vpn connection. Then, I have configured a couple of containers to use the gluetunvpn network, so that all traffic will only flow through the gluetunvpn connection (ie. through the actual VPN connection).

 

I have two challenges:

1) When i update the gluetunvpn container, the container:gluetunvpn networks used by the other containers become invalid. As a result, those other containers get stuck in a restart loop. I can understand that, as the container ID of gluetunvpn will change (hence, I assume, so does the network reference for each of the containers).

2) When i update any of the other containers that use the container:gluetunvpn they fail to restart, because by default there is a port mapping implemented, meant to be used in bridge/host network mode, but not in the case of container:gluetunvpn it seems.

 

This is part of my setup:

 

 

Three questions:

a) I may not use the right implementation of networks to get what i need? is this the case and if so, what would be the preferred way?

b) how to update gluetunvpn without getting the other containers in a restart loop?

c) how to update the other containers without port mapping (ie. this is what breaks restarting the updated container, it seems)?

 

Most grateful for your help!

[michielvv]

any thoughts?

[JonathanM]

What happens if you stop all the containers in that group, update them, then restart them in the correct order?

[michielvv]

Thanks for taking the time to debug this one!

 

If i do what you suggest, it does solve the problem of the network restart loop (question b) indeed. The problem i do not solve is question c : how to update the other containers without port mapping (ie. this is what breaks restarting the updated container, it seems)? If i update the container, it will update, but fail to restart (due to the default port mapping). I have to remove the orphaned docker and reinstall the app from the docker templates section. There should be a way to update the container without the default port mapping....?

[bonienl]

When you update the vpn container, it becomes a new container with a new ID and new network ID (though the name stays the same).

Hence it is required to update the other containers which use this vpn container, to make them associate with the new network ID.

You need to do the container update by changing the current network assignment of the container and reassign the vpn container again as network, then save the change.

 

[michielvv]

Thanks again for the help. Restarting of containers is then clear. The only challenge remaining is installing an update, which seems to apply the default template (with port mapping) rather than the one installed (without port mapping). Any clue how to solve that?

[michielvv]

Solved all of this: bottom line was that i implemented the wrong way of getting dockers to use the vpn docker's network instead of their own:

1. I made a custom network via the command line pointing to the VPN docker

2. in each of the docker's pull down lists I selected this network to use.

 

This causes problems when updating (custom network does not seem to be refreshed with the new docker ID of the VPN docker) and portmapping problems somehow.

 

Instead, I should've done the following:

1. for each docker, set network to 'none'

2. for each docker, add extra parameter "--net=container:[your vpn dockername - only lowercase allowed!!!]"

 

And bingo: updating the vpn dockers refreshes the relying dockers automatically and portmapping is transparently working without errors. super!