#weavenetwork

Hi there !

How is the IP assigning handled for Container? Like the "pipework" method?

Weave Net includes a built-in IP address allocator: http://docs.weave.works/weave/latest_release/ip...

as docker 1.9 plugin?

for the new libnetwork?

Ah, your question is about how IP address allocation works with the plugin?

not really.

When i start a container it needs an IP. Usually docker assigns it

there a two ways to give the container another IP

1.) giving the container the privilege to use "ip addr" inside the container

2.) altering the network namespace on the host

Docker assigns an IP address for a container's eth0 netdev. Weave adds a second ethwe netdev inside the container, and weave assigns the address for that.

both can only be executed AFTER starting the container so i need "magic" to let the application inside the container wait for the IP assignment

Weave Net does that magic for you.

ah i see, i think this is the same approach as the pipework tool does it

but then i ran into race condition. my service gets started before Weave has added ehtwe

The service binds the interfaces only at start

The networkstack setup should be done before the entrypoint/cmd get reached - u understand my problem?

We normally recommend that people use our proxy these days. That takes care of waiting until ethwe is ready before the container entrypoint is called.

your proxy?

See http://docs.weave.works/weave/latest_release/pr...

yes but i dont think it solves my problem

It solves the race condition you described. Have you tried it?

the proxy maps the "docker run" to a "docker run"+"weave network setup" doesnt it?

no just discoverd weav today

can you tall me how weave solves it?

The proxy does a lot of things. Including rewriting the container entrypoint to start a binary that waits for ethwe to be ready before calling the original entrypoint.

ahhhh

rewrite the entrypoint is the jumping point ;)

Yes

does it also support port mappings ? i read about some iptables cmds for the NAT stuff

No, container-based port mappings don't make a lot of sense in the weave network model.

but i have several public services like 80, 443

The iptables commands are an elaboration to the use of "weave expose", so you can put the host machine on the weave network.

sorry i dont get you.

so i need iptable rules to expose the public ports of some containers?

Yes, if that's what you want to happen.

It's described at http://docs.weave.works/weave/latest_release/fe...

hmm okay, so now i do a restart "loadbalancer-container", it gets a new IP, i need to adjust the iptable rules

not so handy

i really need to setup wave playground and inspect the arch ;)

looks like a much more advanced tool than my "docker-wrap.sh"

You can set the IP address of a container explicitly even when using the proxy. Search for WEAVE_CIDR in http://docs.weave.works/weave/latest_release/pr...

ah i see

nice!

so my last question, application isolation uses just subneting right?

theres i no way to define a container which can access all isolation apps?

Ie for monitoring

That's correct: There's currently no isolation beyond subnetting, so you can't have sophisticated isolation policies.

but i can give a container a 10.0.0.1/8 subnet, can this container access 10.1.0.1/24 ?

i think its not possible, the packages wouldnt find the way back

Yeah, that doesn't work (due to reverse path filtering, if nothing else).

hmm any other idea how to monitor my service-ports ?

ahh weave attach, i could attach the monitoring-container to every app-network

i think weave installes a veth pair vor every "attach" ?

dpw: are you one of the creators of weave?

Yes, I'm on the weave engineering team.

nice ;)

can i disable the SDN if i have a private network?

Psi|4ward: Hi - dpw's off to lunch, I'm also on the engineering team at Weaveworks. Could you elaborate a bit more on what you mean?

so with weave i usualle create a software defined network overlay using the public iface

but what if i have a second nic in my servers for the private net

i could bridge to the hosts "eth1" and avoid the VxLAN overhead (or whatever weave uses)

Got it - if you attempt to connect to addresses on the private subnet from within a container it will probably already work via the docker eth0/docker0 bridge

but there are some tunnels to the other hosts?

The kernel will decide how to route your packets based on the destination subnet

If you container tries to access an IP on the weave network, the packet will get routed via the ethwe interface and over the weave router

yes of course!

Container A should speak to Container B, each on differen hosts

If your container tries to send to an IP on your private host subnet, the kernel will use the default route which goes via eth0 -> docker0

I dont want to use the SDN (tunnels) in case ive a dedicated network

perhaps we should stop there, i should inspect the internals of weave fist

At the moment the only way to do what you're asking is to have the containers address the correct subnet themselves

There's no magic 'use direct private networking if available' option

what do you use for tunneling?

We support two methods - a high performance VXLAN encapsulation that goes via the kernel, and a slower userspace UDP encapsulation that supports encryption, NAT traversal and dynamic PMTU discovery

You don't have to configure it, weave selects the best available option on a per peer to peer basis

i thought that ;)