Static IP for LetsEncrypt docker

[tkohhh]

How would I go about giving my LetsEncrypt docker a static IP address?  It's currently configured in bridge mode, and is assigned a 172.17.0 address automatically.  Of course this address can change as I add more dockers in bridge mode.  However, I need a static address so that I can reference from other dockers.  Specifically, the home assistant docker does not allow host names in configuration files, so an IP is needed.

 

Thanks for your help!

[Hoopster]

2 minutes ago, tkohhh said:

How would I go about giving my LetsEncrypt docker a static IP address?

Change the network type to a custom network.  Once you do that you can assign a static IP address to the container

 

 

You will probably have a br0 custom network.

 

br0.3 is a custom network I created with a VLAN for docker containers.

 

Be aware that on some systems a static IP address on docker containers on br0 causes macvlan call traces which will eventually lock up your server.  The solution seems to be to create a VLAN (as I did), or, for some, to assign static IP addresses on br1.

[tkohhh]

Thanks for taking the time to respond!

 

I don't want to do something that will only work for a while before locking up my server, so I don't think I can just change to a custom network and assign an IP.

I'd rather not go through the effort of creating a VLAN if there's another option.

So, I guess that leaves me with "assign static IP address on br1".

 

Can you explain more about what that means and how I would set it up?

[Hoopster]

1 hour ago, tkohhh said:

I don't want to do something that will only work for a while before locking up my server,

This does not happen to everyone.  You could try it and then check your syslog periodically for call traces.  It usually takes several call traces and several days for the server to lock up.  However, the presence of even one macvlan call trace is an indication your system may be susceptible to this issue.

 

Again, you may find that it is not a problem on your system.

 

Here is a forum post which details the problem and potential solutions.

 

1 hour ago, tkohhh said:

So, I guess that leaves me with "assign static IP address on br1".

br1 is the designation given to a second NIC in the server with bridging enabled.

 

 

If you have a second NIC in the server and it is enabled in unRAID with bridging, it will show up in the custom networks list in docker containers as br1 (and br2, br3, etc. for subsequent NICs).

 

I do not currently have an IP address assigned to my second NIC, so it does not show up, but, here is my docker network list:

 

 

br0 is the bridged eth0 on which I get call traces.  br0.3 is the VLAN I created following this guide which eliminated call traces for me and allowed me to set static IP addresses for docker containers on this custom network.

[tkohhh]

I see... currently my second NIC is bonded in an active_backup configuration.  So I would get rid of the bond, and then assign a new IP on my LAN subnet to the second NIC.  Then, I could use that interface to assign a static IP to the docker.

 

I will read up on the macvlan trace issue and see if I can make use of that simpler solution.

 

Thanks again for your help!

[Hoopster]

7 minutes ago, tkohhh said:

I will read up on the macvlan trace issue and see if I can make use of that simpler solution.

This is a weird issue with no way (so far) to determine why it occurs on some systems and not others. You may find it is not even an issue on your system.

 

Some get call traces on br0, but not br1; others get them on br1, but not br0; and a few get them on on both interfaces.  There were a couple of reports of call traces occurring even on VLANs, although that tends to be best solution for those who get call traces on br0/br1.

[tkohhh]

I'm reading through the thread now.  Kudos to you for all of your efforts on this issue... you clearly put a lot of work into it.

 

Ultimately I just really wish that whatever service that is assigning IP addresses for the Docker subnet would allow for reservations.  While dynamic is fine for most dockers, there are a few that definitely benefit from static IPs.

[Hoopster]

7 minutes ago, tkohhh said:

Ultimately I just really wish that whatever service that is assigning IP addresses for the Docker subnet would allow for reservations.

I got around that by not assigning a DHCP pool to br0.3 in unRAID Docker networks and by assigning a DHCP range in my router that is a different range than the addresses on the 192.168.3.x subnet that I want to use for docker containers.  That way, I can assign a static IP address to each docker and I never have to worry about unRAID/docker or the router trying to assign that same address elsewhere. 

 

 

In essence, each IP address is reserved for the docker container to which it is assigned.

[tkohhh]

Well, I just figured out something that I think will satisfy me for now.  I had noticed that the DHCP for the Docker subnet was assigning IPs alphabetically.  Bitwarden was getting 172.17.0.2, Duplicati 172.17.0.3, Grafana 172.17.0.4, etc.  I also noticed that you can drag Docker containers around on the Docker tab in Unraid.  So, I dragged my Letsencrypt container to the top of the list, and then disabled and reenabled Docker in the Unraid settings.  Sure enough, my Letsencrypt container now has 172.17.0.2.

 

Since I can control the sort order of the containers, I can effectively control the IP assignment.  I'll put the dockers that need a static IP at the top of the list, and I'll ensure that any new containers I add go to the end of the list.

[showstopper]

Sorry to necro but..

 

I have been looking at this for a few hours. I have a segregated network and would like swag (and bitwarden) in a seperate network, that i can allow access to. I now have this working but with one issue. I can not set swag to use 180 or 1443 if it is not on the 'proxynet' network. So it will only use 80 and 443. I can't see a way around this.

[tjb_altf4]

4 hours ago, showstopper said:

Sorry to necro but..

 

I have been looking at this for a few hours. I have a segregated network and would like swag (and bitwarden) in a seperate network, that i can allow access to. I now have this working but with one issue. I can not set swag to use 180 or 1443 if it is not on the 'proxynet' network. So it will only use 80 and 443. I can't see a way around this.

Once a container is on its own IP, you can't, and don't need to map ports, it just uses what the application uses natively.