diff --git a/site/features.md b/site/features.md index 0abcc392cd..fa1a556865 100644 --- a/site/features.md +++ b/site/features.md @@ -175,33 +175,44 @@ illustrate, we can achieve the same effect as the first example with host1$ C=$(docker run -e WEAVE_CIDR=none -dti ubuntu) host1$ weave attach $C + 10.2.1.3 (Note that since we modified `DOCKER_HOST` to point to the proxy earlier, we have to pass `-e WEAVE_CIDR=none` to start a container that _doesn't_ get automatically attached to the weave network for the purposes of this example.) +The output shows the IP address that got allocated, in this case on +the default subnet. + There is a matching `weave detach` command: host1$ weave detach $C + 10.2.1.3 You can detach a container from one application network and attach it to another: host1$ weave detach net:default $C + 10.2.1.3 host1$ weave attach net:10.2.2.0/24 $C + 10.2.2.3 or attach a container to multiple application networks, effectively sharing it between applications: host1$ weave attach net:default + 10.2.1.3 host1$ weave attach net:10.2.2.0/24 + 10.2.2.3 Finally, multiple addresses can be attached or detached with a single invocation: host1$ weave attach net:default net:10.2.2.0/24 net:10.2.3.0/24 $C + 10.2.1.3 10.2.2.3 10.2.3.1 host1$ weave detach net:default net:10.2.2.0/24 net:10.2.3.0/24 $C + 10.2.1.3 10.2.2.3 10.2.3.1 ### Security @@ -237,37 +248,36 @@ Let's say that in our example we want `$HOST2` to have access to the application containers. On `$HOST2` we run host2$ weave expose + 10.2.1.132 -(There is a corresponding 'hide' command to revert this step.) +This grants the host access to all application containers in the +default subnet. An IP address is allocated for that purpose, which is +returned. So now -Now, after finding allocated IPs via `weave ps` + host2$ ping 10.2.1.132 - host2$ weave ps weave:expose - weave:expose 02:80:5c:02:f1:b2 10.2.1.132/24 +will work, and, more interestingly, we can ping our `a1` application +container, which is residing on `$HOST1`, after finding its IP +address: host1$ weave ps a1 a1 1e:88:d7:5b:77:68 10.2.1.2/24 -this - - host2$ ping 10.2.1.132 - -will work. And, more interestingly, - host2$ ping 10.2.1.2 -will work too, which is talking to a container that resides on `$HOST1`. - Multiple subnet addresses can be exposed or hidden with a single invocation: host2$ weave expose net:default net:10.2.2.0/24 + 10.2.1.132 10.2.2.130 host2$ weave hide net:default net:10.2.2.0/24 + 10.2.1.132 10.2.2.130 Finally, exposed addresses can be added to weaveDNS by supplying a fully-qualified domain name: host2$ weave expose -h exposed.weave.local + 10.2.1.132 ### Service export @@ -283,6 +293,7 @@ First we need to expose the application network to `$HOST2`, as explained [above](#host-network-integration), i.e. host2$ weave expose + 10.2.1.132 Then we add a NAT rule to route from the outside world to the destination container service. @@ -326,13 +337,11 @@ explained [above](#host-network-integration), this time on `$HOST1`, i.e. host1$ weave expose -h host1.weave.local + 10.2.1.3 Then we add a NAT rule to route from the above IP to the destination service. - host1$ weave ps weave:expose - weave:expose 66:46:f5:ac:7b:c9 10.2.1.3/24 - host1$ iptables -t nat -A PREROUTING -p tcp -d 10.2.1.3 --dport 3322 \ -j DNAT --to-destination $HOST3:2211 @@ -376,14 +385,12 @@ weave via `$HOST1`. We can export it on `$HOST2` by first exposing the application network with host2$ weave expose + 10.2.1.3 and then adding a NAT rule which routes traffic from the `$HOST2` network (i.e. anything which can connect to `$HOST2`) to the service endpoint in the weave network - host1$ weave ps weave:expose - weave:expose 66:46:f5:ac:7b:c9 10.2.1.3/24 - host2$ iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4433 \ -j DNAT --to-destination 10.2.1.3:3322