Address of REST API hosted on service fabric - azure

Suppose I have a stateless service running in service fabric and I have 5 nodes in my service fabric cluster. Now since each node in the cluster has an instance of stateless service, this means there will be 5 instances of my stateless service on 5 nodes.
But since each node has a different IP address and port number where it can host the service, there can be multiple different endpoint addresses at which my service is hosted.
Now my service is actually a REST API providing some crud functionalities.
Now I have set the port no to be 8080 in servicemanifest.xml file.
Now my question is, does setting port no specifically in servicemanifest.xml disable dynamically selection of port? Will this make every node on cluster use same port i.e. 8080 in endpoint address of the service?
Another question is that if the service is shifted to some another machine and deployed there and having 8080 as port can cause conflict if some other service on its cluster is already using the same port i.e. 8080?
How will we let the client know at which endpoint address my API is hosted?

Does setting port no specifically in servicemanifest.xml disable
dynamically selection of port?
Yes it does
Will this make every node on cluster use same port i.e. 8080 in
endpoint address of the service?
Yes, if you set instance count to -1 all nodes will run the service at that port. You can call them by using the external load balancer (external to service) or directly on the node IP / localhost (service to service).
If the service is shifted to some another machine and deployed there
and having 8080 as port can cause conflict if some other service on
its cluster is already using the same port i.e. 8080?
There will never be more that 1 instance of 1 stateless service on 1 node, within the same application. SF takes care of this. However, if another service is using the port, it cannot be used by another service unless you use a server that supports port sharing like http.sys.
To deal with port conflicts, have a look at the built-in reverse proxy or Traefik. Using a reverse proxy takes away the pain of managing ports, and allows you to call your service by its application and service name.

Related

Azure Application Gateway - How to control traffic for different application

I am creating an application gateway and that will be a single point of entry for my multi tenant application. That means I will have multiple application request on this application gateway and then I need to redirect to backend pool. If I will have one application A deployed in app service A then it will listen at port 80 of app gateway. Similar if I have another application, I can expose it using similar way on different port. How can I achieve it. I tried creating multiple rules but not working.
If I read your question correctly, you want multiple app services, each on a potentially different port, to be served by a single application gateway. And it sounds possible you might want to make requests to that application gateway on different port. Sound right?
If so, then what you need to do is something along these lines:
Set up a backend pool for each app service.
Set up an HTTP setting for each backend pool, specifying port, session affinity, protocol, etc. - This will be the port that your App Service takes requests on.
Create a front end IP configuration to expose a public and/or private IP address
Create a listener for each app service, and port that you want to support. This will be the port you want the client requests to use. You can do two listeners per service to allow 80 & 443 (HTTP & HTTPS) traffic, for example.
Create a rule to connect each listener to its backend pool and HTTP setting combination
Optional - set up health probes that target monitoring endpoints based on an URL and a specific HTTP setting entry

How to expose web app for container on two different ports in azure?

Our web app runs on two ports azure web app exposes port 80 by default which we have used for part 1 but for part two we need another port how can we expose it?
Our web app runs perfectly on local.
Our web app runs perfectly on container instance on two ports (there is an option in Azure for multiple ports while creating the container instance).
Update:
I contacted the Azure support team for this and they replied:
"
Web App for Containers currently allows you to expose only one port to the outside world. That means that your container can only listen for HTTP requests on a single port. Some apps need multiple ports. For example, you might have one port that is used for requests into the app and a separate port that is used for a dashboard or admin portal. As of today, that configuration isn't possible in Web App for Containers.
We will attempt to detect which port to bind to your container, but you can also use the WEBSITES_PORT app setting and configure it with a value for the port you want to bind to your container.
So, I'm sorry but you cannot use 2 ports for the same web app."
For your issue, you should know there are differences between Azure Web App and Azure Container Instance.
In Azure Web App, you just can use only two ports: 80 and 443. And they are exposed in default. You just need to listen to one of them or both in the container. But in Azure Container Instance, you can expose all the ports that you use in the container as you wish.
So for Web app for Container, if the two ports are not 80 and 443, then you cannot expose them.
You have to use a virtual machine to accomplish this on azure as they don't allow port other than 80 and 443.
I have been in the same situation and the only solution I could find is to use a virtual machine.
So I created a virtual machine with inbound port accepting traffic from 2 ports and it was working fine.
I also contacted with azure support for this they also suggested to use a virtual machine.

Service Fabric Cluster Custom endpoints vs Application start and end ports

This screenshot was taken while creating a cluster on the Azure portal. As given in the picture below,
what is the difference between Custom endpoint and application
start-end port range?
Why is one called an endpoint and the other called a port?
The custom endpoints help says "Custom endpoints allow for connections to applications running on this node type. Enter endpoints separated by a comma.".
In the documentation here and here it is explained in a very clear way,
Custom endpoints: This field allows you to enter a comma-separated list of ports that you want to expose through the Azure Load Balancer to the public Internet for your applications. For example, if you plan to deploy a web application to your cluster, enter "80" here to allow traffic on port 80 into your cluster.
Application Ports (Start|End): are the ports that are used by the Service Fabric applications. The application port range should be large enough to cover the endpoint requirement of your applications. This range should be exclusive from the dynamic port range on the machine, that is, the EphemeralPorts range as set in the configuration. Service Fabric uses these ports whenever new ports are required and takes care of opening the firewall for these ports.
In Summary:
Custom endpoints are ports opened in the Load Balancer to enable external access.
Application Ports is a range of reserved ports to be opened in the nodes and assigned to services when using dynamic allocated ports, but not externally accessible.

How to start self-hosted OWIN Web API listening to a range of ports?

I'm running an Azure Worker Role that with self-hosted OWIN Web API
Currently, the host is initialized with a single URL like so:
var options = new StartOptions(endpoint);
_app = WebApp.Start<Startup>(options);
The endpoint has a port hard-coded in it. I'd like to have it listen on a range of ports.
My real issue is as follows:
My Web API host is not getting round-robined by Azure's load balancer. I believe this is because the default ("none") affinity setting uses SourceIP, Source Port, Target IP, Target Port, Protocol type to perform its load balancing. However, the clients to my Web API (in the thousands) are always the same clients - they connect every minute to perform some operations. Thus, these client's ports and IP's don't change. My listening port and IP do not change since the host is hard-coded to a port. All of the requests from these clients are getting round-robined to the same instance all the time. I've verified this over and over and over again. My first worker role instance gets all the traffic, as soon as 2nd instance is rebooted. 2nd instance never kicks in.
I would like to try to have my OWIN hosted Web API listen on a range of ports. Is this the right approach? If so, how can this be done?

Endpoint configuration for Service Fabric

I deployed an app on Service Fabric and there's an HTTP listener spawned inside. How can I configure the listening URL in relation to app/cluster?
More precisely, is there any way to build this URL inside the app by retrieving some environment/role parameter ?
Suppose my cluster is called "test", then it will be available at: test.northeurope.cloudapp.azure.com. If I have an app called "Sample" for which I configured an endpoint called "SampleTypeEndpoint" inside ServiceManifest.xml, what would be the complete URL my app would listen to?
The endpoints you configure in ServiceManifest.xml right now fulfill two purposes:
Allow Service Fabric to provide a unique port from an application port range, if you don't need a well-known port.
When opening a web server that uses http.sys, allow Service Fabric to set up URL ACLs for a random port or a well-known port (80, 443, etc) and certificate ACLs for HTTPS.
That's basically it. The actual address on which you open a listener is up to you to determine. Typically, you open a listener on the node IP and use a NAT for ingress traffic on a domain name. In Azure, the NAT is the Azure Load Balancer which is automatically configured to accept traffic on your cluster's VIP as well as the .region.cloudapp.azure.com domain.
Here's a more thorough overview of how this works on Service Fabric cluster in Azure: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-connect-and-communicate-with-services/

Resources