When does this get obsoleted?
possibilities opened this issue · 13 comments
Fantastic script... using happily... but I'm wondering if/when we get similar functionality in core? Are there any issues or PRs I should be watching? Thanks!
We definitely want to merge this (or, rather, the functionality it offers) into Docker's core.
We just to figure out how :-)
I'm still gathering ideas and trying to figure out the right integration points, then an issue (and soon after, a pull request) will be open on Docker's repo!
Cool... sounds incredibly sensible... I'll be watching! 👀 Thanks!
I played a bit around pipework to address some network topologies, but it didn't fit correctly all of my needs, so I did stuff around docker to make it able to use a preconfigured network interface instead of setup a new one attached to its bridge (I want to use another bridge with a level2 network isolation technologie)
If you look to libvirt (or xen that I'm much aware of), it's sound natural to proceed this way. You only have to give a reference to the network interface at container / vm startup, as it's done for volumes. And also no more portmapping is needed, for my purposes.
Not quite sure this solution fit docker principles and roadmap, I just start that as a personal experiment to learn more about golang and linux cgroups (network namespace)
@gdchamal: I would love to know a bit more about what you did. Can you elaborate a little bit about your setup?
(The current idea is to find a way to merge Pipework features within Docker; so if you found a use-case that cannot be easily addressed with Pipework, we totally want to hear about it to make sure that we can either address it, or at least make it easier to integrate!)
Thank you.
I need a predictable eth0 configuration (I don't want to be dependent on port mapping), our provisioning
processes are normally responsible of such network setup. Also I would want to add another interface
to the container, pipework is fine for that and network namespace is a really appreciated feature.
I could nearly achieve such setup using -n docker flag to bypass network configuration (all of, even /etc/hosts and resolv.conf configuration) and pipework x 2 the container (some updates to make it work) and "pipework --wait" to
make process bind eth1 on container.
Make docker start a container with a preconfigured interface (eth0) and pipework this container
to get a second interface up is a way I started to experiment.
At this time of my attempts, I think about a combination of --interfaces vethX, vethY --netns Z
flags to make possible to attach pre provisioned network interfaces and make network isolation
fully possible.
OK. Can you explain what is "predictable eth0 configuration" in that case?
Is it like the eth1 configuration provided by Pipework, except that you need it for eth0 as well?
Exactly, IP allocated to eth0 (and if interface work with dhcp, is on a particular bridge, etc)
is know before container startup in my cases.
OK. So, if I understand correctly, if Pipework had an option to tell it "hey, let's give this container a new eth0 interface" (instead of eth1 as it currently does), that would be fine?
(Sorry if I'm repeating myself, but I want to be sure that I understand correctly before making changes to Pipework :-))
The having to wait for eth1 to come up is a bit fiddly. I would hope that a merge into core Docker would be able to bring up the interface before starting the command.
If pipework were to have an option to replace the eth0 interface, how would one wait for the replacement? pipework --wait could terminate before the old eth0 is taken down.
Actually, I recently merged a pull request allowing to specify other interfaces (instead of eth1).
So you should be able to:
- start the container without eth0 (with
docker run -n=false …) - in the container, wait for eth1 with
pipework --wait -i eth0 - outside, use pipework with e.g.
pipework br1 -i eth0 <containerID> 192.168.1.1/24
Per comments above, -n=false appears to have additional not-well-documented effects in addition to not creating eth0. One would have to additionally research and implement those steps in the container.
I will close this issue for now since there is no actionable step (I mean, having an open issue for "integration of pipework within Docker" won't help much :-)) but if you have a specific problem (side effect of network disable, specific use-case with pipework) don't hesitate to open a new issue, either in the Docker repo (for the first case) or the pipework repo (in the second case)!
Thanks.
There are 2 docker issues to track for 'better docker networking'. You can see here:
https://github.com/dreamcat4/docker-images/blob/master/pipework/0.%20Introduction.md#future