From 9e20a5256bc147f38dd81c5f7042d391c3e5a168 Mon Sep 17 00:00:00 2001 From: Adam Harrison Date: Thu, 18 Jun 2015 10:32:15 +0100 Subject: [PATCH] Rename example containers --- README.md | 20 ++++++++++---------- site/features.md | 48 ++++++++++++++++++++++++------------------------ 2 files changed, 34 insertions(+), 34 deletions(-) diff --git a/README.md b/README.md index 72d45ae6..b14f0f68 100644 --- a/README.md +++ b/README.md @@ -56,7 +56,7 @@ On `$HOST1` run host1$ weave launch host1$ weave launch-dns - host1$ weave run --name h1c1 -ti ubuntu + host1$ weave run --name a1 -ti ubuntu The first two lines start the weave router and DNS, each inside their own container - this needs to be done once per host. Whilst the @@ -81,7 +81,7 @@ Next we repeat similar steps on `$HOST2`... host2$ weave launch $HOST1 host2$ weave launch-dns - host2$ weave run --name h2c1 -ti ubuntu + host2$ weave run --name a2 -ti ubuntu The only difference, apart from the name of the application container, is that we tell our weave that it should peer with the weave on @@ -103,19 +103,19 @@ can talk to each other... On `$HOST1`... - host1$ docker attach h1c1 - root@h1c1:/# ping -c 1 -q h2c1 - PING h2c1.weave.local (10.160.0.2) 56(84) bytes of data. - --- h2c1.weave.local ping statistics --- + host1$ docker attach a1 + root@a1:/# ping -c 1 -q a2 + PING a2.weave.local (10.160.0.2) 56(84) bytes of data. + --- a2.weave.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.341/0.341/0.341/0.000 ms Similarly, on `$HOST2`... - host2$ docker attach h2c1 - root@h2c1:/# ping -c 1 -q h1c1 - PING h1c1.weave.local (10.128.0.2) 56(84) bytes of data. - --- h1c1.weave.local ping statistics --- + host2$ docker attach a2 + root@a2:/# ping -c 1 -q a1 + PING a1.weave.local (10.128.0.2) 56(84) bytes of data. + --- a1.weave.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.366/0.366/0.366/0.000 ms diff --git a/site/features.md b/site/features.md index 224d7d62..478968e0 100644 --- a/site/features.md +++ b/site/features.md @@ -36,18 +36,18 @@ connected. Containers can easily access services from each other; e.g. in the container on `$HOST1` we can start a netcat "service" with - root@h1c1:/# nc -lk -p 4422 + root@a1:/# nc -lk -p 4422 and then connect to it from the container on `$HOST2` with - root@h2c1:/# echo 'Hello, world.' | nc h1c1 4422 + root@a2:/# echo 'Hello, world.' | nc a1 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@h1c1:/# nc -lu -p 5533 + root@a1:/# nc -lu -p 5533 - root@h2c1:/# echo 'Hello, world.' | nc -u h1c1 5533 + root@a2:/# echo 'Hello, world.' | nc -u a1 5533 We can deploy the entire arsenal of standard network tools and applications, developed over decades, to configure, secure, monitor, @@ -117,33 +117,33 @@ This delegates the entire 10.2.0.0/16 subnet to weave, and instructs it to allocate from 10.2.1.0/24 within that if no specific subnet is specified. Now we can launch some containers in the default subnet: - host1$ weave run --name h1c1 -ti ubuntu - host2$ weave run --name h2c1 -ti ubuntu + host1$ weave run --name a1 -ti ubuntu + host2$ weave run --name a2 -ti ubuntu And some more containers in a different subnet: - host1$ weave run net:10.2.2.0/24 --name h1c2 -ti ubuntu - host2$ weave run net:10.2.2.0.24 --name h2c2 -ti ubuntu + host1$ weave run net:10.2.2.0/24 --name b1 -ti ubuntu + host2$ weave run net:10.2.2.0.24 --name b2 -ti 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 h1c2 + host1:~$ docker attach b1 - root@h1c2:/# ping -c 1 -q h2c2 - PING h2c2.weave.local (10.2.2.128) 56(84) bytes of data. - --- h2c2.weave.local ping statistics --- + root@b1:/# ping -c 1 -q b2 + PING b2.weave.local (10.2.2.128) 56(84) bytes of data. + --- b2.weave.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.338/1.338/1.338/0.000 ms - root@h1c2:/# ping -c 1 -q h1c1 - PING h1c1.weave.local (10.2.1.2) 56(84) bytes of data. - --- h1c1.weave.local ping statistics --- + root@b1:/# ping -c 1 -q a1 + PING a1.weave.local (10.2.1.2) 56(84) bytes of data. + --- a1.weave.local ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms - root@h1c2:/# ping -c 1 -q h2c1 - PING h2c1.weave.local (10.2.1.130) 56(84) bytes of data. - --- h2c1.weave.local ping statistics --- + root@b1:/# ping -c 1 -q a2 + PING a2.weave.local (10.2.1.130) 56(84) bytes of data. + --- a2.weave.local ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms @@ -241,8 +241,8 @@ Now, after finding allocated IPs via `weave ps` host2$ weave ps weave:expose weave:expose 02:80:5c:02:f1:b2 10.2.1.132/24 - host1$ weave ps h1c1 - h1c1 1e:88:d7:5b:77:68 10.2.1.2/24 + host1$ weave ps a1 + a1 1e:88:d7:5b:77:68 10.2.1.2/24 this @@ -283,8 +283,8 @@ explained [above](#host-network-integration), i.e. Then we add a NAT rule to route from the outside world to the destination container service. - host1$ weave ps h1c1 - h1c1 1e:88:d7:5b:77:68 10.2.1.2/24 + host1$ weave ps a1 + a1 1e:88:d7:5b:77:68 10.2.1.2/24 host2$ iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 2211 \ -j DNAT --to-destination 10.2.1.2:4422 @@ -292,7 +292,7 @@ destination container service. 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 h1c1. +container a1. With the above in place, we can connect to our 'nc' service from anywhere with @@ -340,7 +340,7 @@ service on port 2211, e.g. then we can connect to it from our application container on `$HOST2` with - root@h2c1:/# echo 'Hello, world.' | nc host1 3322 + root@a2:/# echo 'Hello, world.' | nc host1 3322 The same command will work from any application container.