[DOCKER] Pipework


Recommended Posts

This is an unraid implementation of the dreamcat4/pipework image on the Docker Hub.

 

I use pipework to assign a static IP to a docker container. This has made it possible to move away from VM's to docker containers for some of my main applications.

 

Choosing the correct version

By default docker templates grab the 'latest' build this may cause you issues.

For unRAID 6.0 and 6.1 you need to use

dreamcat4/pipework:1.1.5

 

For unRAID 6.2 you need to use

dreamcat4/pipework:1.1.6

An additional environmental variable is required for unRAID 6.2. If using the Community Application templates this will be already in place.

-e DOCKER_API_VERSION=1.22

 

Installation (Preferred):

Use Community Application to install.

http://lime-technology.com/forum/index.php?topic=40262.0

 

Installation:

Add the template repository to unraid Docker Template Repositories:

https://github.com/tinglis1/docker-containers/tree/master/

Install and run the pipework docker container. No configuration is required for the pipework container. You may want to set the container to autostart.

 

Container configuration

Set the container network mode to 'none' and then add the additional parameters input in the container advanced configuration. The additional parameters are documented at dreamcat4/pipework and jpetazzo/pipework.

An example extra parameters config for a static IP:

 

-e 'pipework_cmd=br0 @CONTAINER_NAME@ 192.168.1.100/[email protected]'

 

In this example the ethernet port used is 'br0', the IP is static at 192.168.2.100 with a /24 network and a gateway of 192.168.1.1.

 

More Info

I have put some more detailed documentation at https://github.com/tinglis1/docker-containers/tree/master/pipework.

Also check out dreamcat4/pipework and jpetazzo/pipework.

 

 

 

 

Link to comment

Here is a couple of screen shots of the configuration that is working for me.

 

Are you trying to set a static or dynamic IP?

 

I have the 'Nerd Pack' plugin installed. I don't think this should make any difference but there is always a chance is might be.

 

Pipework docker

pipework_config_example.png

 

JDownloader2

This has a static IP set.

container_config_example.png

 

 

Edit: Updated image paths to github address

 

Link to comment

The interface is defined in the docker container additional parameters. I have used 'br0', you could try substitute that for your choice of interface on your docker.

 

You may need to bridge the nic to be able to use it, there is some more info on this here https://lime-technology.com/forum/index.php?topic=34872.msg325436#msg325436.

I don't use my second interface port so haven't tested it.

Link to comment

The interface is defined in the docker container additional parameters. I have used 'br0', you could try substitute that for your choice of interface on your docker.

 

You may need to bridge the nic to be able to use it, there is some more info on this here https://lime-technology.com/forum/index.php?topic=34872.msg325436#msg325436.

I don't use my second interface port so haven't tested it.

Thanks for the link. 

Link to comment

Thanks for sharing these screen captures. They definitely helped since I was changing the Pipework container settings instead of the app. I setup everything as recommended using Transmission as an example. My UNRAID box is running on 192.168.1.20 and I'm trying to get Transmission to 1.40 with a different gateway.

 

After everything is set, Transmission still only appears at 192.168.1.20, however the interface loads but doesn't connect to the daemon.

 

Any advice?

2015-11-20_16-50-05.png.0a12b59618cd85c512c218e5019edb96.png

2015-11-20_16-50-22.png.e7df36fe43772ceb7eccd02aba1529fc.png

2015-11-20_16-50-43.png.947eab5de4214a84a824b476e0c5802d.png

Link to comment

Are you checking the success by the pinging the container? The IP address on the docker page is actually set by a separate setting on the advanced settings page (it has a known issue that makes it difficult to change.) and is not representative of the pipework assigned ip.

 

Check that the pipework docker is running with privileges. This is found when looking at advanced settings.

 

Watch the unraid log when the transmission docker is starting. It should show messages about he interface being created and becoming active. Can't remember the exact messages (I am nowhere near my computer at the moment). This might give some insight into what is failing. The best interface will have generated name, not br0.

 

Also it maybe worth trying a reboot. When trying to figure out how to get pipework running I had made so many network connections I got weird results. It also allowed me to test the ability for pipework to assign the correct ip on startup.

Link to comment

I completely forgot to ping that IP. I must be tired and looked for more complicated solutions.

 

Anyway, when I start the container, 192.168.1.40 does in fact ping...and it stops when I stop the container. I also used NMAP to figure out if the ports 9091 and 51413 are open on 1.40 and they are. So it looks like everything is working okay.

 

My next step is to see if it's the configuration of Transmission itself causing the issue. My assumption is that Transmission is setup to only look on 192.168.1.20 (localhost) somewhere in the config. I'm going to start there...

Link to comment
  • 1 month later...

Thanks to the OP/creater of this pipework Docker effort.  Finally got it implemented for use with my VPN and certain dockers.  Used to have everything on unRAID going through VPN, but after setting up pipework and pfsense I am able to give what I need on VPN their own IP and use pfsense to route those IPs to my VPN while everything else stays on regular Internet.  I also used the custom mac address capability in pipework so I can assign static IPs and hostname and access the Dockers by name vs IP.  All that is left is to setup a reverse proxy to handle the ports so I can get away from doing sonarr:8989 and just do sonarr.

Link to comment
  • 3 weeks later...

Just started playing with pipework thanks to unevent.

 

Anyway, it works awesome.  I am still learning and ran into one issue.  I used the following parameters to give my Transmission container it's own IP:

 

-e 'pipework_cmd=br0 @CONTAINER_NAME@ 192.168.1.247/[email protected]'

 

The issue I saw was that when I shut down the Transmisison docker, my unraid box now resolved to both its normal IP and 192.168.1.247.

 

I suspected that the culprit was something MAC related so I was able to work around this issue by providing my Tranmission container its own MAC address by doing this:

 

-e 'pipework_cmd=br0 @CONTAINER_NAME@ 192.168.1.247/[email protected] fc:de:b0:99:53:1c'

 

Problem solved.  :)

 

However, I am seeing other weird behavior...

 

My unRAID box is now reachable on 192.168.1.253 and 192.168.1.254.  I see these entries in the ARP table in pfsense:

 

IP address	MAC address	      Hostname	Interface	
192.168.1.10    00:25:90:64:a7:d8	        LAN
192.168.1.253   4a:61:22:25:72:0b		LAN
192.168.1.254   a2:47:01:45:4f:52		LAN
192.168.1.247   fc:de:b0:99:53:1c		LAN

 

192.168.1.10 is my unraid IP

x.x.x.253 and x.x.x.254 are the question marks

x.x.x.247 is my Transmisison container

 

Anyone have any idea what is going on here?

 

John

Link to comment
  • 2 weeks later...

Might try not using Pipework for that container and see what you get.  Hopefully in 6.2 LT shows Docker networking some love vs. trying to support 10 gamers on a NAS or making one giant unprotected cache pool with limited use in residential environments </sarcasm>.

 

TVH can see the HDHRs just fine if I don't use Pipework and net=Host.  Just wondering why it can't see them when I do force it to use PW.

Link to comment

Hopefully in 6.2 LT shows Docker networking some love vs. trying to support 10 gamers on a NAS or making one giant unprotected cache pool with limited use in residential environments </sarcasm>.

 

I wholeheartedly agree, it sometimes feels like us core users who don't game just seem not to matter much so more.  ::)

Link to comment

Pipework has been working great! However, I just installed it on my brother's server and it won't start. I keep getting an error that says: error: can't connect to unix:///docker.sock.

 

To test this out, I reinstalled it on my server. I updated the software and now I'm getting the error on my own server.

 

Both are UnRaid 6.1.7.

 

Any thoughts on what might be happening? docker.sock is mapped to /var/run/docker.sock.

 

Thanks!

Link to comment

Pipework has been working great! However, I just installed it on my brother's server and it won't start. I keep getting an error that says: error: can't connect to unix:///docker.sock.

 

To test this out, I reinstalled it on my server. I updated the software and now I'm getting the error on my own server.

 

Both are UnRaid 6.1.7.

 

Any thoughts on what might be happening? docker.sock is mapped to /var/run/docker.sock.

 

Thanks!

 

Could the docker have downloaded the latest build that has an error (https://hub.docker.com/r/dreamcat4/pipework/builds/)? Is there a way to set this container to download an earlier version like 1.1.4? Maybe that will fix this issue?

Link to comment
Pipework has been working well for me but I ran into one issue...

 

If I use it with saarg's TVHeadEnd containers, TVH cannot discover my HDHomerun devices.  If I take Pipework out of the mix, TVH sees the devices fine.

 

Any ideas?

 

John

 

John,

 

I have a tvheadend docker image using 'tobbenb/tvheadend-unstable:latest' running with my HDhomerun dual tuner. I did a quick test by assigning a pipework IP address to my existing tvheadend container and I had no issue using the tuner via tvheadend with a kodi frontend.

The only change I made was to change the network type from host to none and added the extra parameter

-e 'pipework_cmd=br0 @CONTAINER_NAME@ 192.168.1.110/[email protected]'

 

 

Link to comment

I am thinking about removing the beta tag from this docker container. The actual container is managed by someone else and appears to be stable. The only beta part was the unraid container configuration.

With the beta tag removed it may attract a few more people to try it out.

 

Anybody got any thoughts on this?

Link to comment

I have a tvheadend docker image using 'tobbenb/tvheadend-unstable:latest' running with my HDhomerun dual tuner. I did a quick test by assigning a pipework IP address to my existing tvheadend container and I had no issue using the tuner via tvheadend with a kodi frontend.

The only change I made was to change the network type from host to none and added the extra parameter

-e 'pipework_cmd=br0 @CONTAINER_NAME@ 192.168.1.110/[email protected]'

 

That is exactly the same command I use with the exception that I specify a MAC address.  I can't understand why you would get a different result...which pisses me off!  :)  That this the only container that I have at this point that is not running through pipework.

 

I'll try without the MAC and see if that helps but I am pretty sure that I tried that somewhere along the way.

 

I'm wondering if it is because you are using saarg's unstable container.  I'm using the stable.  I'll try that also.

 

John

Link to comment

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.

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.