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

Merge pull request #2106 from weaveworks/patch-up-2103

Browse Source 
Patch up #2103
This commit is contained in:
Adam Harrison committed 2016-03-29 10:37:04 +01:00
2 parents 7c37cd98dd ec5008c702
commit a6bb02aca1
31 files changed
+71 -311
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

site/fastdp/using-fastdp.md
+6 -12
View File
@@ -14,9 +14,7 @@ See [How Fastdp Works](/site/fastdp/fastdp-how-it-works.md) for a more in-depth
You can disable fastdp by enabling the `WEAVE_NO_FASTDP` environment variable at `weave launch`:
~~~bash
$ WEAVE_NO_FASTDP=true weave launch
~~~
$ WEAVE_NO_FASTDP=true weave launch
###Fast Datapath and Encryption
@@ -36,20 +34,16 @@ The use of fast datapath is an automated connection-by-connection decision made
Once a Weave network is set up, you can query the connections using the `weave status connections` command:
~~~bash
$ weave status connections
<-192.168.122.25:43889 established fastdp a6:66:4f:a5:8a:11(ubuntu1204)
~~~
$ weave status connections
<-192.168.122.25:43889 established fastdp a6:66:4f:a5:8a:11(ubuntu1204)
Where fastdp indicates that fast datapath is being used on a connection. If fastdp is not shown, the field displays `sleeve` indicating Weave Net's fall-back encapsulation method:
~~~bash
$ weave status connections
<- 192.168.122.25:54782 established sleeve 8a:50:4c:23:11:ae(ubuntu1204)
~~~
$ weave status connections
<- 192.168.122.25:54782 established sleeve 8a:50:4c:23:11:ae(ubuntu1204)
**See Also**
* [Deploying Applications to Weave](/site/using-weave/deploying-applications.md)
* [How Fastdp Works](/site/fastdp/fastdp-how-it-works.md)
site/ip-addresses/configuring-weave.md
-2
View File
@@ -13,11 +13,9 @@ cause a clash.
If after `weave launch`, the following error message
appears:
~~~bash
Network 10.32.0.0/12 overlaps with existing route 10.0.0.0/8 on host.
ERROR: Default --ipalloc-range 10.32.0.0/12 overlaps with existing route on host.
You must pick another range and set it on all hosts.
~~~
As the message indicates, the default range that Weave Net would like to use is
`10.32.0.0/12` - a 12-bit prefix, where all addresses start with the bit
site/ip-addresses/ip-addresses.md
-2
View File
@@ -42,12 +42,10 @@ Several websites offer calculators to decode this kind of address, see: [IP Addr
The following is an example route table for a container that is attached to a Weave
network:
~~~bash
# ip route show
default via 172.17.42.1 dev eth0
10.2.2.0/24 dev ethwe proto kernel scope link src 10.2.2.1
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.170
~~~
It has two interfaces: one that Docker gave it called `eth0`, and one
that weave gave it called `ethwe`. They are on networks
site/ipam/allocation-multi-ipam.md
+2 -2
View File
@@ -23,7 +23,7 @@ for instance:
host1$ docker run -e WEAVE_CIDR="net:10.2.7.0/24 net:10.2.8.0/24 ip:10.3.9.1/24" -ti ubuntu
>>**Note:** The ".0" and ".-1" addresses in a subnet are not used, as required by
>**Note:** The ".0" and ".-1" addresses in a subnet are not used, as required by
[RFC 1122](https://tools.ietf.org/html/rfc1122#page-29)).
When working with multiple subnets in this way, it is usually
@@ -64,4 +64,4 @@ for manual allocation.
* [Address Allocation with IP Address Management (IPAM)](/site/ipam/overview-init-ipam.md)
* [Isolating Applications on a Weave Network](/site/using-weave/isolating-applications.md)
* [Starting, Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md)
* [Starting, Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md)
site/ipam/overview-init-ipam.md
+3 -11
View File
@@ -67,20 +67,16 @@ To illustrate, suppose you have three hosts, accessible to each other
as `$HOST1`, `$HOST2` and `$HOST3`. You can start Weave Net on those three
hosts using these three commands:
~~~bash
host1$ weave launch $HOST2 $HOST3
host2$ weave launch $HOST1 $HOST3
host3$ weave launch $HOST1 $HOST2
~~~
host1$ weave launch $HOST2 $HOST3
host2$ weave launch $HOST1 $HOST3
host3$ weave launch $HOST1 $HOST2
Or, if it is not convenient to name all the other hosts at launch
time, you can pass the number of peers like this:
~~~bash
host1$ weave launch --init-peer-count 3
host2$ weave launch --init-peer-count 3 $HOST3
host3$ weave launch --init-peer-count 3 $HOST2
~~~
The consensus mechanism used to determine a majority, transitions
through three states: 'deferred', 'waiting' and 'achieved':
@@ -97,9 +93,7 @@ Finally, some (but never all) peers can be launched as consensus
observers rather than participants by specifying the `--observer`
option:
~~~bash
host4$ weave launch --observer $HOST3
~~~
You do not need to specify an initial peer count to such peers. This
can be useful to add ephemeral peers to an existing fixed cluster (for
@@ -137,7 +131,6 @@ independent set again.
To illustrate this last point, the following sequence of operations
is safe with respect to Weave Net's startup quorum:
~~~bash
host1$ weave launch
...time passes...
host2$ weave launch $HOST1
@@ -146,7 +139,6 @@ is safe with respect to Weave Net's startup quorum:
...time passes...
...host1 is rebooted...
host1$ weave launch $HOST2 $HOST3
~~~
### <a name="forcing-consensus"></a>Forcing Consensus
site/ipam/stop-remove-peers-ipam.md
-2
View File
@@ -26,10 +26,8 @@ Assume you had started the three peers in the
[overview example](/site/ipam/overview-init-ipam.md), and then host3
caught fire, you can go to one of the other hosts and run:
~~~bash
host1$ weave rmpeer host3
524288 IPs taken over from host3
~~~
Weave Net takes all the IP address ranges owned by host3 and transfers
them to be owned by host1. The name "host3" is resolved via the
site/ipam/troubleshooting-ipam.md
+4 -4
View File
@@ -6,18 +6,18 @@ layout: default
The command
~~~bash
weave status
~~~
reports on the current status of the weave router and IP allocator:
~~~bash
````
...
Service: ipam
Status: awaiting consensus (quorum: 2, known: 0)
Range: 10.32.0.0-10.47.255.255
DefaultSubnet: 10.32.0.0/12
~~~
...
````
The first section covers the router; see the [troubleshooting
guide](/site/troubleshooting.md#weave-status) for full details.
site/plugin/cni-plugin-how-to.md
-10
View File
@@ -16,16 +16,12 @@ your machine has the directories normally used to host CNI plugins.
To create those directories, run (as root):
~~~bash
mkdir -p /opt/cni/bin
mkdir -p /etc/cni/net.d
~~~
Then run:
~~~bash
weave setup
~~~
###Launching Weave Net
@@ -37,10 +33,8 @@ See [Deploying Applications to Weave Net](/site/using-weave/deploying-applicatio
As well as launching Weave Net, you have to run an extra command to
perform some additional configuration of the Weave bridge:
~~~bash
weave launch <peer hosts>
weave expose
~~~
###Configuring Kubernetes to use the CNI Plugin
@@ -48,9 +42,7 @@ After you've launched Weave and peered your hosts, you can configure
Kubernetes to use Weave, by adding the following options to the
`kubelet` command:
~~~bash
--network-plugin=cni --network-plugin-dir=/etc/cni/net.d
~~~
See the [`kubelet` documentation](http://kubernetes.io/v1.1/docs/admin/kubelet.html)
for more details.
@@ -68,11 +60,9 @@ for details on the format and contents of this file.
By default, the Weave CNI plugin adds a default route out via the Weave bridge, so your containers can access resources on the internet. If you do not want this, add a section to the config file that specifies no routes:
~~~bash
"ipam": {
"routes": [ ]
}
~~~
The following other fields in the spec are supported:
site/plugin/plug-in-command-line.md
+1 -3
View File
@@ -8,10 +8,8 @@ layout: default
If you need to give additional arguments to the plugin independently, don't
use `weave launch`, but instead run:
~~~bash
$ weave launch-router [other peers]
$ weave launch-plugin [plugin arguments]
~~~
The plugin command-line arguments are:
@@ -32,4 +30,4 @@ route, add the `--no-multicast-route` flag to `weave launch-plugin`.
**See Also**
* [Using the Weave Net Docker Network Plugin](/site/plugin/weave-plugin-how-to.md)
* [How the Weave Network Plugin Works](/site/plugin/plugin-how-it-works.md)
* [How the Weave Network Plugin Works](/site/plugin/plugin-how-it-works.md)
site/plugin/weave-plugin-how-to.md
+10 -22
View File
@@ -16,9 +16,7 @@ See [Deploying Applications to Weave Net](/site/using-weave/deploying-applicatio
After you've launched Weave Net and peered your hosts, you can start containers using the following, for example:
~~~bash
$ docker run --net=weave -ti ubuntu
~~~
on any of the hosts, and they can all communicate with each other.
@@ -28,38 +26,30 @@ In order to use Weave Net's [Service Discovery](/site/weavedns/overview-using-we
must pass the additional arguments `--dns` and `-dns-search`, for
which a helper is provided in the Weave script:
~~~bash
$ docker run --net=weave -h foo.weave.local $(weave dns-args) -tdi ubuntu
$ docker run --net=weave -h bar.weave.local $(weave dns-args) -ti ubuntu
# ping foo
~~~
###Launching Weave Net and Running Containers Using the Plugin
Just launch the Weave Net router onto each host and make a peer connection with the other hosts:
~~~bash
host1$ weave launch host2
host2$ weave launch host1
~~~
host1$ weave launch host2
host2$ weave launch host1
then run your containers using the Docker command-line:
~~~bash
host1$ docker run --net=weave -ti ubuntu
root@1458e848cd90:/# hostname -i
10.32.0.2
~~~
host1$ docker run --net=weave -ti ubuntu
root@1458e848cd90:/# hostname -i
10.32.0.2
~~~bash
host2$ docker run --net=weave -ti ubuntu
root@8cc4b5dc5722:/# ping 10.32.0.2
host2$ docker run --net=weave -ti ubuntu
root@8cc4b5dc5722:/# ping 10.32.0.2
PING 10.32.0.2 (10.32.0.2) 56(84) bytes of data.
64 bytes from 10.32.0.2: icmp_seq=1 ttl=64 time=0.116 ms
64 bytes from 10.32.0.2: icmp_seq=2 ttl=64 time=0.052 ms
~~~
PING 10.32.0.2 (10.32.0.2) 56(84) bytes of data.
64 bytes from 10.32.0.2: icmp_seq=1 ttl=64 time=0.116 ms
64 bytes from 10.32.0.2: icmp_seq=2 ttl=64 time=0.052 ms
### Restarting the Plugin
@@ -70,9 +60,7 @@ Unfortunately, [Docker 1.9 may also try to communicate with the plugin before it
If you are using `systemd`, it is advised that you modify the Docker unit to remove the timeout on startup. This gives Docker enough time to abandon its attempts. For example, in the file `/lib/systemd/system/docker.service`, add the following under `[Service]`:
~~~bash
TimeoutStartSec=0
~~~
###Bypassing the Central Cluster Store When Building Docker Apps
site/troubleshooting.md
+13 -39
View File
@@ -19,9 +19,7 @@ layout: default
Check the version of Weave Net you are running using:
~~~bash
weave version
~~~
weave version
If it is not the latest version, as shown in the list of
[releases](https://github.com/weaveworks/weave/releases), then it is
@@ -30,9 +28,7 @@ recommended you upgrade using the
To check the Weave Net container logs:
~~~bash
docker logs weave
~~~
docker logs weave
A reasonable amount of information, and all errors, get logged there.
@@ -49,7 +45,7 @@ capture and analysis tools, such as tcpdump and wireshark, to the
A status summary can be obtained using `weave status`:
~~~bash
````
$ weave status
Version: 1.1.0
@@ -79,8 +75,7 @@ $ weave status
Service: plugin
DriverName: weave
~~~
````
The terms used here are explained further at
[How Weave Net Works](/site/router-topology/overview.md).
@@ -132,14 +127,14 @@ exponential back-off.
To view detailed information on the local Weave Net router's type `weave status connections`:
~~~bash
````
$ weave status connections
<- 192.168.48.12:33866 established unencrypted fastdp 7e:21:4a:70:2f:45(host2)
<- 192.168.48.13:60773 pending encrypted fastdp 7e:ae:cd:d5:23:8d(host3)
-> 192.168.48.14:6783 retrying dial tcp4 192.168.48.14:6783: no route to host
-> 192.168.48.15:6783 failed dial tcp4 192.168.48.15:6783: no route to host, retry: 2015-08-06 18:55:38.246910357 +0000 UTC
-> 192.168.48.16:6783 connecting
~~~
````
The columns are as follows:
@@ -163,7 +158,7 @@ The columns are as follows:
Detailed information on peers can be obtained with `weave status
peers`:
~~~bash
````
$ weave status peers
ce:31:e0:06:45:1a(host1)
<- 192.168.48.12:39634 ea:2d:b2:e6:e4:f5(host2) established
@@ -174,7 +169,7 @@ ea:2d:b2:e6:e4:f5(host2)
ee:38:33:a7:d9:71(host3)
-> 192.168.48.12:6783 ea:2d:b2:e6:e4:f5(host2) established
-> 192.168.48.11:6783 ce:31:e0:06:45:1a(host1) established
~~~
````
This lists all peers known to this router, including itself. Each
peer is shown with its name and nickname, then each line thereafter
@@ -188,7 +183,7 @@ the `host3` end of the same connection as `192.168.48.13:49619`.
Detailed information on DNS registrations can be obtained with `weave
status dns`:
~~~bash
````
$ weave status dns
one 10.32.0.1 eebd81120ee4 4a:0f:f6:ec:1c:93
one 10.43.255.255 4fcec78d2a9b 66:c4:47:c6:65:bf
@@ -199,7 +194,7 @@ three 10.40.0.2 8a9c2e2ef00f ba:98:d0:37:4f:1c
two 10.32.0.2 83689b8f34e0 4a:0f:f6:ec:1c:93
two 10.44.0.0 7edc306cb668 66:c4:47:c6:65:bf
two 10.40.0.1 68a5e9c2641b ba:98:d0:37:4f:1c
~~~
````
The columns are as follows:
@@ -210,9 +205,7 @@ The columns are as follows:
### <a name="weave-report"></a>Producing a JSON Report
~~~bash
$ weave report
~~~
weave report
Produces a comprehensive dump of the internal state of the router,
IPAM and DNS services in JSON format, including all the information
@@ -220,35 +213,26 @@ available from the `weave status` commands. You can also supply a
Golang text template to `weave report` in a similar fashion to `docker
inspect`:
~~~bash
$ weave report -f {% raw %}'{{.DNS.Domain}}'{% endraw %} weave.local.
~~~
$ weave report -f {% raw %}'{{.DNS.Domain}}'{% endraw %} weave.local.
Weave Net adds a template function, `json`, which can be applied to get
results in JSON format.
~~~bash
$ weave report -f {% raw %}'{{json .DNS}}'{% endraw %}
{% raw %}{"Domain":"weave.local.","Upstream":["8.8.8.8","8.8.4.4"],"Address":"172.17.0.1:53","TTL":1,"Entries":null}{% endraw %}
~~~
### <a name="list-attached-containers"></a>Listing Attached Containers
~~~bash
weave ps
~~~
weave ps
Produces a list of all containers running on this host that are
connected to the Weave network, like this:
~~~bash
weave:expose 7a:c4:8b:a1:e6:ad 10.2.5.2/24
b07565b06c53 ae:e3:07:9c:8c:d4
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
@@ -259,11 +243,9 @@ displays the Weave bridge MAC and any IP addresses added to it via the
You can also supply a list of container IDs/names to `weave ps`, like this:
~~~bash
$ weave ps able baker
able ce:15:34:a9:b5:6d 10.2.5.1/24
baker 7a:61:a2:49:4b:91 10.2.8.3/24
~~~
## <a name="stop"></a>Stopping Weave Net
@@ -271,15 +253,11 @@ To stop Weave Net, if you have configured your environment to use the
Weave Docker API Proxy, e.g. by running `eval $(weave env)` in your
shell, you must first restore the environment using:
~~~bash
eval $(weave env --restore)
~~~
Then run:
~~~bash
weave stop
~~~
Note that this leaves the local application container network intact.
Containers on the local host can continue to communicate, whereas
@@ -289,9 +267,7 @@ export/import, is disrupted but resumes once Weave is relaunched.
To stop Weave Net and to completely remove all traces of the Weave network on
the local host, run:
~~~bash
weave reset
~~~
Any running application containers permanently lose connectivity
with the Weave network and will have to be restarted in order to
@@ -319,11 +295,9 @@ Snapshot releases are published at times to provide previews of new
features, assist in the validation of bug fixes, etc. One can install the
latest snapshot release using:
~~~bash
sudo curl -L git.io/weave-snapshot -o /usr/local/bin/weave
sudo chmod a+x /usr/local/bin/weave
weave setup
~~~
Snapshot releases report the script version as "(unreleased version)",
and the container image versions as git hashes.
site/using-weave/application-isolation.md
+2 -16
View File
@@ -15,12 +15,10 @@ configure Weave Net's IP allocator to manage multiple subnets.
Using [the netcat example](/site/using-weave/deploying-applications.md), configure multiple subsets:
~~~bash
host1$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24
host1$ eval $(weave env)
host2$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24 $HOST1
host2$ eval $(weave env)
~~~
This delegates the entire 10.2.0.0/16 subnet to Weave Net, and instructs
it to allocate from 10.2.1.0/24 within that, if a specific subnet is not
@@ -28,53 +26,41 @@ specified.
Next, launch the two netcat containers onto the default subnet:
~~~bash
host1$ docker run --name a1 -ti ubuntu
host2$ docker run --name a2 -ti ubuntu
~~~
And then to test the isolation, launch a few more containers onto a different subnet:
~~~bash
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
~~~
Ping each container to confirm that they can talk to each other, but not to the containers of our first subnet:
~~~bash
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
~~~
~~~bash
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
~~~
~~~bash
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
~~~
If required, a container can also be attached to multiple subnets when it is started using:
~~~bash
host1$ docker run -e WEAVE_CIDR="net:default net:10.2.2.0/24" -ti ubuntu
~~~
`net:default` is used to request the allocation of an address from the default subnet in addition to one from an explicitly specified range.
>>**Important:** Containers must be prevented from capturing and injecting raw network packets - this can be accomplished by starting them with the `--cap-drop net_raw` option.
>**Important:** Containers must be prevented from capturing and injecting raw network packets - this can be accomplished by starting them with the `--cap-drop net_raw` option.
>>Note: By default docker permits communication between containers on the same host, via their docker-assigned IP addresses. For complete
>Note: By default docker permits communication between containers on the same host, via their docker-assigned IP addresses. For complete
isolation between application containers, that feature needs to be disabled by [setting `--icc=false`](https://docs.docker.com/engine/userguide/networking/default_network/container-communication/#communication-between-containers) in the docker daemon configuration.
**See Also**
site/using-weave/deploying-applications.md
+1 -13
View File
@@ -63,9 +63,7 @@ To specify multiple peers, supply a list of addresses to which you want to conne
For example:
~~~bash
`host2$:weave launch` <ip address> <ip address>
~~~
host2$ weave launch <ip address> <ip address>
Peers can also be dynamically added. See [Adding Hosts Dynamically](/site/using-weave/finding-adding-hosts-dynamically.md) for more information.
@@ -77,44 +75,34 @@ With two containers running on separate hosts, test that both containers are abl
From the container started on `$HOST1`...
~~~bash
root@a1:/# ping -c 1 -q a2
PING a2.weave.local (10.40.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, in the container started on `$HOST2`...
~~~bash
root@a2:/# ping -c 1 -q a1
PING a1.weave.local (10.32.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
~~~
###<a name="start-netcat"></a>Starting the Netcat Service
The `netcat` service can be started using the following commands:
~~~bash
root@a1:/# nc -lk -p 4422
~~~
and then connected to from the another container on `$HOST2` using:
~~~bash
root@a2:/# echo 'Hello, world.' | nc a1 4422
~~~
Weave Net supports *any* protocol, and it doesn't have to be over TCP/IP. For example, a netcat UDP service can also be run by using the following:
~~~bash
root@a1:/# nc -lu -p 5533
root@a2:/# echo 'Hello, world.' | nc -u a1 5533
~~~
**See Also**
site/using-weave/dynamically-attach-containers.md
+1 -11
View File
@@ -8,11 +8,9 @@ When containers may not know the network to which they will be attached, Weave N
To illustrate...
~~~bash
host1$ C=$(docker run -e WEAVE_CIDR=none -dti ubuntu)
host1$ weave attach $C
10.2.1.3
~~~
where,
@@ -20,43 +18,35 @@ where,
* `weave attach` – the Weave Net command to attach to the specified container
* `10.2.1.3` - the allocated IP address output by `weave attach`, in this case in the default subnet
>>Note If you are using the Weave Docker API proxy, it will have modified `DOCKER_HOST` to point to the proxy and therefore you will 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.
>Note If you are using the Weave Docker API proxy, it will have modified `DOCKER_HOST` to point to the proxy and therefore you will 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.
###Dynamically Detaching Containers
A container can be detached from a subnet, by using the `weave detach` command:
~~~bash
host1$ weave detach $C
10.2.1.3
~~~
You can also detach a container from one network and then attach it to a different one:
~~~bash
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 the same container between applications:
~~~bash
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 using a single command:
~~~bash
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
~~~
>**Important!** Any addresses that were dynamically attached will not be re-attached if the container restarts.
site/using-weave/finding-adding-hosts-dynamically.md
+1 -9
View File
@@ -20,9 +20,7 @@ To accomplish this, launch Weave Net onto the new host
without supplying any additional addresses. And then, from one
of the existing hosts run:
~~~bash
host# weave connect $NEW_HOST
~~~
Other hosts on the Weave network will automatically attempt
to establish connections to the new host as well.
@@ -31,9 +29,7 @@ Alternatively, you can also instruct a peer to forget a
particular host specified to it via `weave launch` or
`weave connect` by running:
~~~bash
host# weave forget $DECOMMISSIONED_HOST
~~~
This prevents the peer from trying to reconnect to that host
once connectivity to it is lost, and therefore can be used
@@ -43,9 +39,7 @@ from the network.
Hosts may also be bulk-replaced. All existing hosts
will be forgotten, and the new hosts will be added:
~~~bash
host# weave connect --replace $NEW_HOST1 $NEW_HOST2
~~~
For complete control over the peer topology, automatic
discovery can be disabled using the `--no-discovery`
@@ -58,11 +52,9 @@ A list of all hosts that a peer has been asked to connect
to with `weave launch` and `weave connect`
can be obtained using:
~~~bash
host# weave status targets
~~~
**See Also**
* [Enabling Multi-Cloud, Multi-Hop Networking and Routing](/site/using-weave/multi-cloud-multi-hop.md)
* [Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md)
* [Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md)
site/using-weave/host-network-integration.md
-10
View File
@@ -9,44 +9,34 @@ For example, returning to the [netcat example](/site/using-weave/deploying-appli
On `$HOST2` run:
~~~bash
host2$ weave expose
10.2.1.132
~~~
This command grants the host access to all of the application containers in the default subnet. An IP address is allocated by Weave Net especially for that purpose, and is returned after running `weave expose`.
Now you are able to ping the host:
~~~bash
host2$ ping 10.2.1.132
~~~
And you can also ping the `a1` netcat application container residing on `$HOST1`:
~~~bash
host2$ ping $(weave dns-lookup a1)
~~~
###Exposing Multiple Subnets
Multiple subnet addresses can be exposed or hidden using a single command:
~~~bash
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
~~~
###Adding Exposed Addresses to weavedns
Exposed addresses can also be added to `weavedns` by supplying fully qualified domain names:
~~~bash
host2$ weave expose -h exposed.weave.local
10.2.1.132
~~~
**See Also**
site/using-weave/isolating-applications.md
-14
View File
@@ -7,60 +7,46 @@ In some instances, you may need to run applications on the same container networ
To do this, you need to configure Weave's IP allocator to manage multiple subnets:
~~~bash
host1$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24
host1$ eval $(weave env)
host2$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24 $HOST1
host2$ eval $(weave env)
~~~
This delegates the entire 10.2.0.0/16 subnet to Weave Net, and instructs it to allocate from 10.2.1.0/24 within that if no specific subnet is specified.
Now you can launch two containers onto the default subnet:
~~~bash
host1$ docker run --name a1 -ti ubuntu
host2$ docker run --name a2 -ti ubuntu
~~~
And then launch several more containers onto a different subnet:
~~~bash
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
~~~
Ping the containers from each subnet to confirm that they can communicate with each other, but not to the containers of our first subnet:
~~~bash
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
~~~
~~~bash
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
~~~
~~~bash
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
~~~
###Attaching Containers to Multiple Subnets and Isolating Applications
A container can also be attached to multiple subnets by using the following command line arguments with `docker run`:
~~~bash
host1$ docker run -e WEAVE_CIDR="net:default net:10.2.2.0/24" -ti ubuntu
~~~
Where,
site/using-weave/manual-ip-address.md
+14 -24
View File
@@ -5,10 +5,8 @@ layout: default
Containers are automatically allocated an IP address that is unique across the Weave network. You can see which address was allocated by running, [`weave ps`](/site/troubleshooting.md#weave-status):
~~~bash
host1$ weave ps a1
a7aee7233393 7a:44:d3:11:10:70 10.32.0.2/12
~~~
Weave Net detects when a container has exited and releases its allocated addresses so they can be re-used by the network.
@@ -23,37 +21,29 @@ For example, we can launch a couple of containers on `$HOST1` and
On `$HOST1`:
~~~bash
host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti ubuntu
root@7ca0f6ecf59f:/#
~~~
host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti ubuntu
root@7ca0f6ecf59f:/#
And `$HOST2`:
~~~bash
host2$ docker run -e WEAVE_CIDR=10.2.1.2/24 -ti ubuntu
root@04c4831fafd3:/#
~~~
host2$ docker run -e WEAVE_CIDR=10.2.1.2/24 -ti ubuntu
root@04c4831fafd3:/#
Then test that the container on `$HOST2` can be reached from the container on `$HOST1`:
~~~bash
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
~~~
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
And in the other direction...
~~~bash
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
round-trip min/avg/max/stddev = 1.034/1.034/1.034/0.000 ms
~~~
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
round-trip min/avg/max/stddev = 1.034/1.034/1.034/0.000 ms
The IP addresses and netmasks can be set to anything, but ensure they don’t conflict with any of the IP ranges in use on the hosts or with IP addresses used by any external services to which the hosts or containers may need to connect.
site/using-weave/security-untrusted-networks.md
-6
View File
@@ -8,16 +8,12 @@ To connect containers across untrusted networks, Weave Net peers can be instruct
For example:
~~~bash
host1$ weave launch --password wfvAwt7sj
~~~
or
~~~bash
host1$ export WEAVE_PASSWORD=wfvAwt7sj
host1$ weave launch
~~~
>NOTE: The command line option takes precedence over the environment variable._
@@ -28,9 +24,7 @@ or
To guard against dictionary attacks, the password needs to be reasonably strong with at least 50 bits of entropy is recommended. An easy way to generate a random password that satisfies this requirement is:
~~~bash
< /dev/urandom tr -dc A-Za-z0-9 | head -c9 ; echo
~~~
The same password must be specified for all Weave Net peers, by default both control and data plane traffic will then use authenticated encryption.
site/using-weave/service-export.md
-6
View File
@@ -13,25 +13,19 @@ you can expose the netcat service running on `HOST1` and make it accessible to t
First, expose the application network to `$HOST2`, as explained in [Integrating a Host Network with a Weave Net](/site/using-weave/host-network-integration.md):
~~~bash
host2$ weave expose
10.2.1.132
~~~
Then add a NAT rule that routes the traffic from the outside world to the destination container service.
~~~bash
host2$ iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 2211 \
-j DNAT --to-destination $(weave dns-lookup a1):4422
~~~
In this example, it is assumed that the "outside world" is connecting to `$HOST2` via 'eth0'. The TCP traffic to port 2211 on the external IPs will be routed to the 'nc' service running on port 4422 in the container a1.
With the above in place, you can connect to the 'nc' service from anywhere using:
~~~bash
echo 'Hello, world.' | nc $HOST2 2211
~~~
>**Note:** Due to the way routing is handled in the Linux kernel, this won't work when run *on* `$HOST2`.
site/using-weave/service-management.md
+1 -21
View File
@@ -21,24 +21,18 @@ Turning back to the [netcat example](/site/using-weave/deploying-applications.md
To do this, expose the application network to `$HOST2`, as explained in [Host Network Integration](/site/using-weave/host-network-integration.md) by running:
~~~bash
host2$ weave expose
10.2.1.132
~~~
Then add a NAT rule to route from the outside world to the destination container service.
~~~bash
host2$ iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 2211 \
-j DNAT --to-destination $(weave dns-lookup a1):4422
~~~
Here it is assumed that the "outside world" is connecting to `$HOST2` via 'eth0'. The TCP traffic to port 2211 on the external IPs will be routed to the 'nc' service, running in the a1 container and listening on port 4422.
With the above in place, you are ready to connect to the 'nc' service from anywhere using:
~~~bash
echo 'Hello, world.' | nc $HOST2 2211
~~~
$ echo 'Hello, world.' | nc $HOST2 2211
>**Note:** Due to the way routing is handled in the Linux kernel, this won't work when run *on* `$HOST2`.
@@ -56,30 +50,22 @@ An additional caveat is that `$HOST3` can only be reached from `$HOST1`, which i
To satisfy this scenario, first [expose the application network to the host](/site/using-weave/host-network-integration.md) by running the following on `$HOST1`:
~~~bash
host1$ weave expose -h host1.weave.local
10.2.1.3
~~~
Then add a NAT rule, which routes from the above IP to the destination service.
~~~bash
host1$ iptables -t nat -A PREROUTING -p tcp -d 10.2.1.3 --dport 3322 \
-j DNAT --to-destination $HOST3:2211
~~~
This allows any application container to reach the service by connecting to 10.2.1.3:3322. So if `$HOST3` is running a
netcat service on port 2211:
~~~bash
host3$ nc -lk -p 2211
~~~
You can now connect to it from the application container running on `$HOST2` using:
~~~bash
root@a2:/# echo 'Hello, world.' | nc host1 3322
~~~
Note that you should be able to run this command from any application container.
@@ -101,23 +87,17 @@ Expanding on the [netcat example](/site/using-weave/deploying-applications.md),
Begin importing the service onto `$HOST2` by first exposing the application network:
~~~bash
host2$ weave expose
10.2.1.3
~~~
Then add a NAT rule which routes traffic from the `$HOST2` network (for example, anything that can connect to `$HOST2`) to the service endpoint on the Weave network:
~~~bash
host2$ iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4433 \
-j DNAT --to-destination 10.2.1.3:3322
~~~
Now any host on the same network as `$HOST2` is able to access the service:
~~~bash
echo 'Hello, world.' | nc $HOST2 4433
~~~
###<a name="change-location"></a>Dynamically Changing Service Locations
site/weave-docker-api/automatic-discovery-proxy.md
+1 -7
View File
@@ -28,10 +28,8 @@ Additionally, the hostname is matched against a regular expression `<regexp>` an
For example, you can launch the proxy using all three flags, as follows:
~~~bash
host1$ weave launch-router && weave launch-proxy --hostname-from-label hostname-label --hostname-match '^aws-[0-9]+-(.*)$' --hostname-replacement 'my-app-$1'
host1$ eval $(weave env)
~~~
>**Note:** regexp substitution groups must be pre-pended with a dollar sign
(for example, `$1`). For further details on the regular expression syntax see
@@ -39,22 +37,18 @@ For example, you can launch the proxy using all three flags, as follows:
After launching the Weave Net proxy with these flags, running a container named `aws-12798186823-foo` without labels results in weavedns registering the hostname `my-app-foo` and not `aws-12798186823-foo`.
~~~bash
host1$ docker run -ti --name=aws-12798186823-foo ubuntu ping my-app-foo
PING my-app-foo.weave.local (10.32.0.2) 56(84) bytes of data.
64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=1 ttl=64 time=0.027 ms
64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=2 ttl=64 time=0.067 ms
~~~
Also, running a container named `foo` with the label
`hostname-label=aws-12798186823-foo` leads to the same hostname registration.
~~~bash
host1$ docker run -ti --name=foo --label=hostname-label=aws-12798186823-foo ubuntu ping my-app-foo
PING my-app-foo.weave.local (10.32.0.2) 56(84) bytes of data.
64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=1 ttl=64 time=0.031 ms
64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=2 ttl=64 time=0.042 ms
~~~
This is because, as explained above, if providing `--hostname-from-label`
to the proxy, the specified label takes precedence over the container's name.
@@ -62,4 +56,4 @@ to the proxy, the specified label takes precedence over the container's name.
**See Also**
* [Name resolution via `/etc/hosts`](/site/weave-docker-api/name-resolution-proxy.md)
* [How Weave Finds Containers](/site/weavedns/how-works-weavedns.md)
* [How Weave Finds Containers](/site/weavedns/how-works-weavedns.md)
site/weave-docker-api/ipam-proxy.md
+1 -11
View File
@@ -8,31 +8,23 @@ If [automatic IP address allocation](/site/ipam/overview-init-ipam.md) is enable
then containers started via the proxy are automatically assigned an IP address, *without having to specify any
special environment variables or any other options*.
~~~bash
host1$ docker run -ti ubuntu
~~~
To use a specific subnet, you can pass a `WEAVE_CIDR` to the container, for example:
~~~bash
host1$ docker run -ti -e WEAVE_CIDR=net:10.32.2.0/24 ubuntu
~~
To start a container without connecting it to the Weave network, pass
`WEAVE_CIDR=none`, for example:
~~~bash
host1$ docker run -ti -e WEAVE_CIDR=none ubuntu
~~~
###Disabling Automatic IP Address Allocation
If you do not want an IP to be assigned by default, the proxy needs to
be passed the `--no-default-ipalloc` flag, for example:
~~~bash
host1$ weave launch-proxy --no-default-ipalloc
~~~
In this configuration, containers using no `WEAVE_CIDR` environment
variable are not connected to the Weave network.
@@ -41,11 +33,9 @@ Containers started with a `WEAVE_CIDR` environment variable are handled as befor
To automatically assign an address in this mode, start the
container with a blank `WEAVE_CIDR`, for example:
~~~bash
host1$ docker run -ti -e WEAVE_CIDR="" ubuntu
~~~
**See Also**
* [Address Allocation with IP Address Management (IPAM)](/site/ipam/overview-init-ipam.md)
* [How to Manually Specify IP Addresses and Subnets](/site/using-weave/manual-ip-address.md)
* [How to Manually Specify IP Addresses and Subnets](/site/using-weave/manual-ip-address.md)
site/weave-docker-api/launching-without-proxy.md
-6
View File
@@ -7,9 +7,7 @@ layout: default
If you don't want to use the proxy, you can also launch
containers on to the Weave network using `weave run`:
~~~bash
$ weave run -ti ubuntu
~~~
The arguments after `run` are passed through to `docker run`. Therefore you
can freely specify whatever Docker options you need.
@@ -19,18 +17,14 @@ this example, it obtains an automatically allocated IP.
You can specify IP addresses manually instead:
~~~bash
$ weave run 10.2.1.1/24 -ti ubuntu
~~~
`weave run` rewrites `/etc/hosts` in the same way
[the proxy does](/site/weave-docker-api/name-resolution-proxy.md). If you need to keep
the original file, specify `--no-rewrite-hosts` when running
the container:
~~~bash
$ weave run --no-rewrite-hosts 10.2.1.1/24 -ti ubuntu
~~~
There are some limitations to starting containers using `weave run`:
site/weave-docker-api/name-resolution-proxy.md
+1 -3
View File
@@ -26,11 +26,9 @@ IP instead of the Weave IP, or you require name resolution for
Docker-managed networks), the proxy must be launched using the
`--no-rewrite-hosts` flag.
~~~bash
host1$ weave launch-router && weave launch-proxy --no-rewrite-hosts
~~~
**See Also**
* [Using Automatic Discovery With the Weave Proxy](/site/weave-docker-api/automatic-discovery-proxy.md)
site/weave-docker-api/securing-proxy.md
-8
View File
@@ -11,9 +11,7 @@ attempts to duplicate it.
In the standard auto-detection case you can launch a TLS-enabled proxy as follows:
~~~bash
host1$ weave launch-proxy
~~~
To disable auto-detection of TLS configuration, you can either pass
the `--no-detect-tls` flag, or you can manually configure the proxy's TLS using
@@ -23,10 +21,8 @@ daemon.
For example, if you generated your certificates and keys
into the Docker host's `/tls` directory, launch the proxy using:
~~~bash
host1$ weave launch-proxy --tlsverify --tlscacert=/tls/ca.pem \
--tlscert=/tls/server-cert.pem --tlskey=/tls/server-key.pem
~~~
The paths to your certificates and key must be provided as absolute
paths as they exist on the Docker host.
@@ -41,20 +37,16 @@ for an example.
With the proxy running over TLS, you can configure the Docker
client to use TLS on a per-invocation basis by running:
~~~bash
$ docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem \
--tlskey=key.pem -H=tcp://host1:12375 version
~~~
or, [by default](https://docs.docker.com/articles/https/#secure-by-default), using:
~~~bash
$ mkdir -pv ~/.docker
$ cp -v {ca,cert,key}.pem ~/.docker
$ eval $(weave env)
$ export DOCKER_TLS_VERIFY=1
$ docker version
~~~
This is exactly the same configuration used when connecting to the
Docker daemon directly, except that the specified port is the Weave
site/weave-docker-api/set-up-proxy.md
-14
View File
@@ -17,15 +17,11 @@ The proxy sits between the Docker client (command line or API) and the
Docker daemon, and intercepts the communication between the two. You can
start it simultaneously with the router and weavedns via `launch`:
~~~bash
host1$ weave launch
~~~
or independently via `launch-proxy`:
~~~bash
host1$ weave launch-router && weave launch-proxy
~~~
The first form is more convenient. But only `launch-proxy` can be passed configuration arguments.
Therefore if you need to modify the default behaviour of the proxy, you must use `launch-proxy`.
@@ -37,9 +33,7 @@ the launching client connects over TCP, the proxy listens on port
12375, on all network interfaces. This can be adjusted using the `-H`
argument, for example:
~~~bash
host1$ weave launch-proxy -H tcp://127.0.0.1:9999
~~~
If no TLS or listening interfaces are set, TLS is auto-configured
based on the Docker daemon's settings, and the listening interfaces are
@@ -53,28 +47,20 @@ All docker commands can be run via the proxy, so it is safe to adjust
your `DOCKER_HOST` to point at the proxy. Weave Net provides a convenient
command for this:
~~~bash
host1$ eval $(weave env)
host1$ docker ps
~~~
The prior settings can be restored with
~~~bash
host1$ eval $(weave env --restore)
~~~
Alternatively, the proxy host can be set on a per-command basis with
~~~bash
host1$ docker $(weave config) ps
~~~
The proxy can be stopped independently with
~~~bash
host1$ weave stop-proxy
~~~
or in conjunction with the router and weavedns via `stop`.
site/weave-docker-api/troubleshooting-proxy.md
+4 -6
View File
@@ -5,24 +5,22 @@ layout: default
The command
~~~bash
weave status
~~~
reports on the current status of various Weave Net components, including
the proxy, if it is running:
~~~bash
````
...
Service: proxy
Address: tcp://127.0.0.1:12375
~~~
...
````
Information on the operation of the proxy can be obtained from the
weaveproxy container logs using:
~~~bash
docker logs weaveproxy
~~~
**See Also**
site/weave-docker-api/using-proxy.md
+1 -9
View File
@@ -16,24 +16,18 @@ Weave network.
To create and start a container via the Weave Net proxy run:
~~~bash
host1$ docker run -ti ubuntu
~~~
or, equivalently run:
~~~bash
host1$ docker create -ti ubuntu
5ef831df61d50a1a49272357155a976595e7268e590f0a2c75693337b14e1382
host1$ docker start 5ef831df61d50a1a49272357155a976595e7268e590f0a2c75693337b14e1382
~~~
Specific IP addresses and networks can be supplied in the `WEAVE_CIDR`
environment variable, for example:
~~~bash
host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti ubuntu
~~~
Multiple IP addresses and networks can be supplied in the `WEAVE_CIDR`
variable by space-separating them, as in
@@ -51,9 +45,7 @@ This command substitutes the Weave network settings when the container has a
Weave Net IP. If a container has more than one Weave Net IP, then the inspect call
only includes one of them.
~~~bash
host1$ weave launch-router && weave launch-proxy --rewrite-inspect
~~~
###Multicast Traffic and Launching the Weave Proxy
@@ -66,4 +58,4 @@ route, add the `--no-multicast-route` flag to `weave launch-proxy`.
* [Setting Up The Weave Docker API Proxy](/site/weave-docker-api/set-up-proxy.md)
* [Securing Docker Communications With TLS](securing-proxy.md)
* [Launching Containers With Weave Run (without the Proxy)](/site/weave-docker-api/launching-without-proxy.md)
* [Launching Containers With Weave Run (without the Proxy)](/site/weave-docker-api/launching-without-proxy.md)
site/weavedns/managing-entries-weavedns.md
-2
View File
@@ -53,10 +53,8 @@ which they were added.
You can resolve entries from any host running weaveDNS with `weave
dns-lookup`:
~~~bash
host1$ weave dns-lookup pingme
10.40.0.1
~~~
### <a name="hot-swapping"></a>Hot-swapping service containers
site/weavedns/troubleshooting-weavedns.md
+4 -6
View File
@@ -10,20 +10,20 @@ layout: default
The command:
~~~bash
weave status
~~~
reports on the current status of various Weave Net components, including
DNS:
~~~bash
````
...
Service: dns
Domain: weave.local.
Upstream: 8.8.8.8, 8.8.4.4
TTL: 1
Entries: 9
~~~
...
````
The first section covers the router; see the [troubleshooting
guide](/site/troubleshooting.md#weave-status) for more details.
@@ -41,9 +41,7 @@ dump](/site/troubleshooting.md#weave-status-dns) of all DNS registrations.
Information on the processing of queries, and the general operation of
weaveDNS, can be obtained from the container logs with
~~~bash
docker logs weave
~~~
### <a name="limitations"></a>Present Limitations