When using Service Fabric Reliable Actors, is it possible for an actor client in one system (for example, on a local deployment) to communicate with an actor server in a different system (for example, on an Azure cloud deployment)? If so, how can this be configured? If not, what Azure functionality could I use to achieve this instead? The linked overview gives code examples for the client and server, but not any of the necessary configuration steps.
For communicating from a client to an actor running in a cluster, you need to have direct connectivity today - for example the Azure Load Balancer can't be in the way. To configure which cluster to connect to, create a ServicePartitionResolver with the FabricClientSettings, SecurityCredentials, and Endpoints matching the cluster, and then use ServicePartitionResolver.SetDefault (https://msdn.microsoft.com/en-us/library/microsoft.servicefabric.services.client.servicepartitionresolver.aspx)
Related
Azure app service A needs to call Azure app service B using System.Net.WebClient class.
Access to app service B is restricted to company's IP range only, through
Azure > app service > Networking > Access Restrictions
Tried adding <public ip of app service A>/32 to B's allow list but that did not work - System.Net.WebClient.DownloadData threw a 403 Forbidden exception.
What else can I try?
It looks like it's impossible to restrict the Public IP address in Access Restrictions of the app service B since both app services in the same app service plan.
Azure App Service is a multi-tenant service, except for App Service Environments. Apps that are not in an App Service environment (not in the Isolated tier) share network infrastructure with other apps. If you restrict the inbound or possible outbound Public IP address of web app service, it looks like restrict the access from itself. Even this, per my understanding, it should be limit the private IP address of the instance in the web app service over the Azure backbone network. However, We could not know the private IP address of each app service.
You can use Azure service plan with isolated price tier but its high cost. So I suggest recreating the web app service A in a different service plan with a different region. Then restrict the possible outbound IP addresses in web app service A.
Additionally, you can get a further understanding of the Azure app service plan in this blog.
I understand what you are trying to achieve and I will suggest you utilize the Azure traffic manager.
Azure Traffic Manager is a DNS-based traffic load balancer. This service allows you to distribute traffic to your public-facing applications across the global Azure regions. Traffic Manager also provides your public endpoints with high availability and quick responsiveness.
Traffic Manager uses DNS to direct the client requests to the appropriate service endpoint based on a traffic-routing method. The traffic manager also provides health monitoring for every endpoint. The endpoint can be any Internet-facing service hosted inside or outside of Azure. Traffic Manager provides a range of traffic-routing methods and endpoint monitoring options to suit different application needs and automatic failover models. Traffic Manager is resilient to failure, including the failure of an entire Azure region.
Please visit the link below for more information
https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview
I faced the same problem and found a solution.
Use NAT Gateway to fix the outbound IP address on Service A
https://learn.microsoft.com/en-us/azure/app-service/networking/nat-gateway-integration
Route all trafic and regional virtual network integration are also needed on Service A (explained in the link above)
Allow access the NAT gateway on Service B by specifying the IP address of the NAT gateway
This method can also disable public access to Service B.
Pivate endpoints can also be used in this scenario, but it disables the SCM(Kudu) either which is used for deployments from Azure Pipelines etc.
I have an ASP.NET MVC application hosted in Azure.
This application is complemented with a desktop application that also has WCF services for communicating with III party interfaces. WCF are hosted locally.
There are thousands of clients using the desktop application at different geographical locations.
Till now, every desktop application used to talk to web app using api with the help of WCF.
This was limited to on demand from the desktop application.
Whenever desktop application feels the need to talk to web app, it used the way of web api from WCF.
Now, what I want is:-
To access the different desktop applications(typically called sites), from azure depending upon the need.
This is required on account of an online ordering system that is through web app/mobile app.
I do not want to keep polling from desktop application to know about if any new order is there for this site.
I feel it would be better if I can play from other side.
Also, keeping in mind that IP of sites will not be fixed. There may be issue with firewall. NAT may translate resource identifier differently.
Can service bus in azure may be of any help, but what confuses me is that every desktop application is having its own WCF service and order should reach the respective site only.
Any type of ideas on this would be appreciated.
According to your description, Service Bus messaging is a perfect way to achieve this.
More information about Service Bus Messaging, we can refer to: Service Bus queues, topics, and subscriptions
In addition, We can also use RabbitMQ or ZeroMQ which is similar with Service Bus Messaging because both of them are free. You can choose an best way to realize your requirements.
About differences between ZeroMQ and RabbitMQ:
ZeroMQ has better performance, but it is built in the case of allowing message data loss to apply to high throughput / low latency applications. Unlike ZeroMQ, RabbitMQ fully implements the AMQP protocol, which is similar to mailbox services, supporting message persistence, transaction, congestion control, load balancing and so on, making RabbitMQ have a more extensive application scenario.
Function RabbitMQ ZeroMQ
Message persistence Support Not Support
Transaction Support Not Support
performance Low High
stability High Low
Support for AMQP protocol Support Not Support
Application scenario Data loss is not allowed High throughput
More information about RabbitMQ and ZeroMQ, we can refer to:
RabbitMQ
ZeroMQ
If you are able to modify the desktop applications, implementing a websockets connection with SignalR might be worth a look. The desktop applications sign up with a SignalR hub you provide.
You can then push data to the clients from, for example an ASP.NET MVC app. It works very reliable and handles lots of connections well. It is typically used for realtime web communication but might be useful in your case, too.
The downside is probably, that the desktop app needs to initially sign up to a hub to receive push messages.
I have a console app that calls a WCF service. This WCF service is on a Azure Cloud Service VM, and the WCF service is only accessible internally (using Windows creds). The Cloud Services VM has been added to our domain.
I have deployed this console app as an Azure webjob. It is living in an Azure App Services Web App by itself - there is no related web app.
When I run the webjob, I get a "System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at..." exception. Which seems to be expected since the Azure App Services Web App is not on the domain or talking to internal DNS.
My question, can/how can I add the VM that is backing the Azure App Services Wep App to our domain? And if not, what options are there for getting this webjob to talk to internal DNS?
In general when trying to connect with on-premise resources or other private networks from within Azure, there are a few options that you can check out:
Option #1: App Service Environents: https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-intro/
App Service Environments are isolated to running only a single customer's applications, and are always deployed into a virtual network. Customers have fine-grained control over both inbound and outbound application network traffic, and applications can establish high-speed secure connections over virtual networks to on-premises corporate resources.
This will give you the most flexibility because of the virtual network, but at the highest cost as it is a premium offering.
Option #2: App Service Hybrid Connections: https://azure.microsoft.com/en-us/documentation/articles/integration-hybrid-connection-overview/
Hybrid Connections are a feature of Azure BizTalk Services. Hybrid Connections provide an easy and convenient way to connect the Web Apps feature in Azure App Service (formerly Websites) and the Mobile Apps feature in Azure App Service (formerly Mobile Services) to on-premises resources behind your firewall.
I'm less familiar with this option, but it's design to work with App Service for these types of scenarios. It may be difficult to use if you require access to an internal DNS or domain controller, however.
Option #3: Service Bus Relay: https://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-relay/
The Service Bus relay service enables you to build hybrid applications that run in both an Azure datacenter and your own on-premises enterprise environment. The Service Bus relay facilitates this by enabling you to securely expose Windows Communication Foundation (WCF) services that reside within a corporate enterprise network to the public cloud, without having to open a firewall connection, or require intrusive changes to a corporate network infrastructure.
This option has been around for a while and is especially designed for connecting to WCF services. It's not specific to Azure App Service (as you can probably tell from the article) but it might still be a good, fairly light-weight fit for your scenario. However, it also will not help you with DNS and on-premise domain controller.
I'm running an Azure webjob alongside an Azure webapp. The job runs periodically and the result of the job is needed in the webapp. How do I get the result there?
I tried with a WCF netNamedPipeBinding but since there are no startup tasks for Azure webapps I cannot add a net.pipe binding to the IIS website nor can I enable the net.pipe protocol.
I have it working now with a basicHttpBinding but this binding is exposed to the entire internet which I absolutely do not want. I simply want machine-local communication between a webjob and webapp running on the same machine.
CORRECTION: I thought I had it working on Azure but that is not the case. When running on Azure I get an error from the webjob: An attempt was made to access a socket in a way forbidden by its access permissions 127.0.0.1:80 (using basicHttpBinding). Probably the webapp has an internal port number I don't know.
You have a few options:
Use the file system to pass messages
Use Azure Storage Queues to pass messages between the two
Use Azure Service Bus Queue to pass messages
Use any shared storage (database, Azure Storage, etc) to pass messages
The benefit of all these approaches is that it makes your message passing async and thus more resilient to one of the two services (web app or web job) going down for some time.
You can use the file-system to communicate between the WebJob and the Websites.
It is shared between them and between all of your instances.
Simply write a file from the WebJob and use a file system watcher in your webapp to recognize when a file is created or changed.
Note you cannot communicate through localhost in Azure Websites (or WebJobs) and cannot listen on a port that is not 80/443.
You can use azure service bus queue, then point your service (web app) to consume messages from queue.
The closest answer is to set WEBSITE_DISABLE_SCM_SEPARATION=true in App Settings. This will enable WebApp and SCM processes work in same sandbox. Unfortunately this option is deprecated by Azure and no longer supported. Thanks all for attempting the answer. More information can be found here.
I need to build a system that is similar to a pub/sub system. It is composed of multiple sub-systems or services running in separate executables or as a Windows Services.
The sub-systems are:
The pub/sub service
A pub/sub service managing communications between the internal sub-systems and the users.
A user can have multiple channels open (A web page connected to a SignalR service, a mobile device connected to a duplex WCF service, etc.).
The service should manage all the channels of an user and be able to send information to them on demand based on topics or specific users.
The service must support multiple transports like SignalR, WCF, or others ...
Worker services
A worker that runs as a Windows Service and sends information to the users using the pub/sub service.
The SignalR and WCF host
The SignalR service and WCF service will be hosted on IIS
My questions are
As the sub-systems run in separate processes, how do I communicate between the pub/sub service and the other sub-systems like (the workers and IIS). The communication must be really fast. Do I use named-pipes, is it fast enough ?
An example; The worker tells the pub/sub system to send a message to a user, the pub/sub systems checks the channels opened for the user (let's say a SignalR channel), then in turn it must notify the SignalR service running in IIS to send the message to the user's browser.
Do you know of implementations of similar systems ?
Observations
I cannot use third-party service-bus services (Azure ..). And even with that .. I can't see a solutions to the problems above.
The service must be very scalable and high-demand proof.
If the question is how to bridge SignalR with other transports there are several solutions.
On a single server you could just connect them up with the Reactive framework's own pubsub mechanism which is neatly encapsulated in the Subject class.
If you need to scale out to multiple servers you'll want to use an existing service bus or perhaps roll your own simple one using SQL server and a SqlDependency.
You could also use SignalR as a client on one server communicating with the other servers to copy messages between them.
I recommend you look into some of the existing Service Bus technologies for .NET.
There is an article which clearly explains the possible mechanism of how to incorporate a pub/sub design pattern in your .NET application. The answer lies in using a .NET In-Memory distributed cache and use its clustering capabilities as a publish subscribe medium. Since it's clustered therefore you won't have to worry about down-times as well.
Basically you'll be using the Application Initiated Custom Events
Register your events
public void OnApplicationEvent(object notifId, object data)
{
...
}
_cache.CustomEvent += new CustomEventCallback(this.OnApplicationEvent);
And fire those events whenever you need to
_cache.RaiseCustomEvent("NotificationID", DateTime.Now);
Pub/Sub design pattern in a .NET distributed cache
Full disclosure: I work for Alachisoft