Please support sharing the host's networking stack. #2012

Closed
tlc opened this Issue Sep 26, 2013 · 18 comments

Projects

None yet

7 participants

@tlc
tlc commented Sep 26, 2013

Please support sharing the host's networking stack.

LXC supports this by having NO lxc.network.type entry.

@jpetazzo
Contributor

Hi,

Can you tell us a little bit more about your use-case?

The problem with sharing the host's networking stack is that the container can no longer run anywhere.
For instance, if a container binds to port 8000, and the host already have something on port 8000, it won't work.
But I understand that it can be useful in some scenarios (e.g. when you know for sure that you have nothing on said port :-))

@tlc
tlc commented Sep 26, 2013

In my personal use case, I don't run multiple copies of a container on the same host, so it's easy to pre-configure and I'd rather not have the overhead and complexity of NAT.

In the more general case, where people do run multiple copies on the same host, I imagine they could configure ports via -e=[] or -v=map[](or a new, specific option) and avoid NAT. I believe this would also let people use UDP.

@jpetazzo
Contributor

OK! If I understand correctly, you want to user Docker as a "software payload delivery mechanism", but not for its isolation and virtualization features? Is that right?

@tlc
tlc commented Sep 26, 2013

While I admit it's less cloud oriented, I don't consider it significantly less isolated or virtualized. (While -v=map breaks that wall, IMO.)

Myself? I'm just exploring, looking for uses.

@jpetazzo
Contributor

Sorry, I think I didn't pick the right words :-)
I meant: in this specific scenario, you want to run only one container on the host; using Docker as a (very special) kind of package manager; am I understanding correctly?

@ajf
ajf commented Sep 29, 2013

I can't speak for @tlc, but we would like to supply (as an environment variable) the ports allocated to the specific container. These port numbers will come from the Mesos system. Mesos knows what ports are available on a host and will assign free port ranges to individual tasks (i.e. docker containers), our apps in those containers will respect the port numbers given. We'd love to be able to just use the host's networking stack since it's much simpler than doing network virtualization and NAT. I hope that makes sense.

@jpetazzo
Contributor

Understood. As long as Docker uses lxc-start as a backend to start containers, it will be difficult to provide that kind of pass-thru, since (AFAIK) lxc-start doesn't allow to re-use the host network namespace.

There might be a way to move processes back to the initial network namespace; but this will probably be very hackish.

For the Mesos use-case, the best solution for now would be to map the ports and pass them as environment variables (e.g. CLI options -p 1234:1234 -e PORT=1234), but in the long run, it should be possible to do what you are asking natively.

@tlc
tlc commented Oct 10, 2013

Container networking in LXC is very flexible. It is triggered by the lxc.network.type configuration file entries. If no such entries exist, then the container will share the host's networking stack. Services and connections started in the container will be using the host's IP address.

https://help.ubuntu.com/lts/serverguide/lxc.html

@jrydberg
Contributor

I could use this as well.

The use case is that I want to run a docker, inside docker, that exposes ports on the host. The outer docker container/image is mostly a fancy package, just like you said @jpetazzo

@ajf
ajf commented Oct 15, 2013

I looked at this and made it work by:

  • Introducing a new -H command line option (although I think that making -n take an option would be better)
  • If -H is present, then the network portion of the LXC template isn't included, and networking isn't initialized in the container.

I can launch and run containers that share the host's networking now and from what I've been doing, it seems to work fine. Is there anything else that I should look out for in terms of things that may be broken?

@jrydberg
Contributor

@ajf Are exposed ports just ignored, or is a proxy still created for them somehow?

@ajf
ajf commented Oct 15, 2013

Looks like exposed ports are just ignored, let me test it out

@ajf
ajf commented Oct 15, 2013

I think it's ignored, inspect says NetworkSettings.PortMapping is null, NetworkSettings.Ports is null, and docker ps doesn't list any port. If I run without -H, it has the ports in ps, as well as in inspect. Is that reasonable or should there be some sort of warning that Exposed ports are useless?

@jrydberg
Contributor

I agree with your that it would be better as an argument for -n. I'm afraid that -H might be too confusing (there's already a global -H option).

Are your patches available somewhere?

@shykes
Contributor
shykes commented Dec 2, 2013

Tagging as networking, and tentatively scheduling for 0.8.

@ajf
ajf commented Dec 5, 2013

@jrydberg I was trying to get my patches approved by my employer, but in that time, someone else did essentially the same thing in #2902

@jpoimboe
Contributor
jpoimboe commented Feb 6, 2014

This feature is already being actively discussed in #2900 and #2902, so I think this one can be closed as a duplicate of those.

@crosbymichael
Member

Sure, we can move the discussion to #2900 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment