From 53cc3a5f320fc0320cf78cd06bc06703b787472f Mon Sep 17 00:00:00 2001 From: Matthias Radestock Date: Tue, 18 Nov 2014 12:23:17 +0000 Subject: [PATCH] change styling of host references in remainder of docs Following #196. --- site/features.md | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/site/features.md b/site/features.md index aa456862..f2ca597b 100644 --- a/site/features.md +++ b/site/features.md @@ -31,11 +31,11 @@ like a giant Ethernet switch to which all the containers are connected. Containers can easily access services from each other; e.g. in the -container on $HOST1 we can start a netcat "service" with +container on `$HOST1` we can start a netcat "service" with root@28841bd02eff:/# nc -lk -p 4422 -and then connect to it from the container on $HOST2 with +and then connect to it from the container on `$HOST2` with root@f76829496120:/# echo 'Hello, world.' | nc 10.0.1.1 4422 @@ -144,8 +144,8 @@ Weave application networks can be integrated with a host's network, establishing connectivity between the host and application containers anywhere. -Let's say that in our example we want $HOST2 to have access to the -application containers. On $HOST2 we run +Let's say that in our example we want `$HOST2` to have access to the +application containers. On `$HOST2` we run host2# weave expose 10.0.1.102/24 @@ -160,7 +160,7 @@ will work. And, more interestingly, host2# ping 10.0.1.1 -will work too, which is talking to a container that resides on $HOST1. +will work too, which is talking to a container that resides on `$HOST1`. ### Service export @@ -170,9 +170,9 @@ from any weave host, irrespective of where the service containers are located. Say we want to make our example netcat "service", which is running in -a container on $HOST1, accessible to the outside world via $HOST2. +a container on `$HOST1`, accessible to the outside world via `$HOST2`. -First we need to expose the application network to $HOST2, as +First we need to expose the application network to `$HOST2`, as explained [above](#host-network-integration), i.e. host2# weave expose 10.0.1.102/24 @@ -183,7 +183,7 @@ destination container service. host2# iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 2211 \ -j DNAT --to-destination 10.0.1.1:4422 -Here we are assuming that the "outside world" is connecting to $HOST2 +Here we are assuming that the "outside world" is connecting to `$HOST2` via 'eth0'. We want TCP traffic to port 2211 on the external IPs to be routed to our 'nc' service, which is running on port 4422 in the container with IP 10.0.1.1. @@ -194,7 +194,7 @@ anywhere with echo 'Hello, world.' | nc $HOST2 2211 (NB: due to the way routing is handled in the Linux kernel, this won't -work when run *on* $HOST2.) +work when run *on* `$HOST2`.) Similar NAT rules to the above can used to expose services not just to the outside world but also other, internal, networks. @@ -206,13 +206,13 @@ access to services which are only reachable from certain weave hosts, irrespective of where the application containers are located. Say that, as an extension of our example, we have a netcat service -running on $HOST3, port 2211, and that $HOST3 is not part of the weave -network and is only reachable from $HOST1, not $HOST2. Nevertheless we +running on `$HOST3`, port 2211, and that `$HOST3` is not part of the weave +network and is only reachable from `$HOST1`, not `$HOST2`. Nevertheless we want to make the service accessible to an application running in a -container on $HOST2. +container on `$HOST2`. First we need to expose the application network to the host, as -explained [above](#host-network-integration), this time on $HOST1, +explained [above](#host-network-integration), this time on `$HOST1`, i.e. host1# weave expose 10.0.1.101/24 @@ -224,12 +224,12 @@ service. -j DNAT --to-destination $HOST3:2211 This allows any application container to reach the service by -connecting to 10.0.1.101:3322. So if $HOST3 is indeed running a netcat +connecting to 10.0.1.101:3322. So if `$HOST3` is indeed running a netcat service on port 2211, e.g. host3# nc -lk -p 2211 -then we can connect to it from our application container on $HOST2 with +then we can connect to it from our application container on `$HOST2` with root@f76829496120:/# echo 'Hello, world.' | nc 10.0.1.101 3322 @@ -258,27 +258,27 @@ scenario (though of course there could be); weave is acting purely as an address translation and routing facility, using the weave application network as an intermediary. -In our example above, the netcat service on $HOST3 is imported into -weave via $HOST1. We can export it on $HOST2 by first exposing the +In our example above, the netcat service on `$HOST3` is imported into +weave via `$HOST1`. We can export it on `$HOST2` by first exposing the application network with host2# weave expose 10.0.1.102/24 -and then adding a NAT rule which routes traffic from the $HOST2 -network (i.e. anything which can connect to $HOST2) to the service +and then adding a NAT rule which routes traffic from the `$HOST2` +network (i.e. anything which can connect to `$HOST2`) to the service endpoint in the weave network host2# iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4433 \ -j DNAT --to-destination 10.0.1.101:3322 -Now any host on the same network as $HOST2 can access the service with +Now any host on the same network as `$HOST2` can access the service with echo 'Hello, world.' | nc $HOST2 4433 Furthermore, as explained in [service-binding](#service-binding), we can dynamically alter the service locations without having to touch the applications that access them, e.g. we could move the example -netcat service to $HOST4:2211 while retaining its 10.0.1.101:3322 +netcat service to `$HOST4:2211` while retaining its 10.0.1.101:3322 endpoint in the weave network. ### Multi-cloud networking