Set docker container network via another container

[tankertux]

I have a use case where I want 2 containers to use the network of a third container. I am on an unRaid trial and am attempting to recreate my docker compose setup via the unRaid interface. I have two deluge containers (network_mode: "service:vpn") that connect through a vpn container (named "vpn" in compose).

 

So far, I have used binhex/delugevpn to get a deluge+vpn setup. I would like to start a second container (binhex/deluge or linuxserver/deluge) that uses the initial containers' network. How can I achieve this via unRaid? 

[tankertux]

I would like to add that the reason I am attempting this setup is that Private Internet Access.com has a limit on devices. By having both containers connect to the internet via a single VPN connection, I get protection for both using a single device while partitioning which downloaders specific users can see/use. I think that if Deluge had better user management, I would not need anything beyond a single delugevpn container.

[tankertux]

I ended up achieving my setup using docker-compose from the command line, using a slimmed down version from my CentOS server. I'm surprised that unRaid does not facilitate container network mode as documented in the official Docker documentation.  

 

As it stands right now, I have the functionality I need, but unRaid informs me that there is always an "update ready" when there is not. 

 

I have also yet to experience the helpful community that everyone seems to tout as a benefit of unRaid over a comparable free solution like SnapRaid + mergerfs or FreeNAS. 

[ken-ji]

well if you have been looking around, you must have missed that you can to specify the really advanced network bits and bobs via the extra parameters field in the template.

so in your case, probably

--network vpn

with the VPN container being named vpn

[BRiT]

In the latest version (RC?) of unraid you can also specify boot order of docker containers. I am unsure ifthere are VM boot orders too. Not certain which category boots first, dockers or vms.

[tankertux]

@ken-jiThank you, I did miss that I could specify extra parameters in the template.  I've just now found binhex' template repository on Github that I can use as a reference.  The XML schema for the templates does not seem well documented (here is the most comprehensive reference I could find).

 

It is ambiguous that the extra params (--network="container:vpn") would override the default <networking><mode>container:vpn</mode></networking> section. I attempted the latter solution in a template and failed to get it working, so I'll give the extra parameters a try.

 

@BRiT Thanks for that, boot order was not something I had considered yet!  I found the Docker Autostart manager on CA

Edited May 6, 2018 by tankertux

[Squid]

Docker containers start first, then VM's

 

While the startup selection in the docker page is a plus, considering that a startup order of A,B,C vs a startup order of B,C,A doesn't make a ton of difference since as soon as container B is started, the next in the order is started immediately (the faster the cache drive, the more this is exacerbated all else being equal) .  But, B may still be firing up, so any dependencies that A for instance has on B or C may still not be met.

 

While the docker start manager came out before unRaid's UI supported a startup order, and now they do somewhat overlap, it still has its place as it lets containers either have a set delay before starting, or check to see if such and such port responds on such and such IP before starting. (useful for dependencies against a VM)

[Zan]

On 5/6/2018 at 4:40 PM, ken-ji said:

well if you have been looking around, you must have missed that you can to specify the really advanced network bits and bobs via the extra parameters field in the template.

so in your case, probably

--network vpn

with the VPN container being named vpn

Sorry to dig up this old thread but I've been trying to achieve the same outcome as OP.

I had this running on Docker for Mac, and want to achieve the same on unRAID via dockerMan rather than using docker-compose:

version: "3.9"
networks:
  vpn:
services:

  jackett:
    image: lscr.io/linuxserver/jackett
    container_name: jackett
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
      #- AUTO_UPDATE=true #optional
      #- RUN_OPTS=<run options here> #optional
    volumes:
      - ./jackett:/config
      - /mnt/user/Downloads/watched:/downloads
    #ports:
      #- 9117:9117
    restart: unless-stopped
    networks:
      - vpn
    network_mode: "service:wireguard"

  wireguard:
    networks:
      - vpn
    image: lscr.io/linuxserver/wireguard
    container_name: wireguard
    privileged: true
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
      #- SERVERURL=wireguard.domain.com #optional
      #- SERVERPORT=51820 #optional
      #- PEERS=1 #optional
      #- PEERDNS=auto #optional
      #- INTERNAL_SUBNET=10.13.13.0 #optional
      #- ALLOWEDIPS=0.0.0.0/0 #optional
    volumes:
      - ./wireguard:/config
      - /lib/modules:/lib/modules
    ports:
      - 51821:51820/udp
      - 9117:9117 #jackett
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv4.conf.all.rp_filter=2
    restart: unless-stopped

 

So I've set up the wireguard docker and added port 9117 to it, removed port 9117 from the jackett docker and set --network="container:wireguard" then in the wireguard docker added port 9117, but pointing the browser to port 9117 times out. curl canhazip.com in both wireguard and jackett dockers shows that they're using the VPN, but I can't figure out how to get the request to port 9117 to reach the jackett docker and return a response. Any ideas?

 

Edited January 13, 2022 by Zan

[tankertux]

Here is the solution I ended up with:
First, I created a custom network for the container that "owns" the network (i.e. wireguard in your case, vpn in mine). Mine is a bridge network called "pianet". The reason for this is to avoid using the legacy docker link functionality to address the "host" container from the reverse proxy.
https://i.imgur.com/Gi1jkxD.png

 

Then, I created my network container, and specified the custom network in its template definition.

https://i.imgur.com/yMlI9fl.png

 

Next, I created my "client" containers (i.e. jackett in your case, torrent client in mine) specifying the containers use the network stack of the "host" container (e.g. --network=container:wireguard-container-name ).  Each secured application will need to listen on distinct ports, as they are all sharing the port space internal to the "host" container

https://i.imgur.com/cBQQP7Y.png

Lastly, I setup a reverse proxy (Nginx in my case) configured to pass connections from the custom network into the "client" container.  The reverse proxy is configured to use the custom network and addresses the "host" container by container-name in the nginx configuration.  This container is where you will specify your port mappings, because all connections to the secured containers will need to come in as requests through the reverse proxy container, which will route the requests to the "host" container on the appropriate port, thusly being directed to the "client" application because the host/client share the same network stack.

https://i.imgur.com/yMlI9fl.png
 

I hope this explanation helps!

[Zan]

2 hours ago, tankertux said:

Lastly, I setup a reverse proxy (Nginx in my case) configured to pass connections from the custom network into the "client" container.  The reverse proxy is configured to use the custom network and addresses the "host" container by container-name in the nginx configuration.  This container is where you will specify your port mappings, because all connections to the secured containers will need to come in as requests through the reverse proxy container, which will route the requests to the "host" container on the appropriate port, thusly being directed to the "client" application because the host/client share the same network stack.

https://i.imgur.com/yMlI9fl.png

Thanks for the reply, tankertux.

 

Couple questions:

1. Do I leave the port mappings as is for the wireguard and jackett containers?

2. What port mappings do I need for the nginx container?

3. Can you provide a sample of your nginx config file/s?

[tankertux]

6 hours ago, Zan said:

1. Do I leave the port mappings as is for the wireguard and jackett containers?

For wireguard, yes.  For jackett, you can, it will do nothing and will not hurt to remove or leave it.

 

6 hours ago, Zan said:

2. What port mappings do I need for the nginx container?

On the nginx container, I map the ports that I would have needed on the client containers (i.e. your port mappings from Jackett should be here)

6 hours ago, Zan said:

3. Can you provide a sample of your nginx config file/s?

 

The following is my nginx.conf file, modified to match your network container name (wireguard) and your client app ports (9117).  I'm not sure what configuration you should have for Jackett after the "location /", but this is what I've found necessary for qbittorrent and deluge.

user  nginx;
worker_processes  1;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
}
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen 9117;
        location / {
            proxy_pass http://wireguard:9117/;
            proxy_set_header        X-Forwarded-Host        $server_name:$server_port;
            proxy_hide_header       Referer;
            proxy_hide_header       Origin;
            proxy_set_header        Referer                 '';
            proxy_set_header        Origin                  '';
            add_header              X-Frame-Options         "SAMEORIGIN"; # see note
        }
    }
   
    include /etc/nginx/conf.d/*.conf;
}