tankertux Posted May 2, 2018 Share Posted May 2, 2018 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? Quote Link to comment
tankertux Posted May 3, 2018 Author Share Posted May 3, 2018 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. Quote Link to comment
tankertux Posted May 5, 2018 Author Share Posted May 5, 2018 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. Quote Link to comment
ken-ji Posted May 6, 2018 Share Posted May 6, 2018 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 1 Quote Link to comment
BRiT Posted May 6, 2018 Share Posted May 6, 2018 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. Quote Link to comment
tankertux Posted May 6, 2018 Author Share Posted May 6, 2018 (edited) @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 Quote Link to comment
Squid Posted May 6, 2018 Share Posted May 6, 2018 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) 1 Quote Link to comment
Zan Posted January 13, 2022 Share Posted January 13, 2022 (edited) 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 Quote Link to comment
tankertux Posted January 13, 2022 Author Share Posted January 13, 2022 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! 1 Quote Link to comment
Zan Posted January 13, 2022 Share Posted January 13, 2022 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? Quote Link to comment
tankertux Posted January 14, 2022 Author Share Posted January 14, 2022 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; } Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.