Update features docs to use proxy
This commit is contained in:
Adam Harrison committed
1 parent
344119f42a
commit
81d5a8f4f5
1 file changed
+43
-50
+43
-50
@@ -23,9 +23,7 @@ example](https://github.com/weaveworks/weave#example):
|
||||
* [Dynamic topologies](#dynamic-topologies)
|
||||
* [Container mobility](#container-mobility)
|
||||
* [Fault tolerance](#fault-tolerance)
|
||||
* [Automatic IP address management](#ipam)
|
||||
* [Automatic discovery with WeaveDNS](#dns)
|
||||
* [Working with the Docker CLI and API](#proxy)
|
||||
* [Further reading](#further-reading)
|
||||
|
||||
### <a name="virtual-ethernet-switch"></a>Virtual Ethernet Switch
|
||||
|
||||
@@ -67,25 +65,25 @@ notation](http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notat
|
||||
|
||||
On $HOST1:
|
||||
|
||||
host1$ C=$(weave run 10.2.1.1/24 -ti ubuntu)
|
||||
host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti ubuntu
|
||||
root@7ca0f6ecf59f:/#
|
||||
|
||||
And $HOST2:
|
||||
|
||||
host2$ C=$(weave run 10.2.1.2/24 -ti ubuntu)
|
||||
host2$ docker run -e WEAVE_CIDR=10.2.1.2/24 -ti ubuntu
|
||||
root@04c4831fafd3:/#
|
||||
|
||||
Then on $HOST1...
|
||||
Then in the container on $HOST1...
|
||||
|
||||
host1$ docker attach $C
|
||||
root@28841bd02eff:/# ping -c 1 -q 10.2.1.2
|
||||
root@7ca0f6ecf59f:/# 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...
|
||||
Similarly, in the container on $HOST2...
|
||||
|
||||
host2$ docker attach $C
|
||||
root@f76829496120:/# ping -c 1 -q 10.2.1.1
|
||||
root@04c4831fafd3:/# 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
|
||||
@@ -93,10 +91,10 @@ Similarly, on $HOST2...
|
||||
|
||||
The IP addresses and netmasks can be anything you like, but make sure
|
||||
they don't conflict with any IP ranges in use on the hosts (including
|
||||
those delegated to IPAM) or IP addresses of external services the
|
||||
hosts or containers need to connect to. The same IP range must be used
|
||||
everywhere, and the individual IP addresses must, of course, be
|
||||
unique.
|
||||
those delegated to weave's [automatic IP address allocator](#ipam)) or
|
||||
IP addresses of external services the hosts or containers need to
|
||||
connect to. The same IP range must be used everywhere, and the
|
||||
individual IP addresses must, of course, be unique.
|
||||
|
||||
### <a name="application-isolation"></a>Application isolation
|
||||
|
||||
@@ -109,27 +107,27 @@ Let's begin by configuring weave's allocator to manage multiple
|
||||
subnets:
|
||||
|
||||
host1$ weave launch -iprange 10.2.0.0/16 -ipsubnet 10.2.1.0/24
|
||||
host1$ weave launch-dns
|
||||
host1$ weave launch-dns && weave launch-proxy
|
||||
host1$ eval $(weave proxy-env)
|
||||
host2$ weave launch -iprange 10.2.0.0/16 -ipsubnet 10.2.1.0/24 $HOST1
|
||||
host2$ weave launch-dns
|
||||
host2$ weave launch-dns && weave launch-proxy
|
||||
host2$ eval $(weave proxy-env)
|
||||
|
||||
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 a1 -ti ubuntu
|
||||
host2$ weave run --name a2 -ti ubuntu
|
||||
host1$ docker run --name a1 -ti ubuntu
|
||||
host2$ docker run --name a2 -ti ubuntu
|
||||
|
||||
And some more containers in a different subnet:
|
||||
|
||||
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
|
||||
host1$ docker run -e WEAVE_CIDR=net:10.2.2.0/24 --name b1 -ti ubuntu
|
||||
host2$ docker run -e WEAVE_CIDR=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 b1
|
||||
|
||||
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 ---
|
||||
@@ -153,7 +151,11 @@ well-known technique from the 'on metal' days to containers.
|
||||
If desired, a container can be attached to multiple subnets when it is
|
||||
started:
|
||||
|
||||
host1$ weave run net:default net:10.2.2.0/24 -ti ubuntu
|
||||
host1$ docker run -e WEAVE_CIDR="net:default net:10.2.2.0/24" -ti ubuntu
|
||||
|
||||
`net:default` is used here to request allocation of an address from
|
||||
the default subnet in addition to one from an explicitly specified
|
||||
range.
|
||||
|
||||
NB: By default docker permits communication between containers on the
|
||||
same host, via their docker-assigned IP addresses. For complete
|
||||
@@ -166,17 +168,19 @@ be accomplished by starting them with the `--cap-drop net_raw` option.
|
||||
|
||||
### <a name="dynamic-network-attachment"></a>Dynamic network attachment
|
||||
|
||||
In some scenarios containers are started independently, e.g. via some
|
||||
existing tool chain, or require more complex startup sequences than
|
||||
provided by `weave run`. And sometimes the decision which application
|
||||
network a container should be part of is made post-startup. For these
|
||||
situations, weave allows an existing, running container to be attached
|
||||
to the weave network. To illustrate, we can achieve the same effect as
|
||||
the first example with
|
||||
Sometimes the application network to which a container should be
|
||||
attached is not known in advance. For these situations, weave allows
|
||||
an existing, running container to be attached 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$ C=$(docker run -e WEAVE_CIDR=none -dti ubuntu)
|
||||
host1$ weave attach $C
|
||||
|
||||
(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.)
|
||||
|
||||
There is a matching `weave detach` command:
|
||||
|
||||
host1$ weave detach $C
|
||||
@@ -479,23 +483,12 @@ restarted in that event, and indeed may not even experience a
|
||||
temporary connectivity failure if the weave container is restarted
|
||||
quickly enough.
|
||||
|
||||
### <a name="ipam"></a>Automatic IP Address Management
|
||||
### <a name="further-reading"></a>Further reading
|
||||
|
||||
Weave can automatically assign unique IP addresses to each container
|
||||
across the network. The `run`, `start`, `attach`, `expose` and `hide`
|
||||
commands will then fetch an address automatically if none is
|
||||
specified. See the [IPAM](ipam.html) documentation for details on how
|
||||
to enable and use this feature.
|
||||
We have made use of weave's automatic IP address allocation, DNS
|
||||
server, and proxy throughout the examples. Each of these components
|
||||
offers additional functionality which you can read about here:
|
||||
|
||||
### <a name="dns"></a>Automatic discovery with WeaveDNS
|
||||
|
||||
WeaveDNS is a distributed DNS service for weave networks, enabling
|
||||
containers to address each other by name rather than IP address. Find
|
||||
out more about WeaveDNS from its [documentation](weavedns.html).
|
||||
|
||||
### <a name="proxy"></a>Working with the Docker CLI and API
|
||||
|
||||
Instead of the `weave` command-line utility, you may prefer to use the
|
||||
standard Docker command-line interface, or the Docker remote API, for
|
||||
starting weave-enabled containers. This can be accomplished with the
|
||||
[Weave Proxy](proxy.html).
|
||||
* [Automatic IP address management](ipam.html)
|
||||
* [Automatic discovery with WeaveDNS](weavedns.html)
|
||||
* [Configuring the interaction with Docker](proxy.html)
|
||||
Reference in new issue
Block a user