Merge branch '1.0'
This commit is contained in:
commit
f31a3c1261
6 files changed
+25
-21
No files matched your search
@@ -62,10 +62,10 @@ First start weave on $HOST1:
|
||||
|
||||
host1$ weave launch && weave launch-dns && weave launch-proxy
|
||||
|
||||
this runs the weave router, DNS and proxy, each in their own
|
||||
container. Next we configure our `DOCKER_HOST` environment variable to
|
||||
point to the proxy, so that containers launched via the docker command
|
||||
line are automatically attached to the weave network:
|
||||
this runs the weave router, DNS and Docker API proxy, each in their
|
||||
own container. Next we configure our `DOCKER_HOST` environment
|
||||
variable to point to the proxy, so that containers launched via the
|
||||
docker command line are automatically attached to the weave network:
|
||||
|
||||
host1$ eval $(weave proxy-env)
|
||||
|
||||
@@ -98,11 +98,11 @@ available. Also, we can tell weave to connect to multiple peers by
|
||||
supplying multiple addresses, separated by spaces. And we can
|
||||
[add peers dynamically](http://docs.weave.works/weave/latest_release/features.html#dynamic-topologies).
|
||||
|
||||
The router, DNS and proxy need to be started once per host. The
|
||||
relevant container images are pulled down on demand, but if you wish
|
||||
you can preload them by running `weave setup` - this is particularly
|
||||
useful for automated deployments, and ensures that there are no delays
|
||||
during later operations.
|
||||
The router, DNS and Docker API proxy need to be started once per
|
||||
host. The relevant container images are pulled down on demand, but if
|
||||
you wish you can preload them by running `weave setup` - this is
|
||||
particularly useful for automated deployments, and ensures that there
|
||||
are no delays during later operations.
|
||||
|
||||
Now that we've got everything set up, let's see whether our containers
|
||||
can talk to each other...
|
||||
|
||||
+4
-2
@@ -57,8 +57,10 @@ our data centre.
|
||||
|
||||
### <a name="docker"></a>Seamless Docker integration
|
||||
|
||||
Weave includes a [proxy](proxy.html) so that containers launched via
|
||||
the Docker [command-line interface](https://docs.docker.com/reference/commandline/cli/) or
|
||||
Weave includes a [Docker API proxy](proxy.html) so that containers
|
||||
launched via the Docker
|
||||
[command-line interface](https://docs.docker.com/reference/commandline/cli/)
|
||||
or
|
||||
[remote API](https://docs.docker.com/reference/api/docker_remote_api/)
|
||||
are attached to the weave network before they begin execution.
|
||||
|
||||
|
||||
@@ -29,8 +29,9 @@ encrypted, which carry encapsulated network packets. These
|
||||
|
||||
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 by the proxy. Also
|
||||
connected to the bridge is the weave router container.
|
||||
is given an IP address & netmask supplied either by the user or
|
||||
Weave's IP address allocator. 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
|
||||
|
||||
+4
-4
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: Weave Proxy
|
||||
title: Weave Docker API Proxy
|
||||
layout: default
|
||||
---
|
||||
|
||||
# Weave Proxy
|
||||
# Weave Docker API Proxy
|
||||
|
||||
The proxy automatically attaches containers to the weave network when
|
||||
they are started using the ordinary Docker
|
||||
The Docker API proxy automatically attaches containers to the weave
|
||||
network when they are started using the ordinary Docker
|
||||
[command-line interface](https://docs.docker.com/reference/commandline/cli/)
|
||||
or
|
||||
[remote API](https://docs.docker.com/reference/api/docker_remote_api/),
|
||||
|
||||
@@ -142,7 +142,7 @@ is waiting for a while before connecting again.
|
||||
There may also be further sections for the
|
||||
[IP address allocator](ipam.html#troubleshooting),
|
||||
[weaveDNS](weavedns.html#troubleshooting), and
|
||||
[proxy](proxy.html#troubleshooting).
|
||||
[Weave Docker API Proxy](proxy.html#troubleshooting).
|
||||
|
||||
### <a name="list-attached-containers"></a>List attached containers
|
||||
|
||||
|
||||
+4
-3
@@ -87,9 +87,10 @@ or in conjunction with the router and proxy via `stop`.
|
||||
|
||||
The weaveDNS container running on every host acts as the nameserver
|
||||
for containers on that host. It learns about hostnames for local
|
||||
containers from the proxy and from the `weave run` command. If a
|
||||
hostname is in the `.weave.local` domain then weaveDNS records the
|
||||
association of that name with the container's weave IP address(es).
|
||||
containers from the Weave Docker API proxy and from the `weave run`
|
||||
command. If a hostname is in the `.weave.local` domain then weaveDNS
|
||||
records the association of that name with the container's weave IP
|
||||
address(es).
|
||||
|
||||
When weaveDNS is queried for a name in the `.weave.local` domain, it
|
||||
first checks its own records. If the name is not found there, it asks
|
||||
|
||||
Reference in new issue
Block a user