diff --git a/site/fastdp/using-fastdp.md b/site/fastdp/using-fastdp.md index b2a4e336..7f732d0b 100644 --- a/site/fastdp/using-fastdp.md +++ b/site/fastdp/using-fastdp.md @@ -14,9 +14,7 @@ See [How Fastdp Works](/site/fastdp/fastdp-how-it-works.md) for a more in-depth You can disable fastdp by enabling the `WEAVE_NO_FASTDP` environment variable at `weave launch`: -~~~bash -$ WEAVE_NO_FASTDP=true weave launch -~~~ + $ WEAVE_NO_FASTDP=true weave launch ###Fast Datapath and Encryption @@ -36,20 +34,16 @@ The use of fast datapath is an automated connection-by-connection decision made Once a Weave network is set up, you can query the connections using the `weave status connections` command: -~~~bash -$ weave status connections -<-192.168.122.25:43889 established fastdp a6:66:4f:a5:8a:11(ubuntu1204) -~~~ + $ weave status connections + <-192.168.122.25:43889 established fastdp a6:66:4f:a5:8a:11(ubuntu1204) 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 -<- 192.168.122.25:54782 established sleeve 8a:50:4c:23:11:ae(ubuntu1204) -~~~ + $ weave status connections + <- 192.168.122.25:54782 established sleeve 8a:50:4c:23:11:ae(ubuntu1204) **See Also** * [Deploying Applications to Weave](/site/using-weave/deploying-applications.md) * [How Fastdp Works](/site/fastdp/fastdp-how-it-works.md) - \ No newline at end of file + diff --git a/site/ip-addresses/configuring-weave.md b/site/ip-addresses/configuring-weave.md index a7d023c4..9b3b4009 100644 --- a/site/ip-addresses/configuring-weave.md +++ b/site/ip-addresses/configuring-weave.md @@ -13,11 +13,9 @@ cause a clash. If after `weave launch`, the following error message appears: -~~~bash Network 10.32.0.0/12 overlaps with existing route 10.0.0.0/8 on host. ERROR: Default --ipalloc-range 10.32.0.0/12 overlaps with existing route on host. You must pick another range and set it on all hosts. -~~~ As the message indicates, the default range that Weave Net would like to use is `10.32.0.0/12` - a 12-bit prefix, where all addresses start with the bit diff --git a/site/ip-addresses/ip-addresses.md b/site/ip-addresses/ip-addresses.md index af53d86b..65a3e588 100644 --- a/site/ip-addresses/ip-addresses.md +++ b/site/ip-addresses/ip-addresses.md @@ -42,12 +42,10 @@ Several websites offer calculators to decode this kind of address, see: [IP Addr The following is an example route table for a container that is attached to a Weave network: -~~~bash # ip route show default via 172.17.42.1 dev eth0 10.2.2.0/24 dev ethwe proto kernel scope link src 10.2.2.1 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.170 -~~~ It has two interfaces: one that Docker gave it called `eth0`, and one that weave gave it called `ethwe`. They are on networks diff --git a/site/ipam/allocation-multi-ipam.md b/site/ipam/allocation-multi-ipam.md index 1bb68799..227fd512 100644 --- a/site/ipam/allocation-multi-ipam.md +++ b/site/ipam/allocation-multi-ipam.md @@ -23,7 +23,7 @@ for instance: host1$ docker run -e WEAVE_CIDR="net:10.2.7.0/24 net:10.2.8.0/24 ip:10.3.9.1/24" -ti ubuntu ->>**Note:** The ".0" and ".-1" addresses in a subnet are not used, as required by +>**Note:** The ".0" and ".-1" addresses in a subnet are not used, as required by [RFC 1122](https://tools.ietf.org/html/rfc1122#page-29)). When working with multiple subnets in this way, it is usually @@ -64,4 +64,4 @@ for manual allocation. * [Address Allocation with IP Address Management (IPAM)](/site/ipam/overview-init-ipam.md) * [Isolating Applications on a Weave Network](/site/using-weave/isolating-applications.md) - * [Starting, Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md) \ No newline at end of file + * [Starting, Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md) diff --git a/site/ipam/overview-init-ipam.md b/site/ipam/overview-init-ipam.md index d8feb6a0..2d3feff5 100644 --- a/site/ipam/overview-init-ipam.md +++ b/site/ipam/overview-init-ipam.md @@ -67,20 +67,16 @@ To illustrate, suppose you have three hosts, accessible to each other as `$HOST1`, `$HOST2` and `$HOST3`. You can start Weave Net on those three hosts using these three commands: -~~~bash - host1$ weave launch $HOST2 $HOST3 - host2$ weave launch $HOST1 $HOST3 - host3$ weave launch $HOST1 $HOST2 -~~~ + host1$ weave launch $HOST2 $HOST3 + host2$ weave launch $HOST1 $HOST3 + host3$ weave launch $HOST1 $HOST2 Or, if it is not convenient to name all the other hosts at launch time, you can pass the number of peers like this: -~~~bash host1$ weave launch --init-peer-count 3 host2$ weave launch --init-peer-count 3 $HOST3 host3$ weave launch --init-peer-count 3 $HOST2 -~~~ The consensus mechanism used to determine a majority, transitions through three states: 'deferred', 'waiting' and 'achieved': @@ -97,9 +93,7 @@ Finally, some (but never all) peers can be launched as consensus observers rather than participants by specifying the `--observer` option: -~~~bash host4$ weave launch --observer $HOST3 -~~~ You do not need to specify an initial peer count to such peers. This can be useful to add ephemeral peers to an existing fixed cluster (for @@ -137,7 +131,6 @@ independent set again. To illustrate this last point, the following sequence of operations is safe with respect to Weave Net's startup quorum: -~~~bash host1$ weave launch ...time passes... host2$ weave launch $HOST1 @@ -146,7 +139,6 @@ is safe with respect to Weave Net's startup quorum: ...time passes... ...host1 is rebooted... host1$ weave launch $HOST2 $HOST3 -~~~ ### Forcing Consensus diff --git a/site/ipam/stop-remove-peers-ipam.md b/site/ipam/stop-remove-peers-ipam.md index 1fc335a9..0cdc6fce 100644 --- a/site/ipam/stop-remove-peers-ipam.md +++ b/site/ipam/stop-remove-peers-ipam.md @@ -26,10 +26,8 @@ Assume you had started the three peers in the [overview example](/site/ipam/overview-init-ipam.md), and then host3 caught fire, you can go to one of the other hosts and run: -~~~bash host1$ weave rmpeer host3 524288 IPs taken over from host3 -~~~ 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 diff --git a/site/ipam/troubleshooting-ipam.md b/site/ipam/troubleshooting-ipam.md index 5b0c0d6d..c8f8e194 100644 --- a/site/ipam/troubleshooting-ipam.md +++ b/site/ipam/troubleshooting-ipam.md @@ -6,18 +6,18 @@ layout: default The command -~~~bash weave status -~~~ reports on the current status of the weave router and IP allocator: -~~~bash +```` +... Service: ipam Status: awaiting consensus (quorum: 2, known: 0) Range: 10.32.0.0-10.47.255.255 DefaultSubnet: 10.32.0.0/12 -~~~ +... +```` The first section covers the router; see the [troubleshooting guide](/site/troubleshooting.md#weave-status) for full details. diff --git a/site/plugin/cni-plugin-how-to.md b/site/plugin/cni-plugin-how-to.md index f5fa78de..dea6adc2 100644 --- a/site/plugin/cni-plugin-how-to.md +++ b/site/plugin/cni-plugin-how-to.md @@ -16,16 +16,12 @@ your machine has the directories normally used to host CNI plugins. To create those directories, run (as root): -~~~bash mkdir -p /opt/cni/bin mkdir -p /etc/cni/net.d -~~~ Then run: -~~~bash weave setup -~~~ ###Launching Weave Net @@ -37,10 +33,8 @@ See [Deploying Applications to Weave Net](/site/using-weave/deploying-applicatio As well as launching Weave Net, you have to run an extra command to perform some additional configuration of the Weave bridge: -~~~bash weave launch weave expose -~~~ ###Configuring Kubernetes to use the CNI Plugin @@ -48,9 +42,7 @@ After you've launched Weave and peered your hosts, you can configure Kubernetes to use Weave, by adding the following options to the `kubelet` command: -~~~bash --network-plugin=cni --network-plugin-dir=/etc/cni/net.d -~~~ See the [`kubelet` documentation](http://kubernetes.io/v1.1/docs/admin/kubelet.html) for more details. @@ -68,11 +60,9 @@ for details on the format and contents of this file. By default, the Weave CNI plugin adds a default route out via the Weave bridge, so your containers can access resources on the internet. If you do not want this, add a section to the config file that specifies no routes: -~~~bash "ipam": { "routes": [ ] } -~~~ The following other fields in the spec are supported: diff --git a/site/plugin/plug-in-command-line.md b/site/plugin/plug-in-command-line.md index ced2e81a..bb5aba93 100644 --- a/site/plugin/plug-in-command-line.md +++ b/site/plugin/plug-in-command-line.md @@ -8,10 +8,8 @@ layout: default If you need to give additional arguments to the plugin independently, don't use `weave launch`, but instead run: -~~~bash $ weave launch-router [other peers] $ weave launch-plugin [plugin arguments] -~~~ The plugin command-line arguments are: @@ -32,4 +30,4 @@ route, add the `--no-multicast-route` flag to `weave launch-plugin`. **See Also** * [Using the Weave Net Docker Network Plugin](/site/plugin/weave-plugin-how-to.md) - * [How the Weave Network Plugin Works](/site/plugin/plugin-how-it-works.md) \ No newline at end of file + * [How the Weave Network Plugin Works](/site/plugin/plugin-how-it-works.md) diff --git a/site/plugin/weave-plugin-how-to.md b/site/plugin/weave-plugin-how-to.md index 7c374b4c..67c5e891 100644 --- a/site/plugin/weave-plugin-how-to.md +++ b/site/plugin/weave-plugin-how-to.md @@ -16,9 +16,7 @@ See [Deploying Applications to Weave Net](/site/using-weave/deploying-applicatio After you've launched Weave Net and peered your hosts, you can start containers using the following, for example: -~~~bash $ docker run --net=weave -ti ubuntu -~~~ on any of the hosts, and they can all communicate with each other. @@ -28,38 +26,30 @@ In order to use Weave Net's [Service Discovery](/site/weavedns/overview-using-we must pass the additional arguments `--dns` and `-dns-search`, for which a helper is provided in the Weave script: -~~~bash $ 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: -~~~bash -host1$ weave launch host2 -host2$ weave launch host1 -~~~ + host1$ weave launch host2 + host2$ weave launch host1 then run your containers using the Docker command-line: -~~~bash -host1$ docker run --net=weave -ti ubuntu -root@1458e848cd90:/# hostname -i -10.32.0.2 -~~~ + host1$ docker run --net=weave -ti ubuntu + root@1458e848cd90:/# hostname -i + 10.32.0.2 -~~~bash -host2$ docker run --net=weave -ti ubuntu -root@8cc4b5dc5722:/# ping 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 -~~~ + 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 ### Restarting the Plugin @@ -70,9 +60,7 @@ Unfortunately, [Docker 1.9 may also try to communicate with the plugin before it If you are using `systemd`, 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]`: -~~~bash TimeoutStartSec=0 -~~~ ###Bypassing the Central Cluster Store When Building Docker Apps diff --git a/site/troubleshooting.md b/site/troubleshooting.md index 3686a363..3a50e724 100644 --- a/site/troubleshooting.md +++ b/site/troubleshooting.md @@ -19,9 +19,7 @@ layout: default Check the version of Weave Net you are running using: -~~~bash -weave version -~~~ + weave version If it is not the latest version, as shown in the list of [releases](https://github.com/weaveworks/weave/releases), then it is @@ -30,9 +28,7 @@ recommended you upgrade using the To check the Weave Net container logs: -~~~bash -docker logs weave -~~~ + docker logs weave A reasonable amount of information, and all errors, get logged there. @@ -49,7 +45,7 @@ capture and analysis tools, such as tcpdump and wireshark, to the A status summary can be obtained using `weave status`: -~~~bash +```` $ weave status Version: 1.1.0 @@ -79,8 +75,7 @@ $ weave status Service: plugin DriverName: weave - -~~~ +```` The terms used here are explained further at [How Weave Net Works](/site/router-topology/overview.md). @@ -132,14 +127,14 @@ exponential back-off. To view detailed information on the local Weave Net router's type `weave status connections`: -~~~bash +```` $ weave status connections <- 192.168.48.12:33866 established unencrypted fastdp 7e:21:4a:70:2f:45(host2) <- 192.168.48.13:60773 pending encrypted fastdp 7e:ae:cd:d5:23:8d(host3) -> 192.168.48.14:6783 retrying dial tcp4 192.168.48.14:6783: no route to host -> 192.168.48.15:6783 failed dial tcp4 192.168.48.15:6783: no route to host, retry: 2015-08-06 18:55:38.246910357 +0000 UTC -> 192.168.48.16:6783 connecting -~~~ +```` The columns are as follows: @@ -163,7 +158,7 @@ The columns are as follows: Detailed information on peers can be obtained with `weave status peers`: -~~~bash +```` $ weave status peers ce:31:e0:06:45:1a(host1) <- 192.168.48.12:39634 ea:2d:b2:e6:e4:f5(host2) established @@ -174,7 +169,7 @@ ea:2d:b2:e6:e4:f5(host2) ee:38:33:a7:d9:71(host3) -> 192.168.48.12:6783 ea:2d:b2:e6:e4:f5(host2) established -> 192.168.48.11:6783 ce:31:e0:06:45:1a(host1) established -~~~ +```` This lists all peers known to this router, including itself. Each peer is shown with its name and nickname, then each line thereafter @@ -188,7 +183,7 @@ the `host3` end of the same connection as `192.168.48.13:49619`. Detailed information on DNS registrations can be obtained with `weave status dns`: -~~~bash +```` $ weave status dns one 10.32.0.1 eebd81120ee4 4a:0f:f6:ec:1c:93 one 10.43.255.255 4fcec78d2a9b 66:c4:47:c6:65:bf @@ -199,7 +194,7 @@ three 10.40.0.2 8a9c2e2ef00f ba:98:d0:37:4f:1c two 10.32.0.2 83689b8f34e0 4a:0f:f6:ec:1c:93 two 10.44.0.0 7edc306cb668 66:c4:47:c6:65:bf two 10.40.0.1 68a5e9c2641b ba:98:d0:37:4f:1c -~~~ +```` The columns are as follows: @@ -210,9 +205,7 @@ The columns are as follows: ### Producing a JSON Report -~~~bash -$ weave report -~~~ + weave report Produces a comprehensive dump of the internal state of the router, IPAM and DNS services in JSON format, including all the information @@ -220,35 +213,26 @@ available from the `weave status` commands. You can also supply a Golang text template to `weave report` in a similar fashion to `docker inspect`: -~~~bash -$ weave report -f {% raw %}'{{.DNS.Domain}}'{% endraw %} weave.local. -~~~ + $ weave report -f {% raw %}'{{.DNS.Domain}}'{% endraw %} weave.local. Weave Net adds a template function, `json`, which can be applied to get results in JSON format. -~~~bash $ weave report -f {% raw %}'{{json .DNS}}'{% endraw %} {% raw %}{"Domain":"weave.local.","Upstream":["8.8.8.8","8.8.4.4"],"Address":"172.17.0.1:53","TTL":1,"Entries":null}{% endraw %} -~~~ ### Listing Attached Containers -~~~bash -weave ps -~~~ - + weave ps Produces a list of all containers running on this host that are connected to the Weave network, like this: -~~~bash weave:expose 7a:c4:8b:a1:e6:ad 10.2.5.2/24 b07565b06c53 ae:e3:07:9c:8c:d4 5245643870f1 ce:15:34:a9:b5:6d 10.2.5.1/24 e32a7d37a93a 7a:61:a2:49:4b:91 10.2.8.3/24 caa1d4ee2570 ba:8c:b9:dc:e1:c9 10.2.1.1/24 10.2.2.1/24 -~~~ On each line are the container ID, its MAC address, then the list of IP address/routing prefix length ([CIDR @@ -259,11 +243,9 @@ displays the Weave bridge MAC and any IP addresses added to it via the You can also supply a list of container IDs/names to `weave ps`, like this: -~~~bash $ weave ps able baker 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 Net @@ -271,15 +253,11 @@ 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 using: -~~~bash eval $(weave env --restore) -~~~ Then run: -~~~bash weave stop -~~~ Note that this leaves the local application container network intact. Containers on the local host can continue to communicate, whereas @@ -289,9 +267,7 @@ export/import, is disrupted but resumes once Weave is relaunched. To stop Weave Net and to completely remove all traces of the Weave network on the local host, run: -~~~bash weave reset -~~~ Any running application containers permanently lose connectivity with the Weave network and will have to be restarted in order to @@ -319,11 +295,9 @@ Snapshot releases are published at times to provide previews of new features, assist in the validation of bug fixes, etc. One can install the latest snapshot release using: -~~~bash sudo curl -L git.io/weave-snapshot -o /usr/local/bin/weave sudo chmod a+x /usr/local/bin/weave weave setup -~~~ Snapshot releases report the script version as "(unreleased version)", and the container image versions as git hashes. diff --git a/site/using-weave/application-isolation.md b/site/using-weave/application-isolation.md index dcb464d3..6be14975 100644 --- a/site/using-weave/application-isolation.md +++ b/site/using-weave/application-isolation.md @@ -15,12 +15,10 @@ configure Weave Net's IP allocator to manage multiple subnets. Using [the netcat example](/site/using-weave/deploying-applications.md), configure multiple subsets: -~~~bash host1$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24 host1$ eval $(weave env) host2$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24 $HOST1 host2$ eval $(weave env) -~~~ 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 @@ -28,53 +26,41 @@ specified. Next, launch the two netcat containers onto the default subnet: -~~~bash host1$ docker run --name a1 -ti ubuntu host2$ docker run --name a2 -ti ubuntu -~~~ And then to test the isolation, launch a few more containers onto a different subnet: -~~~bash host1$ docker run -e WEAVE_CIDR=net:10.2.2.0/24 --name b1 -ti ubuntu host2$ docker run -e WEAVE_CIDR=net:10.2.2.0.24 --name b2 -ti ubuntu -~~~ Ping each container to confirm that they can talk to each other, but not to the containers of our first subnet: -~~~bash root@b1:/# ping -c 1 -q b2 PING b2.weave.local (10.2.2.128) 56(84) bytes of data. --- b2.weave.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.338/1.338/1.338/0.000 ms -~~~ -~~~bash root@b1:/# ping -c 1 -q a1 PING a1.weave.local (10.2.1.2) 56(84) bytes of data. --- a1.weave.local ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms -~~~ -~~~bash root@b1:/# ping -c 1 -q a2 PING a2.weave.local (10.2.1.130) 56(84) bytes of data. --- a2.weave.local ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms -~~~ If required, a container can also be attached to multiple subnets when it is started using: -~~~bash host1$ docker run -e WEAVE_CIDR="net:default net:10.2.2.0/24" -ti ubuntu -~~~ `net:default` is used to request the allocation of an address from the default subnet in addition to one from an explicitly specified range. ->>**Important:** Containers must be prevented from capturing and injecting raw network packets - this can be accomplished by starting them with the `--cap-drop net_raw` option. +>**Important:** Containers must be prevented from capturing and injecting raw network packets - this can be accomplished by starting them with the `--cap-drop net_raw` option. ->>Note: By default docker permits communication between containers on the same host, via their docker-assigned IP addresses. For complete +>Note: By default docker permits communication between containers on the same host, via their docker-assigned IP addresses. For complete isolation between application containers, that feature needs to be disabled by [setting `--icc=false`](https://docs.docker.com/engine/userguide/networking/default_network/container-communication/#communication-between-containers) in the docker daemon configuration. **See Also** diff --git a/site/using-weave/deploying-applications.md b/site/using-weave/deploying-applications.md index 94ba683c..5495bd9e 100644 --- a/site/using-weave/deploying-applications.md +++ b/site/using-weave/deploying-applications.md @@ -63,9 +63,7 @@ To specify multiple peers, supply a list of addresses to which you want to conne For example: -~~~bash - `host2$:weave launch` -~~~ + host2$ weave launch Peers can also be dynamically added. See [Adding Hosts Dynamically](/site/using-weave/finding-adding-hosts-dynamically.md) for more information. @@ -77,44 +75,34 @@ With two containers running on separate hosts, test that both containers are abl From the container started on `$HOST1`... -~~~bash root@a1:/# ping -c 1 -q a2 PING a2.weave.local (10.40.0.2) 56(84) bytes of data. --- a2.weave.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.341/0.341/0.341/0.000 ms -~~~ Similarly, in the container started on `$HOST2`... -~~~bash root@a2:/# ping -c 1 -q a1 PING a1.weave.local (10.32.0.2) 56(84) bytes of data. --- a1.weave.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.366/0.366/0.366/0.000 ms -~~~ ###Starting the Netcat Service The `netcat` service can be started using the following commands: -~~~bash root@a1:/# nc -lk -p 4422 -~~~ and then connected to from the another container on `$HOST2` using: -~~~bash root@a2:/# echo 'Hello, world.' | nc a1 4422 -~~~ 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 root@a2:/# echo 'Hello, world.' | nc -u a1 5533 -~~~ **See Also** diff --git a/site/using-weave/dynamically-attach-containers.md b/site/using-weave/dynamically-attach-containers.md index dcc29368..fbd66923 100644 --- a/site/using-weave/dynamically-attach-containers.md +++ b/site/using-weave/dynamically-attach-containers.md @@ -8,11 +8,9 @@ When containers may not know the network to which they will be attached, Weave N To illustrate... -~~~bash host1$ C=$(docker run -e WEAVE_CIDR=none -dti ubuntu) host1$ weave attach $C 10.2.1.3 -~~~ where, @@ -20,43 +18,35 @@ where, * `weave attach` – the Weave Net command to attach to the specified container * `10.2.1.3` - the allocated IP address output by `weave attach`, in this case in 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. +>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. ###Dynamically Detaching Containers A container can be detached from a subnet, by using the `weave detach` command: -~~~bash host1$ weave detach $C 10.2.1.3 -~~~ You can also detach a container from one network and then attach it to a different one: -~~~bash host1$ weave detach net:default $C 10.2.1.3 host1$ weave attach net:10.2.2.0/24 $C 10.2.2.3 -~~~ or, attach a container to multiple application networks, effectively sharing the same container between applications: -~~~bash host1$ weave attach net:default 10.2.1.3 host1$ weave attach net:10.2.2.0/24 10.2.2.3 -~~~ Finally, multiple addresses can be attached or detached using a single command: -~~~bash host1$ weave attach net:default net:10.2.2.0/24 net:10.2.3.0/24 $C 10.2.1.3 10.2.2.3 10.2.3.1 host1$ weave detach net:default net:10.2.2.0/24 net:10.2.3.0/24 $C 10.2.1.3 10.2.2.3 10.2.3.1 -~~~ >**Important!** Any addresses that were dynamically attached will not be re-attached if the container restarts. diff --git a/site/using-weave/finding-adding-hosts-dynamically.md b/site/using-weave/finding-adding-hosts-dynamically.md index 6d9646d3..6d3fd961 100644 --- a/site/using-weave/finding-adding-hosts-dynamically.md +++ b/site/using-weave/finding-adding-hosts-dynamically.md @@ -20,9 +20,7 @@ To accomplish this, launch Weave Net onto the new host without supplying any additional addresses. And then, from one of the existing hosts run: -~~~bash host# weave connect $NEW_HOST -~~~ Other hosts on the Weave network will automatically attempt to establish connections to the new host as well. @@ -31,9 +29,7 @@ Alternatively, you can also instruct a peer to forget a particular host specified to it via `weave launch` or `weave connect` by running: -~~~bash host# weave forget $DECOMMISSIONED_HOST -~~~ This prevents the peer from trying to reconnect to that host once connectivity to it is lost, and therefore can be used @@ -43,9 +39,7 @@ from the network. Hosts may also be bulk-replaced. All existing hosts will be forgotten, and the new hosts will be added: -~~~bash host# weave connect --replace $NEW_HOST1 $NEW_HOST2 -~~~ For complete control over the peer topology, automatic discovery can be disabled using the `--no-discovery` @@ -58,11 +52,9 @@ A list of all hosts that a peer has been asked to connect to with `weave launch` and `weave connect` can be obtained using: -~~~bash host# weave status targets -~~~ **See Also** * [Enabling Multi-Cloud, Multi-Hop Networking and Routing](/site/using-weave/multi-cloud-multi-hop.md) - * [Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md) \ No newline at end of file + * [Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md) diff --git a/site/using-weave/host-network-integration.md b/site/using-weave/host-network-integration.md index 01c0e0fc..93fccf4d 100644 --- a/site/using-weave/host-network-integration.md +++ b/site/using-weave/host-network-integration.md @@ -9,44 +9,34 @@ For example, returning to the [netcat example](/site/using-weave/deploying-appli On `$HOST2` run: -~~~bash 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 Net especially for that purpose, and is returned after running `weave expose`. Now you are able to ping the host: -~~~bash host2$ ping 10.2.1.132 -~~~ And you can also ping the `a1` netcat application container residing on `$HOST1`: -~~~bash host2$ ping $(weave dns-lookup a1) -~~~ ###Exposing Multiple Subnets Multiple subnet addresses can be exposed or hidden using a single command: -~~~bash host2$ weave expose net:default net:10.2.2.0/24 10.2.1.132 10.2.2.130 host2$ weave hide net:default net:10.2.2.0/24 10.2.1.132 10.2.2.130 -~~~ ###Adding Exposed Addresses to weavedns Exposed addresses can also be added to `weavedns` by supplying fully qualified domain names: -~~~bash host2$ weave expose -h exposed.weave.local 10.2.1.132 -~~~ **See Also** diff --git a/site/using-weave/isolating-applications.md b/site/using-weave/isolating-applications.md index d594e46a..3e684971 100644 --- a/site/using-weave/isolating-applications.md +++ b/site/using-weave/isolating-applications.md @@ -7,60 +7,46 @@ In some instances, you may need to run applications on the same container networ To do this, you need to configure Weave's IP allocator to manage multiple subnets: -~~~bash host1$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24 host1$ eval $(weave env) host2$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24 $HOST1 host2$ eval $(weave env) -~~~ 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: -~~~bash host1$ docker run --name a1 -ti ubuntu host2$ docker run --name a2 -ti ubuntu -~~~ And then launch several more containers onto a different subnet: -~~~bash host1$ docker run -e WEAVE_CIDR=net:10.2.2.0/24 --name b1 -ti ubuntu host2$ docker run -e WEAVE_CIDR=net:10.2.2.0.24 --name b2 -ti ubuntu -~~~ Ping the containers from each subnet to confirm that they can communicate with each other, but not to the containers of our first subnet: -~~~bash root@b1:/# ping -c 1 -q b2 PING b2.weave.local (10.2.2.128) 56(84) bytes of data. --- b2.weave.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.338/1.338/1.338/0.000 ms -~~~ -~~~bash root@b1:/# ping -c 1 -q a1 PING a1.weave.local (10.2.1.2) 56(84) bytes of data. --- a1.weave.local ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms -~~~ -~~~bash root@b1:/# ping -c 1 -q a2 PING a2.weave.local (10.2.1.130) 56(84) bytes of data. --- a2.weave.local ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms -~~~ ###Attaching Containers to Multiple Subnets and Isolating Applications A container can also be attached to multiple subnets by using the following command line arguments with `docker run`: -~~~bash host1$ docker run -e WEAVE_CIDR="net:default net:10.2.2.0/24" -ti ubuntu -~~~ Where, diff --git a/site/using-weave/manual-ip-address.md b/site/using-weave/manual-ip-address.md index 470b93a1..ae0cad82 100644 --- a/site/using-weave/manual-ip-address.md +++ b/site/using-weave/manual-ip-address.md @@ -5,10 +5,8 @@ layout: default Containers are automatically allocated an IP address that is unique across the Weave network. You can see which address was allocated by running, [`weave ps`](/site/troubleshooting.md#weave-status): -~~~bash host1$ weave ps a1 a7aee7233393 7a:44:d3:11:10:70 10.32.0.2/12 -~~~ Weave Net detects when a container has exited and releases its allocated addresses so they can be re-used by the network. @@ -23,37 +21,29 @@ For example, we can launch a couple of containers on `$HOST1` and On `$HOST1`: -~~~bash -host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti ubuntu -root@7ca0f6ecf59f:/# -~~~ + host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti ubuntu + root@7ca0f6ecf59f:/# And `$HOST2`: -~~~bash -host2$ docker run -e WEAVE_CIDR=10.2.1.2/24 -ti ubuntu -root@04c4831fafd3:/# -~~~ + host2$ docker run -e WEAVE_CIDR=10.2.1.2/24 -ti ubuntu + root@04c4831fafd3:/# Then test that the container on `$HOST2` can be reached from the container on `$HOST1`: -~~~bash -root@7ca0f6ecf59f:/# ping -c 1 -q 10.2.1.2 -PING 10.2.1.2 (10.2.1.2): 48 data bytes ---- 10.2.1.2 ping statistics --- -1 packets transmitted, 1 packets received, 0% packet loss -round-trip min/avg/max/stddev = 1.048/1.048/1.048/0.000 ms -~~~ + root@7ca0f6ecf59f:/# ping -c 1 -q 10.2.1.2 + PING 10.2.1.2 (10.2.1.2): 48 data bytes + --- 10.2.1.2 ping statistics --- + 1 packets transmitted, 1 packets received, 0% packet loss + round-trip min/avg/max/stddev = 1.048/1.048/1.048/0.000 ms And in the other direction... -~~~bash -root@04c4831fafd3:/# ping -c 1 -q 10.2.1.1 -PING 10.2.1.1 (10.2.1.1): 48 data bytes ---- 10.2.1.1 ping statistics --- -1 packets transmitted, 1 packets received, 0% packet loss -round-trip min/avg/max/stddev = 1.034/1.034/1.034/0.000 ms -~~~ + root@04c4831fafd3:/# ping -c 1 -q 10.2.1.1 + PING 10.2.1.1 (10.2.1.1): 48 data bytes + --- 10.2.1.1 ping statistics --- + 1 packets transmitted, 1 packets received, 0% packet loss + round-trip min/avg/max/stddev = 1.034/1.034/1.034/0.000 ms The IP addresses and netmasks can be set to anything, but ensure they don’t conflict with any of the IP ranges in use on the hosts or with IP addresses used by any external services to which the hosts or containers may need to connect. diff --git a/site/using-weave/security-untrusted-networks.md b/site/using-weave/security-untrusted-networks.md index 5d977fba..4d433e0a 100644 --- a/site/using-weave/security-untrusted-networks.md +++ b/site/using-weave/security-untrusted-networks.md @@ -8,16 +8,12 @@ To connect containers across untrusted networks, Weave Net peers can be instruct For example: -~~~bash host1$ weave launch --password wfvAwt7sj -~~~ or -~~~bash host1$ export WEAVE_PASSWORD=wfvAwt7sj host1$ weave launch -~~~ >NOTE: The command line option takes precedence over the environment variable._ @@ -28,9 +24,7 @@ or To guard against dictionary attacks, the password needs to be reasonably strong with at least 50 bits of entropy is recommended. An easy way to generate a random password that satisfies this requirement is: -~~~bash < /dev/urandom tr -dc A-Za-z0-9 | head -c9 ; echo -~~~ The same password must be specified for all Weave Net peers, by default both control and data plane traffic will then use authenticated encryption. diff --git a/site/using-weave/service-export.md b/site/using-weave/service-export.md index 622f5d2d..2cc0f306 100644 --- a/site/using-weave/service-export.md +++ b/site/using-weave/service-export.md @@ -13,25 +13,19 @@ you can expose the netcat service running on `HOST1` and make it accessible to t 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): -~~~bash host2$ weave expose 10.2.1.132 -~~~ Then add a NAT rule that routes the traffic from the outside world to the destination container service. -~~~bash host2$ iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 2211 \ -j DNAT --to-destination $(weave dns-lookup a1):4422 -~~~ In this example, it is assumed that the "outside world" is connecting to `$HOST2` via 'eth0'. The TCP traffic to port 2211 on the external IPs will be routed to the 'nc' service running on port 4422 in the container a1. With the above in place, you can connect to the 'nc' service from anywhere using: -~~~bash echo 'Hello, world.' | nc $HOST2 2211 -~~~ >**Note:** Due to the way routing is handled in the Linux kernel, this won't work when run *on* `$HOST2`. diff --git a/site/using-weave/service-management.md b/site/using-weave/service-management.md index 2050b98d..4e609bb2 100644 --- a/site/using-weave/service-management.md +++ b/site/using-weave/service-management.md @@ -21,24 +21,18 @@ Turning back to the [netcat example](/site/using-weave/deploying-applications.md To do this, expose the application network to `$HOST2`, as explained in [Host Network Integration](/site/using-weave/host-network-integration.md) by running: -~~~bash host2$ weave expose 10.2.1.132 -~~~ Then add a NAT rule to route from the outside world to the destination container service. -~~~bash host2$ iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 2211 \ -j DNAT --to-destination $(weave dns-lookup a1):4422 -~~~ Here it is assumed that the "outside world" is connecting to `$HOST2` via 'eth0'. The TCP traffic to port 2211 on the external IPs will be routed to the 'nc' service, running in the a1 container and listening on port 4422. With the above in place, you are ready to connect to the 'nc' service from anywhere using: -~~~bash - echo 'Hello, world.' | nc $HOST2 2211 -~~~ + $ echo 'Hello, world.' | nc $HOST2 2211 >**Note:** Due to the way routing is handled in the Linux kernel, this won't work when run *on* `$HOST2`. @@ -56,30 +50,22 @@ An additional caveat is that `$HOST3` can only be reached from `$HOST1`, which i 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`: -~~~bash host1$ weave expose -h host1.weave.local 10.2.1.3 -~~~ Then add a NAT rule, which routes from the above IP to the destination service. -~~~bash host1$ iptables -t nat -A PREROUTING -p tcp -d 10.2.1.3 --dport 3322 \ -j DNAT --to-destination $HOST3:2211 -~~~ This allows any application container to reach the service by connecting to 10.2.1.3:3322. So if `$HOST3` is running a netcat service on port 2211: -~~~bash host3$ nc -lk -p 2211 -~~~ You can now connect to it from the application container running on `$HOST2` using: -~~~bash root@a2:/# echo 'Hello, world.' | nc host1 3322 -~~~ Note that you should be able to run this command from any application container. @@ -101,23 +87,17 @@ Expanding on the [netcat example](/site/using-weave/deploying-applications.md), Begin importing the service onto `$HOST2` by first exposing the application network: -~~~bash host2$ weave expose 10.2.1.3 -~~~ 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: -~~~bash host2$ iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4433 \ -j DNAT --to-destination 10.2.1.3:3322 -~~~ Now any host on the same network as `$HOST2` is able to access the service: -~~~bash echo 'Hello, world.' | nc $HOST2 4433 -~~~ ###Dynamically Changing Service Locations diff --git a/site/weave-docker-api/automatic-discovery-proxy.md b/site/weave-docker-api/automatic-discovery-proxy.md index 9b85d6e2..78ab3f05 100644 --- a/site/weave-docker-api/automatic-discovery-proxy.md +++ b/site/weave-docker-api/automatic-discovery-proxy.md @@ -28,10 +28,8 @@ Additionally, the hostname is matched against a regular expression `` an For example, you can launch the proxy using all three flags, as follows: -~~~bash host1$ weave launch-router && weave launch-proxy --hostname-from-label hostname-label --hostname-match '^aws-[0-9]+-(.*)$' --hostname-replacement 'my-app-$1' host1$ eval $(weave env) -~~~ >**Note:** regexp substitution groups must be pre-pended with a dollar sign (for example, `$1`). For further details on the regular expression syntax see @@ -39,22 +37,18 @@ For example, you can launch the proxy using all three flags, as follows: 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`. -~~~bash 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. 64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=1 ttl=64 time=0.027 ms 64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=2 ttl=64 time=0.067 ms -~~~ Also, running a container named `foo` with the label `hostname-label=aws-12798186823-foo` leads to the same hostname registration. -~~~bash host1$ docker run -ti --name=foo --label=hostname-label=aws-12798186823-foo ubuntu ping my-app-foo PING my-app-foo.weave.local (10.32.0.2) 56(84) bytes of data. 64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=1 ttl=64 time=0.031 ms 64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=2 ttl=64 time=0.042 ms -~~~ This is because, as explained above, if providing `--hostname-from-label` to the proxy, the specified label takes precedence over the container's name. @@ -62,4 +56,4 @@ to the proxy, the specified label takes precedence over the container's name. **See Also** * [Name resolution via `/etc/hosts`](/site/weave-docker-api/name-resolution-proxy.md) - * [How Weave Finds Containers](/site/weavedns/how-works-weavedns.md) \ No newline at end of file + * [How Weave Finds Containers](/site/weavedns/how-works-weavedns.md) diff --git a/site/weave-docker-api/ipam-proxy.md b/site/weave-docker-api/ipam-proxy.md index 1a73d9a9..a1aa6da9 100644 --- a/site/weave-docker-api/ipam-proxy.md +++ b/site/weave-docker-api/ipam-proxy.md @@ -8,31 +8,23 @@ If [automatic IP address allocation](/site/ipam/overview-init-ipam.md) is enable then containers started via the proxy are automatically assigned an IP address, *without having to specify any special environment variables or any other options*. -~~~bash host1$ docker run -ti ubuntu -~~~ To use a specific subnet, you can pass a `WEAVE_CIDR` to the container, for example: -~~~bash host1$ docker run -ti -e WEAVE_CIDR=net:10.32.2.0/24 ubuntu -~~ To start a container without connecting it to the Weave network, pass `WEAVE_CIDR=none`, for example: -~~~bash host1$ docker run -ti -e WEAVE_CIDR=none ubuntu -~~~ ###Disabling Automatic IP Address Allocation If you do not want an IP to be assigned by default, the proxy needs to be passed the `--no-default-ipalloc` flag, for example: -~~~bash host1$ weave launch-proxy --no-default-ipalloc -~~~ In this configuration, containers using no `WEAVE_CIDR` environment variable are not connected to the Weave network. @@ -41,11 +33,9 @@ Containers started with a `WEAVE_CIDR` environment variable are handled as befor To automatically assign an address in this mode, start the container with a blank `WEAVE_CIDR`, for example: -~~~bash host1$ docker run -ti -e WEAVE_CIDR="" ubuntu -~~~ **See Also** * [Address Allocation with IP Address Management (IPAM)](/site/ipam/overview-init-ipam.md) - * [How to Manually Specify IP Addresses and Subnets](/site/using-weave/manual-ip-address.md) \ No newline at end of file + * [How to Manually Specify IP Addresses and Subnets](/site/using-weave/manual-ip-address.md) diff --git a/site/weave-docker-api/launching-without-proxy.md b/site/weave-docker-api/launching-without-proxy.md index 24f55f26..ef37c6fa 100644 --- a/site/weave-docker-api/launching-without-proxy.md +++ b/site/weave-docker-api/launching-without-proxy.md @@ -7,9 +7,7 @@ layout: default If you don't want to use the proxy, you can also launch containers on to the Weave network using `weave run`: -~~~bash $ weave run -ti ubuntu -~~~ The arguments after `run` are passed through to `docker run`. Therefore you can freely specify whatever Docker options you need. @@ -19,18 +17,14 @@ this example, it obtains an automatically allocated IP. You can specify IP addresses manually instead: -~~~bash $ weave run 10.2.1.1/24 -ti ubuntu -~~~ `weave run` rewrites `/etc/hosts` in the same way [the proxy does](/site/weave-docker-api/name-resolution-proxy.md). If you need to keep the original file, specify `--no-rewrite-hosts` when running the container: -~~~bash $ weave run --no-rewrite-hosts 10.2.1.1/24 -ti ubuntu -~~~ There are some limitations to starting containers using `weave run`: diff --git a/site/weave-docker-api/name-resolution-proxy.md b/site/weave-docker-api/name-resolution-proxy.md index 79d0e1c3..41b802b4 100644 --- a/site/weave-docker-api/name-resolution-proxy.md +++ b/site/weave-docker-api/name-resolution-proxy.md @@ -26,11 +26,9 @@ IP instead of the Weave IP, or you require name resolution for Docker-managed networks), the proxy must be launched using the `--no-rewrite-hosts` flag. -~~~bash host1$ weave launch-router && weave launch-proxy --no-rewrite-hosts -~~~ **See Also** * [Using Automatic Discovery With the Weave Proxy](/site/weave-docker-api/automatic-discovery-proxy.md) - \ No newline at end of file + diff --git a/site/weave-docker-api/securing-proxy.md b/site/weave-docker-api/securing-proxy.md index 4abf5bbe..c56c5f72 100644 --- a/site/weave-docker-api/securing-proxy.md +++ b/site/weave-docker-api/securing-proxy.md @@ -11,9 +11,7 @@ attempts to duplicate it. In the standard auto-detection case you can launch a TLS-enabled proxy as follows: -~~~bash host1$ weave launch-proxy -~~~ To disable auto-detection of TLS configuration, you can either pass the `--no-detect-tls` flag, or you can manually configure the proxy's TLS using @@ -23,10 +21,8 @@ daemon. For example, if you generated your certificates and keys into the Docker host's `/tls` directory, launch the proxy using: -~~~bash host1$ weave launch-proxy --tlsverify --tlscacert=/tls/ca.pem \ --tlscert=/tls/server-cert.pem --tlskey=/tls/server-key.pem -~~~ The paths to your certificates and key must be provided as absolute paths as they exist on the Docker host. @@ -41,20 +37,16 @@ for an example. With the proxy running over TLS, you can configure the Docker client to use TLS on a per-invocation basis by running: -~~~bash $ docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem \ --tlskey=key.pem -H=tcp://host1:12375 version -~~~ or, [by default](https://docs.docker.com/articles/https/#secure-by-default), using: -~~~bash $ mkdir -pv ~/.docker $ cp -v {ca,cert,key}.pem ~/.docker $ eval $(weave env) $ export DOCKER_TLS_VERIFY=1 $ docker version -~~~ This is exactly the same configuration used when connecting to the Docker daemon directly, except that the specified port is the Weave diff --git a/site/weave-docker-api/set-up-proxy.md b/site/weave-docker-api/set-up-proxy.md index 0638310e..740bda04 100644 --- a/site/weave-docker-api/set-up-proxy.md +++ b/site/weave-docker-api/set-up-proxy.md @@ -17,15 +17,11 @@ The proxy sits between the Docker client (command line or API) and the Docker daemon, and intercepts the communication between the two. You can start it simultaneously with the router and weavedns via `launch`: -~~~bash host1$ weave launch -~~~ or independently via `launch-proxy`: -~~~bash host1$ weave launch-router && weave launch-proxy -~~~ The first form is more convenient. But only `launch-proxy` can be passed configuration arguments. Therefore if you need to modify the default behaviour of the proxy, you must use `launch-proxy`. @@ -37,9 +33,7 @@ the launching client connects over TCP, the proxy listens on port 12375, on all network interfaces. This can be adjusted using the `-H` argument, for example: -~~~bash host1$ weave launch-proxy -H tcp://127.0.0.1:9999 -~~~ If no TLS or listening interfaces are set, TLS is auto-configured based on the Docker daemon's settings, and the listening interfaces are @@ -53,28 +47,20 @@ All docker commands can be run via the proxy, so it is safe to adjust your `DOCKER_HOST` to point at the proxy. Weave Net provides a convenient command for this: -~~~bash host1$ eval $(weave env) host1$ docker ps -~~~ The prior settings can be restored with -~~~bash host1$ eval $(weave env --restore) -~~~ Alternatively, the proxy host can be set on a per-command basis with -~~~bash host1$ docker $(weave config) ps -~~~ The proxy can be stopped independently with -~~~bash host1$ weave stop-proxy -~~~ or in conjunction with the router and weavedns via `stop`. diff --git a/site/weave-docker-api/troubleshooting-proxy.md b/site/weave-docker-api/troubleshooting-proxy.md index 0ed3087c..138f283c 100644 --- a/site/weave-docker-api/troubleshooting-proxy.md +++ b/site/weave-docker-api/troubleshooting-proxy.md @@ -5,24 +5,22 @@ layout: default The command -~~~bash weave status -~~~ reports on the current status of various Weave Net components, including the proxy, if it is running: -~~~bash +```` +... Service: proxy Address: tcp://127.0.0.1:12375 -~~~ +... +```` Information on the operation of the proxy can be obtained from the weaveproxy container logs using: -~~~bash docker logs weaveproxy -~~~ **See Also** diff --git a/site/weave-docker-api/using-proxy.md b/site/weave-docker-api/using-proxy.md index 585fc720..35793630 100644 --- a/site/weave-docker-api/using-proxy.md +++ b/site/weave-docker-api/using-proxy.md @@ -16,24 +16,18 @@ Weave network. To create and start a container via the Weave Net proxy run: -~~~bash host1$ docker run -ti ubuntu -~~~ or, equivalently run: -~~~bash host1$ docker create -ti ubuntu 5ef831df61d50a1a49272357155a976595e7268e590f0a2c75693337b14e1382 host1$ docker start 5ef831df61d50a1a49272357155a976595e7268e590f0a2c75693337b14e1382 -~~~ Specific IP addresses and networks can be supplied in the `WEAVE_CIDR` environment variable, for example: -~~~bash host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti ubuntu -~~~ Multiple IP addresses and networks can be supplied in the `WEAVE_CIDR` variable by space-separating them, as in @@ -51,9 +45,7 @@ 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. -~~~bash host1$ weave launch-router && weave launch-proxy --rewrite-inspect -~~~ ###Multicast Traffic and Launching the Weave Proxy @@ -66,4 +58,4 @@ route, add the `--no-multicast-route` flag to `weave launch-proxy`. * [Setting Up The Weave Docker API Proxy](/site/weave-docker-api/set-up-proxy.md) * [Securing Docker Communications With TLS](securing-proxy.md) - * [Launching Containers With Weave Run (without the Proxy)](/site/weave-docker-api/launching-without-proxy.md) \ No newline at end of file + * [Launching Containers With Weave Run (without the Proxy)](/site/weave-docker-api/launching-without-proxy.md) diff --git a/site/weavedns/managing-entries-weavedns.md b/site/weavedns/managing-entries-weavedns.md index 228d8378..3331fe96 100644 --- a/site/weavedns/managing-entries-weavedns.md +++ b/site/weavedns/managing-entries-weavedns.md @@ -53,10 +53,8 @@ which they were added. You can resolve entries from any host running weaveDNS with `weave dns-lookup`: -~~~bash host1$ weave dns-lookup pingme 10.40.0.1 -~~~ ### Hot-swapping service containers diff --git a/site/weavedns/troubleshooting-weavedns.md b/site/weavedns/troubleshooting-weavedns.md index 4dd251b9..533d9e92 100644 --- a/site/weavedns/troubleshooting-weavedns.md +++ b/site/weavedns/troubleshooting-weavedns.md @@ -10,20 +10,20 @@ layout: default The command: -~~~bash weave status -~~~ reports on the current status of various Weave Net components, including DNS: -~~~bash +```` +... Service: dns Domain: weave.local. Upstream: 8.8.8.8, 8.8.4.4 TTL: 1 Entries: 9 -~~~ +... +```` The first section covers the router; see the [troubleshooting guide](/site/troubleshooting.md#weave-status) for more details. @@ -41,9 +41,7 @@ dump](/site/troubleshooting.md#weave-status-dns) of all DNS registrations. Information on the processing of queries, and the general operation of weaveDNS, can be obtained from the container logs with -~~~bash docker logs weave -~~~ ### Present Limitations