I've created a simple Stateful Actor and a Web API (self hosted) and deployed it to Azure. It has worked and I can browse the nodes in the Service Fabric Explorer.
Azure gives me a url but when I add /api/values to the end (which works fine locally) it downloads a file called values and I can't open it as it is a binary file.
I want to call the web api from a Xamarin app (ie normal Rest api call) but if I can't call it via a browser I'm a bit stuck.
I would comment this on Stephen's answer, but I lack sufficient reputation.
To add a custom port to the Load Balancer after the service fabric cluster has been created you can (in the newer Azure portal):
Navigate to the load balancer resource for your service fabric cluster.
Under "Settings" find the "Load balancing rules" option.
This will have at least two rules, more if you did setup custom rules during the setup of the cluster.
Add a new rule.
Give it a name
'Port' is the external port you'd like to hit.
'BackendPort' is the port your service is configured to listen on.
The defaults on the other settings work in a pinch.
Note if you have multiple ports to enable, they each need their own rule.
I do know the above worked in my 'hello world' sandbox project.
I'm climbing the service fabric learning curve myself so I can't comment with authority on the other settings.
Have discovered what was missing.
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-cluster-creation-via-portal/
This link here walks through creating the Service Fabric app on Azure and in particular the field "Application input endpoints" needs to have the port you want to use. For the samples, they are mostly port 80 or 8081.
There is supposed to be a way to add these ports afterwards which I tried (and so did a Microsoft support engineer) and it did not seem to work. You are supposed to be able to add these ports to the Load Balancer associated with the Service Fabric App.
I recreated my Service Fabric app, exactly as I did before but this time filled in the ports I want to use in the Node Type section and now I can hit the webapi services I've deployed. This field can be left blank which is what I did first time round and was why I had issues.
Not really related to Service Fabric, it's just how you set up your HTTP response headers in Web API. Recommend tagging this with asp.net or asp.net-web-api for a more thorough answer.
Tutorials and technical resources around Azure Service Fabric Stateless Web API tend to be slightly disjointed, given that the platform and resources are still quite immature.
This Stateless Web API tutorial, at the time of writing, is very effective.
As prerequisite to the tutorial:
Update Visual Studio to the latest version (Extensions and Updates)
Update the Service Fabric SDK to the latest version (Web Platform Installer)
Explicitly specify the EndPoint Port attribute (defined in ServiceManifest.xml) when setting up your Azure Service Fabric Cluster Node Type parameters
Following these steps will successfully allow deployment to both local and remote clusters, and will expose your Web API endpoints for consumption.
Related
I am working on MS Teams development. I installed the MS Teams toolkit in VS Code, set up my subscription with Azure and sideloading is active in my tenant.
When I run the app, it tries to install ngrok. This step fails as my organization does not allow running ngrok or other words tunnelling from our company laptop. We can run this on a VM to go around this but VM is not always available.
I am looking for a resolution for below scenarios:
Is there a way to debug MS Teams application without ngrok?
If we need a https URL, is it possible to configure a web app to facilitate that?
I tried removing install ngrok step from: /.vscode/tasks.json, but there are subsequent steps it the file dependent on that
I've done quite a bit of research on this question myself as I'd been getting a lot of pushback from our IT department regarding the security threats that come with using a tunneling service like ngrok. It eventually led me to this video posted on the MS forums from a Microsoft engineer who explains it clearly.
What it comes down to is that the Teams client (browser/desktop) approaches webservices (configured in the manifest file) differently depending on the type of interaction. If you're testing configurable tabs, task modules or configuration pages, then you can easily route the app to those sites running on your localhost through the manifest. The Teams client will approach them directly. Problems start to arise when you want to debug what happens when you use a bot or message extension, outgoing webhook or MS Graph change notifications (just quoting the video here, there might be other scenarios).
Basically, what happens is that the Teams client goes through a Microsoft-hosted service first, called Microsoft Teams Services, which will then approach your bot framework cloud service (typically an Azure Bot resource). This then forwards any incoming messages to whatever endpoint you have configured. What happens in these separate stages isn't completely clear to me, but what I do know is that whatever is typed by the user in the Teams client is translated to a JSON structure that can be interpreted by your server-side bot code (for C# apps, this is typically your CloudAdapter-derived class working with your TeamsBot-derived class). These messages are then routed to the relevant TeamsBot class method based on properties in the JSON.
Now the issue that ngrok solves is that, when the Teams client goes onto the public internet to reach the MS Teams Services server and then the Azure Bot resource, it then needs a public address to route the traffic to. It doesn't know about your local network anymore. As ngrok sets up a TCP tunnel between their server and your local PC, it is able to route traffic coming to their server to your PC. The Azure Bot now has a public address to send the messages to.
To my knowledge, there is no way to circumvent this as long as Teams client inner workings always make it go outside of your local network. For chat scenarios, the Bot Framework Emulator might offer a solution for unit testing. As far as I can see it performs the translation of chat input to the JSON message model of the Bot Framework and routes it to a local address for your chatbot to process it. Unfortunately, this doesn't work for chat message extension type messages.
As for the question whether ngrok can be avoided, I think the answer is definitely yes but you would need an alternative. There's several alternatives around that you might be able to host yourself if you have the technical know-how. Depending on your IT department, being in control of the public-internet-facing server might be a more viable solution for them. Another option is to host ngrok on a VM or cloud machine with less access to your internal network's resources than your PC/laptop has and test the code there.
TL;DR: If the the feature you're testing is approached directly by the Teams client, you can enter localhost in the manifest and debug it. If you're testing a feature that the teams client approaches through Microsoft Teams Services and the Bot Framework, you need to find a way to expose your code to the public internet. You can use ngrok or host your own alternative depending on requirements.
use mkcert to generate a certificate for ex. localhost.test
add losthost.test to your host file
use https://localhost.test for debugging
In my current project. The previous dev has hosted an asp.net core 6 Web API as a window service using Kestrel on azure window virtual machine. I have to create a replica on the same API; please take a reference to the below links.
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/windows-service?view=aspnetcore-6.0&tabs=visual-studio
https://dev.to/sumitkharche/how-to-host-asp-net-core-3-1-web-applications-as-windows-service-52k2
I can create, build and install the API as a window service in an azure virtual machine and local machine as well, which also works in localhost: port.
Now I want to map that API to some domains like www.someting.com. But cannot find a way how to map a domain.
In this window service way, API hosting is pretty new to me, and there is also not enough documentation that can help me.
Please suggest.
Got some info from this related question: Using SignalR with Azure Service Fabric
Quote in quote from that comment history:
"After deploying this application, you can see that some calls to signalR fails and Some succeeds...."
Just want to know if anybody had similar implementation (signalR with Web API...).
And I don't want to set instance count 1 for the stateless Web API.
You can configure LoadBalancer that is used by Service Fabric to persist session. This will result in particular client ending up always in the same node.
You can do it by accessing LoadBalancer assigned to service fabric cluster in azure portal. Then go to "Load balancing rules", select rule that is responsible for signalR port and set "Session persistence" to "Client IP". This can also be done from PowerShell or ARM template.
I am kind of new to system architecture. That is, all of my web apps have been relatively flat...two machines at the most running web client and database.
I have been handed the following architecture:
1 VMware machine will run the web application, an MVC 3 app.
1 VMWare machine will host the SQL Server database
1 VMWare machine will host the services.
The machine I'm confused about is the last one. From what I understand, the services project contains references to three other projects: the model, where the entity framework edmx resides, the entities project, which contains T4 templates that use the entity edmx file as input, and the business project which is where the actual business rules are implemented and the meat of the CRUD actions take place.
From what I understand, the intent is to not run an IIS WCF web services interface, but to make calls to WCF services (like those hosted in the MMC services snap in) on the machine over the internet. There is a deployment project in the solution for the services project but I don't know if it's configured properly. I think the idea is to just run the installer on the services machine and it will work.
My specific question is if there are any important things that I need to keep in mind when implementing, configuring, and deploying these services?
I'm kind of new to all of this. I was under the impression that you had to make calls to WCF services via IIS hosted endpoints and that you couldn't (or it at least was inadvisable) to make what amounts to RPC-like calls to machines over the internet.
Since you are new to WCF services, I suggest reading this MSDN article on Hosting and Consuming WCF services.
From what you describe, it looks like you are using Windows Service as a host for your WCF service.
The most common choice for a host is IIS because of its extensive features including self-starting services, ease of deployment, load balancing and so on.
Windows Service is a valid host, provided you can justify the question 'Why not IIS?'. Maybe, you need full control over the activation and lifetime of your WCF service. Not sure.
p.s. Ensure the account that your Windows Service runs under, has the minimum privileges.
This question has probably less to do with actual programming and more to do with environment setup.
I'm developing an application for a Windows CE device, which will use a service hosted in Microsoft Azure. Obviously, this is all under development, and the service itself has not yet been uploaded to Azure. So I'm using the emulators provided by MS to deploy the service locally. Also, I don't think uploading the service to Azure just to debug it is a good idea, as that could net us a bill for Azure we don't yet want to pay.
Also, please note, I'm using VS2008 for the Windows CE project and VS2010 for the Azure project (thank you MS for dropping support for mobile devices -_-).
The problem is, the service seems to be accessible only via 127.0.0.1 or localhost, and if I physically connect a Windows CE device or use an emulated one, it becomes a new entity on the network, and cannot access that service any more.
How can I debug my Window CE application and have it see the service, whilst still being able to debug the service itself?
You are correct, the development fabric (the compute emulator that allows you to build an azure application and debug it locally) is only meant for local development. There are some hacks that allow you to get around that, but I wouldn't recommend it.
My recommendation would be to spin up the service in a more traditional hosting environment, at least in these early stages. You can define it as a web app just as you always would have, and get it functioning. Then, when you know its mostly complete, create a cloud service project and do an add existing to bring your web app into the cloud service solution. Once in, its a simple matter to add the web app as a web role.
From there, you can complete testing of the service in both the local and hosted azure environments as needed. This allows you to minimize your development costs while still leveraging the power of the cloud. As an upside, you also have done most of the basic work to ensure your service is compatible with multiple deployment scenarios giving you a greater degree of choice for its final production state.
OK, I don't know if this was intentional, or if I found one of the mentioned hacks, but I saw that IIS hosts the Azure site I created on port 5100, and the binding for this site is *, so it accepts all connections.
Using this I could access the service from my emulator, and I could still debug all Azure related stuff.