#weavenetwork

does weave support containers talking outside of weave virtual network?

like the app is in weave virtual network and DBs are in physical servers

nice question sujith

sujith: Yes, you can always give containers another interface. In fact, in the default set-up a container will have two interfaces, one on the weave network and one on the (host-only) docker network.

sujith: also you can add a route as explained here: http://zettio.github.io/weave/features.html#ser...

which might be preferred if only some of your containers can reach the DB directly

hi. if i don't want some services to communicate or use weave, is there a way to tell weave to exclude that traffic?

mameen: don't attach them to the weave network

moonfish: I should've explained better.. i run let's say service A in a container, that includes Consul agent. I specify --net=host option for communications with A from other VMs. But I'd like Consul agent to communicate via weave. Is it possible?

oh, so you have multiple processes in a single container, and want some to use weave but not others?

exactly!

actually, looking at what you just wrote, why do you need the --net=host? Couldn't you use weave's service export feature?

--net=host and weave don't mix well.

yes, i could and it works but with weave don't get required network througput

so was trying to see if i can cherry pick to tell the services whether to use weave or not!

could you expose the service in the normal docker way, i.e. with port publishing?

then you wouldn't have to run with --net=host

unfortunately not yet, it uses a wide range of ephemeral ports for clients to connect. it's in works to define a port range that can then be exposed rather than --net=host

in that case the only other option I can think of is to run the consul agent in a separate container. but that would presumably defeat its purpose.

btw, I am surprised that exposing the service gives you unsatisfactory performance.

it should not impose any more overhead than what docker is doing when publishing ports of containers.

issue is network throughput performance when using weave. > 10x drop that's not feasible.

but thanks for your responses

the 10x drop should only occur when going across hosts.

when you expose a service that is provided by a container on the same host then the weave router doesn't get involved; it's all handled by the linux kernel, bridges, iptables, etc.

<moonfish> that's true. for consul agent running along service A, i'd like that to register to a centralized consul server and the need to cross VM/host boundaries.

right. and that consul communication should pose no performance problem for weave.

well true, it's insignificant and can be ignored. that's not true for service A that's network intensive

right. so run both in a single weave container, expose the service to the hosty through weave's service export (which should be able to handle port ranges, with the right iptables magic), and let consul communicate over weave.

@bryanb thanks you,I will give it a try