I'm trying to to use Consul to implement service discovery in a microservice architecture.
I've tried to setup my dotnet core 3.1 application to self register with Consul, and I have 3 VM's running Consul, automatically picking a leader of the 3.
Reading numerous examples online, they all have one thing in common: I need to know the URL of my microservice. Now, using IIS I have 2 options when it comes to hosting; Sites and applications. Sites have a certain URL connected to them (Example: http://api.microservice1.com) whereas application use the servername in the URL (Example: http://webappserver1/microservice1).
As I have 2 servers (Let's say webapp01 and webapp02) I can't know what server the service is running on, and therefore I can't seem to find a solution as to using IIS applications instead of IIS sites. My service would be one of the following routes:
http://webapp01/microservice1
http://webapp02/microservice1
Is there a way for me to use IIS applications and not sites? How would I register my microservice with Consul? Perhaps I'm just forced to use IIS sites and not applications?
Related
I would to host two ASP.NET Core Applications, a Web API and a Blazor Server App, but I searched in the internet and the answers that I founded only target to a different path inside of one application, that's not my case. I would to use they like a sub-address of the same Azure Web App for example: www.example.com and www.example.com/api where each one will be a different .NET Core application. So I suspect that I'll need to create two Azure App Services and try to communicate they both, but maybe the structured that I wonder won't work in this way, it's that right? How I can do this?
I have the same setup as you; an ASP.NET Core web API, and a Blazor Server Side app.
As you want to use the same domain for both services, you would have to use Azure API Management or some other proxy if you were to route requests to two different Azure App Services.
An easier option is to deploy both services to the same App Service, but as different virtual applications. You publish your Blazor app as normal, but for the Web API you would publish to a new virtual application /api.
To enable this virtual application, navigate to Configuration and then Path mappings in your App Service. Here you already have the default virtual application / pointing to site\wwwroot. You then add another virtual application named /api pointing to site\wwwroot\api:
When adding the virtual application, remember to remove checkbox for Directory (making it a virtual application instead), and optionally enable Preload:
If you publish your app using Azure DevOps Pipeline, it has an option to specify virtual application if another than default should be used.
You can now navigate to your two different URLs and hit each service. Note that when developing your Web API, you should not add api to your controllers routes, as this virtual application does that for you.
I am relatively new at configuring IIS and am wondering if the following scenario is possible.
My application consists of 2 Web apps. 1 is an ASP.NET Core App that hosts a Javascript SPA. I have a second MVC App that is a combined Authorization Server using OpenIddict and the main API that the SPA talks to.
On my dev machine these 2 apps run on different ports.
These 2 apps go together to make our solution for any given customer. I can get this all working on IIS treating each app as it's own website with it's own port.
But I would like to be able to bundle these 2 apps under 1 website. Ultimately we will have several customer websites and each "website" really consists of these 2 apps bundled together.
I understand that I can create a single website and then convert my 2 existing sites to a web application. So 2 web apps sit under the main web site. But these all will run under the same port.
I would really like my API and Authserver to run on a different port. Is there a way to each this type of scenario?
What is the recommended best practice for what I am describing?
I do not want the API / Auth Server project to be shared by all the customer sites. I want each customer site to have it's own instance of the Authorization server and API.
It would be great if you could create 2 websites and then sort of group them into a parent website container (if that makes any sense).
You can create two applications within your website on IIS. Then each application would be accessed as http://customerwebsite/app1 and http://customerwebsite/app2
I need to create 3 separate and independent versions of my ASP.NET WEB API and host them all at the same port and in the same IIS.
So, let's assume that my current API runs at:
http://xxx.xxx.xxx.xxx/api
I need to replicate it to
xxx.xxx.xxx.xxx/test/api
xxx.xxx.xxx.xxx/dev/api
but it is very important that each one will have it's own configuration on IIS.
The reason for that is that I want each "version" of the API to have a different connection string.
Of course this will have to be done with out any change in my current code, just via IIS setup.
You can create applications under an IIS site to accomplish this. You can even use WebDeploy to deploy them all. Follow this blog post -
http://dotnetcatch.com/2016/03/03/simple-service-versioning-with-webdeploy/
I am in the process of building a Web based client for a Server application which is running as a Windows Service. The server application currently has a Windows Form based Client Application written in C# and the idea is to obsolete it and provide a new Web based Client Application. The Server application will be exposing REST based APIs and the Client Application would be using the REST APIs to communicate with the Server Application. (Currently the Server App exposes SOAP based endpoints which are consumed by the Windows Form Based App)
The Browser based client application would be written using Angular JS. The Client Application would be used by at max 10 concurrent users. The App is targeted for system administrators and would be used inside the enterprise environment.
Another requirement is to integrate Active Directory Authentication for the Client Application. So given the performance requirement and authentication requirements, I am wondering whether I should use IIS for hosting the Web Application. Or should I just use the existing Server to self host the web pages.
If at all I go with Self Hosting option, would Katana Self host be a good option? Or should i use WCF Rest kit to serve the pages?
What are the performance implications of using a Self Hosted mechanism for hosing the Web Application compared to IIS?
Any suggestion would be greatly appreciated.
WCF REST Starter kit is still in second preview 2 version from 2009 so I'd be pushed to recommend using it.
The question of IIS or self host depends, do you need the features that IIS has out of the box like logging, restart after failure, etc?
My suggestion would be to use ASP.NET Web API (or Nancy, which is an excellent choice too) but keep your hosting layer separate from your application layer so you have the flexibility to decide how you host your service later on.
The second suggestion is performance test early on, pick a hosting mechanism and measure how the service copes under load - you may find out that you're worrying about something that you don't need to.
I have a web application that was being developed using Web Roles in Azure. It is a relatively complex application in which clients communicate with each other via the web server. Client to server communication is via SignalR and within server instances Web Api is used.
It was critical that it was tested against multiple instances of web roles since the all of plumbing needed to potentially communicate across the various instances of web roles.
This was easy to do in web roles since in Visual Studio's project properties you would simply up the instance count and the Azure Compute Emulator would open a bunch of instances for you.
After attending a recent Microsoft technical briefing, it was suggested that web roles were being superseded by Web Apps in Azure App Service. Indeed on the surface these appeared to be a better fit to my problem and I have been investigating this as an architecture.
The problem I have found is how to simulate multiple instances? Web Apps in development spin up in a single IIS express instance and thus have the same IP address on my development computer. Web Roles spin up in difference instances and all have different IP addresses which makes testing easy. From what I understand on production, web apps, if configured to have multiple instances, will get different IP addresses (and/or ports) since they may be running on different servers
So how do I test multiple instances of Web Apps in the Azure App Service that need to cross communicate in development?
...or am I just missing something big here?
Thanks in advance.
Dave A
You can use the ARRAffinity value to specify which instance you want to hit, allowing your request to hit any instance you want.
You can find more details here: http://blog.amitapple.com/post/2014/03/access-specific-instance/#.VhLIGXmFMis
Could you run full IIS (w3wp) locally for testing? If so, you could create multiple sites or applications using different application pools, and hence processes.
I found this. http://blog.tylerdoerksen.com/2013/11/01/azure-websites-vs-cloud-services/
In short, given that I need to have some internal communication then Web Apps in Azure App Service should not be used.