Docker Blog Series Part 6 – How to use Service Fabric Reverse Proxy for container services

Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices and containers. Service Fabric also addresses the significant challenges in developing and managing cloud native applications. It is also an orchestrator of services across a cluster of machines and it is continuing to invest heavily in container orchestration and management. In this blog post, we will check out how to use Service Fabric Reverse Proxy for container services.

Container services are encapsulated, individually deployable components that run as isolated instances on the same kernel to take advantage of virtualization that an operating system provides. Thus, each application and its runtime, dependencies, and system libraries run inside a container with full, private access to the container's own isolated view of operating system constructs. Microservices running inside containers in Service Fabric run on a subset of nodes. Service Fabric orchestration is responsible for service discovery, resolution and routing. As a result, the endpoint for the services running inside the container can change dynamically.

If the container services are deployed in Azure Service Fabric, we could use Azure Load Balancer to reach the services from outside. To make these services/endpoints accessible to external clients, we configure the Load Balancer to forward traffic to each port that the service uses. This approach works but requires each service to be configured on Load Balancer.

Other approach could be to use Reverse proxy. Instead of configuring ports of individual service in Load Balancer, we configure the port of the Reverse proxy.  Following is the specific URI format, Reverse proxy uses for service discovery.

http(s)://<Cluster FQDN | internal IP>:Port/<MyApp>/<MyService>

One of the challenges when using Reverse proxy approaches is when you configure Reverse proxy port in the Load Balancer, all the services in the cluster that expose an HTTP endpoint are addressable from outside the cluster. Due to this reason, we recommend to use SF Reverse proxy for internal services.

But if you have mix of microservices which includes internal and external services, we would have to expose the reverse proxy port in the load balancer to expose external services. But that would implicitly also expose our internal services which we dont want to. So a workaround for now would be to use the below port configuration in the Docker compose file. We will be explicitly dropping the HTTP prefix from the ports. This will ensure that those container services which have this configuration will not be exposed. This will make sure that the internal container service with this configuration will not be exposed through the Load Balancer.

You can check out my previous blog below to see how to do Docker – Compose deployment for Service Fabric.

As you saw above, you can leverage Azure Service Fabric Reverse proxy to expose different types of services. To read more about Azure Service Fabric proxy check out the following links.

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reverseproxy https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reverse-proxy-diagnostics https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reverseproxy-configure-secure-communication