<commit_before>---
title: Managing Services in Weave Net - Exporting, Importing, Binding and Routing
menu_order: 90
---

This section contains the following topics: 

 * [Exporting Services](#exporting)
 * [Importing Services](#importing)
 * [Binding Services](#binding)
 * [Routing Services](#routing)
 * [Dynamically Changing Service Locations](#change-location)



###<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.

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`.

To do this, expose the application network to `$HOST2`, as explained in [Host Network Integration](/site/using-weave/host-network-integration.md) by running:

    host2$ weave expose
    10.2.1.132

Then add a NAT rule to route 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:

    $ 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.


###<a name="importing"></a>Importing Services

Applications running in containers on a Weave network can be given access to services, which are only reachable from certain 
Weave hosts, regardless of where the actual application containers are located.

Expanding on the [netcat service example](/site/using-weave.md), you now decide to add a third, non-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`.

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`: <commit_msg>make service export section match whats in the separate doc<commit_after>---
title: Managing Services in Weave Net - Exporting, Importing, Binding and Routing
menu_order: 90
---

This section contains the following topics: 

 * [Exporting Services](#exporting)
 * [Importing Services](#importing)
 * [Binding Services](#binding)
 * [Routing Services](#routing)
 * [Dynamically Changing Service Locations](#change-location)



###<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 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.

###<a name="importing"></a>Importing Services

Applications running in containers on a Weave network can be given access to services, which are only reachable from certain 
Weave hosts, regardless of where the actual application containers are located.

Expanding on the [netcat service example](/site/using-weave.md), you now decide to add a third, non-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`.

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`: 
{'fraction_non_alphanumeric': 0.08135349172066235, 'fraction_numerical': 0.018718502519798418, 'mean_word_length': 4.3587270973963355, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 13, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 2, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3209633', 'n_tokens_mistral': 1591, 'n_tokens_neox': 1482, 'n_words': 781}