Recommended Posts

Hi everybody,

 

I was testing FreeNAS and I found that you are able to assign IPs to the docker containers.

 

I am wondering if it is possible to assign an IP within my network to the container in XPEnology instead of it always running on the same IP as the NAS but with a different port.

Share this post


Link to post
Share on other sites
Posted (edited)

Yes it is, I just did this.... 
 

I couldn't figure out how to do it with the default bridge, so I made a new one and moved all of my containers to it:

1. Open PuTTY or a terminal app (ssh) to your NAS..  (make sure SSH/Terminal is turned on under Control Panel/Terminal&SNMP/Enable SSH Service (I set a custom port)
2. Sign in SSH as an admin user
3. type sudo su for superuser privileges (reenter password)

4. type (without quotes) "docker network create —driver bridge —subnet=172.18.0.0/16 —gateway 172.18.0.1 bridgename" <enter>

5. type (without quotes) "docker network connect --ip 172.18.0.2 bridgename containername

6. Type (without quotes) "docker inspect containername" and look through the config... Now instead of a 0.0.0.0 address, you should see the IP you assigned.

Now that I think about it, I may have been able to just type "docker network connect --ip 172.17.0.2 bridge Camil/veryngix" (examples) and it may have assigned to the existing  bridge... I just had that AHA moment after writing this out.....

 

 

edit: I use home bridge and sabnzbd in my setup... they kept trading IP's during any reboot event... now SAB stays on it's ip and docker on its own.. I've installed other packages and let them connect DHCP, and they get assigned IP's into the original bridge like normal... I them move them if I want to... I've been too lazy/busy to simply it down to a single bridge.

 

Edited by Bucket

Share this post


Link to post
Share on other sites
Posted (edited)
On 3/2/2019 at 8:06 AM, PREngineer said:

I was testing FreeNAS and I found that you are able to assign IPs to the docker containers.

 

The reason is quite easy: every docker container is started in its own isolated vm. What you see is the ip of the vm running the docker engine that is running the container.

You could do the same with HVV and minimal docker vms- though, is it realy worth it?!

 

On 3/13/2019 at 9:16 PM, Bucket said:

Yes it is, I just did this.... 
 

I couldn't figure out how to do it with the default bridge, so I made a new one and moved all of my containers to it:

1. Open PuTTY or a terminal app (ssh) to your NAS..  (make sure SSH/Terminal is turned on under Control Panel/Terminal&SNMP/Enable SSH Service (I set a custom port)
2. Sign in SSH as an admin user
3. type sudo su for superuser privileges (reenter password)

4. type (without quotes) "docker network create —driver bridge —subnet=172.18.0.0/16 —gateway 172.18.0.1 bridgename" <enter>

5. type (without quotes) "docker network connect --ip 172.18.0.2 bridgename containername

6. Type (without quotes) "docker inspect containername" and look through the config... Now instead of a 0.0.0.0 address, you should see the IP you assigned.

Now that I think about it, I may have been able to just type "docker network connect --ip 172.17.0.2 bridge Camil/veryngix" (examples) and it may have assigned to the existing  bridge... I just had that AHA moment after writing this out.....

 

 

edit: I use home bridge and sabnzbd in my setup... they kept trading IP's during any reboot event... now SAB stays on it's ip and docker on its own.. I've installed other packages and let them connect DHCP, and they get assigned IP's into the original bridge like normal... I them move them if I want to... I've been too lazy/busy to simply it down to a single bridge.

 

 

It is neither supposed to access another container from another container by its ip. They should be access by their name or network alias.

Nor is it supposed to access a container from the lan by its ip. This is where port mappings come into play - or if you like it fency and complicated macvlan.

 

Heck, you could even add your Synolgy as the gateway to the bridged network in your router and be happy.. BUT is definitly not how it is intended.

Just because things can be done, doesn't mean they should be done. There is a reason why some succesful patterns emerge and some approaches become antipatterns...

Edited by haydibe

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.