Is there a way to deploy a containerized say .net core web app to IIS on a web server and use things like docker swarm and a virtual load balancer.
Am I looking at this all wrong? Would IIS even factor here?
If you want to go down this path, IIS does run in a (Windows) container, however most web apps I’ve seen uses Kestrel as the application web server (I.e. the default netcore images) and some kind of reverse proxy in front (Nginx, HAproxy) to handle things like load balancing, SSL termination and serving of static content.
I think the use case for IIS (though I haven’t used it so I may be wrong here) is to serve legacy ASP.net applications in a containerized environment.
See:
https://hub.docker.com/r/microsoft/iis/
Related
Preface: I'm new to the whole web hosting thing, so I apologize if any information I give doesn't make sense or is inaccurate. I will do my best to explain things.
I currently have a self-hosted server running Windows Server 2019 that is hosting two sites via IIS. I recently have created an application that runs on a Docker container instance that hosts a website on port 40444. I would like to access this site via a specific subdirectory on my website instead of the port (www.mywebsite.com/website3 instead of www.mywebsite.com:40444). For clarification, here is an example of what I'm looking to do:
www.mywebsite.com/website1 (hosted on IIS)
www.mywebsite.com/website2 (hosted on IIS)
www.mywebsite.com/website3 (hosted on docker via port 40444)
I was able to get a basic reverse proxy set up and successfully got the docker application to show on localhost/, but I would prefer using a subdirectory if possible.(image below).
I attempted to change (.*) to (.*)website3$ and it did what I wanted, but the website cannot load any files (i.e css, js, etc.) and gives me the following error
https://www.mywebsite.com/css/style.css net::ERR_ABORTED 404 (Not Found)
If IIS isn't the best option to accomplish what I need I am more than happy to use a different solution. As I mentioned before, I'm new to web hosting and it was just the simplest to set up.
I am in the process of evaluating moving a very large Azure Cloud Service (Web Role) microservice architecture to AKS and have been working through the necessary code and build changes to support it.
In order to replicate the production environment locally for the developers, we run nginx on the host with SSL offloading and DNS (hosted in Azure) A records pointing to 127.0.0.1. When running in the Azure Emulator, the net affect is the ability for both the developer to visit the various web front ends in their browser (i.e. https://myapp.mydomain.dev) as well as hit the various API's in the solution (Web API 2) in Postman/cURL, etc.
Additionally due to how the networking of the Azure Emulator works, the apps themselves can resolve each other through nginx on the host (i.e. MVC app at https://myapp.mydomain.dev can obtain a token from the IdP web API at https://identity.mydomain.dev and then use that token at the API at https://api.mydomain.dev). This is the critical piece and the source of my question.
All attempts at getting the containers themselves to resolve each other the same way the host OS can (browser/Postman, SSL offloading via nginx) have failed. Many of the instructions out there are understandably for linux containers but having adapted the various networking docker-compose settings for the windows container equivalent have not yet yielded an success. In order to keep the development environments aligned with the real work systems, which are tenantized and make sure of the default mapping in nginx to catch all incoming traffic and route it to a specific user facing app/container, it is not as simple as determining a "static" method of addressing these on startup and why the effort was put in to produce the development environments we have today.
Right now when one service (container) attempts to communication with another, it ultimately results in a resolution error as all requests resolve to https://127.0.0.1 due to the DNS A records hosted in Azure for the domain. Since this migration will be a longer term project, the environments need to co-exist so changing the way that DNS is resolved (real DNS A records pointing to 127.0.0.1), host running nginx and handling SSL offloading to the various webroles normally running in the Azure Emulator is not an option.
Is there a way (with Windows containers) to either:
Allow the container to utilize nginx on the host OS transparently (app must still call the API at https://api.mydomain.dev), which will cause the traffic to be routed properly to the correct container/port defined in the docker-compose file?
OR
Run nginx on each container, allowing each container to then resolve and route appropriately without knowing the IP of the other container, possibly through an alias which could be added to the containers nginx.conf before the service starts?
The platform utilizes OAuth2/OIDC and it is critical to maintain the full URL to the other services from the applications perspective. Beyond mirroring production and sandbox environments, this URL's are utilized for redirect URL and post logout redirect URL validation among other things so using "https://myContainerNameForOtherContainerAlias" is not a workable solution.
Will I have the same problem when setting up the AKS environment as well?
On our IIS we have multiple websites that serve shared applications under their respective hostname/bindings...
We achieve this by deploying the applications and then using the "Add Application" so that it can be served as "http://myhost1.com/myAddedApplicationAlias".
This works great, except that when deploying the application to be shared, we have to enter a bogus port number...
How can we avoid this port binding since the added application will be served from an existing web site's hostname/bindings?
Let's say we have 2 separate applications, a Web Api application and a MVC application both written in .NET 4.5. If you were to host the MVC application in IIS under the host header "https://www.mymvcapp.com/" would it be possible to host the Web Api application separately in IIS under the host header "https://www.mymvcapp.com/api/"?
The processes running the 2 applications in IIS need to be separate. I know of the separate methods of hosting, self hosting and hosting using IIS. I would like to use IIS if at all possible.
Also, how would I host two applications (an API and a web application) if each were on a separate server so that I could serve the api from http://www.mymvcapp.com/api?
There are at least 4 ways of doing what you want to do. The first two methods are for if you have 1 web server, and both applications are served from that one web server running IIS. This method also works if you have multiple web servers running behind a load-balancer, so long as the API and the Web site are running on the same server.
The second two methods are using what's called a "Reverse Proxy", essentially a way to route traffic from one server (the proxy server) to multiple internal servers depending on what type of traffic you're receiving. This is for when you run your web servers on a set of servers and run your API on a different set of servers. You can use any reverse proxy software you want, I mention nginx and HAProxy because I've used both in the past.
Single Web Server running IIS
There are two ways to do it in IIS:
If your physical folder structure is as follows:
c:\sites\mymvcapp
c:\sites\mymvcapp\api
You can do the following:
Create a Child Application
Creating a child application will allow your "API" site to be reachable from www.mymvcapp.com/api, without any routing changes needed.
To do that:
Open IIS Manager
Click on the appropriate site in the "Sites" folder tree on the left side
Right Click on the API folder
click "Convert to Application"
The downside is that all Child Applications inherit the web config of their parent, and if you have conflicting settings in there, you'll see some runtime weirdness (if it works at all).
Create a directory Junction
The second way is a way to do it so that the applications maintain their separateness; and again you don't have to do any routing.
Assuming two folder structures:
c:\sites\api
c:\sites\mvcapp
You can set up Junctions in Windows. From the command line*:
cd c:\sites
mklink /D /J mymvcapp c:\sites\mvcapp
cd mymvcapp
mklink /D /J api c:\sites\api
Then go into IIS Manager, and convert both to applications. This way, the API will be available in \api\, but not actually share its web.config settings with the parent.
Multiple Servers
If you use nginx or haproxy as a reverse proxy, you can set it up to route calls to each app depending.
nginx Reverse Proxy settings
In your nginx.conf (best practice is to create a sites-enabled conf that's a symlink to sites-available, and you can destroy that symlink whenever deploying) do the following:
location / {
proxy_pass http://mymvcapp.com:80
}
location /api {
proxy_pass http://mymvcapp.com:81
}
and then you'd set the correct IIS settings to have each site listen on ports 80 (mymvcapp) and ports 81 (api).
HAProxy
acl acl_WEB hdr_beg(host) -i mymvcapp.com
acl acl_API path_beg -i /api
use_backend API if acl_API
use_backend WEB if acl_WEB
backend API
server web mymvcapp.com:81
backend WEB
server web mymvcapp.com:80
*I'm issuing the Junction command from memory; I did this a few months ago, but not recently, so let me know if there are issues with the command
NB: the config files are not meant to be complete config files -- only to show the settings necessary for reverse proxying. Depending on your environment there may be other settings you need to set.
Can I have both a page using ASP.NET MVC 4 and another using Django under the same hosting?
Yes , you can config your web server to serve django project at the same host with ASP.Net or with some php application
otherwise you can install apache with iis and config apache to load django project and iis to load ASP.Net application
you can manage it by manage their ports
for example port 80 for IIS and port 8080 for apache
if you want to do it you should install wsgi_mod in apache
you can see here : https://docs.djangoproject.com/en/1.2/howto/deployment/modwsgi/
Regards
Mohammad
Yes, just configure your web server to serve Django separately from ASP.NET application.
If you want to serve ASP.NET you need a Windows-based server. Serving Django from Windows is not a big problem, but you will probably not be able to do it from a shared hosting account. Shared windows hosting is usually locked down / limited so much that hosting Django is impossible.
I agree with Daniel Eriksson ... It will be difficult to control hosting environment for Django on shared server. Moreover, I do not see Django listed on Microsoft's Web Platform Installer (http://www.microsoft.com/web/gallery/categories.aspx) application list. That means, it might be difficult to setup & take true benefits of dJango application on Windows platform.
If you still decide to host asp.net + django on a windows platform, go for a VPS hosting.