From e2c8dba981c9ad23f12548078bed7479d63a9138 Mon Sep 17 00:00:00 2001 From: Anita Buehrle Date: Thu, 3 Mar 2016 16:12:12 -0600 Subject: [PATCH 1/2] cleaned up product names --- site/encryption/crypto-overview.md | 12 ++++---- site/encryption/implementation.md | 10 +++---- site/fastdp/fastdp-how-it-works.md | 6 ++-- site/fastdp/using-fastdp.md | 10 +++---- site/features.md | 30 +++++++++---------- site/installing-weave.md | 6 ++-- site/introducing-weave.md | 12 +++----- site/ipam/allocation-multi-ipam.md | 2 +- site/ipam/overview-init-ipam.md | 20 ++++++------- site/ipam/stop-remove-peers-ipam.md | 27 +++++++++-------- site/ipam/troubleshooting-ipam.md | 6 ++-- site/plugin/plugin-how-it-works.md | 8 ++--- site/plugin/weave-plugin-how-to.md | 10 +++---- site/router-topology/network-topology.md | 4 +-- site/router-topology/overview.md | 18 +++++------ site/router-topology/router-encapsulation.md | 6 ++-- site/troubleshooting.md | 29 +++++++++--------- site/using-weave/application-isolation.md | 10 +++---- site/using-weave/deploying-applications.md | 18 +++++------ .../dynamically-attach-containers.md | 4 +-- .../finding-adding-hosts-dynamically.md | 14 ++++----- site/using-weave/host-network-integration.md | 6 ++-- site/using-weave/isolating-applications.md | 2 +- site/using-weave/manual-ip-address.md | 4 +-- site/using-weave/multi-cloud-multi-hop.md | 11 ++++--- .../security-untrusted-networks.md | 9 +++--- site/using-weave/service-export.md | 6 ++-- site/using-weave/service-management.md | 10 +++---- .../automatic-discovery-proxy.md | 5 ++-- site/weave-docker-api/ipam-proxy.md | 6 ++-- .../weave-docker-api/name-resolution-proxy.md | 8 ++--- site/weave-docker-api/set-up-proxy.md | 6 ++-- .../weave-docker-api/troubleshooting-proxy.md | 2 +- site/weave-docker-api/using-proxy.md | 14 ++++----- site/weavedns/how-works-weavedns.md | 4 +-- site/weavedns/troubleshooting-weavedns.md | 2 +- 36 files changed, 176 insertions(+), 181 deletions(-) diff --git a/site/encryption/crypto-overview.md b/site/encryption/crypto-overview.md index ae8c6602..4ff4d0e0 100644 --- a/site/encryption/crypto-overview.md +++ b/site/encryption/crypto-overview.md @@ -5,11 +5,11 @@ layout: default -Weave can be configured to encrypt both the data passing over the TCP +Weave Net can be configured to encrypt both the data passing over the TCP connections and the payloads of UDP packets sent between peers. This is accomplished using the [NaCl](http://nacl.cr.yp.to/) crypto libraries, employing Curve25519, XSalsa20 and Poly1305 to encrypt and -authenticate messages. Weave protects against injection and replay +authenticate messages. Weave Net protects against injection and replay attacks for traffic forwarded between peers. NaCl was selected because of its good reputation both in terms of @@ -20,17 +20,17 @@ quite difficult to use NaCl incorrectly. Contrast this with libraries such as OpenSSL where the library and its APIs are vast in size, poorly documented, and easily used wrongly. -There are some similarities between Weave's crypto and -[TLS](https://tools.ietf.org/html/rfc4346). Weave does not need to cater +There are some similarities between Weave Net's crypto and +[TLS](https://tools.ietf.org/html/rfc4346). Weave Net does not need to cater for multiple cipher suites, certificate exchange and other requirements emanating from X509, and a number of other features. This simplifies the protocol and implementation considerably. On the other -hand, Weave needs to support UDP transports, and while there are +hand, Weave Net needs to support UDP transports, and while there are extensions to TLS such as [DTLS](https://tools.ietf.org/html/rfc4347) which can operate over UDP, these are not widely implemented and deployed. **See Also** - * [How Weave Implements Encryption](/site/encryption/ephemeral-key.md) + * [How Weave Implements Encryption](/site/encryption/implementation.md) * [Securing Containers Across Untrusted Networks](/site/using-weave/security-untrusted-networks.md) \ No newline at end of file diff --git a/site/encryption/implementation.md b/site/encryption/implementation.md index 175b8319..0eb55c15 100644 --- a/site/encryption/implementation.md +++ b/site/encryption/implementation.md @@ -1,5 +1,5 @@ --- -title: How Weave Implements Encryption +title: How Weave Net Implements Encryption layout: default --- @@ -27,7 +27,7 @@ When a peer has received a public key from the remote peer, it uses this to form the ephemeral session key for this connection. The public key from the remote peer is combined with the private key for the local peer in the usual [Diffie-Hellman way](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange), -resulting in both peersarriving at the same shared key. To this is appended the supplied +resulting in both peers arriving at the same shared key. To this is appended the supplied password, and the result is hashed through SHA256, to form the final ephemeral session key. @@ -53,7 +53,7 @@ between two peers. Generating fresh keys for every connection provides forward secrecy at the cost of placing a demand on the Linux CSPRNG (accessed by `GenerateKey` via `/dev/urandom`) proportional to -the number of inbound connection attempts. Weave has accept throttling +the number of inbound connection attempts. Weave Net has accept throttling to mitigate against denial of service attacks that seek to deplete the CSPRNG entropy pool, however even at the lower bound of ten requests per second, there may not be enough entropy gathered on a headless @@ -71,7 +71,7 @@ entirely safe for use as key material. By way of comparison, this is exactly how OpenSSL works - it reads 256 bits of entropy at startup, and uses that to seed an internal CSPRNG, -which is used to generate keys. While Weave could have taken +which is used to generate keys. While Weave Net could have taken the same approach and built a custom CSPRNG to work around the potential `/dev/random` blocking issue, the decision was made to rely on the [heavily scrutinised](http://eprint.iacr.org/2012/251.pdf) Linux random number @@ -80,7 +80,7 @@ here](http://cr.yp.to/highspeed/coolnacl-20120725.pdf) (page 10, 'Centralizing randomness'). >>**Note:**The aforementioned notwithstanding, if -Weave's demand on `/dev/urandom` is causing you problems with blocking +Weave Net's demand on `/dev/urandom` is causing you problems with blocking `/dev/random` reads, please get in touch with us - we'd love to hear about your use case. diff --git a/site/fastdp/fastdp-how-it-works.md b/site/fastdp/fastdp-how-it-works.md index 80874841..3ed4033e 100644 --- a/site/fastdp/fastdp-how-it-works.md +++ b/site/fastdp/fastdp-how-it-works.md @@ -4,12 +4,12 @@ layout: default --- -Weave implements an overlay network between Docker hosts. Without fast datapath enabled, each packet is encapsulated in a tunnel protocol header and sent to the destination host, where the header is removed. The Weave router is a user space process, which means that the packet follows a winding path in and out of the Linux kernel: +Weave Net implements an overlay network between Docker hosts. Without fast datapath enabled, each packet is encapsulated in a tunnel protocol header and sent to the destination host, where the header is removed. The Weave router is a user space process, which means that the packet follows a winding path in and out of the Linux kernel: ![Weave Net Encapsulation](/images/weave-net-encap1-1024x459.png) -The fast datapath in Weave uses the Linux kernel's [Open vSwitch datapath module](https://www.kernel.org/doc/Documentation/networking/openvswitch.txt). This module enables the Weave router to tell the kernel how to process packets: +The fast datapath in Weave Net uses the Linux kernel's [Open vSwitch datapath module](https://www.kernel.org/doc/Documentation/networking/openvswitch.txt). This module enables the Weave Net router to tell the kernel how to process packets: ![Weave Net Encapsulation](/images/weave-net-fdp1-1024x454.png) @@ -19,7 +19,7 @@ Because Weave Net issues instructions directly to the kernel, context switches a Prior to version 1.2, Weave Net used a custom encapsulation format. Fast data path uses VXLAN, and like Weave Net's custom encapsulation format, VXLAN is UDP-based, and therefore needs no special configuration with network infrastructure. ->>Note:The required open vSwitch datapath (ODP) and VXLAN features are present in Linux kernel versions 3.12 and greater. If your kernel was built without the necessary modules Weave Net will fall back to the "user mode" packet path. +>>**Note:** The required open vSwitch datapath (ODP) and VXLAN features are present in Linux kernel versions 3.12 and greater. If your kernel was built without the necessary modules Weave Net will fall back to the "user mode" packet path. **See Also** diff --git a/site/fastdp/using-fastdp.md b/site/fastdp/using-fastdp.md index 44cf1659..28eeb300 100644 --- a/site/fastdp/using-fastdp.md +++ b/site/fastdp/using-fastdp.md @@ -20,19 +20,19 @@ $ WEAVE_NO_FASTDP=true weave launch ###Fast Datapath and Encryption -Encryption does not work with fast datapath. If you enable encryption using the `--password` option to launch weave (or you use the `WEAVE_PASSWORD` environment variable), fast data path will by default be disabled. +Encryption does not work with fast datapath. If you enable encryption using the `--password` option to launch weave (or you use the `WEAVE_PASSWORD` environment variable), fast datapath will by default be disabled. -When encryption is not in use there may be other conditions in which the fastdp will revert back to `sleeve mode`. Once these conditions pass, weave will revert back to using fastdp. To view which mode Weave is using, run `weave status connections`. +When encryption is not in use there may be other conditions in which the fast datapath reverts to `sleeve mode`. Once these conditions pass, Weave Net reverts back to using fastdp. To view which mode Weave Net is using, run `weave status connections`. ###Viewing Connection Mode Fastdp or Sleeve -Weave automatically uses the fastest datapath for every connection unless it encounters a situation that prevents it from working. To ensure that Weave can use the fast data path: +Weave Net automatically uses the fastest datapath for every connection unless it encounters a situation that prevents it from working. To ensure that Weave Net can use the fast datapath: * Avoid Network Address Translation (NAT) devices * Open UDP port 6784 (This is the port used by the Weave routers) * Ensure that `WEAVE_MTU` fits with the `MTU` of the intermediate network (see below) -The use of fast datapath is an automated connection-by-connection decision made by Weave, and because of this, you may end up with a mixture of connection tunnel types. If fast data path cannot be used for a connection, Weave falls back to the "user space" packet path. +The use of fast datapath is an automated connection-by-connection decision made by Weave Net, and because of this, you may end up with a mixture of connection tunnel types. If fast datapath cannot be used for a connection, Weave Net falls back to the "user space" packet path. Once a Weave network is set up, you can query the connections using the `weave status connections` command: @@ -41,7 +41,7 @@ $ weave status connections <-192.168.122.25:43889 established fastdp a6:66:4f:a5:8a:11(ubuntu1204) ~~~ -Where fastdp indicates that fast data path is being used on a connection. If fastdp is not shown, the field displays `sleeve` indicating Weave Net's fall-back encapsulation method: +Where fastdp indicates that fast datapath is being used on a connection. If fastdp is not shown, the field displays `sleeve` indicating Weave Net's fall-back encapsulation method: ~~~bash $ weave status connections diff --git a/site/features.md b/site/features.md index 45d1fa7b..0a46f4d4 100644 --- a/site/features.md +++ b/site/features.md @@ -37,7 +37,7 @@ To application containers, the network established by Weave resembles a giant Ethernet switch, where all containers are connected and can easily access services from one another. -Because Weave uses standard protocols, your favorite network +Because Weave Net uses standard protocols, your favorite network tools and applications, developed over decades, can still be used to configure, secure, monitor, and troubleshoot a container network. @@ -50,7 +50,7 @@ and [Deploying Applications to Weave Net](/site/using-weave/deploying-applicatio ###Fast Datapath -Weave automatically chooses the fastest available method to +Weave Net automatically chooses the fastest available method to transport data between peers. The best performing of these (the 'fast datapath') offers near-native throughput and latency. @@ -63,7 +63,7 @@ See [Using Fast Datapath](/site/fastdp/using-fastdp.md) and ###Seamless Docker Integration (Weave Docker API Proxy) -Weave includes a [Docker API Proxy](/site/weave-docker-api/set-up-proxy.md), which can be +Weave Net includes a [Docker API Proxy](/site/weave-docker-api/set-up-proxy.md), which can be used to launch containers to the Weave network using the Docker [command-line interface](https://docs.docker.com/reference/commandline/cli/) or the [remote API](https://docs.docker.com/reference/api/docker_remote_api/). To use the proxy run: @@ -82,7 +82,7 @@ See [Using the Weave Docker API](/site/weave-docker-api/using-proxy.md) ###Weave Network Docker Plugin -Weave can also be used as a [Docker plugin](https://docs.docker.com/engine/extend/plugins_network/). A Docker network +Weave Net can also be used as a [Docker plugin](https://docs.docker.com/engine/extend/plugins_network/). A Docker network named `weave` is created by `weave launch`, which is used as follows: $ docker run --net=weave -ti ubuntu @@ -107,7 +107,7 @@ Containers are automatically allocated a unique IP address. To view the addresse Instead of allowing Weave to automatically allocate addresses, an IP address and a network can be explicitly specified. See [How to Manually Specify IP Addresses and Subnets(/site/using-weave/manual-ip-address.md) for instructions. -For a discussion on how Weave uses IPAM, see [Automatic IP Address Management](/site/ipam/overview-init-ipam.md). And also review the +For a discussion on how Weave Net uses IPAM, see [Automatic IP Address Management](/site/ipam/overview-init-ipam.md). And also review the [the basics of IP addressing](/site/ip-addresses/ip-addresses.md) for an explanation of addressing and private networks. @@ -128,7 +128,7 @@ See [Naming and discovery with Weavedns](/site/weavedns/how-works-weavedns.md). ###Application Isolation -A single weave network can host multiple, isolated +A single Weave network can host multiple, isolated applications, with each application's containers being able to communicate with each other but not with the containers of other applications. @@ -158,13 +158,13 @@ for details. ###Security In keeping with our ease-of-use philosophy, the cryptography -in Weave is intended to satisfy a particular user requirement: +in Weave Net is intended to satisfy a particular user requirement: strong, out-of-the-box security without a complex setup or the need to wade your way through the configuration of cipher suite negotiation, certificate generation or any of the other things needed to properly secure an IPsec or TLS installation. -Weave communicates via TCP and UDP on a well-known port, so +Weave Net communicates via TCP and UDP on a well-known port, so you can adapt whatever is appropriate to your requirements - for example an IPsec VPN for inter-DC traffic, or VPC/private network inside a data-center. @@ -175,7 +175,7 @@ mechanism which you can use in conjunction with or as an alternative to any other security technologies you have running alongside Weave. -Weave implements encryption and security using [Daniel J. Bernstein's NaCl library](http://nacl.cr.yp.to/index.html). +Weave Net implements encryption and security using [Daniel J. Bernstein's NaCl library](http://nacl.cr.yp.to/index.html). For information on how to secure your Docker network connections, see [Securing Connections Across Untrusted Networks](/site/using-weave/security-untrusted-networks.md) @@ -184,7 +184,7 @@ and for a more technical discussion on how Weave implements encryption see, [Usi ###Host Network Integration -Weave application networks can be integrated with a host's +Weave Net application networks can be integrated with a host's network, and establish connectivity between the host and application containers anywhere. @@ -213,7 +213,7 @@ See [Enabling Multi-Cloud networking and Muti-hop Routing](/site/using-weave/mul ###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 +even when there is only partial connectivity between the hosts. Weave Net routes traffic between containers as long as there is at least one *path* of connected hosts between them. @@ -239,17 +239,17 @@ See [Managing Services in Weave: Exporting, Importing, Binding and Routing](/sit ###Fault Tolerance -Weave peers continually exchange topology information, and +Weave Net 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, where containers on either side of a partition can continue to communicate, with full connectivity being restored when the partition heals. -The Weave Router container is very lightweight, fast and and disposable. -For example, should Weave ever run into difficulty, one can +The Weave Net Router container is very lightweight, fast and and disposable. +For example, should Weave Net 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 -if the Weave container is restarted quickly enough, +if the Weave Net container is restarted quickly enough, may not experience a temporary connectivity failure. diff --git a/site/installing-weave.md b/site/installing-weave.md index 3e4848f5..37d3470a 100644 --- a/site/installing-weave.md +++ b/site/installing-weave.md @@ -15,12 +15,12 @@ Install Weave Net by running the following: If you are on OSX and are using Docker Machine) you need to make sure that a VM is running and configured before getting Weave Net. Setting up a VM is shown in [the Docker Machine documentation](https://docs.docker.com/installation/mac/#from-your-shell). -After the VM is configured with Docker Machine, Weave can be launched directly from the OSX host. +After the VM is configured with Docker Machine, Weave Net can be launched directly from the OSX host. -Weave respects the environment variable `DOCKER_HOST`, so that you can run +Weave Net respects the environment variable `DOCKER_HOST`, so that you can run and control a Weave Network locally on a remote host. See [Using The Weave Docker API Proxy](/site/weave-docker-api/using-proxy.md) -With Weave downloaded onto your VMs or hosts, you are ready to launch a Weave network and deploy apps onto it. See [Deploying Applications to Weave](/site/using-weave/deploying-applications.md#launching) +With Weave Net downloaded onto your VMs or hosts, you are ready to launch a Weave network and deploy apps onto it. See [Deploying Applications to Weave](/site/using-weave/deploying-applications.md#launching) CoreOS users see [here](https://github.com/fintanr/weave-gs/blob/master/coreos-simple/user-data) for an example of installing Weave using cloud-config. diff --git a/site/introducing-weave.md b/site/introducing-weave.md index 7f56af9f..090db762 100644 --- a/site/introducing-weave.md +++ b/site/introducing-weave.md @@ -4,11 +4,7 @@ layout: default --- -##What is Weave Net? - -Weave creates a virtual network that connects Docker containers deployed across multiple hosts and enables their automatic discovery. With Weave Net, portable microservices-based applications consisting of multiple containers can run anywhere: on one host, multiple hosts or even across cloud providers and data centers. -Applications use the network just as if the containers were all plugged into the same network switch, without having to configure port mappings, or ambassador links. - +Weave Net creates a virtual network that connects Docker containers deployed across multiple hosts and enables their automatic discovery. With Weave Net, portable microservices-based applications consisting of multiple containers can run anywhere: on one host, multiple hosts or even across cloud providers and data centers. Applications use the network just as if the containers were all plugged into the same network switch, without having to configure port mappings, or ambassador links. Services provided by application containers on the weave network can be exposed to the outside world, regardless of where they are running. Similarly, existing internal systems can be opened to accept connections from application containers irrespective of their location. @@ -17,13 +13,13 @@ Services provided by application containers on the weave network can be exposed ###Hassle Free Configuration -Weave simplifies setting up a container network. Because containers on a Weave network use standard port numbers, (for example MySQL’s default is port 3306), managing microservices is straightforward. Every container can find the IP of any other container using a simple DNS query on the container's name, and it can also communicate directly without NAT, without using port mappings or complicated ambassador linking. And best of all deploying a Weave container network requires zero changes to your application’s code. +Weave Net simplifies setting up a container network. Because containers on a Weave network use standard port numbers, (for example MySQL’s default is port 3306), managing microservices is straightforward. Every container can find the IP of any other container using a simple DNS query on the container's name, and it can also communicate directly without NAT, without using port mappings or complicated ambassador linking. And best of all deploying a Weave container network requires zero changes to your application’s code. ![Weave Net Encapsulation](/images/weave-net-overview.png) ###Service Discovery -Weave implements service discovery by providing a fast "micro DNS" server at each node. You simply name containers and everything 'just works', including load balancing across multiple containers with the same name. +Weave Net implements service discovery by providing a fast "micro DNS" server at each node. You simply name containers and everything 'just works', including load balancing across multiple containers with the same name. ###No External Cluster Store Required @@ -34,7 +30,7 @@ For information about the Weave Docker Plugin, see “Using the Weave Network Do ###Operates in Partially Connected Networks -Weave can forward traffic between nodes, and it works even if the mesh network is only partially connected. This means that you can have a mix of legacy systems and containerized apps and still use Weave Net to keep everything in communication. +Weave Net can forward traffic between nodes, and it works even if the mesh network is only partially connected. This means that you can have a mix of legacy systems and containerized apps and still use Weave Net to keep everything in communication. ###Weave Net is Fast diff --git a/site/ipam/allocation-multi-ipam.md b/site/ipam/allocation-multi-ipam.md index fe6b9daf..1bb68799 100644 --- a/site/ipam/allocation-multi-ipam.md +++ b/site/ipam/allocation-multi-ipam.md @@ -4,7 +4,7 @@ layout: default --- -IP subnets are used to define or restrict routing. By default, Weave +IP subnets are used to define or restrict routing. By default, Weave Net puts all containers into a subnet that spans the entire allocation range, so that every Weave-attached container can communicate with every other Weave-attached container. diff --git a/site/ipam/overview-init-ipam.md b/site/ipam/overview-init-ipam.md index f85eb49c..c52ffca3 100644 --- a/site/ipam/overview-init-ipam.md +++ b/site/ipam/overview-init-ipam.md @@ -4,11 +4,11 @@ layout: default --- -Weave automatically assigns containers a unique IP address +Weave Net automatically assigns containers a unique IP address across the network, and also releases that address when the container exits. Unless you explicitly specify an address, this occurs for all invocations of the `run`, `start`, -`attach`, `detach`, `expose`, and `hide` commands. Weave can also assign +`attach`, `detach`, `expose`, and `hide` commands. Weave Net can also assign addresses in multiple subnets. The following automatic IP address managment topics are discussed: @@ -22,8 +22,8 @@ The following automatic IP address managment topics are discussed: ### Initializing Peers on a Weave Network Just once, when the first automatic IP address allocation is requested -in the whole network, Weave needs a majority of peers to be present in -order to avoid formation of isolated groups, which could lead to +in the whole network, Weave Net needs a majority of peers to be present in +order to avoid formation of isolated groups, which can lead to inconsistency, for example, the same IP address being allocated to two different containers. @@ -31,7 +31,7 @@ Therefore, you must either supply the list of all peers in the network at `weave `--init-peer-count` flag to specify how many peers there will be. To illustrate, suppose you have three hosts, accessible to each other -as `$HOST1`, `$HOST2` and `$HOST3`. You can start weave on those three +as `$HOST1`, `$HOST2` and `$HOST3`. You can start Weave Net on those three hosts using these three commands: host1$ weave launch $HOST2 $HOST3 @@ -60,7 +60,7 @@ through three states: 'deferred', 'waiting' and 'achieved': themselves successfully * 'achieved' - consensus achieved; allocations proceed normally -Finally, you may launch some peers as election observers using the +Finally, you some peers can be launched as election observers using the `--observer` option: host4$ weave launch --observer $HOST3 @@ -76,7 +76,7 @@ initial peer counts accordingly. Normally it isn't a problem to over-estimate `--init-peer-count`, but if you supply a number that is too small, then multiple independent groups may form. -Weave uses the estimate of the number of peers at initialization to +Weave Net uses the estimate of the number of peers at initialization to compute a majority or quorum number - specifically floor(n/2) + 1. If the actual number of peers is less than half the number stated, then @@ -100,7 +100,7 @@ that was correct when they first started, then they could form an independent set again. To illustrate this last point, the following sequence of operations -is safe with respect to Weave's startup quorum: +is safe with respect to Weave Net's startup quorum: host1$ weave launch ...time passes... @@ -113,8 +113,8 @@ is safe with respect to Weave's startup quorum: ### Choosing an Allocation Range -By default, Weave allocates IP addresses in the 10.32.0.0/12 -range. This can be overridden with the `--ipalloc-range` option, e.g. +By default, Weave Net allocates IP addresses in the 10.32.0.0/12 +range. This can be overridden with the `--ipalloc-range` option: host1$ weave launch --ipalloc-range 10.2.0.0/16 diff --git a/site/ipam/stop-remove-peers-ipam.md b/site/ipam/stop-remove-peers-ipam.md index 0272927e..1d9d0e2c 100644 --- a/site/ipam/stop-remove-peers-ipam.md +++ b/site/ipam/stop-remove-peers-ipam.md @@ -5,29 +5,30 @@ layout: default You may wish to `weave stop` and re-launch to change some config or to -upgrade to a new version; provided the underlying protocol hasn't -changed it will pick up where it left off and learn from peers in the -network which address ranges it was previously using. If, however, you -run `weave reset` this will remove the peer from the network so -if Weave is run again on that node it will start from scratch. +upgrade to a new version. Provided that the underlying protocol hasn't +changed, Weave Net picks up where it left off and learns from peers in the +network which address ranges it was previously using. + +If, however, you run `weave reset` this removes the peer from the network so +if Weave Net is run again on that node it will start from scratch. For failed peers, the `weave rmpeer` command can be used to -permanently remove the ranges allocated to said peer. This will allow -other peers to allocate IPs in the ranges previously owner by the rm'd -peer, and as such should be used with extreme caution - if the rm'd +permanently remove the ranges allocated to said peer. This allows +other peers to allocate IPs in the ranges previously owned by the removed peer +peer, and as such should be used with extreme caution - if the removed peer had transferred some range of IP addresses to another peer but this is not known to the whole network, or if it later rejoins the Weave network, the same IP address may be allocated twice. -Assuming we had started the three peers in the example earlier, and -host3 has caught fire, we can go to one of the other hosts and run: +Assume you had started the three peers in the example earlier, and +then host3 caught fire, you can go to one of the other hosts and run: host1$ weave rmpeer host3 -Weave will take all the IP address ranges owned by host3 and transfer +Weave Net takes all the IP address ranges owned by host3 and transfers them to be owned by host1. The name "host3" is resolved via the -'nickname' feature of weave, which defaults to the local host -name. Alternatively, one can supply a peer name as shown in `weave +'nickname' feature of Weave Net, which defaults to the local host +name. Alternatively, you can supply a peer name as shown in `weave status`. **See Also** diff --git a/site/ipam/troubleshooting-ipam.md b/site/ipam/troubleshooting-ipam.md index 2f8c80fd..1818a0e5 100644 --- a/site/ipam/troubleshooting-ipam.md +++ b/site/ipam/troubleshooting-ipam.md @@ -8,7 +8,7 @@ The command weave status -reports on the current status of the weave router and IP allocator: +reports on the current status of the Weave Net router and IP allocator: ```` ... @@ -21,8 +21,8 @@ reports on the current status of the weave router and IP allocator: ... ```` -The first section covers the router; see the [troubleshooting -guide](/site/troubleshooting.md#weave-status) for full details. +The first section covers the router; see the [Troubleshooting +Guide](/site/troubleshooting.md#weave-status) for full details. The 'Service: ipam' section displays the consensus state as well as the total allocation range and default subnet. \ No newline at end of file diff --git a/site/plugin/plugin-how-it-works.md b/site/plugin/plugin-how-it-works.md index c0b8309c..27a76d41 100644 --- a/site/plugin/plugin-how-it-works.md +++ b/site/plugin/plugin-how-it-works.md @@ -1,16 +1,16 @@ --- -title: How the Weave Docker Network Plugin Works +title: How the Weave Net Docker Network Plugin Works layout: default --- -The Weave plugin actually provides *two* network drivers to Docker - one named `weavemesh` that can operate without a cluster store and another one named `weave` that can only work with one (like Docker's overlay driver). +The Weave Net plugin actually provides *two* network drivers to Docker - one named `weavemesh` that can operate without a cluster store and another one named `weave` that can only work with one (like Docker's overlay driver). ### `weavemesh` driver -* Weave handles all co-ordination between hosts (referred to by Docker as a "local scope" driver) +* Weave Net handles all co-ordination between hosts (referred to by Docker as a "local scope" driver) * Supports a single network only. A network named `weave` is automatically created for you. -* Uses Weave's partition tolerant IPAM +* Uses Weave Net's partition tolerant IPAM If you do create additional networks using the `weavemesh` driver, containers attached to them will be able to communicate with containers attached to `weave`. There is no isolation between those networks. diff --git a/site/plugin/weave-plugin-how-to.md b/site/plugin/weave-plugin-how-to.md index 96d11a37..d1ee9521 100644 --- a/site/plugin/weave-plugin-how-to.md +++ b/site/plugin/weave-plugin-how-to.md @@ -5,16 +5,16 @@ layout: default Docker versions 1.9 and later have a plugin mechanism for adding -different network providers. Weave installs itself as a network plugin +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, the Weave peers must be connected to each other, by specifying the other hosts during `weave launch` or via +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`](/site/using-weave/finding-adding-hosts-dynamically.md). See [Deploying Applications to Weave Net](/site/using-weave/deploying-applications.md#peer-connections) for a discussion on peer connections. -After you've launched Weave and peered your hosts, you can start containers using the following, for example: +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 @@ -22,7 +22,7 @@ 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's [Service Discovery](/site/weavedns/overview-using-weavedns.md) you +In order to use Weave Net's [Service Discovery](/site/weavedns/overview-using-weavedns.md) you must pass the additional arguments `--dns` and `-dns-search`, for which a helper is provided in the Weave script: @@ -32,7 +32,7 @@ which a helper is provided in the Weave script: -###Launching Weave and Running Containers Using the Plugin +###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: diff --git a/site/router-topology/network-topology.md b/site/router-topology/network-topology.md index 0a47406e..d836ecca 100644 --- a/site/router-topology/network-topology.md +++ b/site/router-topology/network-topology.md @@ -1,5 +1,5 @@ --- -title: How Weave Inteprets Network Topology +title: How Weave Net Inteprets Network Topology layout: default --- @@ -144,7 +144,7 @@ which time the topology should have updated. **See Also** - * [Weave Router Encapsulation](/site/router-topology/router-encapsulation.md) + * [Weave Net Router Encapsulation](/site/router-topology/router-encapsulation.md) diff --git a/site/router-topology/overview.md b/site/router-topology/overview.md index 4c150f30..4a96a3ef 100644 --- a/site/router-topology/overview.md +++ b/site/router-topology/overview.md @@ -5,14 +5,14 @@ layout: default -A Weave network consists of a number of 'peers' - Weave routers +A Weave network consists of a number of 'peers' - Weave Net routers residing on different hosts. Each peer has a name, which tends to remain the same over restarts, a human friendly nickname for use in status and logging output and a unique identifier (UID) that 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. -Weave routers establish TCP connections with each other, over which they +Weave Net routers establish TCP connections with each other, over which they perform a protocol handshake and subsequently exchange [topology](/site/router-topology/network-topology.md) information. These connections are encrypted if @@ -20,13 +20,13 @@ so configured. Peers also establish UDP "connections", possibly encrypted, which carry encapsulated network packets. These "connections" are duplex and can traverse firewalls. -Weave creates a network bridge on the host. Each container is +Weave Net 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 an IP address and netmask supplied either by the user or -by Weave's IP address allocator. Also connected to the bridge is the -Weave router container. +by Weave Net's IP address allocator. Also connected to the bridge is the +Weave Net router container. -A Weave router captures Ethernet packets from its bridge-connected +A Weave Net 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 @@ -35,15 +35,15 @@ 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 +Weave Net 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. Weave can route packets in partially connected networks with +peer. Weave Net can route packets in partially connected networks with changing topology. For example, in this network, peer 1 is connected directly to 2 and 3, but if 1 needs to send a packet to 4 or 5 it must first send it to peer 3: -![Partially connected Weave Network](images/top-diag1.png "Partially connected Weave Network") +![A Partially Connected Weave Network](images/top-diag1.png "Partially connected Weave Network") **See Also** diff --git a/site/router-topology/router-encapsulation.md b/site/router-topology/router-encapsulation.md index ab68bdba..99b9c166 100644 --- a/site/router-topology/router-encapsulation.md +++ b/site/router-topology/router-encapsulation.md @@ -1,10 +1,10 @@ --- -title: Weave Router Encapsulation +title: Weave Net Router Encapsulation layout: default --- -When the Weave router forwards packets, the encapsulation looks +When the Weave Net router forwards packets, the encapsulation looks something like this: +-----------------------------------+ @@ -61,4 +61,4 @@ MAC discovery. **See Also** - * [How Weave Inteprets Network Topology](/site/router-topology/network-topology.md) \ No newline at end of file + * [How Weave Net Inteprets Network Topology](/site/router-topology/network-topology.md) \ No newline at end of file diff --git a/site/troubleshooting.md b/site/troubleshooting.md index 8db9028e..3aa876a2 100644 --- a/site/troubleshooting.md +++ b/site/troubleshooting.md @@ -1,9 +1,8 @@ --- -title: Troubleshooting Weave +title: Troubleshooting Weave Net layout: default --- -# Troubleshooting Weave * [Basic Diagnostics](#diagnostics) * [Status Reporting](#weave-status) @@ -18,7 +17,7 @@ layout: default ## Basic Diagnostics -Check the version of Weave you are running using: +Check the version of Weave Net you are running using: weave version @@ -27,7 +26,7 @@ If it is not the latest version, as shown in the list of recommended you upgrade using the [installation instructions](https://github.com/weaveworks/weave#installation). -To check the Weave container logs: +To check the Weave Net container logs: docker logs weave @@ -82,7 +81,7 @@ $ weave status The terms used here are explained further at [How Weave Net Works](/site/router-topology/overview.md). - * **Version** - shows the Weave version. + * **Version** - shows the Weave Net version. * **Protocol**- indicates the Weave Router inter-peer communication protocol name and supported versions (min..max). @@ -120,14 +119,14 @@ available with [`weave status peers`](#weave-status-peers). ### List Connections -Connections between Weave peers carry control traffic over TCP and +Connections between Weave Net peers carry control traffic over TCP and data traffic over UDP. For a connection to be fully established, the TCP connection and UDP datapath must be able to transmit information -in both directions. Weave routers check this regularly with +in both directions. Weave Net routers check this regularly with heartbeats. Failed connections are automatically retried, with an exponential back-off. -Detailed information on the local Weave router's connections can be +Detailed information on the local Weave Net router's connections can be obtained using `weave status connections`: ```` @@ -219,7 +218,7 @@ inspect`: $ weave report -f {% raw %}'{{.DNS.Domain}}'{% endraw %} weave.local. -Weave adds a template function, `json`, which can be applied to get +Weave Net adds a template function, `json`, which can be applied to get results in JSON format. $ weave report -f {% raw %}'{{json .DNS}}'{% endraw %} @@ -251,11 +250,11 @@ You can also supply a list of container IDs/names to `weave ps`, like this: able ce:15:34:a9:b5:6d 10.2.5.1/24 baker 7a:61:a2:49:4b:91 10.2.8.3/24 -## Stopping Weave +## Stopping Weave Net -To stop Weave, if you have configured your environment to use the +To stop Weave Net, if you have configured your environment to use the Weave Docker API Proxy, e.g. by running `eval $(weave env)` in your -shell, you must first restore the environment with +shell, you must first restore the environment using: eval $(weave env --restore) @@ -268,8 +267,8 @@ 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 once Weave is relaunched. -To stop Weave and to completely remove all traces of the Weave network on -the local host, run +To stop Weave Net and to completely remove all traces of the Weave network on +the local host, run: weave reset @@ -289,7 +288,7 @@ Weave and run application containers from If you are shutting down or restarting a host deliberately, run `weave reset` to clear everything down. -The Weave Docker plugin does restart automatically because it must +The Weave Net Docker plugin does restart automatically because it must always start with Docker, as described in [its documentation](/site/weave-docker-api/using-proxy.md). diff --git a/site/using-weave/application-isolation.md b/site/using-weave/application-isolation.md index bf6bd04e..dcb464d3 100644 --- a/site/using-weave/application-isolation.md +++ b/site/using-weave/application-isolation.md @@ -7,11 +7,11 @@ A single Weave network can host multiple, isolated applications where each appli to communicate with each other, but not with the containers of other applications. To isolate applications, you can make use of `isolation-through-subnets` technique. - This common strategy is an example of how with Weave many of your `on metal` - techniques can still be used to deploy applications to a container network. +This common strategy is an example of how with Weave Net many of your `on metal` +techniques can still be used to deploy applications to a container network. To begin isolating an application (or parts of an application), -configure Weave's IP allocator to manage multiple subnets. +configure Weave Net's IP allocator to manage multiple subnets. Using [the netcat example](/site/using-weave/deploying-applications.md), configure multiple subsets: @@ -22,7 +22,7 @@ Using [the netcat example](/site/using-weave/deploying-applications.md), configu host2$ eval $(weave env) ~~~ -This delegates the entire 10.2.0.0/16 subnet to Weave, and instructs +This delegates the entire 10.2.0.0/16 subnet to Weave Net, and instructs it to allocate from 10.2.1.0/24 within that, if a specific subnet is not specified. @@ -79,7 +79,7 @@ isolation between application containers, that feature needs to be disabled by [ **See Also** - * [Managing Services in Weave: Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md) + * [Managing Services in Weave Net: Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md) * [Exposing Services to the Outside World] (/site/using-weave/service-export.md) diff --git a/site/using-weave/deploying-applications.md b/site/using-weave/deploying-applications.md index 84874229..21719ea6 100644 --- a/site/using-weave/deploying-applications.md +++ b/site/using-weave/deploying-applications.md @@ -13,7 +13,7 @@ This section contains the following topics: ###Launching Weave Net -Before launching Weave and deploying your apps, ensure that Docker is [installed]( https://docs.docker.com/engine/installation/) on both hosts. +Before launching Weave Net and deploying your apps, ensure that Docker is [installed]( https://docs.docker.com/engine/installation/) on both hosts. On `$HOST1` run: @@ -23,8 +23,8 @@ On `$HOST1` run: Where, - * The first line runs Weave. - * The second line configures the Weave environment, so that containers launched via the Docker command line are automatically attached to the Weave network, and, + * The first line runs Weave Net. + * The second line configures the Weave Net environment, so that containers launched via the Docker command line are automatically attached to the Weave network, and, * The third line runs the application container using [Docker commands]( https://docs.Docker.com/engine/reference/commandline/daemon/). >>**Note:** If the first command results in an error like @@ -33,7 +33,7 @@ Where, >>**Important!** if you are running the Weave Docker Network Plugin do not run `eval $(weave env)`. See [Using the Weave Net Docker Network Plugin](/site/pluing/weave-plugin-how-to.md) for more information. -Weave must be launched once per host. The relevant container images will be pulled down from Docker Hub on demand during `weave launch`. +Weave Net must be launched once per host. The relevant container images will be pulled down from Docker Hub on demand during `weave launch`. You can also preload the images by running `weave setup`. Preloaded images are useful for automated deployments, and ensure there are no delays during later operations. @@ -42,19 +42,19 @@ If you are deploying an application that consists of more than one container to ###Creating Peer Connections Between Hosts -To launch Weave on an additional host and create a peer connection, run the following: +To launch Weave Net on an additional host and create a peer connection, run the following: host2$ weave launch $HOST1 host2$ eval $(weave env) host2$ docker run --name a2 -ti ubuntu -As noted above, the same steps are repeated for `$HOST2`. The only difference, besides the application container’s name, is that `$HOST2` is told to peer with Weave on `$HOST1` during launch. +As noted above, the same steps are repeated for `$HOST2`. The only difference, besides the application container’s name, is that `$HOST2` is told to peer with Weave Net on `$HOST1` during launch. You can also peer with other hosts by specifying the IP address, and a `:port` by which `$HOST2` can reach `$HOST1`. >>**Note:** If there is a firewall between `$HOST1` and `$HOST2`, you must permit traffic to flow through TCP 6783 and UDP 6783/6798, which are Weave’s control nd data ports. -There are a number of different ways that you can specify peers on a Weave network. You can launch Weave on `$HOST1` and then peer with `$HOST2`, or you can launch on `$HOST2` and peer with `$HOST1` or you can tell both hosts about each other at launch. The order in which peers are specified is not important. Weave automatically (re)connects to peers when they become available. +There are a number of different ways that you can specify peers on a Weave network. You can launch Weave Net on `$HOST1` and then peer with `$HOST2`, or you can launch on `$HOST2` and peer with `$HOST1` or you can tell both hosts about each other at launch. The order in which peers are specified is not important. Weave Net automatically (re)connects to peers when they become available. ####Specifying Multiple Peers at Launch @@ -102,7 +102,7 @@ and then connected to from the another container on `$HOST2` using: root@a2:/# echo 'Hello, world.' | nc a1 4422 ~~~ -Weave supports *any* protocol, and it doesn't have to be over TCP/IP. For example, a netcat UDP service can also be run by using the following: +Weave Net supports *any* protocol, and it doesn't have to be over TCP/IP. For example, a netcat UDP service can also be run by using the following: ~~~bash root@a1:/# nc -lu -p 5533 @@ -113,5 +113,5 @@ Weave supports *any* protocol, and it doesn't have to be over TCP/IP. For exampl **See Also** * [Installing Weave Net](/site/installing-weave.md) - * [Using Fastdp With Weave](/site/fastdp/using-fastdp.md) + * [Using Fastdp With Weave Net](/site/fastdp/using-fastdp.md) * [Using the Weave Net Docker Network Plugin](/site/plugin/weave-plugin-how-to.md) diff --git a/site/using-weave/dynamically-attach-containers.md b/site/using-weave/dynamically-attach-containers.md index 12fc3d8f..449d2561 100644 --- a/site/using-weave/dynamically-attach-containers.md +++ b/site/using-weave/dynamically-attach-containers.md @@ -4,7 +4,7 @@ layout: default --- -When containers may not know the network to which they will be attached, Weave enables you to dynamically attach and detach containers to and from a given network, even when a container is already running. +When containers may not know the network to which they will be attached, Weave Net enables you to dynamically attach and detach containers to and from a given network, even when a container is already running. To illustrate these scenarios, imagine a netcat service running in a container on $host1 and you need to attach it to another subnet. To attach the netcat service container to a given subnet run: @@ -15,7 +15,7 @@ To illustrate these scenarios, imagine a netcat service running in a container o Where, * `C=$(Docker run -e WEAVE_CIDR=none -dti ubuntu)` is a variable for the subnet on which to attach - * `weave attach` – the Weave command to attach to the specified subnet, which takes the variable for the subnet + * `weave attach` – the Weave Net command to attach to the specified subnet, which takes the variable for the subnet * `10.2.1.3` - the allocated IP address output by `weave attach` and in this case, represents the default subnet >>Note If you are using the Weave Docker API proxy, it will have modified `DOCKER_HOST` to point to the proxy and therefore you will have to pass `-e WEAVE_CIDR=none` to start a container that _doesn't_ get automatically attached to the weave network for the purposes of this example. diff --git a/site/using-weave/finding-adding-hosts-dynamically.md b/site/using-weave/finding-adding-hosts-dynamically.md index 668b4eed..823c6681 100644 --- a/site/using-weave/finding-adding-hosts-dynamically.md +++ b/site/using-weave/finding-adding-hosts-dynamically.md @@ -5,24 +5,24 @@ layout: default To add a host to an existing Weave network, simply launch -Weave on the host, and then supply the address of at least -one host. Weave automatically discovers any other hosts in -the network and establishes connections with them if it +Weave Net on the host, and then supply the address of at least +one host. Weave Net automatically discovers any other hosts in +the network and establishes connections with them if it can (in order to avoid unnecessary multi-hop routing). -In some situations all existing Weave hosts may be +In some situations all existing Weave Net hosts may be unreachable from the new host due to firewalls, etc. However, it is still possible to add the new host, provided that inverse connections, for example, from existing hosts to the new hosts, are available. -To accomplish this, launch Weave onto the new host +To accomplish this, launch Weave Net onto the new host without supplying any additional addresses. And then, from one of the existing hosts run: host# weave connect $NEW_HOST -Other hosts in the Weave network will automatically attempt +Other hosts on the Weave network will automatically attempt to establish connections to the new host as well. Alternatively, you can also instruct a peer to forget a @@ -45,7 +45,7 @@ For complete control over the peer topology, automatic discovery can be disabled using the `--no-discovery` option with `weave launch`. -If discovery if disabled, Weave only connects to the +If discovery if disabled, Weave Net only connects to the addresses specified at launch time and with `weave connect`. A list of all hosts that a peer has been asked to connect diff --git a/site/using-weave/host-network-integration.md b/site/using-weave/host-network-integration.md index 1d38efc0..505c51db 100644 --- a/site/using-weave/host-network-integration.md +++ b/site/using-weave/host-network-integration.md @@ -1,5 +1,5 @@ --- -title: Integrating a Host Network with Weave +title: Integrating a Host Network with Weave Net layout: default --- @@ -12,7 +12,7 @@ On `$HOST2` run: host2$ weave expose 10.2.1.132 -This command grants the host access to all of the application containers in the default subnet. An IP address is allocated by Weave especially for that purpose, and is returned after running `weave expose`. +This command grants the host access to all of the application containers in the default subnet. An IP address is allocated by Weave Net especially for that purpose, and is returned after running `weave expose`. Now you are able to ping the host: @@ -25,7 +25,7 @@ And you can also ping the `a1` netcat application container residing on `$HOST1` ###Exposing Multiple Subnets -Multiple subnet addresses can be exposed or hidden with a single command: +Multiple subnet addresses can be exposed or hidden using a single command: host2$ weave expose net:default net:10.2.2.0/24 10.2.1.132 10.2.2.130 diff --git a/site/using-weave/isolating-applications.md b/site/using-weave/isolating-applications.md index 7eeb5155..351ffabb 100644 --- a/site/using-weave/isolating-applications.md +++ b/site/using-weave/isolating-applications.md @@ -14,7 +14,7 @@ To do this, you need to configure Weave's IP allocator to manage multiple subnet host2$ eval $(weave env) ~~~ -This delegates the entire 10.2.0.0/16 subnet to Weave, and instructs it to allocate from 10.2.1.0/24 within that if no specific subnet is specified. +This delegates the entire 10.2.0.0/16 subnet to Weave Net, and instructs it to allocate from 10.2.1.0/24 within that if no specific subnet is specified. Now you can launch two containers onto the default subnet: diff --git a/site/using-weave/manual-ip-address.md b/site/using-weave/manual-ip-address.md index 084d9a38..8eedeebb 100644 --- a/site/using-weave/manual-ip-address.md +++ b/site/using-weave/manual-ip-address.md @@ -8,11 +8,11 @@ Containers are automatically allocated an IP address that is unique across the W host1$ weave ps a1 a7aee7233393 7a:44:d3:11:10:70 10.32.0.2/12 -Weave detects when a container has exited and releases its allocated addresses so they can be re-used by the network. +Weave Net detects when a container has exited and releases its allocated addresses so they can be re-used by the network. See the [Automatic IP Address Management](/site/ipam/overview-init-ipam.md) and also an explanation of [the basics of IP addressing](/site/ip-addresses/ip-addresses.md) for further details. -Instead of allowing Weave to allocate IP addresses automatically (using IPAM), there may be instances where you need to control a particular container or a cluster by setting an IP address for it. +Instead of allowing Weave Net to allocate IP addresses automatically (using IPAM), there may be instances where you need to control a particular container or a cluster by setting an IP address for it. You can specify an IP address and a network explicitly, using Classless Inter-Domain Routing or [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing). diff --git a/site/using-weave/multi-cloud-multi-hop.md b/site/using-weave/multi-cloud-multi-hop.md index 5702bc0d..214177eb 100644 --- a/site/using-weave/multi-cloud-multi-hop.md +++ b/site/using-weave/multi-cloud-multi-hop.md @@ -6,13 +6,12 @@ layout: default ###Enabling Multi-Cloud Networking -Before multi-cloud networking can be enabled, you must c -onfigure the network to allow connections through Weave's -control and data ports on the Docker hosts. By default, the +Before multi-cloud networking can be enabled, you must configure the network to allow +connections through Weave Net's control and data ports on the Docker hosts. By default, the control port defaults to TCP 6783, and the data ports to UDP 6783/6784. -To override Weave’s default ports specify a port using +To override Weave Net’s default ports, specify a port using the `WEAVE_PORT` setting. For example, if WEAVE_PORT is set to `9000`, then Weave uses TCP 9000 for its control port and UDP 9000/9001 for its data port. @@ -27,14 +26,14 @@ A network of containers across more than two hosts can be established even when there is only partial connectivity between the hosts. -Weave routes traffic between containers as long as +Weave Net routes traffic between containers as long as there is at least one *path* of connected hosts between them. For example, if a Docker host in a local data center 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 and Weave in this instance will route the +still communicate and Weave Net in this instance will route the traffic via the local data center. **See Also** diff --git a/site/using-weave/security-untrusted-networks.md b/site/using-weave/security-untrusted-networks.md index 31cd65eb..f772cf4f 100644 --- a/site/using-weave/security-untrusted-networks.md +++ b/site/using-weave/security-untrusted-networks.md @@ -4,7 +4,7 @@ layout: default --- -To connect containers across untrusted networks, Weave peers can be instructed to encrypt traffic by supplying a `--password` option or by using the `WEAVE_PASSWORD` environment variable during `weave launch`. +To connect containers across untrusted networks, Weave Net peers can be instructed to encrypt traffic by supplying a `--password` option or by using the `WEAVE_PASSWORD` environment variable during `weave launch`. For example: @@ -26,7 +26,7 @@ To guard against dictionary attacks, the password needs to be reasonably strong < /dev/urandom tr -dc A-Za-z0-9 | head -c9 ; echo -The same password must be specified for all Weave peers, by default both control and data plane traffic will then use authenticated encryption. +The same password must be specified for all Weave Net peers, by default both control and data plane traffic will then use authenticated encryption. Fast datapath does not support encryption. If you supply a password at `weave launch` the router falls back to a slower @@ -34,7 +34,7 @@ password at `weave launch` the router falls back to a slower If some of your peers are co-located in a trusted network (for example within the boundary of your own datacenter) you can use the `--trusted-subnets` argument to `weave launch` to selectively disable data plane encryption as an optimization. -Both peers must consider the other to be in a trusted subnet for this to take place - if they do not agree, Weave [falls back to a slower method]( /site/fastdp/using-fastdp.md) for transporting data between peers, since fast datapath does not support encryption. +>>**Note:** Both peers must consider the other to be in a trusted subnet for this to take place - if they do not agree, Weave Net [falls back to a slower method]( /site/fastdp/using-fastdp.md) for transporting data between peers, since fast datapath does not support encryption. Be aware that: @@ -45,4 +45,5 @@ Be aware that: **See Also** - * [Using Encryption With Weave](/site/encryption/crypto-overview.md) + * [Using Encryption With Weave Net](/site/encryption/crypto-overview.md) + * [Using Fast Datapath](/site/using-weave/using-fastdap.md) diff --git a/site/using-weave/service-export.md b/site/using-weave/service-export.md index feeb1141..c91b647a 100644 --- a/site/using-weave/service-export.md +++ b/site/using-weave/service-export.md @@ -5,13 +5,13 @@ layout: default Services running in containers on a Weave network can be made accessible to the outside world (and, more generally, to other networks) -from any Weave host, irrespective of where the service containers are +from any Weave Net host, irrespective of where the service containers are located. Returning to the netcat example service, described in [Deploying Applications]( /site/using-weave/deploying-applications.md), you can expose the netcat service running on `HOST1` and make it accessible to the outside world via `$HOST2`. -First, expose the application network to `$HOST2`, as explained in [Integrating a Host Network with a Weave](/site/using-weave/host-network-integration.md): +First, expose the application network to `$HOST2`, as explained in [Integrating a Host Network with a Weave Net](/site/using-weave/host-network-integration.md): host2$ weave expose 10.2.1.132 @@ -36,4 +36,4 @@ Similar NAT rules to the above can be used to expose services not just to the ou **See Also** * [Using Weave Net](/site/using-weave/intro-example.md) - * [Managing Services in Weave: Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md) \ No newline at end of file + * [Managing Services in Weave Net: Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md) \ No newline at end of file diff --git a/site/using-weave/service-management.md b/site/using-weave/service-management.md index 3de56d28..172764ed 100644 --- a/site/using-weave/service-management.md +++ b/site/using-weave/service-management.md @@ -1,5 +1,5 @@ --- -title: Managing Services in Weave - Exporting, Importing, Binding and Routing +title: Managing Services in Weave Net - Exporting, Importing, Binding and Routing layout: default --- @@ -48,7 +48,7 @@ Weave hosts, regardless of where the actual application containers are located. Using the netcat service example described in [Deploying Applications](/site/using-weave/deploying-applications.md), and expanding upon it, you now decide to add a third containerized netcat service. This additional netcat service runs on `$HOST3`, and listens on port 2211, but it is not on the Weave network. -An additional caveat is that `$HOST3` can only be reached from `$HOST1`, which is not accessible via `$HOST2`. Nonetheless, you still need to make the `$HOST3` service available to an application that is running in a container on `$HOST2`. +An additional caveat is that `$HOST3` can only be reached from `$HOST1`, which is not accessible via `$HOST2`. Nonetheless, you still need to make a `$HOST3` service available to an application that is running in a container on `$HOST2`. To satisfy this scenario, first expose the [application network to the host](/site/using-weave/host-network-integration.md) by running the following on `$HOST1`: @@ -83,16 +83,16 @@ You can point application containers to another service location by changing the You can combine the service export and service import features to establish connectivity between applications and services residing on disjointed networks, even if those networks are separated by firewalls and have overlapping IP ranges. -Each network imports its services into Weave, while at the same time, exports from Weave any services that are required by its applications. In this scenario, there are no application containers (although, there could be). Weave is acting as an address translation and routing facility, and uses the Weave container network as an intermediary. +Each network imports its services into Weave Net, while at the same time, exports from Weave Net any services that are required by its applications. In this scenario, there are no application containers (although, there could be). Weave Net is acting as an address translation and routing facility, and uses the Weave container network as an intermediary. -Expanding on the [netcat example](/site/using-weave/deploying-applications.md), you can also import an additional netcat service running on `$HOST3` into Weave via `$HOST1`. +Expanding on the [netcat example](/site/using-weave/deploying-applications.md), you can also import an additional netcat service running on `$HOST3` into Weave Net via `$HOST1`. Begin importing the service onto `$HOST2` by first exposing the application network: host2$ weave expose 10.2.1.3 -Then add a NAT rule which routes traffic from the `$HOST2` network (i.e. anything which can connect to `$HOST2`) to the service endpoint on the Weave network: +Then add a NAT rule which routes traffic from the `$HOST2` network (for example, anything that can connect to `$HOST2`) to the service endpoint on the Weave network: host2$ iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4433 \ -j DNAT --to-destination 10.2.1.3:3322 diff --git a/site/weave-docker-api/automatic-discovery-proxy.md b/site/weave-docker-api/automatic-discovery-proxy.md index cb6fc496..9057d0e0 100644 --- a/site/weave-docker-api/automatic-discovery-proxy.md +++ b/site/weave-docker-api/automatic-discovery-proxy.md @@ -1,5 +1,5 @@ --- -title: Using Automatic Discovery With the Weave Proxy +title: Using Automatic Discovery With the Weave Net Proxy layout: default --- @@ -35,8 +35,7 @@ For example, you can launch the proxy using all three flags, as follows: (for example, `$1`). For further details on the regular expression syntax see [Google's re2 documentation](https://github.com/google/re2/wiki/Syntax). -After launching the Weave proxy with these flags, running a container named `aws-12798186823-foo` without labels results in -weavedns registering the hostname `my-app-foo` and not `aws-12798186823-foo`. +After launching the Weave Net proxy with these flags, running a container named `aws-12798186823-foo` without labels results in weavedns registering the hostname `my-app-foo` and not `aws-12798186823-foo`. host1$ docker run -ti --name=aws-12798186823-foo ubuntu ping my-app-foo PING my-app-foo.weave.local (10.32.0.2) 56(84) bytes of data. diff --git a/site/weave-docker-api/ipam-proxy.md b/site/weave-docker-api/ipam-proxy.md index 4c3d478f..6c5f2576 100644 --- a/site/weave-docker-api/ipam-proxy.md +++ b/site/weave-docker-api/ipam-proxy.md @@ -4,13 +4,13 @@ layout: default --- -If [automatic IP address allocation](/site/ipam/overview-init-ipam.md) is enabled in Weave (by default IPAM is enabled), +If [automatic IP address allocation](/site/ipam/overview-init-ipam.md) is enabled in Weave Net (by default IPAM is enabled), then containers started via the proxy are automatically assigned an IP address, *without having to specify any special environment variables or any other options*. host1$ docker run -ti ubuntu -To use a specific subnet, we pass a `WEAVE_CIDR` to the container, e.g. +To use a specific subnet, you can pass a `WEAVE_CIDR` to the container, for example: host1$ docker run -ti -e WEAVE_CIDR=net:10.32.2.0/24 ubuntu @@ -27,7 +27,7 @@ be passed the `--no-default-ipalloc` flag, for example: host1$ weave launch-proxy --no-default-ipalloc -In this configuration, containers with no `WEAVE_CIDR` environment +In this configuration, containers using no `WEAVE_CIDR` environment variable are not connected to the Weave network. Containers started with a `WEAVE_CIDR` environment variable are handled as before. diff --git a/site/weave-docker-api/name-resolution-proxy.md b/site/weave-docker-api/name-resolution-proxy.md index 0d1bc42a..4020d0b9 100644 --- a/site/weave-docker-api/name-resolution-proxy.md +++ b/site/weave-docker-api/name-resolution-proxy.md @@ -4,19 +4,19 @@ layout: default --- -When starting Weave-enabled containers, the proxy automatically +When starting Weave Net enabled containers, the proxy automatically replaces the container's `/etc/hosts` file, and disables Docker's control over it. The new file contains an entry for the container's hostname -and Weave IP address, as well as additional entries that have been +and Weave Net IP address, as well as additional entries that have been specified using the `--add-host` parameters. This ensures that: - name resolution of the container's hostname, for example, via `hostname -i`, -returns the Weave IP address. This is required for many cluster-aware +returns the Weave Net IP address. This is required for many cluster-aware applications to work. - unqualified names get resolved via DNS, for example typically via weavedns -to Weave IP addresses. This is required so that in a typical setup +to Weave Net IP addresses. This is required so that in a typical setup one can simply "ping ", i.e. without having to specify a `.weave.local` suffix. diff --git a/site/weave-docker-api/set-up-proxy.md b/site/weave-docker-api/set-up-proxy.md index 2431a56f..26c42228 100644 --- a/site/weave-docker-api/set-up-proxy.md +++ b/site/weave-docker-api/set-up-proxy.md @@ -1,5 +1,5 @@ --- -title: Setting Up The Weave Docker API Proxy +title: Setting Up The Weave Net Docker API Proxy layout: default --- @@ -11,7 +11,7 @@ or the [remote API](https://docs.docker.com/reference/api/docker_remote_api/), instead of `weave run`. -###Setting Up The Weave Docker API Proxy +###Setting Up The Weave Net Docker API Proxy The proxy sits between the Docker client (command line or API) and the Docker daemon, and intercepts the communication between the two. You can @@ -44,7 +44,7 @@ remote docker daemon, then any firewalls inbetween need to be configured to permit access to the proxy port. All docker commands can be run via the proxy, so it is safe to adjust -your `DOCKER_HOST` to point at the proxy. Weave provides a convenient +your `DOCKER_HOST` to point at the proxy. Weave Net provides a convenient command for this: host1$ eval $(weave env) diff --git a/site/weave-docker-api/troubleshooting-proxy.md b/site/weave-docker-api/troubleshooting-proxy.md index b224244b..b8c6ded0 100644 --- a/site/weave-docker-api/troubleshooting-proxy.md +++ b/site/weave-docker-api/troubleshooting-proxy.md @@ -7,7 +7,7 @@ The command weave status -reports on the current status of various weave components, including +reports on the current status of various Weave Net components, including the proxy, if it is running: ```` diff --git a/site/weave-docker-api/using-proxy.md b/site/weave-docker-api/using-proxy.md index 1c95c066..70c54d83 100644 --- a/site/weave-docker-api/using-proxy.md +++ b/site/weave-docker-api/using-proxy.md @@ -4,17 +4,17 @@ layout: default --- -When containers are created via the Weave proxy, their entrypoint is +When containers are created via the Weave Net proxy, their entrypoint is modified to wait for the Weave network interface to become available. -When they are started via the Weave proxy, containers are +When they are started via the Weave Net proxy, containers are [automatically assigned IP addresses](/site/ipam/overview-init-ipam.md) and connected to the Weave network. -###Creating and Starting Containers with the Weave Proxy +###Creating and Starting Containers with the Weave Net Proxy -To create and start a container via the Weave proxy run: +To create and start a container via the Weave Net proxy run: host1$ docker run -ti ubuntu @@ -41,8 +41,8 @@ IPPrefixLen), are still returned when `docker inspect` is run. If you want `docker inspect` to return the Weave NetworkSettings instead, then the proxy must be launched using the `--rewrite-inspect` flag. -This command substitutes the Weave Network settings when the container has a -Weave IP. If a container has more than one Weave IP, then the inspect call +This command substitutes the Weave network settings when the container has a +Weave Net IP. If a container has more than one Weave Net IP, then the inspect call only includes one of them. host1$ weave launch-router && weave launch-proxy --rewrite-inspect @@ -51,7 +51,7 @@ only includes one of them. ###Multicast Traffic and Launching the Weave Proxy By default, multicast traffic is routed over the Weave network. -To turn this off, e.g. because you want to configure your own multicast +To turn this off, for example, because you want to configure your own multicast route, add the `--no-multicast-route` flag to `weave launch-proxy`. diff --git a/site/weavedns/how-works-weavedns.md b/site/weavedns/how-works-weavedns.md index c132ee0f..93ef233c 100644 --- a/site/weavedns/how-works-weavedns.md +++ b/site/weavedns/how-works-weavedns.md @@ -9,8 +9,8 @@ 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) in its in-memory -database, and then broadcasts the association to other Weave peers in the +name with the container's Weave Net IP address(es) in its in-memory +database, and then broadcasts the association to other Weave Net peers in the cluster. When weavedns is queried for a name in the `.weave.local` domain, it diff --git a/site/weavedns/troubleshooting-weavedns.md b/site/weavedns/troubleshooting-weavedns.md index 8c774352..77c418a2 100644 --- a/site/weavedns/troubleshooting-weavedns.md +++ b/site/weavedns/troubleshooting-weavedns.md @@ -12,7 +12,7 @@ The command: weave status -reports on the current status of various Weave components, including +reports on the current status of various Weave Net components, including DNS: ```` From be2dfda78e2bcb100997bc5df874b1d451d8f09f Mon Sep 17 00:00:00 2001 From: Anita Buehrle Date: Tue, 8 Mar 2016 12:14:27 -0600 Subject: [PATCH 2/2] edits from awh --- site/ipam/overview-init-ipam.md | 2 +- site/ipam/stop-remove-peers-ipam.md | 4 ++-- site/using-weave/service-management.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/site/ipam/overview-init-ipam.md b/site/ipam/overview-init-ipam.md index c52ffca3..1850cec0 100644 --- a/site/ipam/overview-init-ipam.md +++ b/site/ipam/overview-init-ipam.md @@ -60,7 +60,7 @@ through three states: 'deferred', 'waiting' and 'achieved': themselves successfully * 'achieved' - consensus achieved; allocations proceed normally -Finally, you some peers can be launched as election observers using the +Finally, some peers can be launched as election observers using the `--observer` option: host4$ weave launch --observer $HOST3 diff --git a/site/ipam/stop-remove-peers-ipam.md b/site/ipam/stop-remove-peers-ipam.md index 1d9d0e2c..7c07645f 100644 --- a/site/ipam/stop-remove-peers-ipam.md +++ b/site/ipam/stop-remove-peers-ipam.md @@ -14,8 +14,8 @@ if Weave Net is run again on that node it will start from scratch. For failed peers, the `weave rmpeer` command can be used to permanently remove the ranges allocated to said peer. This allows -other peers to allocate IPs in the ranges previously owned by the removed peer -peer, and as such should be used with extreme caution - if the removed +other peers to allocate IPs in the ranges previously owned by the removed peer, +and as such should be used with extreme caution - if the removed peer had transferred some range of IP addresses to another peer but this is not known to the whole network, or if it later rejoins the Weave network, the same IP address may be allocated twice. diff --git a/site/using-weave/service-management.md b/site/using-weave/service-management.md index 172764ed..a58946f0 100644 --- a/site/using-weave/service-management.md +++ b/site/using-weave/service-management.md @@ -48,7 +48,7 @@ Weave hosts, regardless of where the actual application containers are located. Using the netcat service example described in [Deploying Applications](/site/using-weave/deploying-applications.md), and expanding upon it, you now decide to add a third containerized netcat service. This additional netcat service runs on `$HOST3`, and listens on port 2211, but it is not on the Weave network. -An additional caveat is that `$HOST3` can only be reached from `$HOST1`, which is not accessible via `$HOST2`. Nonetheless, you still need to make a `$HOST3` service available to an application that is running in a container on `$HOST2`. +An additional caveat is that `$HOST3` can only be reached from `$HOST1`, which is not accessible via `$HOST2`. Nonetheless, you still need to make the `$HOST3` service available to an application that is running in a container on `$HOST2`. To satisfy this scenario, first expose the [application network to the host](/site/using-weave/host-network-integration.md) by running the following on `$HOST1`: