reweave/weave
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #2227 from weaveworks/2207-dedup-service-export-docs

Browse Source 
dedup service export docs

Fixes #2207.
This commit is contained in:
Matthias Radestock committed 2016-04-27 17:31:34 +01:00
2 parents 789a6192f2 65ecac6f1a
commit 7decce690a
4 files changed
+16 -52
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

site/faq.md
+2 -2
View File
@@ -22,7 +22,7 @@ For more information, refer to [Manually Specifying the IP Address of a Containe
**Q: How do I expose one of my containers to the outside world?**
Exposing a container to the outside world is described in [Exposing Services to the Outside](/site/using-weave/service-export.md).
Exposing a container to the outside world is described in [Exporting Services](/site/using-weave/service-management.md#exporting).
**Q: Can I connect my existing 'legacy' network with a Weave container network?**
@@ -33,7 +33,7 @@ For example, you have a Weave network that runs on hosts A, B, C. and you have a
The simplest way to accomplish this would be to run Weave on the host and then run, `weave expose` to expose the network to any running containers. See [Integrating a Network Host](/site/using-weave/host-network-integration.md) If this is not possible, you could also expose a port on the container on host B and then connect to it.
You can read about exposing ports in [Service Exporting](/site/using-weave/service-export.md).
You can read about exposing ports in [Exporting Services](/site/using-weave/service-management.md#exporting).
**Q: Why am I seeing the same IP address assigned to two different containers on different hosts?**
site/using-weave/application-isolation.md
-1
View File
@@ -67,4 +67,3 @@ isolation between application containers, that feature needs to be disabled by [
* [Automatic Allocation Across Multiple Subnets](/site/ipam/allocation-multi-ipam.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)
site/using-weave/service-export.md
-39
View File
@@ -1,39 +0,0 @@
---
title: Exposing Services to the Outside World
menu_order: 70
---
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 Net host, irrespective of where the service containers are
located.
Returning to the [netcat example service](/site/using-weave.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 Net](/site/using-weave/host-network-integration.md):
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.
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:
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`.
Similar NAT rules to the above can be used to expose services not just to the outside world but also to other, internal, networks.
**See Also**
* [Using Weave Net](/site/using-weave.md)
* [Managing Services in Weave Net: Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md)
site/using-weave/service-management.md
+14 -10
View File
@@ -13,31 +13,35 @@ This section contains the following topics:
###<a name="exporting"></a> Exporting Services
###<a name="exporting"></a>Exporting Services
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, regardless of where the service containers are located.
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 Net host, irrespective of where the service containers are
located.
Turning back to the [netcat example](/site/using-weave.md), say you want the netcat service, which is running in a container on `$HOST1`, to be accessible to the outside world via `$HOST2`.
Returning to the [netcat example service](/site/using-weave.md),
you can expose the netcat service running on `HOST1` and make it accessible to the outside world via `$HOST2`.
To do this, expose the application network to `$HOST2`, as explained in [Host Network Integration](/site/using-weave/host-network-integration.md) by running:
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
Then add a NAT rule to route from the outside world to the destination container service.
Then add a NAT rule that routes the traffic from the outside world to the destination container service.
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:
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.
$ echo 'Hello, world.' | nc $HOST2 2211
With the above in place, you can connect to the 'nc' service from anywhere using:
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`.
Similar NAT rules to the above can used to expose services not just to the outside world but also other, internal, networks.
Similar NAT rules to the above can be used to expose services not just to the outside world but also to other, internal, networks.
###<a name="importing"></a>Importing Services