In this example, we'll be using the same lab topology we used in Chapter 3, User-Defined Networks, where we discussed user-defined overlay networks:

You'll need a couple of hosts, preferably with some of them being on different subnets. It is assumed that the Docker hosts used in this lab are in their default configuration. In some cases, the changes we make may require you to have root-level access to the system.

Weave is installed and managed through the Weave CLI tool. Once downloaded, it manages not only Weave-related configuration but also the provisioning of Weave services. On each host you wish to configure, you simply run the following three commands:

If all of these commands complete successfully, your Docker host is now ready to use Weave for Docker networking. To verify, you can check the Weave status using the weave status command:

user@docker1:~$ weave status
        Version: 1.7.1 (up to date; next check at 2016/10/11 01:26:42)

        Service: router
       Protocol: weave 1..2
           Name: 12:d2:fe:7a:c1:f2(docker1)
     Encryption: disabled
  PeerDiscovery: enabled
        Targets: 0
    Connections: 0
          Peers: 1
 TrustedSubnets: none

        Service: ipam
         Status: idle
          Range: 10.32.0.0/12
  DefaultSubnet: 10.32.0.0/12

        Service: dns
         Domain: weave.local.
       Upstream: 10.20.30.13
            TTL: 1
        Entries: 0

        Service: proxy
        Address: unix:///var/run/weave/weave.sock

        Service: plugin
     DriverName: weave
user@docker1:~$ 

This output provides you with information regarding all five of Weave's network-related services. Those are router, ipam, dns, proxy, and plugin. At this point, you might be wondering where all these services are running. Keeping with the Docker theme, they're all running inside containers on the host:

As you can see, there are three Weave-related containers running on the host. Running the weave launch command spawned all three containers. Each container provides unique services that Weave uses to network containers. The weaveproxy container serves as a shim layer allowing Weave to be leveraged directly from the Docker CLI. The weaveplugin container implements a custom network driver for Docker. The "weave" container is commonly called the Weave router and provides all the other services that are related to Weave networking.

Each of these containers can be configured and run independently. Running Weave with the weave launch command assumes that you'd like to use all three containers and deploys them with a sane set of defaults. However, if you ever wish to change the settings related to a specific container, you'd need to launch the containers independently. This can be done in this manner:

weave launch-router
weave launch-proxy
weave launch-plugin

If at any time you wish to clean up the Weave configuration on a particular host, you can issue the weave reset command, which will clean up all the Weave-related service containers. To start our example, we'll only be using the Weave router container. Let's clear out the Weave configuration and then start just that container on our host docker1:

user@docker1:~$ weave reset
user@docker1:~$ weave launch-router
e5af31a8416cef117832af1ec22424293824ad8733bb7a61d0c210fb38c4ba1e
user@docker1:~$

The Weave router (weave container) is the only container we need to provide the majority of the network functionality. Let's take a look at the configuration options that are passed to the Weave router by default by inspecting the weave container configuration:

user@docker1:~$ docker inspect weave
…<Additional output removed for brevity>…
        "Args": [
            "--port",
            "6783",
            "--name",
            "12:d2:fe:7a:c1:f2",
            "--nickname",
            "docker1",
            "--datapath",
            "datapath",
            "--ipalloc-range",
            "10.32.0.0/12",
            "--dns-effective-listen-address",
            "172.17.0.1",
            "--dns-listen-address",
            "172.17.0.1:53",
            "--http-addr",
            "127.0.0.1:6784",
            "--resolv-conf",
            "/var/run/weave/etc/resolv.conf" 
…<Additional output removed for brevity>… 
user@docker1:~$

There are some items worth pointing out in the preceding output. The IP allocation range is given as 10.32.0.0/12. This is significantly different than the 172.17.0.0/16 we're used to dealing with by default on the docker0 bridge. Also, there's an IP address defined to be used as the DNS listen address. Recall that Weave also provides WeaveDNS, which can be used to resolve the names of other containers on the Weave network by name. Notice that this IP address is that of the docker0 bridge interface on the host.

Let's now configure another one of our hosts as part of the Weave network:

user@docker2:~$ sudo curl -L git.io/weave -o /usr/local/bin/weave
user@docker2:~$ sudo chmod +x /usr/local/bin/weave
user@docker2:~$ weave launch-router 10.10.10.101
48e5035629b5124c8d3bedf09fca946b333bb54aff56704ceecef009b53dd449
user@docker2:~$

Note that we installed Weave in the same manner as before, but when we launched the router container, we did so by specifying the IP address of the first Docker host. In Weave, this is how we peer multiple hosts together. Any host you wish to connect to the Weave network just needs to specify the IP address of any existing node on the Weave network. If we check the status of Weave on this newly attached node, we should see that it shows as connected:

user@docker2:~$ weave status
        Version: 1.7.1 (up to date; next check at 2016/10/11 03:36:22)
        Service: router
       Protocol: weave 1..2
           Name: e6:b1:90:cd:76:da(docker2)
     Encryption: disabled
  PeerDiscovery: enabled
        Targets: 1
    Connections: 1 (1 established)
          Peers: 2 (with 2 established connections)
 TrustedSubnets: none
…<Additional output removed for brevity>…
user@docker2:~$

We can proceed to connect the other two remaining nodes in the same way after Weave is installed:

user@docker3:~$ weave launch-router 10.10.10.102
user@docker4:~$ weave launch-router 192.168.50.101

In each case, we specify the previously joined Weave node as the peer of the node we are attempting to join. In our case, our join pattern looks like what's shown in the following image:

However, we could have had each node join any other existing node and achieved the same result. That is, joining nodes docker2, docker3, and docker4 to docker1 would have yielded the same end state. This is because Weave only needs to talk to an existing node to get information about the current state of the Weave network. Since all of the existing members have that information, it doesn't matter which one they talk to in order to join a new node to the Weave network. If we check the status of any of the Weave nodes now, we should see that we have a total of four peers:

user@docker4:~$ weave status
        Version: 1.7.1 (up to date; next check at 2016/10/11 03:25:22)

        Service: router
       Protocol: weave 1..2
           Name: 42:ec:92:86:1a:31(docker4)
     Encryption: disabled
  PeerDiscovery: enabled
        Targets: 1
    Connections: 3 (3 established)
          Peers: 4 (with 12 established connections)
 TrustedSubnets: none 
…<Additional output removed for brevity>… 
user@docker4:~$

We can see that this node has three connections, one to each of the other joined nodes. This gives us a total of four peers with twelve connections, three per Weave node. So despite only configuring peering between three nodes, we end up with a full mesh for container connectivity between all the hosts:

Now the configuration of Weave is complete, and we have a full mesh network between all of our Weave-enabled Docker hosts. You can verify the connections that each host has with the other peers using the weave status connections command:

user@docker1:~$ weave status connections
-> 192.168.50.102:6783   established fastdp 42:ec:92:86:1a:31(docker4)
<- 10.10.10.102:45632    established fastdp e6:b1:90:cd:76:da(docker2)
<- 192.168.50.101:38411  established fastdp ae:af:a6:36:18:37(docker3)
user@docker1:~$ 

You'll note that this configuration did not require the configuration of a standalone key-value store.

It should also be noted that Weave peers can be managed manually using the Weave CLI connect and forget commands. If you fail to specify an existing member of the Weave network when you instantiate Weave, you can use Weave connect to manually connect to an existing member. Also, if you remove a member from the Weave network and don't expect it to return, you can tell the network to entirely forget the peer with the forget command.