reweave/weave
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

reduce likelihood of IP clashes in tests & examples

Browse Source 
by using the 10.2 range, which is not one used by docker and also is
less likely than 10.0 to be used by something else.

Fixes #402.
This commit is contained in:
Matthias Radestock committed 2015-03-09 20:51:26 +00:00
1 parent abb1c6c781
commit 123e8bbb28
16 files changed
+77 -77
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

README.md
+8 -8
View File
@@ -51,7 +51,7 @@ two containers, one on each host.
On `$HOST1` run (as root)
host1# weave launch
host1# C=$(weave run 10.0.1.1/24 -t -i ubuntu)
host1# C=$(weave run 10.2.1.1/24 -t -i ubuntu)
The first line starts the weave router, in a container. This needs to
be done once on each host. The required docker image for the weave
@@ -83,7 +83,7 @@ addresses must, of course, be unique.
We repeat similar steps on `$HOST2`...
host2# weave launch $HOST1
host2# C=$(weave run 10.0.1.2/24 -t -i ubuntu)
host2# C=$(weave run 10.2.1.2/24 -t -i ubuntu)
The only difference, apart from the choice of IP address for the
application container, is that we tell our weave that it should peer
@@ -105,18 +105,18 @@ can talk to each other...
On `$HOST1`...
host1# docker attach $C
root@28841bd02eff:/# ping -c 1 -q 10.0.1.2
PING 10.0.1.2 (10.0.1.2): 48 data bytes
--- 10.0.1.2 ping statistics ---
root@28841bd02eff:/# ping -c 1 -q 10.2.1.2
PING 10.2.1.2 (10.2.1.2): 48 data bytes
--- 10.2.1.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.048/1.048/1.048/0.000 ms
Similarly, on `$HOST2`...
host2# docker attach $C
root@f76829496120:/# ping -c 1 -q 10.0.1.1
PING 10.0.1.1 (10.0.1.1): 48 data bytes
--- 10.0.1.1 ping statistics ---
root@f76829496120:/# ping -c 1 -q 10.2.1.1
PING 10.2.1.1 (10.2.1.1): 48 data bytes
--- 10.2.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.034/1.034/1.034/0.000 ms
nameserver/http_test.go
+1 -1
View File
@@ -23,7 +23,7 @@ func TestHttp(t *testing.T) {
containerID = "deadbeef"
testDomain = "weave.local."
successTestName = "test1." + testDomain
testAddr1 = "10.0.2.1/24"
testAddr1 = "10.2.2.1/24"
dockerIP = "9.8.7.6"
)
nameserver/mdns_server_test.go
+2 -2
View File
@@ -13,8 +13,8 @@ import (
var (
containerID = "deadbeef"
testName = "test.weave.local."
testAddr1 = "10.0.2.1/24"
testInAddr1 = "1.2.0.10.in-addr.arpa."
testAddr1 = "10.2.2.1/24"
testInAddr1 = "1.2.2.10.in-addr.arpa."
)
func sendQuery(name string, querytype uint16) error {
nameserver/server_test.go
+2 -2
View File
@@ -12,7 +12,7 @@ import (
)
const (
testRDNSsuccess = "1.2.0.10.in-addr.arpa."
testRDNSsuccess = "1.2.2.10.in-addr.arpa."
testRDNSfail = "4.3.2.1.in-addr.arpa."
testRDNSnonlocal = "8.8.8.8.in-addr.arpa."
testPort = 17625
@@ -23,7 +23,7 @@ func TestUDPDNSServer(t *testing.T) {
successTestName = "test1.weave.local."
failTestName = "test2.weave.local."
nonLocalName = "weave.works."
testAddr1 = "10.0.2.1"
testAddr1 = "10.2.2.1"
)
testCIDR1 := testAddr1 + "/24"
nameserver/zone_test.go
+5 -5
View File
@@ -11,7 +11,7 @@ func TestZone(t *testing.T) {
containerID = "deadbeef"
otherContainerID = "cowjuice"
successTestName = "test1.weave."
testAddr1 = "10.0.2.1/24"
testAddr1 = "10.2.2.1/24"
)
var zone = new(ZoneDb)
@@ -21,9 +21,9 @@ func TestZone(t *testing.T) {
wt.AssertNoErr(t, err)
// Add a few more records to make the job harder
err = zone.AddRecord("abcdef0123", "adummy.weave.", net.ParseIP("10.0.0.1"))
err = zone.AddRecord("abcdef0123", "adummy.weave.", net.ParseIP("10.2.0.1"))
wt.AssertNoErr(t, err)
err = zone.AddRecord("0123abcdef", "zdummy.weave.", net.ParseIP("10.0.0.2"))
err = zone.AddRecord("0123abcdef", "zdummy.weave.", net.ParseIP("10.2.0.2"))
wt.AssertNoErr(t, err)
// Check that the address is now there.
@@ -35,7 +35,7 @@ func TestZone(t *testing.T) {
}
// See if we can find the address by IP.
foundName, err := zone.LookupInaddr("1.2.0.10.in-addr.arpa.")
foundName, err := zone.LookupInaddr("1.2.2.10.in-addr.arpa.")
wt.AssertNoErr(t, err)
if foundName != successTestName {
@@ -69,7 +69,7 @@ func TestDeleteFor(t *testing.T) {
var (
id = "foobar"
name = "foo.weave."
addr1 = "10.1.2.3/24"
addr1 = "10.2.2.3/24"
addr2 = "10.2.7.8/24"
)
zone := new(ZoneDb)
site/boot2docker.md
+1 -1
View File
@@ -23,7 +23,7 @@ example above, the 'launch' command would be run like this:
and the 'run' command like this:
host1# C=$(boot2docker ssh "sudo ./weave run 10.0.1.1/24 -t -i ubuntu")
host1# C=$(boot2docker ssh "sudo ./weave run 10.2.1.1/24 -t -i ubuntu")
For more information about how to access services running in
Boot2Docker from the host or other machines (i.e. outside of the weave
site/features.md
+33 -33
View File
@@ -37,14 +37,14 @@ container on `$HOST1` we can start a netcat "service" with
and then connect to it from the container on `$HOST2` with
root@f76829496120:/# echo 'Hello, world.' | nc 10.0.1.1 4422
root@f76829496120:/# echo 'Hello, world.' | nc 10.2.1.1 4422
Note that *any* protocol is supported. Doesn't even have to be over
TCP/IP, e.g. a netcat UDP service would be run with
root@28841bd02eff:/# nc -lu -p 5533
root@f76829496120:/# echo 'Hello, world.' | nc -u 10.0.1.1 5533
root@f76829496120:/# echo 'Hello, world.' | nc -u 10.2.1.1 5533
We can deploy the entire arsenal of standard network tools and
applications, developed over decades, to configure, secure, monitor,
@@ -63,28 +63,28 @@ To accomplish that, we assign each application a different subnet. So,
in the above example, if we wanted to add another application similar
to, but isolated from, our first, we'd launch the containers with...
host1# D=$(weave run 10.0.2.1/24 -t -i ubuntu)
host2# D=$(weave run 10.0.2.2/24 -t -i ubuntu)
host1# D=$(weave run 10.2.2.1/24 -t -i ubuntu)
host2# D=$(weave run 10.2.2.2/24 -t -i ubuntu)
A quick 'ping' test in the containers confirms that they can talk to
each other but not the containers of our first application...
host1# docker attach $D
root@da50502598d5:/# ping -c 1 -q 10.0.2.2
PING 10.0.2.2 (10.0.2.2): 48 data bytes
--- 10.0.2.2 ping statistics ---
root@da50502598d5:/# ping -c 1 -q 10.2.2.2
PING 10.2.2.2 (10.2.2.2): 48 data bytes
--- 10.2.2.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.562/0.562/0.562/0.000 ms
root@da50502598d5:/# ping -c 1 -q 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
--- 10.0.1.1 ping statistics ---
root@da50502598d5:/# ping -c 1 -q 10.2.1.1
PING 10.2.1.1 (10.2.1.1) 56(84) bytes of data.
--- 10.2.1.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
root@da50502598d5:/# ping -c 1 -q 10.0.1.2
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.
--- 10.0.1.2 ping statistics ---
root@da50502598d5:/# ping -c 1 -q 10.2.1.2
PING 10.2.1.2 (10.2.1.2) 56(84) bytes of data.
--- 10.2.1.2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
This isolation-through-subnets scheme is an example of carrying over a
@@ -110,23 +110,23 @@ to the weave network. To illustrate, we can achieve the same effect as
the first example with
host1# C=$(docker run -d -t -i ubuntu)
host1# weave attach 10.0.1.1/24 $C
host1# weave attach 10.2.1.1/24 $C
There is a matching `weave detach` command:
host1# weave detach 10.0.1.1/24 $C
host1# weave detach 10.2.1.1/24 $C
You can detach a container from one application network and attach it
to another:
host1# weave detach 10.0.1.1/24 $C
host1# weave attach 10.0.2.1/24 $C
host1# weave detach 10.2.1.1/24 $C
host1# weave attach 10.2.2.1/24 $C
or attach a container to multiple application networks, effectively
sharing it between applications:
host1# weave attach 10.0.1.1/24 $C
host1# weave attach 10.0.2.1/24 $C
host1# weave attach 10.2.1.1/24 $C
host1# weave attach 10.2.2.1/24 $C
### <a name="security"></a>Security
@@ -158,18 +158,18 @@ anywhere.
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.0.1.102/24
host2# weave expose 10.2.1.102/24
choosing an unused IP address in the application subnet. (There is a
corresponding 'hide' command to revert this step.)
Now
host2# ping 10.0.1.2
host2# ping 10.2.1.2
will work. And, more interestingly,
host2# ping 10.0.1.1
host2# ping 10.2.1.1
will work too, which is talking to a container that resides on `$HOST1`.
@@ -186,18 +186,18 @@ a container on `$HOST1`, accessible to the outside world via `$HOST2`.
First we need to expose the application network to `$HOST2`, as
explained [above](#host-network-integration), i.e.
host2# weave expose 10.0.1.102/24
host2# weave expose 10.2.1.102/24
Then we add a NAT rule to route from the outside world to the
destination container service.
host2# iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 2211 \
-j DNAT --to-destination 10.0.1.1:4422
-j DNAT --to-destination 10.2.1.1:4422
Here we are assuming that the "outside world" is connecting to `$HOST2`
via 'eth0'. We want TCP traffic to port 2211 on the external IPs to be
routed to our 'nc' service, which is running on port 4422 in the
container with IP 10.0.1.1.
container with IP 10.2.1.1.
With the above in place, we can connect to our 'nc' service from
anywhere with
@@ -226,23 +226,23 @@ First we need to expose the application network to the host, as
explained [above](#host-network-integration), this time on `$HOST1`,
i.e.
host1# weave expose 10.0.1.101/24
host1# weave expose 10.2.1.101/24
Then we add a NAT rule to route from the above IP to the destination
service.
host1# iptables -t nat -A PREROUTING -p tcp -d 10.0.1.101 --dport 3322 \
host1# iptables -t nat -A PREROUTING -p tcp -d 10.2.1.101 --dport 3322 \
-j DNAT --to-destination $HOST3:2211
This allows any application container to reach the service by
connecting to 10.0.1.101:3322. So if `$HOST3` is indeed running a netcat
connecting to 10.2.1.101:3322. So if `$HOST3` is indeed running a netcat
service on port 2211, e.g.
host3# nc -lk -p 2211
then we can connect to it from our application container on `$HOST2` with
root@f76829496120:/# echo 'Hello, world.' | nc 10.0.1.101 3322
root@f76829496120:/# echo 'Hello, world.' | nc 10.2.1.101 3322
The same command will work from any application container.
@@ -251,7 +251,7 @@ The same command will work from any application container.
Importing a service provides a degree of indirection that allows late
and dynamic binding, similar to what can be achieved with a proxy. In
our example, application containers are unaware that the service they
are accessing at `10.0.1.101:3322` is in fact residing on
are accessing at `10.2.1.101:3322` is in fact residing on
`$HOST3:2211`. We can point application containers at another service
location by changing the above NAT rule, without having to alter the
applications themselves.
@@ -273,14 +273,14 @@ In our example above, the netcat service on `$HOST3` is imported into
weave via `$HOST1`. We can export it on `$HOST2` by first exposing the
application network with
host2# weave expose 10.0.1.102/24
host2# weave expose 10.2.1.102/24
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
host2# iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4433 \
-j DNAT --to-destination 10.0.1.101:3322
-j DNAT --to-destination 10.2.1.101:3322
Now any host on the same network as `$HOST2` can access the service with
@@ -289,7 +289,7 @@ Now any host on the same network as `$HOST2` can access the service with
Furthermore, as explained in [service-binding](#service-binding), we
can dynamically alter the service locations without having to touch
the applications that access them, e.g. we could move the example
netcat service to `$HOST4:2211` while retaining its 10.0.1.101:3322
netcat service to `$HOST4:2211` while retaining its 10.2.1.101:3322
endpoint in the weave network.
### <a name="multi-cloud-networking"></a>Multi-cloud networking
site/troubleshooting.md
+3 -3
View File
@@ -130,9 +130,9 @@ Produces a list of all the containers running on this host that are
connected to the weave network, like this:
b07565b06c53 ae:e3:07:9c:8c:d4
5245643870f1 ce:15:34:a9:b5:6d 10.0.5.1/24
e32a7d37a93a 7a:61:a2:49:4b:91 10.0.8.3/24
caa1d4ee2570 ba:8c:b9:dc:e1:c9 10.0.1.1/24 10.0.2.1/24
5245643870f1 ce:15:34:a9:b5:6d 10.2.5.1/24
e32a7d37a93a 7a:61:a2:49:4b:91 10.2.8.3/24
caa1d4ee2570 ba:8c:b9:dc:e1:c9 10.2.1.1/24 10.2.2.1/24
On each line are the container ID, its MAC address, then the list of
IP address/routing prefix length ([CIDR
test/100_cross_hosts_test.sh
+2 -2
View File
@@ -2,8 +2,8 @@
. ./config.sh
C1=10.1.1.4
C2=10.1.1.7
C1=10.2.1.4
C2=10.2.1.7
start_suite "Ping over cross-host weave network"
test/110_encryption_test.sh
+2 -2
View File
@@ -2,8 +2,8 @@
. ./config.sh
C1=10.1.1.4
C2=10.1.1.7
C1=10.2.1.4
C2=10.2.1.7
start_suite "Ping over encrypted cross-host weave network"
test/200_dns_test.sh
+1 -1
View File
@@ -9,7 +9,7 @@ start_suite "Resolve names on a single host"
run_on $HOST1 sudo $WEAVE stop || true
run_on $HOST1 sudo $WEAVE stop-dns || true
run_on $HOST1 sudo $WEAVE launch-dns 10.0.0.2/8
run_on $HOST1 sudo $WEAVE launch-dns 10.2.254.1/24
docker_on $HOST1 rm -f c1 c2 || true
test/210_dns_multicast_test.sh
+2 -2
View File
@@ -16,8 +16,8 @@ done
run_on $HOST1 sudo $WEAVE launch
run_on $HOST2 sudo $WEAVE launch $HOST1
run_on $HOST1 sudo $WEAVE launch-dns 10.3.3.2/24 -debug
run_on $HOST2 sudo $WEAVE launch-dns 10.3.3.3/24 -debug
run_on $HOST1 sudo $WEAVE launch-dns 10.2.254.1/24 -debug
run_on $HOST2 sudo $WEAVE launch-dns 10.2.254.2/24 -debug
run_on $HOST2 sudo $WEAVE run $C2/24 -t --name=c2 -h seetwo.weave.local ubuntu
run_on $HOST1 sudo $WEAVE run --with-dns $C1/24 --name=c1 -t aanand/docker-dnsutils /bin/sh
test/220_dns_custom_test.sh
+1 -1
View File
@@ -9,7 +9,7 @@ start_suite "Resolve names in custom domain"
run_on $HOST1 sudo $WEAVE stop || true
run_on $HOST1 sudo $WEAVE stop-dns || true
run_on $HOST1 sudo $WEAVE launch-dns 10.0.0.2/8 --localDomain foo.bar.
run_on $HOST1 sudo $WEAVE launch-dns 10.2.254.1/24 --localDomain foo.bar.
docker_on $HOST1 rm -f c1 c2 || true
test/300_fallback_dns_test.sh
+2 -2
View File
@@ -5,10 +5,10 @@
start_suite "Resolve a non-weave address"
run_on $HOST1 sudo $WEAVE stop-dns || true
run_on $HOST1 sudo $WEAVE launch-dns 10.2.6.2 -debug
run_on $HOST1 sudo $WEAVE launch-dns 10.2.254.1/24 -debug
docker_on $HOST1 rm -f c1 || true
run_on $HOST1 sudo $WEAVE run --with-dns 10.1.1.5/24 --name=c1 -t aanand/docker-dnsutils /bin/sh
run_on $HOST1 sudo $WEAVE run --with-dns 10.2.1.5/24 --name=c1 -t aanand/docker-dnsutils /bin/sh
ok=$(docker -H tcp://$HOST1:2375 exec -i c1 dig +short -t MX weave.works)
assert "test -n \"$ok\" && echo pass" "pass"
weave
+1 -1
View File
@@ -84,7 +84,7 @@ is_cidr() {
validate_cidr() {
if ! is_cidr "$1" ; then
echo "Invalid CIDR: $1" >&2
echo "CIDR must of be of form <ip_address>/<routing_prefix_length>, e.g. 10.0.1.1/24" >&2
echo "CIDR must of be of form <ip_address>/<routing_prefix_length>, e.g. 10.2.1.1/24" >&2
exit 1
fi
}
weavedns/README.md
+11 -11
View File
@@ -18,9 +18,9 @@ domain registers it in weaveDNS. For example:
```bash
$ weave launch
$ weave launch-dns 10.1.254.1/24
$ weave run 10.1.1.25/24 -ti -h pingme.weave.local ubuntu
$ shell1=$(weave run --with-dns 10.1.1.26/24 -ti -h ubuntu.weave.local ubuntu)
$ weave launch-dns 10.2.254.1/24
$ weave run 10.2.1.25/24 -ti -h pingme.weave.local ubuntu
$ shell1=$(weave run --with-dns 10.2.1.26/24 -ti -h ubuntu.weave.local ubuntu)
$ docker attach $shell1
# ping pingme
@@ -31,8 +31,8 @@ Each weaveDNS container started with `launch-dns` needs to be given
its own, unique, IP address, in a subnet that is a) common to all
weaveDNS containers, b) disjoint from the application subnets, and c)
not in use on any of the hosts. In our example the weaveDNS address is
in subnet 10.1.254.0/24 and the application containers are in
subnet 10.1.1.0/24.
in subnet 10.2.254.0/24 and the application containers are in
subnet 10.2.1.0/24.
WeaveDNS containers can be stopped with `stop-dns`.
@@ -67,7 +67,7 @@ hostnames across all sub-domains plus some external domains, you need
behaviour.
```bash
weave run --with-dns 10.1.1.4/24 -ti \
weave run --with-dns 10.2.1.4/24 -ti \
--dns-search=zone1.weave.local --dns-search=zone2.weave.local \
--dns-search=corp1.com --dns-search=corp2.com \
--dns-search=weave.local ubuntu
@@ -95,7 +95,7 @@ supply a different bridge device, use the environment variable
`DOCKER_BRIDGE`, e.g.,
```bash
$ sudo DOCKER_BRIDGE=someother weave launch-dns 10.1.254.1/24
$ sudo DOCKER_BRIDGE=someother weave launch-dns 10.2.254.1/24
```
### Supplying the DNS server
@@ -107,7 +107,7 @@ make it use weaveDNS:
```bash
$ docker_ip=$(docker inspect --format='{{ .NetworkSettings.Gateway }}' weavedns)
$ shell2=$(docker run --dns=$docker_ip -ti ubuntu)
$ weave attach 10.1.1.27/24 $shell2
$ weave attach 10.2.1.27/24 $shell2
```
This isn't very useful unless the container is also attached to the
@@ -142,7 +142,7 @@ its hostname, you can register it using the HTTP API:
```bash
$ docker start $shell2
$ curl -X PUT "http://$dns_ip:6785/name/$shell2/10.1.1.27" -d fqdn=shell2.weave.local
$ curl -X PUT "http://$dns_ip:6785/name/$shell2/10.2.1.27" -d fqdn=shell2.weave.local
```
### Registering multiple containers with the same name
@@ -163,7 +163,7 @@ containers that die. You can tell it not to, by adding `--watch=false`
to the container args:
```bash
$ weave launch-dns 10.1.254.1/24 --watch=false
$ weave launch-dns 10.2.254.1/24 --watch=false
```
### Unregistering
@@ -174,7 +174,7 @@ API with e.g., `curl`:
```bash
$ docker stop $shell2
$ dns_ip=$(docker inspect --format='{{ .NetworkSettings.IPAddress }}' weavedns)
$ curl -X DELETE "http://$dns_ip:6785/name/$shell2/10.1.1.27"
$ curl -X DELETE "http://$dns_ip:6785/name/$shell2/10.2.1.27"
```
## Present limitations