From a1badfccc7f724008da0ddae89ac40e5ef7eefc0 Mon Sep 17 00:00:00 2001 From: Michael Bridgen Date: Fri, 14 Nov 2014 11:55:07 +0000 Subject: [PATCH 1/4] Put gh-pages branch in site/ git read-tree -u --prefix=site/ gh-pages This is so we can work on code and docs at the same time. --- site/_config.yml | 4 + site/_layouts/default.html | 43 +++ site/boot2docker.md | 26 ++ site/building.md | 92 +++++++ site/features.md | 354 ++++++++++++++++++++++++ site/how-it-works.md | 37 +++ site/images/blacktocat.png | Bin 0 -> 1428 bytes site/index.md | 14 + site/javascripts/main.js | 1 + site/params.json | 1 + site/stylesheets/pygment_trac.css | 70 +++++ site/stylesheets/stylesheet.css | 431 ++++++++++++++++++++++++++++++ site/troubleshooting.md | 152 +++++++++++ 13 files changed, 1225 insertions(+) create mode 100644 site/_config.yml create mode 100644 site/_layouts/default.html create mode 100644 site/boot2docker.md create mode 100644 site/building.md create mode 100644 site/features.md create mode 100644 site/how-it-works.md create mode 100644 site/images/blacktocat.png create mode 100644 site/index.md create mode 100644 site/javascripts/main.js create mode 100644 site/params.json create mode 100644 site/stylesheets/pygment_trac.css create mode 100644 site/stylesheets/stylesheet.css create mode 100644 site/troubleshooting.md diff --git a/site/_config.yml b/site/_config.yml new file mode 100644 index 00000000..cfb2b170 --- /dev/null +++ b/site/_config.yml @@ -0,0 +1,4 @@ +markdown: redcarpet + +redcarpet: + extensions: ['fenced_code_blocks', 'smart'] diff --git a/site/_layouts/default.html b/site/_layouts/default.html new file mode 100644 index 00000000..b84feff7 --- /dev/null +++ b/site/_layouts/default.html @@ -0,0 +1,43 @@ + + + + + + + + + + + weave {% if page.title %} | {{ page.title }} {% endif %} + + + + +
+
+ View on GitHub + +

weave

+

The Docker Network

+ +
+
+ + +
+
+ {{ content }} +
+
+ + + + + + + + diff --git a/site/boot2docker.md b/site/boot2docker.md new file mode 100644 index 00000000..125ccfa0 --- /dev/null +++ b/site/boot2docker.md @@ -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") diff --git a/site/building.md b/site/building.md new file mode 100644 index 00000000..fe84f79a --- /dev/null +++ b/site/building.md @@ -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. diff --git a/site/features.md b/site/features.md new file mode 100644 index 00000000..aa456862 --- /dev/null +++ b/site/features.md @@ -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) + +### 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. + +### 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. + +### 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 + +### 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. + +### 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. + +### 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. + +### 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. + +### 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. + +### 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. + +### 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. + +### 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. + +### 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. + +### 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. + +### 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. + +### 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/). diff --git a/site/how-it-works.md b/site/how-it-works.md new file mode 100644 index 00000000..dceb89d4 --- /dev/null +++ b/site/how-it-works.md @@ -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). diff --git a/site/images/blacktocat.png b/site/images/blacktocat.png new file mode 100644 index 0000000000000000000000000000000000000000..6e264fe57a2e35a2855405ac7d4102c3f6ddcdae GIT binary patch literal 1428 zcmeAS@N?(olHy`uVBq!ia0vp^av;pX1|+Qw)-3{3k|nMYCBgY=CFO}lsSJ)O`AMk? zp1FzXsX?iUDV2pMQ*9U+n3Xa^B1$5BeXNr6bM+EIYV;~{3xK*A7;Nk-3KEmEQ%e+* zQqwc@Y?a>c-mj#PnPRIHZt82`Ti~3Uk?B!Ylp0*+7m{3+ootz+WN)WnQ(*-(AUCxn zQK2F?C$HG5!d3}vt`(3C64qBz04piUwpD^SD#ABF!8yMuRl!uxKsVXI%s|1+P|wiV z#N6CmN5ROz&_Lh7NZ-&%*U;R`*vQJjKmiJrfVLH-q*(>IxIyg#@@$ndN=gc>^!3Zj z%k|2Q_413-^$jg8EkR}&8R-I5=oVMzl_XZ^<`pZ$OmImpPAEg{v+u2}(t{7puX=A(aKG z`a!A1`K3k4z=%sz23b{L-^Aq1JP;qO z-q+X4Gq1QLF)umQ)5TT^Xo6m5W{Q=eg`=5?o13Glvx}*rp{t>#shg3DvyriZv5}jZ ztD`wguSMv>2~2MaLa!4}y`ZF!TL84#CABECEH%ZgC_h&L>}9J=EN(GzcCm0X zaRr%YgxxI=y(w7S0@dq`Q?EYIG5Vm0MT%&c5HR(CnDAr^T6f1avxRvmvnsN+?-j}Z~1)Zr#rqzrt`edmo44*B<0=C4>mrxHF6$p zVws~UocMfeI`gB8pYMLYTzA87`NOI2w2B*JM5L`^AkN4AFQu&S+6ULTPjv;vzl4& z-eaK_F|D4~l3hzBSF~icNT@MID=v+_X`vpuvf=8+S(|^vlRdHe0<)v-^wiVR3w=TQ)uFA9F z>vmqStatus 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. + +### 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. From eeff76dbd706341b4a500599595b4b928092cf4e Mon Sep 17 00:00:00 2001 From: Michael Bridgen Date: Fri, 14 Nov 2014 14:00:22 +0000 Subject: [PATCH 2/4] Script to merge master/site into gh-pages --- bin/merge-into-gh-pages | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100755 bin/merge-into-gh-pages diff --git a/bin/merge-into-gh-pages b/bin/merge-into-gh-pages new file mode 100755 index 00000000..a21a6f1e --- /dev/null +++ b/bin/merge-into-gh-pages @@ -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 From 10263429935faac101d15fc8e4980b602155101c Mon Sep 17 00:00:00 2001 From: Michael Bridgen Date: Fri, 14 Nov 2014 14:02:26 +0000 Subject: [PATCH 3/4] Lowercase weave for consistency --- site/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/site/index.md b/site/index.md index 8c3537d2..3e10185a 100644 --- a/site/index.md +++ b/site/index.md @@ -1,9 +1,9 @@ --- -title: Weave, the Docker network +title: weave, the Docker network layout: default --- -# Weave documentation +# weave documentation * [Introduction and example (in README)](https://github.com/zettio/weave#readme) * [Features](features.html) From 04ed4aef6c81494d0e69a6fc23a9e360c55a7b87 Mon Sep 17 00:00:00 2001 From: Michael Bridgen Date: Fri, 14 Nov 2014 14:08:45 +0000 Subject: [PATCH 4/4] Script to publish gh-pages to site Ideally to be used after merging changes from master with `./bin/merge-into-gh-pages` --- bin/publish-gh-pages | 3 +++ 1 file changed, 3 insertions(+) create mode 100755 bin/publish-gh-pages diff --git a/bin/publish-gh-pages b/bin/publish-gh-pages new file mode 100755 index 00000000..f31728b5 --- /dev/null +++ b/bin/publish-gh-pages @@ -0,0 +1,3 @@ +#! /bin/sh +set -e +git push git@github.com:zettio/weave gh-pages:gh-pages