Merge pull request #180 from squaremo/issue176_move_ghpages_to_master
Move gh-pages to master
This commit is contained in:
Ilya Dmitrichenko committed
commit
5104baf953
15 files changed
+1245
No files matched your search
Executable
+17
@@ -0,0 +1,17 @@
|
||||
#! /bin/sh
|
||||
set -e
|
||||
|
||||
MERGE_ARGS="-X subtree=site"
|
||||
|
||||
merge_dir=$(mktemp -d -t weave-merge)/weave
|
||||
git clone -b gh-pages . $merge_dir
|
||||
|
||||
pushd $merge_dir
|
||||
git pull --ff-only git@github.com:zettio/weave gh-pages
|
||||
git fetch origin master
|
||||
git merge $MERGE_ARGS -e -m "Merge master into gh-pages" origin/master
|
||||
|
||||
popd
|
||||
git fetch $merge_dir gh-pages:gh-pages
|
||||
|
||||
# rm -rf $merge_dir
|
||||
Executable
+3
@@ -0,0 +1,3 @@
|
||||
#! /bin/sh
|
||||
set -e
|
||||
git push git@github.com:zettio/weave gh-pages:gh-pages
|
||||
@@ -0,0 +1,4 @@
|
||||
markdown: redcarpet
|
||||
|
||||
redcarpet:
|
||||
extensions: ['fenced_code_blocks', 'smart']
|
||||
@@ -0,0 +1,43 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta charset='utf-8' />
|
||||
<meta http-equiv="X-UA-Compatible" content="chrome=1" />
|
||||
<meta name="description" content="weave : The Docker Network" />
|
||||
|
||||
<link rel="stylesheet" type="text/css" media="screen" href="stylesheets/stylesheet.css">
|
||||
|
||||
<title>weave {% if page.title %} | {{ page.title }} {% endif %}</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<!-- HEADER -->
|
||||
<div id="header_wrap" class="outer">
|
||||
<header class="inner">
|
||||
<a id="forkme_banner" href="https://github.com/zettio/weave">View on GitHub</a>
|
||||
|
||||
<h1 id="project_title">weave</h1>
|
||||
<h2 id="project_tagline">The Docker Network</h2>
|
||||
|
||||
</header>
|
||||
</div>
|
||||
|
||||
<!-- MAIN CONTENT -->
|
||||
<div id="main_content_wrap" class="outer">
|
||||
<section id="main_content" class="inner">
|
||||
{{ content }}
|
||||
</section>
|
||||
</div>
|
||||
|
||||
<!-- FOOTER -->
|
||||
<div id="footer_wrap" class="outer">
|
||||
<footer class="inner">
|
||||
|
||||
</footer>
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Installing Weave with Boot2Docker
|
||||
layout: default
|
||||
---
|
||||
|
||||
## Installation with Boot2Docker
|
||||
|
||||
If you are running Docker inside the Boot2Docker VM, e.g. because you
|
||||
are on a Mac, then the following changes are required to these
|
||||
instructions:
|
||||
|
||||
Assuming you have fetched the 'weave' script via curl or similar, and
|
||||
it is in the current directory, transfer it to the Boot2Docker VM and
|
||||
make it executable like this:
|
||||
|
||||
host1$ boot2docker ssh "cat > weave" < weave
|
||||
host1$ boot2docker ssh "chmod a+x weave"
|
||||
|
||||
Then, if we were trying to create the same containers as in the first
|
||||
example above, the 'launch' command would be run like this:
|
||||
|
||||
host1$ boot2docker ssh "sudo ./weave launch"
|
||||
|
||||
and the 'run' command like this:
|
||||
|
||||
host1# C=$(boot2docker ssh "sudo ./weave run 10.0.1.1/24 -t -i ubuntu")
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
title: Building Weave
|
||||
layout: default
|
||||
---
|
||||
|
||||
**NB** This is only necessary if you want to work on the weave code.
|
||||
|
||||
## Building directly on Linux
|
||||
|
||||
You can work on weave without using a VM if you are running the docker
|
||||
daemon outside a VM. (These instructions have only been tested on
|
||||
Ubuntu.)
|
||||
|
||||
To build weave you need `libpcap-dev` and `docker` installed. And `go`
|
||||
(and `git` and `hg` to fetch dependencies).
|
||||
|
||||
The package name is `github.com/zettio/weave`, so assuming `$GOPATH`
|
||||
is set:
|
||||
|
||||
```bash
|
||||
$ cd $GOPATH
|
||||
$ WEAVE=github.com/zettio/weave
|
||||
$ git clone https://$WEAVE src/$WEAVE
|
||||
$ cd src/$WEAVE
|
||||
```
|
||||
|
||||
Then simply run
|
||||
|
||||
```bash
|
||||
$ make
|
||||
```
|
||||
|
||||
This will build the weave router, produce a docker image
|
||||
`zettio/weave` and export that image to `/var/tmp/weave.tar`.
|
||||
|
||||
## Building using Vagrant
|
||||
|
||||
If you aren't running Linux, or otherwise don't want to run the docker
|
||||
daemon outside a VM, you can use
|
||||
[Vagrant](https://www.vagrantup.com/downloads.html) to run a
|
||||
development environment. You'll probably need to install
|
||||
[VirtualBox](https://www.virtualbox.org/wiki/Downloads) too, for
|
||||
Vagrant to run VMs in.
|
||||
|
||||
First, check out the code:
|
||||
|
||||
```bash
|
||||
$ git clone https://github.com/zettio/weave
|
||||
$ cd weave
|
||||
```
|
||||
|
||||
The `Vagrantfile` in the top directory constructs a VM that has
|
||||
|
||||
* docker installed
|
||||
* go tools installed
|
||||
* weave dependencies installed
|
||||
* $GOPATH set to ~
|
||||
* the local working directory mapped as a synced folder into the
|
||||
right place in $GOPATH
|
||||
|
||||
Once you are in the working directory you can issue
|
||||
|
||||
```bash
|
||||
$ vagrant up
|
||||
```
|
||||
|
||||
and wait for a while (don't worry, the long download and package
|
||||
installation is done just once). The working directory is sync'ed with
|
||||
`~/src/github.com/zettio/weave` on the VM, so you can edit files and
|
||||
use git and so on in the regular filesystem.
|
||||
|
||||
To build and run the code, you need to use the VM. To log in and build
|
||||
the weave image, do
|
||||
|
||||
```bash
|
||||
$ vagrant ssh
|
||||
vm$ cd src/github.com/zettio/weave
|
||||
vm$ make
|
||||
```
|
||||
|
||||
The docker daemon is also running in this VM, so you can then do
|
||||
|
||||
```bash
|
||||
vm$ sudo ./weave launch
|
||||
vm$ docker ps
|
||||
```
|
||||
|
||||
and so on.
|
||||
|
||||
You can provide extra Vagrant configuration by putting a file
|
||||
`Vagrant.local` in the same place as `Vagrantfile`; for instance, to
|
||||
forward additional ports.
|
||||
@@ -0,0 +1,354 @@
|
||||
---
|
||||
title: Weave features
|
||||
layout: default
|
||||
---
|
||||
|
||||
# Weave features
|
||||
|
||||
Weave has a few more features beyond those illustrated by the [basic
|
||||
example](https://github.com/zettio/weave#example):
|
||||
|
||||
* [Virtual ethernet switch](#virtual-ethernet-switch)
|
||||
* [Application isolation](#application-isolation)
|
||||
* [Dynamic network attachment](#dynamic-network-attachment)
|
||||
* [Security](#security)
|
||||
* [Host network integration](#host-network-integration)
|
||||
* [Service export](#service-export)
|
||||
* [Service import](#service-import)
|
||||
* [Service binding](#service-binding)
|
||||
* [Service routing](#service-routing)
|
||||
* [Multi-cloud networking](#multi-cloud-networking)
|
||||
* [Multi-hop routing](#multi-hop-routing)
|
||||
* [Dynamic topologies](#dynamic-topologies)
|
||||
* [Container mobility](#container-mobility)
|
||||
* [Fault tolerance](#fault-tolerance)
|
||||
* [DNS](#dns)
|
||||
|
||||
### <a name="virtual-ethernet-switch"></a>Virtual Ethernet Switch
|
||||
|
||||
To application containers, the network established by weave looks
|
||||
like a giant Ethernet switch to which all the containers are
|
||||
connected.
|
||||
|
||||
Containers can easily access services from each other; e.g. in the
|
||||
container on $HOST1 we can start a netcat "service" with
|
||||
|
||||
root@28841bd02eff:/# nc -lk -p 4422
|
||||
|
||||
and then connect to it from the container on $HOST2 with
|
||||
|
||||
root@f76829496120:/# echo 'Hello, world.' | nc 10.0.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
|
||||
|
||||
We can deploy the entire arsenal of standard network tools and
|
||||
applications, developed over decades, to configure, secure, monitor,
|
||||
and troubleshoot our container network. To put it another way, we can
|
||||
now re-use the same tools and techniques when deploying applications
|
||||
as containers as we would have done when deploying them 'on metal' in
|
||||
our data centre.
|
||||
|
||||
### <a name="application-isolation"></a>Application isolation
|
||||
|
||||
A single weave network can host multiple, isolated applications, with
|
||||
each application's containers being able to communicate with each
|
||||
other but not containers of other applications.
|
||||
|
||||
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)
|
||||
|
||||
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 ---
|
||||
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 ---
|
||||
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 ---
|
||||
1 packets transmitted, 0 received, 100% packet loss, time 0ms
|
||||
|
||||
This isolation-through-subnets scheme is an example of carrying over a
|
||||
well-known technique from the 'on metal' days to containers.
|
||||
|
||||
NB: 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/articles/networking/#between-containers)
|
||||
in the docker daemon configuration.
|
||||
|
||||
### <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
|
||||
|
||||
host1# C=$(docker run -d -t -i ubuntu)
|
||||
host1# weave attach 10.0.1.1/24 $C
|
||||
|
||||
There is a matching `weave detach` command:
|
||||
|
||||
host1# weave detach 10.0.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
|
||||
|
||||
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
|
||||
|
||||
### <a name="security"></a>Security
|
||||
|
||||
In order to connect containers across untrusted networks, weave peers
|
||||
can be told to encrypt traffic by supplying a `-password` option when
|
||||
launching weave, e.g.
|
||||
|
||||
host1# weave launch -password wEaVe
|
||||
|
||||
The same password must be specified for all weave peers; it is a
|
||||
component in the creation of ephemeral session keys for connections
|
||||
between peers.
|
||||
|
||||
### <a name="host-network-integration"></a>Host network integration
|
||||
|
||||
Weave application networks can be integrated with a host's network,
|
||||
establishing connectivity between the host and application containers
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
will work. And, more interestingly,
|
||||
|
||||
host2# ping 10.0.1.1
|
||||
|
||||
will work too, which is talking to a container that resides on $HOST1.
|
||||
|
||||
### <a name="service-export"></a>Service export
|
||||
|
||||
Services running in containers on a weave network can be made
|
||||
accessible to the outside world (and, more generally, other networks)
|
||||
from any weave host, irrespective of where the service containers are
|
||||
located.
|
||||
|
||||
Say we want to make our example netcat "service", which is running in
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
With the above in place, we can connect to our 'nc' service from
|
||||
anywhere with
|
||||
|
||||
echo 'Hello, world.' | nc $HOST2 2211
|
||||
|
||||
(NB: due to the way routing is handled in the Linux kernel, this won't
|
||||
work when run *on* $HOST2.)
|
||||
|
||||
Similar NAT rules to the above can used to expose services not just to
|
||||
the outside world but also other, internal, networks.
|
||||
|
||||
### <a name="service-import"></a>Service import
|
||||
|
||||
Applications running in containers on a weave network can be given
|
||||
access to services which are only reachable from certain weave hosts,
|
||||
irrespective of where the application containers are located.
|
||||
|
||||
Say that, as an extension of our example, we have a netcat service
|
||||
running on $HOST3, port 2211, and that $HOST3 is not part of the weave
|
||||
network and is only reachable from $HOST1, not $HOST2. Nevertheless we
|
||||
want to make the service accessible to an application running in a
|
||||
container on $HOST2.
|
||||
|
||||
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
|
||||
|
||||
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 \
|
||||
-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
|
||||
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
|
||||
|
||||
The same command will work from any application container.
|
||||
|
||||
### <a name="service-binding"></a>Service binding
|
||||
|
||||
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
|
||||
`$HOST3:2211`. We can point application containers at another service
|
||||
location by changing the above NAT rule, without having to alter the
|
||||
applications themselves.
|
||||
|
||||
### <a name="service-routing"></a>Service routing
|
||||
|
||||
The [service export](#service-export) and
|
||||
[service import](#service-import) features can be combined to
|
||||
establish connectivity between applications and services residing on
|
||||
disjoint networks, even when those networks are separated by firewalls
|
||||
and might have overlapping IP ranges. Each network imports its
|
||||
services into weave, and in turn exports from weave services required
|
||||
by its applications. There are no application containers in this
|
||||
scenario (though of course there could be); weave is acting purely as
|
||||
an address translation and routing facility, using the weave
|
||||
application network as an intermediary.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
Now any host on the same network as $HOST2 can access the service with
|
||||
|
||||
echo 'Hello, world.' | nc $HOST2 4433
|
||||
|
||||
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
|
||||
endpoint in the weave network.
|
||||
|
||||
### <a name="multi-cloud-networking"></a>Multi-cloud networking
|
||||
|
||||
Weave can network containers hosted in different cloud providers /
|
||||
data centres. So, for example, one could run an application consisting
|
||||
of containers on GCE, EC2 and in local data centres.
|
||||
|
||||
To enable this, the network must be configured to permit TCP and UDP
|
||||
connections to port 6783 of the docker hosts.
|
||||
|
||||
### <a name="multi-hop-routing"></a>Multi-hop routing
|
||||
|
||||
A network of containers across more than two hosts can be established
|
||||
even when there is only partial connectivity between the hosts. Weave
|
||||
is able to route traffic between containers as long as there is at
|
||||
least one *path* of connected hosts between them.
|
||||
|
||||
So, for example, if a docker host in a local data centre can connect
|
||||
to hosts in GCE and EC2, but the latter two cannot connect to each
|
||||
other, containers in the latter two can still communicate; weave will
|
||||
route the traffic via the local data centre.
|
||||
|
||||
### <a name="dynamic-topologies"></a>Dynamic topologies
|
||||
|
||||
To add a host to an existing weave network, one simply launches weave
|
||||
on the host, supplying the address of at least one existing
|
||||
host. Weave will automatically discover the other hosts in the network
|
||||
and establish connections to them if it can (in order to avoid
|
||||
unnecessary multi-hop routing).
|
||||
|
||||
In some situations all existing weave hosts may be unreachable from
|
||||
the new host due to firewalls, etc. However, it is still possible to
|
||||
add the new host, provided inverse connections, i.e. from existing
|
||||
hosts to the new hosts, are possible. To accomplish that, one launches
|
||||
weave on the new host without supplying any additional addresses, and
|
||||
then on one of the existing hosts runs
|
||||
|
||||
host# weave connect $NEW_HOST
|
||||
|
||||
Other hosts in the weave network will automatically attempt to
|
||||
establish connections to the new host too.
|
||||
|
||||
### <a name="container-mobility"></a>Container mobility
|
||||
|
||||
Containers can be moved between hosts without requiring any
|
||||
reconfiguration or, in many cases, restarts of other containers. All
|
||||
that is required is for the migrated container to be started with the
|
||||
same IP address as it was given originally.
|
||||
|
||||
### <a name="fault-tolerance"></a>Fault tolerance
|
||||
|
||||
Weave peers continually exchange topology information, and monitor
|
||||
and (re)establish network connections to other peers. So if hosts or
|
||||
networks fail, weave can "route around" the problem. This includes
|
||||
network partitions; containers on either side of a partition can
|
||||
continue to communicate, with full connectivity being restored when
|
||||
the partition heals.
|
||||
|
||||
The weave container is very light-weight - just over 8MB image size
|
||||
and a few 10s of MBs of runtime memory - and disposable. I.e. should
|
||||
weave ever run into difficulty, one can simply stop it (with `weave
|
||||
stop`) and restart it. Application containers do *not* have to be
|
||||
restarted in that event, and indeed may not even experience a
|
||||
temporary connectivity failure if the weave container is restarted
|
||||
quickly enough.
|
||||
|
||||
### <a name="dns"></a>DNS
|
||||
|
||||
WeaveDNS is a distributed DNS service for weave networks, enabling
|
||||
containers to address each other by name rather than IP address. A
|
||||
preview release of weaveDNS is described [on our
|
||||
blog](http://weaveblog.com/2014/11/04/have-you-met-weavedns/).
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: How Weave works
|
||||
layout: default
|
||||
---
|
||||
|
||||
## How does it work?
|
||||
|
||||
Weave creates a network bridge on the host. Each container is
|
||||
connected to that bridge via a veth pair, the container side of which
|
||||
is given the IP address & netmask supplied in 'weave run'. Also
|
||||
connected to the bridge is the weave router container.
|
||||
|
||||
A weave router captures Ethernet packets from its bridge-connected
|
||||
interface in promiscuous mode, using 'pcap'. This typically excludes
|
||||
traffic between local containers, and between the host and local
|
||||
containers, all of which is routed straight over the bridge by the
|
||||
kernel. Captured packets are forwarded over UDP to weave router peers
|
||||
running on other hosts. On receipt of such a packet, a router injects
|
||||
the packet on its bridge interface using 'pcap' and/or forwards the
|
||||
packet to peers.
|
||||
|
||||
Weave routers learn which peer host a particular MAC address resides
|
||||
on. They combine this knowledge with topology information in order to
|
||||
make routing decisions and thus avoid forwarding every packet to every
|
||||
peer. The topology information captures which peers are connected to
|
||||
which other peers; weave can route packets in partially connected
|
||||
networks with changing topology.
|
||||
|
||||
Weave routers establish TCP connections to each other, over which they
|
||||
perform a protocol handshake and subsequently exchange topology
|
||||
information. These connections are encrypted if so configured. Peers
|
||||
also establish UDP "connections", possibly encrypted, for the
|
||||
aforementioned packet forwarding. These "connections" are duplex and
|
||||
can traverse firewalls.
|
||||
|
||||
More details on the inner workings of weave can be found in the
|
||||
[architecture documentation](https://github.com/zettio/weave/blob/master/docs/architecture.txt).
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.4 KiB |
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: weave, the Docker network
|
||||
layout: default
|
||||
---
|
||||
|
||||
# weave documentation
|
||||
|
||||
* [Introduction and example (in README)](https://github.com/zettio/weave#readme)
|
||||
* [Features](features.html)
|
||||
* [Troubleshooting](troubleshooting.html)
|
||||
* [Building](building.html)
|
||||
* [Using with Boot2Docker](boot2docker.html)
|
||||
* [How it works](how-it-works.html)
|
||||
* [Contact information](https://github.com/zettio/weave#contact-us)
|
||||
@@ -0,0 +1 @@
|
||||
console.log('This would be the main JS file.');
|
||||
@@ -0,0 +1 @@
|
||||
{"name":"Weave","tagline":"The Docker Network","body":"","google":"","note":"Don't delete this file! It's used internally to help with page regeneration."}
|
||||
@@ -0,0 +1,70 @@
|
||||
.highlight .hll { background-color: #ffffcc }
|
||||
.highlight { background: #f0f3f3; }
|
||||
.highlight .c { color: #0099FF; font-style: italic } /* Comment */
|
||||
.highlight .err { color: #AA0000; background-color: #FFAAAA } /* Error */
|
||||
.highlight .k { color: #006699; font-weight: bold } /* Keyword */
|
||||
.highlight .o { color: #555555 } /* Operator */
|
||||
.highlight .cm { color: #0099FF; font-style: italic } /* Comment.Multiline */
|
||||
.highlight .cp { color: #009999 } /* Comment.Preproc */
|
||||
.highlight .c1 { color: #0099FF; font-style: italic } /* Comment.Single */
|
||||
.highlight .cs { color: #0099FF; font-weight: bold; font-style: italic } /* Comment.Special */
|
||||
.highlight .gd { background-color: #FFCCCC; border: 1px solid #CC0000 } /* Generic.Deleted */
|
||||
.highlight .ge { font-style: italic } /* Generic.Emph */
|
||||
.highlight .gr { color: #FF0000 } /* Generic.Error */
|
||||
.highlight .gh { color: #003300; font-weight: bold } /* Generic.Heading */
|
||||
.highlight .gi { background-color: #CCFFCC; border: 1px solid #00CC00 } /* Generic.Inserted */
|
||||
.highlight .go { color: #AAAAAA } /* Generic.Output */
|
||||
.highlight .gp { color: #000099; font-weight: bold } /* Generic.Prompt */
|
||||
.highlight .gs { font-weight: bold } /* Generic.Strong */
|
||||
.highlight .gu { color: #003300; font-weight: bold } /* Generic.Subheading */
|
||||
.highlight .gt { color: #99CC66 } /* Generic.Traceback */
|
||||
.highlight .kc { color: #006699; font-weight: bold } /* Keyword.Constant */
|
||||
.highlight .kd { color: #006699; font-weight: bold } /* Keyword.Declaration */
|
||||
.highlight .kn { color: #006699; font-weight: bold } /* Keyword.Namespace */
|
||||
.highlight .kp { color: #006699 } /* Keyword.Pseudo */
|
||||
.highlight .kr { color: #006699; font-weight: bold } /* Keyword.Reserved */
|
||||
.highlight .kt { color: #007788; font-weight: bold } /* Keyword.Type */
|
||||
.highlight .m { color: #FF6600 } /* Literal.Number */
|
||||
.highlight .s { color: #CC3300 } /* Literal.String */
|
||||
.highlight .na { color: #330099 } /* Name.Attribute */
|
||||
.highlight .nb { color: #336666 } /* Name.Builtin */
|
||||
.highlight .nc { color: #00AA88; font-weight: bold } /* Name.Class */
|
||||
.highlight .no { color: #336600 } /* Name.Constant */
|
||||
.highlight .nd { color: #9999FF } /* Name.Decorator */
|
||||
.highlight .ni { color: #999999; font-weight: bold } /* Name.Entity */
|
||||
.highlight .ne { color: #CC0000; font-weight: bold } /* Name.Exception */
|
||||
.highlight .nf { color: #CC00FF } /* Name.Function */
|
||||
.highlight .nl { color: #9999FF } /* Name.Label */
|
||||
.highlight .nn { color: #00CCFF; font-weight: bold } /* Name.Namespace */
|
||||
.highlight .nt { color: #330099; font-weight: bold } /* Name.Tag */
|
||||
.highlight .nv { color: #003333 } /* Name.Variable */
|
||||
.highlight .ow { color: #000000; font-weight: bold } /* Operator.Word */
|
||||
.highlight .w { color: #bbbbbb } /* Text.Whitespace */
|
||||
.highlight .mf { color: #FF6600 } /* Literal.Number.Float */
|
||||
.highlight .mh { color: #FF6600 } /* Literal.Number.Hex */
|
||||
.highlight .mi { color: #FF6600 } /* Literal.Number.Integer */
|
||||
.highlight .mo { color: #FF6600 } /* Literal.Number.Oct */
|
||||
.highlight .sb { color: #CC3300 } /* Literal.String.Backtick */
|
||||
.highlight .sc { color: #CC3300 } /* Literal.String.Char */
|
||||
.highlight .sd { color: #CC3300; font-style: italic } /* Literal.String.Doc */
|
||||
.highlight .s2 { color: #CC3300 } /* Literal.String.Double */
|
||||
.highlight .se { color: #CC3300; font-weight: bold } /* Literal.String.Escape */
|
||||
.highlight .sh { color: #CC3300 } /* Literal.String.Heredoc */
|
||||
.highlight .si { color: #AA0000 } /* Literal.String.Interpol */
|
||||
.highlight .sx { color: #CC3300 } /* Literal.String.Other */
|
||||
.highlight .sr { color: #33AAAA } /* Literal.String.Regex */
|
||||
.highlight .s1 { color: #CC3300 } /* Literal.String.Single */
|
||||
.highlight .ss { color: #FFCC33 } /* Literal.String.Symbol */
|
||||
.highlight .bp { color: #336666 } /* Name.Builtin.Pseudo */
|
||||
.highlight .vc { color: #003333 } /* Name.Variable.Class */
|
||||
.highlight .vg { color: #003333 } /* Name.Variable.Global */
|
||||
.highlight .vi { color: #003333 } /* Name.Variable.Instance */
|
||||
.highlight .il { color: #FF6600 } /* Literal.Number.Integer.Long */
|
||||
|
||||
.type-csharp .highlight .k { color: #0000FF }
|
||||
.type-csharp .highlight .kt { color: #0000FF }
|
||||
.type-csharp .highlight .nf { color: #000000; font-weight: normal }
|
||||
.type-csharp .highlight .nc { color: #2B91AF }
|
||||
.type-csharp .highlight .nn { color: #000000 }
|
||||
.type-csharp .highlight .s { color: #A31515 }
|
||||
.type-csharp .highlight .sc { color: #A31515 }
|
||||
@@ -0,0 +1,431 @@
|
||||
/*******************************************************************************
|
||||
Slate Theme for GitHub Pages
|
||||
by Jason Costello, @jsncostello
|
||||
*******************************************************************************/
|
||||
|
||||
@import url(pygment_trac.css);
|
||||
|
||||
/*******************************************************************************
|
||||
MeyerWeb Reset
|
||||
*******************************************************************************/
|
||||
|
||||
html, body, div, span, applet, object, iframe,
|
||||
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
|
||||
a, abbr, acronym, address, big, cite, code,
|
||||
del, dfn, em, img, ins, kbd, q, s, samp,
|
||||
small, strike, strong, sub, sup, tt, var,
|
||||
b, u, i, center,
|
||||
dl, dt, dd, ol, ul, li,
|
||||
fieldset, form, label, legend,
|
||||
table, caption, tbody, tfoot, thead, tr, th, td,
|
||||
article, aside, canvas, details, embed,
|
||||
figure, figcaption, footer, header, hgroup,
|
||||
menu, nav, output, ruby, section, summary,
|
||||
time, mark, audio, video {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
border: 0;
|
||||
font: inherit;
|
||||
vertical-align: baseline;
|
||||
}
|
||||
|
||||
/* HTML5 display-role reset for older browsers */
|
||||
article, aside, details, figcaption, figure,
|
||||
footer, header, hgroup, menu, nav, section {
|
||||
display: block;
|
||||
}
|
||||
|
||||
ol, ul {
|
||||
list-style: none;
|
||||
}
|
||||
|
||||
blockquote, q {
|
||||
}
|
||||
|
||||
table {
|
||||
border-collapse: collapse;
|
||||
border-spacing: 0;
|
||||
}
|
||||
|
||||
a:focus {
|
||||
outline: none;
|
||||
}
|
||||
|
||||
/*******************************************************************************
|
||||
Theme Styles
|
||||
*******************************************************************************/
|
||||
|
||||
body {
|
||||
box-sizing: border-box;
|
||||
color:#373737;
|
||||
background: #212121;
|
||||
font-size: 16px;
|
||||
font-family: 'Myriad Pro', Calibri, Helvetica, Arial, sans-serif;
|
||||
line-height: 1.5;
|
||||
-webkit-font-smoothing: antialiased;
|
||||
}
|
||||
|
||||
h1, h2, h3, h4, h5, h6 {
|
||||
margin: 10px 0;
|
||||
font-weight: 700;
|
||||
color:#222222;
|
||||
font-family: 'Lucida Grande', 'Calibri', Helvetica, Arial, sans-serif;
|
||||
letter-spacing: -1px;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 36px;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
h2 {
|
||||
padding-bottom: 10px;
|
||||
font-size: 32px;
|
||||
background: url('../images/bg_hr.png') repeat-x bottom;
|
||||
}
|
||||
|
||||
h3 {
|
||||
font-size: 24px;
|
||||
}
|
||||
|
||||
h4 {
|
||||
font-size: 21px;
|
||||
}
|
||||
|
||||
h5 {
|
||||
font-size: 18px;
|
||||
}
|
||||
|
||||
h6 {
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
p {
|
||||
margin: 10px 0 15px 0;
|
||||
}
|
||||
|
||||
footer p {
|
||||
color: #f2f2f2;
|
||||
}
|
||||
|
||||
a {
|
||||
text-decoration: none;
|
||||
color: #007edf;
|
||||
text-shadow: none;
|
||||
|
||||
transition: color 0.5s ease;
|
||||
transition: text-shadow 0.5s ease;
|
||||
-webkit-transition: color 0.5s ease;
|
||||
-webkit-transition: text-shadow 0.5s ease;
|
||||
-moz-transition: color 0.5s ease;
|
||||
-moz-transition: text-shadow 0.5s ease;
|
||||
-o-transition: color 0.5s ease;
|
||||
-o-transition: text-shadow 0.5s ease;
|
||||
-ms-transition: color 0.5s ease;
|
||||
-ms-transition: text-shadow 0.5s ease;
|
||||
}
|
||||
|
||||
#main_content a:hover {
|
||||
color: #0069ba;
|
||||
text-shadow: #0090ff 0px 0px 2px;
|
||||
}
|
||||
|
||||
footer a:hover {
|
||||
color: #43adff;
|
||||
text-shadow: #0090ff 0px 0px 2px;
|
||||
}
|
||||
|
||||
em {
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
strong {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
img {
|
||||
position: relative;
|
||||
margin: 0 auto;
|
||||
max-width: 739px;
|
||||
padding: 5px;
|
||||
margin: 10px 0 10px 0;
|
||||
border: 1px solid #ebebeb;
|
||||
|
||||
box-shadow: 0 0 5px #ebebeb;
|
||||
-webkit-box-shadow: 0 0 5px #ebebeb;
|
||||
-moz-box-shadow: 0 0 5px #ebebeb;
|
||||
-o-box-shadow: 0 0 5px #ebebeb;
|
||||
-ms-box-shadow: 0 0 5px #ebebeb;
|
||||
}
|
||||
|
||||
pre, code {
|
||||
width: 100%;
|
||||
color: #222;
|
||||
background-color: #fff;
|
||||
|
||||
font-family: Monaco, "Bitstream Vera Sans Mono", "Lucida Console", Terminal, monospace;
|
||||
font-size: 14px;
|
||||
|
||||
border-radius: 2px;
|
||||
-moz-border-radius: 2px;
|
||||
-webkit-border-radius: 2px;
|
||||
|
||||
|
||||
|
||||
}
|
||||
|
||||
pre {
|
||||
width: 100%;
|
||||
padding: 10px;
|
||||
box-shadow: 0 0 10px rgba(0,0,0,.1);
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
code {
|
||||
padding: 3px;
|
||||
margin: 0 3px;
|
||||
box-shadow: 0 0 10px rgba(0,0,0,.1);
|
||||
}
|
||||
|
||||
pre code {
|
||||
display: block;
|
||||
box-shadow: none;
|
||||
}
|
||||
|
||||
blockquote {
|
||||
color: #666;
|
||||
margin-bottom: 20px;
|
||||
padding: 0 0 0 20px;
|
||||
border-left: 3px solid #bbb;
|
||||
}
|
||||
|
||||
ul, ol, dl {
|
||||
margin-bottom: 15px
|
||||
}
|
||||
|
||||
ul li {
|
||||
list-style: inside;
|
||||
padding-left: 20px;
|
||||
}
|
||||
|
||||
ol li {
|
||||
list-style: decimal inside;
|
||||
padding-left: 20px;
|
||||
}
|
||||
|
||||
dl dt {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
dl dd {
|
||||
padding-left: 20px;
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
dl p {
|
||||
padding-left: 20px;
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
hr {
|
||||
height: 1px;
|
||||
margin-bottom: 5px;
|
||||
border: none;
|
||||
background: url('../images/bg_hr.png') repeat-x center;
|
||||
}
|
||||
|
||||
table {
|
||||
border: 1px solid #373737;
|
||||
margin-bottom: 20px;
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
th {
|
||||
font-family: 'Lucida Grande', 'Helvetica Neue', Helvetica, Arial, sans-serif;
|
||||
padding: 10px;
|
||||
background: #373737;
|
||||
color: #fff;
|
||||
}
|
||||
|
||||
td {
|
||||
padding: 10px;
|
||||
border: 1px solid #373737;
|
||||
}
|
||||
|
||||
form {
|
||||
background: #f2f2f2;
|
||||
padding: 20px;
|
||||
}
|
||||
|
||||
img {
|
||||
width: 100%;
|
||||
max-width: 100%;
|
||||
}
|
||||
|
||||
/*******************************************************************************
|
||||
Full-Width Styles
|
||||
*******************************************************************************/
|
||||
|
||||
.outer {
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
.inner {
|
||||
position: relative;
|
||||
max-width: 640px;
|
||||
padding: 20px 10px;
|
||||
margin: 0 auto;
|
||||
}
|
||||
|
||||
#forkme_banner {
|
||||
display: block;
|
||||
position: absolute;
|
||||
top:0;
|
||||
right: 10px;
|
||||
z-index: 10;
|
||||
padding: 10px 50px 10px 10px;
|
||||
color: #fff;
|
||||
background: url('../images/blacktocat.png') #0090ff no-repeat 95% 50%;
|
||||
font-weight: 700;
|
||||
box-shadow: 0 0 10px rgba(0,0,0,.5);
|
||||
border-bottom-left-radius: 2px;
|
||||
border-bottom-right-radius: 2px;
|
||||
}
|
||||
|
||||
#header_wrap {
|
||||
background: #212121;
|
||||
background: -moz-linear-gradient(top, #373737, #212121);
|
||||
background: -webkit-linear-gradient(top, #373737, #212121);
|
||||
background: -ms-linear-gradient(top, #373737, #212121);
|
||||
background: -o-linear-gradient(top, #373737, #212121);
|
||||
background: linear-gradient(top, #373737, #212121);
|
||||
}
|
||||
|
||||
#header_wrap .inner {
|
||||
padding: 50px 10px 30px 10px;
|
||||
}
|
||||
|
||||
#project_title {
|
||||
margin: 0;
|
||||
color: #fff;
|
||||
font-size: 42px;
|
||||
font-weight: 700;
|
||||
text-shadow: #111 0px 0px 10px;
|
||||
}
|
||||
|
||||
#project_tagline {
|
||||
color: #fff;
|
||||
font-size: 24px;
|
||||
font-weight: 300;
|
||||
background: none;
|
||||
text-shadow: #111 0px 0px 10px;
|
||||
}
|
||||
|
||||
#downloads {
|
||||
position: absolute;
|
||||
width: 210px;
|
||||
z-index: 10;
|
||||
bottom: -40px;
|
||||
right: 0;
|
||||
height: 70px;
|
||||
background: url('../images/icon_download.png') no-repeat 0% 90%;
|
||||
}
|
||||
|
||||
.zip_download_link {
|
||||
display: block;
|
||||
float: right;
|
||||
width: 90px;
|
||||
height:70px;
|
||||
text-indent: -5000px;
|
||||
overflow: hidden;
|
||||
background: url(../images/sprite_download.png) no-repeat bottom left;
|
||||
}
|
||||
|
||||
.tar_download_link {
|
||||
display: block;
|
||||
float: right;
|
||||
width: 90px;
|
||||
height:70px;
|
||||
text-indent: -5000px;
|
||||
overflow: hidden;
|
||||
background: url(../images/sprite_download.png) no-repeat bottom right;
|
||||
margin-left: 10px;
|
||||
}
|
||||
|
||||
.zip_download_link:hover {
|
||||
background: url(../images/sprite_download.png) no-repeat top left;
|
||||
}
|
||||
|
||||
.tar_download_link:hover {
|
||||
background: url(../images/sprite_download.png) no-repeat top right;
|
||||
}
|
||||
|
||||
#main_content_wrap {
|
||||
background: #f2f2f2;
|
||||
border-top: 1px solid #111;
|
||||
border-bottom: 1px solid #111;
|
||||
}
|
||||
|
||||
#main_content {
|
||||
padding-top: 40px;
|
||||
}
|
||||
|
||||
#footer_wrap {
|
||||
background: #212121;
|
||||
}
|
||||
|
||||
|
||||
|
||||
/*******************************************************************************
|
||||
Small Device Styles
|
||||
*******************************************************************************/
|
||||
|
||||
@media screen and (max-width: 480px) {
|
||||
body {
|
||||
font-size:14px;
|
||||
}
|
||||
|
||||
#downloads {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.inner {
|
||||
min-width: 320px;
|
||||
max-width: 480px;
|
||||
}
|
||||
|
||||
#project_title {
|
||||
font-size: 32px;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 28px;
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-size: 24px;
|
||||
}
|
||||
|
||||
h3 {
|
||||
font-size: 21px;
|
||||
}
|
||||
|
||||
h4 {
|
||||
font-size: 18px;
|
||||
}
|
||||
|
||||
h5 {
|
||||
font-size: 14px;
|
||||
}
|
||||
|
||||
h6 {
|
||||
font-size: 12px;
|
||||
}
|
||||
|
||||
code, pre {
|
||||
min-width: 320px;
|
||||
max-width: 480px;
|
||||
font-size: 11px;
|
||||
}
|
||||
|
||||
}
|
||||
@@ -0,0 +1,152 @@
|
||||
---
|
||||
title: Troubleshooting Weave
|
||||
layout: default
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Make sure you are running the latest version - you can download it
|
||||
with
|
||||
|
||||
docker pull zettio/weave:latest
|
||||
|
||||
Check the weave container logs with
|
||||
|
||||
docker logs weave
|
||||
|
||||
A reasonable amount of information, and all errors, get logged there.
|
||||
|
||||
The log verbosity can be increased by supplying the `-debug` flag when
|
||||
launching weave. Be warned, this will log information on a per-packet
|
||||
basis, so can produce a lot of output.
|
||||
|
||||
Another useful debugging technique is to attach standard packet
|
||||
capture and analysis tools, such as tcpdump and wireshark, to the
|
||||
`weave` network bridge on the host.
|
||||
|
||||
One can ask a weave router for a [status report](#status-report) or
|
||||
for a [list of attached containers](#list-attached-containers).
|
||||
|
||||
To stop weave, run
|
||||
|
||||
weave stop
|
||||
|
||||
Note that this leaves the local application container network intact;
|
||||
containers on the local host can continue to communicate, whereas
|
||||
communication with containers on different hosts, as well as service
|
||||
export/import, is disrupted but resumes when weave is relaunched.
|
||||
|
||||
To stop weave and completely remove all traces of the weave network on
|
||||
the local host, run
|
||||
|
||||
weave reset
|
||||
|
||||
Any running application containers will permanently lose connectivity
|
||||
with the weave network and have to be restarted in order to
|
||||
re-connect.
|
||||
|
||||
### <a name="status-report"></a>Status report
|
||||
|
||||
The command
|
||||
|
||||
weave status
|
||||
|
||||
reports on the current status of the weave router.
|
||||
|
||||
This produces output like:
|
||||
|
||||
````
|
||||
Our name is 7a:f4:56:87:76:3b
|
||||
Sniffing traffic on &{39 65535 ethwe ae:e3:07:9c:8c:d4 up|broadcast|multicast}
|
||||
MACs:
|
||||
ba:8c:b9:dc:e1:c9 -> 7a:f4:56:87:76:3b (2014-10-23 16:39:19.482338935 +0000 UTC)
|
||||
ce:15:34:a9:b5:6d -> 7a:f4:56:87:76:3b (2014-10-23 16:39:28.257103595 +0000 UTC)
|
||||
7a:61:a2:49:4b:91 -> 7a:f4:56:87:76:3b (2014-10-23 16:39:27.482970752 +0000 UTC)
|
||||
9e:95:0c:54:8e:39 -> 7a:16:dd:5b:83:de (2014-10-23 16:39:28.795601325 +0000 UTC)
|
||||
72:5f:a4:60:e5:ce -> 7a:16:dd:5b:83:de (2014-10-23 16:39:29.575995255 +0000 UTC)
|
||||
Peers:
|
||||
Peer 7a:16:dd:5b:83:de (v31) (UID 13151318985609435078)
|
||||
-> 7a:f4:56:87:76:3b [37.157.33.76:7195]
|
||||
Peer 7a:f4:56:87:76:3b (v1) (UID 6913268221365110570)
|
||||
-> 7a:16:dd:5b:83:de [191.235.147.190:6783]
|
||||
Topology:
|
||||
unicast:
|
||||
7a:f4:56:87:76:3b -> 00:00:00:00:00:00
|
||||
7a:16:dd:5b:83:de -> 7a:16:dd:5b:83:de
|
||||
broadcast:
|
||||
7a:f4:56:87:76:3b -> [7a:16:dd:5b:83:de]
|
||||
7a:16:dd:5b:83:de -> []
|
||||
Reconnects:
|
||||
192.168.32.1:6783 (next try at 2014-10-23 16:39:50.585932102 +0000 UTC)
|
||||
````
|
||||
|
||||
The terms used here are explained further at
|
||||
[how it works](how-it-works.html).
|
||||
|
||||
A 'peer' on the weave network is a weave router; one per host. Each
|
||||
peer has a name, which tends to remain the same over restarts, and a
|
||||
unique identifier (UID) which is different each time it is run. These
|
||||
are opaque identifiers as far as the router is concerned, although the
|
||||
name defaults to a MAC address.
|
||||
|
||||
The 'Sniffing traffic' line shows details of the virtual ethernet
|
||||
interface that weave is using to receive packets on the local
|
||||
machine.
|
||||
|
||||
The 'MACs' section lists all MAC addresses known to this router. These
|
||||
identify containers in the weave network, as well as points for
|
||||
[host network integration](features.html#host-network-integration). For
|
||||
each MAC the list shows the peer they reside on, and the time when the
|
||||
router last saw some traffic from that MAC. The router forgets
|
||||
addresses which are inactive for longer than 10 minutes.
|
||||
|
||||
The 'Peers' section lists all peers known to this router, including
|
||||
itself. Each peer is shown with its name, version number (incremented
|
||||
on each reconnect) and the UID. Then each line beginning `->` shows
|
||||
another peer that it is connected to, with the IP address and port
|
||||
number of the connection. In the above example, the local router has
|
||||
connected to its peer using address 191.235.147.190:6783, and its peer
|
||||
sees the same connection as coming from 37.157.33.76:7195.
|
||||
|
||||
The 'Topology' section summarised the information for deciding how to
|
||||
route packets between peers, which is mostly of interest when the
|
||||
weave network is not fully connected. See the
|
||||
[architecture documentation](https://raw.githubusercontent.com/zettio/weave/master/docs/architecture.txt)
|
||||
for a full explanation.
|
||||
|
||||
Finally, 'Reconnects' lists peers that this router is aware of, but is
|
||||
not currently connected to. Each line contains some information about
|
||||
whether it is attempting to connect or is waiting for a while before
|
||||
connecting again.
|
||||
|
||||
### <a name="list-attached-containers"></a>List attached containers
|
||||
|
||||
weave ps
|
||||
|
||||
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
|
||||
|
||||
On each line are the container ID, its MAC address, then the list of
|
||||
IP address/routing prefix length ([CIDR
|
||||
notation](http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing))
|
||||
assigned on the weave network.
|
||||
|
||||
### Reboots
|
||||
|
||||
When a host reboots, docker's default behaviour is to restart any
|
||||
containers that were running. Since weave relies on special network
|
||||
configuration outside of the containers, the weave network will not
|
||||
function in this state.
|
||||
|
||||
To remedy this, stop and re-launch the weave container, and re-attach
|
||||
the application containers with `weave attach`.
|
||||
|
||||
For a more permanent solution,
|
||||
[disable Docker's auto-restart feature](https://docs.docker.com/articles/host_integration/)
|
||||
and create appropriate startup scripts to launch weave and run
|
||||
application containers from your favourite process manager.
|
||||
Reference in new issue
Block a user