Network Service ​

Throughout the last few sections, we may have said that a TSF instance 'notifies' the Register Service, or the Register Service 'broadcasts' information to all TSF instances -- this all takes place via our Network Service. What we really meant earlier was that the 'sender' puts a key/value into our distributed Network Service that is read by anyone interested. This is how information flows through our TSF.

The Network Service is a distributed and replicated key-value store. Because of its distributed and replicated nature, when multiple instances of the Network Service are started, a client can get immediate updates while reading a key even if another client updates that key while connecting to a different instance of the Network Service. Even if an instance of the Network Service goes down, the others are still there to serve client requests.

All of the communication involving events in the TSF happen through the Network Service. Because of this, the Network Service being up is essential for the TSF to start and while the TSF is running.

There are no configuration files for the Network Service, but there are some variables that need to be configured to start the Network Service and allow other clients to connect to the Network Service. There are 2 ports that the Network Service needs to expose, a peer port and a client port. Because of its distributed nature, if multiple instances of the Network Service are started, they need to communicate with each other about key value pairs have been added to each other to make sure that each instance has the same data -- this peer port is for that purpose. And of course, for clients to connect and use the Network Service, there needs to be another port, the client port.

Let's say that we want to start 2 instances of the Network Service, and we are using 2380 as the peer port, and 2379 as the client port. The below configurations are needed to start the Network Service and have clients connect to it.

Environment variable:

• key: INITIAL_HOST_URLS
• value: network-service-1=http://network-service-1:2380,network-service-2=http://network-service-2:2380
  • This is so each Network Service instance coming up knows the others to connect to, which is why it uses the peer port, 2380.

Each client (in this case, each TSF Instance, the Register Service, and our Management Console) needs to have these endpoints added to their configuration files in order to connect to the Network Service, which is why it uses the client port, 2379. The below snippet shows how this would work in an override configuration file:

"networkServiceEndpoints": [
   "http://network-service-1:2379",
   "http://network-service-2:2379"
 ]

Configuring Setup ​

Recall the command you ran to start the single instance of the network service in the example.

docker network create --subnet 10.0.0.0/24 test-tsf

docker run -d -p 23797:2379 --ip 10.0.0.17 --name network-service-1 \
--hostname network-service-1 --network test-tsf -e INSTANCE_NUM=1 \
-e INITIAL_HOST_URLS=network-service-1=http://network-service-1:2380 \
-e CLUSTER_STATE=new ts/network:<release-version>

Starting Multiple Network Service Instances ​

How would this change if we wanted to start multiple instances?

The first part of the command creating the network remains identical (only needs to be done once, not for each network service instance).

Network Service Instance 1

docker run -d -p 23797:2379 --ip 10.0.0.17 --name network-service-1 \
--hostname network-service-1 --network test-tsf -e INSTANCE_NUM=1 \
-e INITIAL_HOST_URLS=network-service-1=http://network-service-1:2380,network-service-2=http://network-service-2:2380 \
-e CLUSTER_STATE=new ts/network:<release-version>

Network Service Instance 2

docker run -d -p 23798:2379 --ip 10.0.0.17 --name network-service-2 \
--hostname network-service-2 --network test-tsf -e INSTANCE_NUM=2 \
-e INITIAL_HOST_URLS=network-service-1=http://network-service-1:2380,network-service-2=http://network-service-2:2380 \
-e CLUSTER_STATE=new ts/network:<release-version>

Notice the main difference here is that the environment variable INITIAL_HOST_URLS is modified to include all Network Service instances that are in the cluster - to make sure that each Network Service instance knows how to connect to each other.

Change Client and Peer Ports ​

What if you didn't want to use 2379 and 2380 as the peer and client ports? These are the defaults as defined in the Dockerfile - if you want to change these ports, in the docker run command, add the environment variables PEER_PORT and CLIENT_PORT

E.g.

docker run -d -p 23797:3000 --ip 10.0.0.17 --name network-service-1 \
--hostname network-service-1 --network test-tsf -e PEER_PORT=3000 \
-e CLIENT_PORT=8000 -e INSTANCE_NUM=1 \
-e INITIAL_HOST_URLS=network-service-1=http://network-service-1:8000 \
-e CLUSTER_STATE=new ts/network:<release-version>

And, clients would use ["http://network-service-1:3000"] to connect instead of 2379.

Changing Hostname ​

In the above commands, and in the client configuration files, the hostname "network-service" is used to identify the Network Service endpoints. As with the ports, this is also configurable in the same way as above.

docker run -d -p 23797:2379 --ip 10.0.0.17 --name my-network-service-1 \
--hostname my-network-service-1 --network test-tsf -e INSTANCE_NUM=1 \
-e INITIAL_HOST_URLS=my-network-service-1=http://my-network-service-1:2380 \
-e HOSTNAME=my-network-service -e CLUSTER_STATE=new \
ts/network:<release-version>

Note: If you are running the TSF without docker, all of the information above is the same, except instead of modifying the environment variables as we are doing above, you need to modify the corresponding fields in the start.sh script that you ran (See the start.sh script in the Network Service non docker tar for a complete list of all configurable properties).

<-Go back