5.3 KiB
title, menu_order
| title | menu_order |
|---|---|
| Integrating Docker via the Network Plugin | 60 |
- Launching Weave Net and Running Containers Using the Plugin
- Restarting the Plugin
- Bypassing the Central Cluster Store When Building Docker Apps
- Using other plugin command-line arguments
Docker versions 1.9 and later have a plugin mechanism for adding
different network providers. Weave Net installs itself as a network plugin
when you start it with weave launch. The Weave Docker Networking plugin is fast and easy to use and
best of all doesn't require an external cluster store in order to use it.
To create a network which can span multiple Docker hosts, Weave Net peers must be connected to each other, by specifying the other hosts during weave launch or via
weave connect.
See Using Weave Net for a discussion on peer connections.
After you've launched Weave Net and peered your hosts, you can start containers using the following, for example:
$ docker run --net=weave -ti ubuntu
on any of the hosts, and they can all communicate with each other.
Warning! It is inadvisable to attach containers to the Weave network using the Weave Docker Networking Plugin and Weave Docker API Proxy simultaneously. Such containers will end up with two Weave network interfaces and two IP addresses, which is rarely desirable. To ensure that the proxy is not being used, do not run eval $(weave env), or docker $(weave config).
In order to use Weave Net's Service Discovery you
must pass the additional arguments --dns and -dns-search, for
which a helper is provided in the Weave script:
$ 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:
host1$ weave launch host2
host2$ weave launch host1
then run your containers using the Docker command-line:
host1$ docker run --net=weave -ti ubuntu
root@1458e848cd90:/# hostname -i
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
The plugin, like all Weave Net components, is started with a policy of --restart=always, so that it is always there after a restart or reboot. If you remove this container (for example, when using weave reset) before removing all endpoints created using --net=weave, Docker may hang for a long time when it subsequently tries to re-establish communications to the plugin.
Unfortunately, Docker 1.9 may also try to communicate with the plugin before it has even started it.
If you are using systemd with Docker 1.9, 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]:
TimeoutStartSec=0
###Bypassing the Central Cluster Store When Building Docker Apps
To run a Docker cluster without a central database, you need to ensure the following:
- Run in "local" scope. This tells Docker to ignore any cross-host coordination.
- Allow Weave to handle all the cross-host coordination and to set up all networks. This is done by using the
weave launchcommand. - Provide an IP Address Management (IPAM) driver, which links to Weave Net's own IPAM system
All cross-host coordination is handled by Weave Net's "mesh" communication, using gossipDNS and eventual consistency to avoid the need for constant communication and dependency on a central cluster store.
###Using other plugin command-line arguments
If you need to give additional arguments to the plugin independently, don't
use weave launch, but instead run:
$ weave launch-router [other peers]
$ weave launch-plugin [plugin arguments]
The plugin command-line arguments are:
--log-level=debug|info|warning|error--tells the plugin how much information to emit for debugging.--no-restart-- remove the default policy of--restart=always, if you want to control start-up of the plugin yourself--no-multicast-route-- stops weave from adding a static IP route for multicast traffic onto its interface
By default, multicast traffic is routed over the weave network.
To turn this off, e.g. you want to configure your own multicast
route, add the --no-multicast-route flag to weave launch-plugin.
Note: When using the Docker Plugin, there is no need to run
eval $(weave env)to enable the Proxy. If you do, you may end up with two weave network interfaces and two IP addresses for each container.
See Also