Azure Service Fabric Windows Containers - Inter Container Communication

0
votes

I have created an Azure Service Fabric Cluster using "Windows 2016 DataCenter with Containers" OS and enabled Reverse Proxy listening on Port 80 on the cluster. We intend to deploy our legacy ASP.NET MVC & WCF applications on this cluster.

In our existing deployment model we have services co-located on same host communicating to each other because of chatty communication and low latency requirements. Is it possible for apps hosted in windows container to communicate with other windows container apps on the same Node? Basically I would like to have Node affinity between two windows container apps on the same Service Fabric Node.

I tried it with a sample application and it looks like the only option is to use Private IP of container which is getting dynamically assigned. Is it possible to pass --ip-address parameter while instantiating containers on Service Fabric cluster?

[Update: 04/05/2017]

Service Fabric Cluster Version: 5.5.219.0

Total NodeTypes: 1

Total Nodes: 3

Both containers are deployed on all three nodes. Azure internet load balancer is used to expose Service Fabric Reverse Proxy. All services are accessing internally as well as externally via reverse proxy.

Gaurav

2
azureazure-service-fabricservice-fabric-statefulwindows-containerservice-fabric-actor

2 Answers

1
votes

There is what you can do now in the v5.5 release and what is coming in the next release.

For v5.5 Release This GitHub repo https://github.com/Azure-Samples/service-fabric-dotnet-containers shows how to communicate between Windows Containers where you can map a host port to the private port on the container using PortBinding policy in the Application manifest.

You can then communicate either called the Naming Service over REST (this is what this sample does) or as you say and is easier, with the ReverseProxy which has a URL format. If both containers are deployed on the same machine then the communication is via the local ReverseProxy and you get local calls between the containers. See https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reverseproxy. As Mikkel points out, you have to tell Service Fabric that you want the containers on the same VM, through placement constraints.

Note: for the GitHub sample above to work on your local machine you need to update the local dev manifest ClusterManifestTemplate.xml in the C:\Program Files\Microsoft SDKs\Service Fabric\ClusterSetup\NonSecure\FiveNode folder and change the IPAddressOrFQDN attribute from "localhost" to the actual IP of the machine it is running on. This is due to a Windows Server Network bug, documentated in the git repo above. i.e

<Node NodeName="_Node_0" IPAddressOrFQDN="ComputerFullName" IsSeedNode="true"  NodeTypeRef="NodeType0" FaultDomain="fd:/0" UpgradeDomain="0" />

becomes

<Node NodeName="_Node_0" IPAddressOrFQDN="192.1.3.50" IsSeedNode="true"  NodeTypeRef="NodeType0" FaultDomain="fd:/0" UpgradeDomain="0" />

Coming for v5.6 Release In the next release we have added a DNS server layered on top of the Naming Service, so that you can use DNS names in place of fabric:/ names used by the reverse proxy. This means that within the Service Fabric cluster you can call between the containers with http://[domainname]/path calls instead. Same rules apply for the calls between local containers on the same machine as for the reverse proxy.