I have an ASP.NET Core 3.1 application running on a docker container in kubernetes. It consists of two services which send data from the one to the other via Azure Service Bus.
Hot to check on the Service Bus a readiness probe?
I Was trying to find an API on https://learn.microsoft.com/en-us/dotnet/api/microsoft.servicebus?view=azure-dotnet and I did not found any fitting function.
Do you use it? Is it necessary?
There are some endpoints that can be used but are protected behind system/admin keys. But it seems that there is an issue already filed to expose endpoints for Kubernetes You can follow the thread for updates or you can also follow up on this thread.
Related
I have asp.net core REST API interacting with Azure Queue with input data. I have a Azure Function App with trigger on Azure Queue service. Whenever any entry that happens at the Azure Queue level, Azure Function app gets triggered which executes certain business functionality and returns the response.
After going the article : https://endjin.com/blog/2022/09/bye-bye-azure-functions-hello-azure-container-apps-part-2-migrating-from-azure-functions-to-asp-net-core , I am planning to migrate the Azure Function app to Azure Container app with gRPC based services.
I tried to explore few details https://learn.microsoft.com/en-us/azure/container-apps/samples but did not come across any good reference.
Here my challenge is how to trigger the gRPC C# services whenever any entry is added to the Azure Service Queue.
Can anyone help me here by providing some guidance?
Container Apps are built on top of KEDA, so any auto-scalers it supports (storage queues is one of them), you can use to scale your app but you lose bindings when moving away from Azure Functions.
Since bindings are not present anymore, you must use the Azure Storage Queues SDK directly in your code. So, you would call your gRPC service as you dequeue messages.
Container Apps are useful for HTTP triggered functions since you can use HTTP Frameworks like ASP.NET and leverage their complete feature set like built-in authentication, middleware, etc.
For other bindings, unless you have lots of custom code that need to run beyond the limits of Azure Functions or are perhaps trying to convert your existing non-Azure Function app to run serverless, you are likely better off using Azure Functions since most of the service-level binding code is taken care, reducing effort to maintain.
Obviously, if there is no binding support for your auxiliary service like IBM MQ or ActiveMQ, then you would want to use Container Apps instead.
I want to build a Windows Service project that, besides other responsibilities, based on the configuration can dynamically start and stop a self-hosted ASP.NET Core API instance.
All of the current examples where we host ASP.NET Core in Windows service rely on a developer to create an ASP.NET Core API project, and then, Nuget in the package Microsoft.Extensions.Hosting.WindowsServices and call
Host.CreateDefaultBuilder(args).UseWindowsService()
as a part of the builder/build process.
However I would like to have a completely separated API that is either gets started or not based on the configuration. Thus, it's "plumbing" code for setting up the hostin should happen in an ExecuteAsync method of the BackgroundService, not be hard-coded along with the startup code.
Basically, I want "A service that hosts many background services, including the API one's", not "An API project that supports hosting in Windows service".
I am failing to find a good example on how this is achieved, e.g. "web stuff" is instantiated from a BackgroundService, not from app root code in Program.cs.
Any hint on how to achieve this would be appreciated.
I may be wrong in my ideas but here the plan.
I have an app who has 2 services, with a client who consume these services.
Because I want them to be micro-services, I've planed to build an API Gateway to have only one access point and redirect requests.
I've found some docs for building this and I stumbled into Ocelot to do the job, it seems to fully answer my ideas.
But here the problem, if I want to run multiple instances of my services, I need a service discovery, that Ocelot can do with Consul, but it need in the service to register the service discovery provider in his configuration.
What I wanted to do is to discover services dynamically without configuring a service discovery provider in the services. Is it possible ?
Plus, if I want to run an another instance of the Gateway, the services will not register on this new instance.
Any hints or better solution ?
I currently use Azure Application Insights for logging on all of my Web API and MVC applications. Obviously the majority of this logging is automatic which is great. For events that I manually want to capture I have implemented a "LoggingUtility" which has methods like "LogError" and "LogInformation" that simply call Trace.TraceError and Trace.TraceInformation (the thinking is that the implementation of logging could be changed in one place in the future). The Trace is then captured by Application Insights.
I have started to develop some Stateful Services in Azure Service Fabric and cannot seem to find a way to use Application Insights. I have stumbled upon several articles pointing me towards a NuGet package that was in prerelease but has now been removed (https://www.nuget.org/packages/Microsoft.ServiceFabric.Telemetry.ApplicationInsights/).
Of course the Service Fabric templates generate the "ServiceEventSource" but firstly I cannot see how this would be useful for Application Insights and ideally I want all logging to be done through my "LoggingUtility" class.
Is it possible to integrate Application Insights into Service Fabric? If so, can I simply continue using Trace (via my "LoggingUtility" class)?
You have two options:
1. Using the Application Insights SDK in your LoggingUtility class to send information directly to AI
2. Using Windows Azure Diagnostics (WAD) to forward Eventsource traces to AI, using the provided EventSource class in the SF project templates. That class you can modify to be your LoggingUtility class implementation.
Considering that you are running your SF cluster in Azure, the second approach is the current recommendation, as Service Fabric system service events are also using Event Tracing.
For configuring Azure Diagnostics to AI, follow the steps outlined in this article: https://azure.microsoft.com/en-us/blog/azure-diagnostics-integration-with-application-insights/
Be aware this article targets Cloud Services and VMs, but just use the VM Scale Set for configuring Azure Diagnostics in stead of a VM. That should work.
The NuGet package is no longer supported: https://social.msdn.microsoft.com/Forums/en-US/f0f1ad78-4d83-48e5-b1da-4a9f0eddb9b2/application-insights-for-service-fabric?forum=AzureServiceFabric
We used the new Microsoft.Extentions.Logging and wrote a insights logger - it gets the service fabric messages via Trace we also pulled out all the ETW stuff it doesnt add much .
Is there a way to subscribe to an actor event from ASP.NET 5 - based service? I saw similar feature in service-fabric-dotnet-data-streaming-websockets sample, but the sample uses OWIN-based web service and it has PublicGateway class derived from StatelessService where one can hook to the service Task RunAsync override. I haven't found any StatelessService-derived type in the ASP.NET 5 - based project code. Seems like it's auto-generated, if to look into the project ServiceManifest.XML?
The goal I'm trying to achieve is the same with the sample - I want to subscribe to events from actor service to publish them through SignalR hub.
The difference you're seeing is that the OWIN (Katana, to be precise) sample is a Service Fabric Reliable Service - a service written on the Service Fabric API - that uses Katana to open an HTTP listener. The ASP.NET 5 (now called ASP.NET Core 1) project you're seeing is what we call a "Guest Host" which is a separate EXE hosted by Service Fabric but doesn't implement any of the Service Fabric APIs. The reason it's done this way currently is because the current ASP.NET Core 1 hosting model makes it difficult to open a web server programmatically like we do with Katana.
However, this is changing. The upcoming RC2 of ASP.NET Core 1 will let you easily start a web server programmatically, similar to the way we do it with Katana, so you can write a service on the Service Fabric API and open an ASP.NET Core 1 server from the service. Here is an example using the RC2 build: https://github.com/weidazhao/Hosting
That said, you don't necessarily need to be inside a Reliable Service to hook into actor events. Any code running in the cluster can do it by pulling in the Reliable Actors NuGet package (Microsoft.ServiceFabric.Actors) and using the ActorProxy API. You can do this in a Guest Host service, you just won't have RunAsync as an entry point to do it in.