[DOCKER] Pipework


Recommended Posts

I am currently trying to use Pipework for my docker containers.  I'm trying to use a vlan interface bro.5 which I confirmed works by setting up a VM on that interface.  

 

I added a extra variable 

 

-e 'pipework_cmd=bro.5 MineOS 192.168.5.40/[email protected]'

the Pipework log states that

 

/entrypoint.sh: line 363: export: `Extra Parameters=-e 'pipework_cmd=bro.5 MineOS 192.168.5.40/[email protected]'': not a valid identifier

What exactly am I doing wrong?

 

I tried some other variants of the command line but i get the same eror everytime

 

I set the network type to none.  I also tried just using the bro interface on dhcp and it did not seem to work either. 

 

any help would be appreciated

mineos-dockerpipework.PNG

Link to comment
On 03/12/2017 at 1:13 AM, brambo23 said:

I am currently trying to use Pipework for my docker containers.  I'm trying to use a vlan interface bro.5 which I confirmed works by setting up a VM on that interface.  

 

I added a extra variable 

 


-e 'pipework_cmd=bro.5 MineOS 192.168.5.40/[email protected]'

the Pipework log states that

 


/entrypoint.sh: line 363: export: `Extra Parameters=-e 'pipework_cmd=bro.5 MineOS 192.168.5.40/[email protected]'': not a valid identifier

What exactly am I doing wrong?

 

I tried some other variants of the command line but i get the same eror everytime

 

I set the network type to none.  I also tried just using the bro interface on dhcp and it did not seem to work either. 

 

any help would be appreciated

mineos-dockerpipework.PNG

 

I no longer use this as feature as i am using the inbuilt networking in unraid 6.4.

 

I would suggest following the instructions earlier in the thread from unevent.

Quote

Leave "@CONTAINER_NAME@" exactly as it is

 

-e 'pipework_cmd=bro.5 @CONTAINER_NAME@ 192.168.5.40/[email protected]'

 

Link to comment

Not sure if 'bro.5' is valid for pipework, might try using an integer instead when you create the bridge.  Also, not sure on how the variable '@CONTAINER_NAME@' is translated - it may be the human friendly name or it could be the alphanumeric id, I suggest to use the default @CONTAINER_NAME@ as shown above.  Also suggest to change the /32 subnet to /24 (255.255.255.0).

Edited by unevent
Link to comment

Have you got pipework working with other docker containers with using the vlan bridge?

If so then it is likely to do with the br0.5 interface. It could be the name or it could be the way it is handled by pipework.

Have you tried nested quotes? This may help if it is a naming issue.


Have a look at the code for pipework if you want as well.

https://github.com/jpetazzo/pipework/blob/master/pipework

The interface name is transfer to the variable ‘IFNAME’


Sent from my iPhone using Tapatalk

Link to comment

Sigh

 

I knew it was something stupid.

 

The reason I kept getting the same error no matter what I did was because I named the key under the new variable gui "Extra Parameters" and having that space caused issues.

 

Changing Extra Parameters to EP finally produced something different.

 

Also a second note I noticed i was naming my interface bro instead of br0 so im sure I would be getting issues once I changed EP.

 

Haven't successfully gotten pipework to work well for me yet, but now i can start troubleshooting it properly.

Link to comment
  • 3 months later...

Hi guys,

 

This is a basic question.

 

What is the advantage of using this as opposed to the main unRAID ip?

 

My uR is on 192.168,1.201

so my Couchpotato is on 192.168.1.201:5050

 

I am guessing that with Pipework I can make Couchpotato be on 192.168.1.190. But what would be the advantage of this? I am guessing security, but don’t see how.

 

This is a question out of ignorance.

 

H.

Link to comment
Hi guys,
 
This is a basic question.
 
What is the advantage of using this as opposed to the main unRAID ip?
 
My uR is on 192.168,1.201
so my Couchpotato is on 192.168.1.201:5050
 
I am guessing that with Pipework I can make Couchpotato be on 192.168.1.190. But what would be the advantage of this? I am guessing security, but don’t see how.
 
This is a question out of ignorance.
 
H.
I may be wrong, but is there still a need for this at all given we can allocate dedicated IP addresses per container.

My use case for dedicated IP per container is for pihole only, but I guess it could also be useful for policy routing so certain IP sources go over a VPN and others directly over WAN.

Sent from my LG-H815 using Tapatalk

  • Upvote 1
Link to comment
  • 3 months later...

I believe pipework is just a shell script.  Pipework is not as popular these days due to Docker including more network support in their later versions.  I still use it, but I am on 6.3.5.  All my Dockers have their own IP accessible to/from anything I want.  I do think going virtual machine will get you what you want and be a lot easier.  Rather simple to do in Virtualbox, but getting that running on unRAID is not a simple click and go process.  KVM should support what you want to do, but my experience with it is limited since it has limitations in the unRAID implementation that prevent me from using it over virtualbox for my use case.  That link I posted in the other thread had instructions for a Debian vm with four tuners and tvheadend.  There are probably many more Google hits with instructions since the law change was recent and seems to be a rather big deal for those in Germany.  Good luck.

Link to comment

thanks, i think im pretty straight forward with an VM, if deb or a libreelec one ...

but as im really happy with the docker and i would like to keep it as simple as possible ...

and im not really in a rush, currently i also have a octopus net with 4 tuners (wich i then would drop),

a vu+ with 8 cable fbc tuner (currently as iptv source in TVH, but a pain to setup ...),

so would be nice to have but not a must have now.

And pipework seems to be a nice solution for ip´s for dockers when u want to let them talk to each other,

just works out of the box, compared to buildin ip solution where a reverse proxy docker and the "client" dockers behind dont work anymore

cause they cant reach each other anymore easy.

 

thanks again for the tipps, time will tell ;)

Link to comment

ok, got it working with pipework

 

starting the docker several times in Host Mode, each time another extra parameter

 

-e 'pipework_cmd=br0 -i eth4 @CONTAINER_NAME@ 192.168.1.211/[email protected]'

-e 'pipework_cmd=br0 -i eth5 @CONTAINER_NAME@ 192.168.1.212/[email protected]'

-e 'pipework_cmd=br0 -i eth6 @CONTAINER_NAME@ 192.168.1.213/[email protected]'

 

now it has all 3 extra ips and host ip (and host mode)

 

just in case someone is interested

Link to comment
  • 1 year later...

I see this is quite old but have got it working nonetheless, as it is so old I was curious to know if there were other/better alternatives?  I am using it to give a couple of dockers an alternative gateway (my vm running ubuntu server vpn) 

 

Thanks! 

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.