TCP Routing Comes to Cloud Foundry
TCP Routing Comes to Cloud Foundry
It was announced on the cf-dev mailing list and demoed in CF Summit 2016... yes, TCP Routing is now available on Cloud Foundry. Read on and we'll discuss all the potential perks this brings.
Join the DZone community and get the full member experience.Join For Free
Insight into the right steps to take for migrating workloads to public cloud and successfully reducing cost as a result. Read the Guide.
It was announced on the cf-dev mailing list and demoed in CF Summit 2016... yes, TCP Routing is now available on Cloud Foundry. It will allow developers to bring non-http work loads to Cloud Foundry. It will open up the platform and its benefits to all kind of new applications!
I would like to give readers a quick tour of the TCP Routing feature in Cloud Foundry. TCP routes in Cloud Foundry are based on reserving an external/frontend port of a TCP router group for an application. Any traffic coming in on that port will be forwarded to one or more instances of that application (using a round-robin load balancing policy). TCP router groups are a collection of one or more TCP routers (HAProxy) that are identically configured. This is done for the high availability of the TCP routing layer. Also, this concept of router groups allows for adding multiple router groups of different types to allow different routing functionality to be added to Cloud Foundry in the future. Currently, there is only one router group of the type TCP. But, this could be easily changed to add multiple TCP router groups thereby allowing different applications to reserve the same port on different router groups.
At Cloud Foundry, we strive to keep the developer experience simple and similar to existing UX. With that as our guiding principle, we developed TCP routing for user experience. So, let's take a look at the developer experience of TCP routing.
To create a TCP route, you should first create a TCP domain. Creation of a TCP domain is very similar to HTTP domains, you just need to specify the router group when creating the TCP domain as follows:
cf create-shared-domain tcp.example.com --router-group default-tcp
You can see that while creating a TCP shared domain you just need to specify the TCP router group. You can get all the router groups available in your deployment by running following command:
cf router-groups Getting router groups as admin ... name type default-tcp tcp
There is only one router group available today with routing deployment and that is named default-tcp.
Now you are ready to create and map TCP routes to your application. Of course, here we are assuming that DNS entries for the above-created TCP domain will resolve to a load balancer in front of TCP router groups or if TCP routers have public IP addresses then it will resolve to TCP routers. This has to be done by the operator/administrator of your Cloud Foundry deployment.
Now let's push an application, create a TCP route, and map it to the application... and let's do it all in one command... yes one command!
cf push mqttbroker --docker-image toke/mosquitto -d tcp.example.com --random-route
There are many things going on here. Let's break it down:
- A Docker image toke/mosquitto is being downloaded from Docker hub.
- It is staged (a droplet is created).
- A random TCP route is created. This is achieved by specifying TCP domain through -d tcp.example.com option and --random-route option. As explained above a TCP route consists of reserving an external port on the TCP router group, by specifying random-route option we let the system choose the free port from available ports on router-group and reserve that port for creating a TCP route.
- This TCP route is mapped to the application mqttbroker.
- Staged application is now deployed and run.
- Application is now ready to receive the traffic on the TCP route that is mapped to the application.
With the above command, we have pushed an MQTT broker (mosquitto) as CF App! We can now give the TCP route mapped to this MQTT broker to publishers and subscribers to publish and subscribe MQTT messages.
Like HTTP routes, you can create and map a TCP route independent of cf push. This is how you can do it:
cf create-route SPACE DOMAIN (--port PORT | --random-port) e.g. cf create-route s1 tcp.example.com --port 8883 e.g. cf create-route s1 tcp.example.com --random-port
The above command will allow you to create a TCP route. Notice that it allows you to let the system choose a port for you (--random-port) or you can specify the port of your choice (--port 8883). Of course, if you specify the port of your choice and if it is unavailable then route creation will fail and you will get an error message indicating that port is already reserved and not available. Once the TCP route is created you can map it to an application, again very similar to how you will map HTTP routes. Note that if the TCP route being mapped is not present then it will be created (again very much like HTTP routes), so you don't need to create a TCP route beforehand if you have the application to bind to. The only time you will need to create a TCP route is if you need to reserve a port and use it later to bind to an app.
cf map-route APP_NAME DOMAIN (--port PORT | --random-port) e.g. cf map-route myapp tcp.example.com --port 8883 e.g. cf map-route myapp tcp.example.com --random-port
This is command will map the TCP route to an app and create the TCP route if one doesn't exist.
That's it... your apps that need non-HTTP protocol support can now happily run on Cloud Foundry. Now all the great benefits that web apps got from Cloud Foundry are available to non-HTTP apps as well.
As always, we love feedback—please share your experiences in the comments!
Opinions expressed by DZone contributors are their own.