I have two meteor applications. One is a fairly complex job management application (application 1), and the other is more or less a feature for application 1 that was built as an internal mvp to test out the feature (application 2). Now I need to integrate application 2 into application 1, but the problem I have is there are several conflicting packages being used between the two applications: application 1 = iron:router+blaze+custom CSS, application 2 = flowrouter+react+ionic.
To handle these issues with conflicting packages, I would like to set up the second application on a separate server, but keep it under the same domain as the first application. I also would prefer that application 2 lives under a subdirectory (/application2), as opposed to a subdomain.
Is there a good way to do this without dealing with setting up a reverse proxy, such as nginx? Basically, I want my meteor application 1 to connect or route to the new server for application 2 anytime the user clicks on a link to the /application2 subdomain, and then application 2 routes back to application 1 anytime a link to any other subdirectory is clicked. Thanks.
Related
Is it possible to publish an ASP.NET (core) application to a running site on IIS 8 without having to stop and start the website manually?
Visual Studio 2015 keeps giving the error that a file is in use. I'm using publish to the file system, because my Web Deploy to a server in our network fails at the end with an error that it cannot authenticate on the server with port 443.
I don't mind IIS having to recycle the application pool, but when I constantly have to put the app down, publish (which takes about a minute) and restart it, it's not really good for the users.
Another option would be something like 2 websites running the same application, but only if this is automatable. Then it would put down 1 of the 2, update this, put it on, put down the second, update this and start it.
A third option is something like a hot update, where I could just update the application while it being on.
Can anyone point me in the right direction (perhaps some blog posts), because my Google searches didn't give me any good information?
If you copy a file called app_offline.htm to the application folder IIS will gracefully stop your application and start serving the contents of the app_offline.htm file. When application is stopped you can copy your files. After files are copied remove the app_offline.htm file and IIS will start your app. VS does that for you when you deploy to Azure but not when deploying to file system.
You mention "two websites running the same application". Do you mean two web servers hosting the same app?
If you already have multiple web servers (a.k.a. cluster of servers, or web farm), you can simply take some servers out of the cluster and update them. That is how we push out our updates. We use software from Citrix for managing the server farm. It also handles load balancing. This type of software allows one to monitor the servers, so you can determine when all the users have "moved" off the web servers (that were recently taken out of cluster). Then you can iisreset, deploy the new build, and move on to the next server (or set of servers, depending on your configuration). We have more than 20 virtual web servers. Typically we take down half of the servers, update them, and take the other half down as we put the first half back in the cluster/farm. This should allow for uninterrupted service. I understand you want to automate the process. I'll assume you're using Windows NLB (network load balancing). You could write a PowerShell script to automate taking down the servers. Here's a reference:
https://technet.microsoft.com/en-us/library/ee817138
I understand this may be viewed as a workaround. I'm not sure if recycling the app pool is always necessary with ASP.NET Core. I wasn't able to find a definitive answer. Most production applications should be on more than one web server anyway. Even if you don't have a lot of users, you should have multiple web servers for failover purposes.
I have developed a well-decoupled website using WebAPI and AngularJS as follows:
SOLUTION
|—— WEB.API Project
|—— Website pages Project
'—— Other projects related to functionalities
This setup is on my own computer.
Now I'm here wanting to deploy to my web server (iis 7.5, privately owned, WebDeploy installed). It is possible to deploy both projects on a single web site? (other projects are class libraries, so no hassle)
For what I know, I have to deploy the WebAPI part to a website, and the UI part to another website. May I put them on a single website?
You can put the Web API project in a virtual directory under the main web site. That's what we are actually doing in our current project.
You can, but you should be worried when files conflict. If both projects have a web.config for example, this could break either of them.
If not, it should be possible, but I wouldn't immediately recommend it. I would split them off in separate virtual directories so you can maintain the two separate projects easily.
You could also self-host the Web API using OWIN, so you wouldn't then need to set up a project in IIS etc and you could then have multiple clients talking to the same API.
There's a tutorial here which is more advanced.
I have a near identical project setup. Personally I picked 2 separate apps, I have a multi server setup with load balancers - the choice may have been different if I had a single server or low amount of expected traffic.
This gives the advantage:
I expected my WebAPI to have a larger amount of traffic than the web pages, due to mobile clients also consuming the WebAPI as well as the front end webpages. Because the API is in its own website, it has its own app pool - this means that each application has its own resource pool (app can grow to use more memory and CPU better), not shared like they would be on a virtual directory.
Disadvantages:
Because there is two separate app pools, I have one bound to port 80 and the other to port 8080. As I had a large server farm to roll this out on, I already had a load balancer in front of the webservers - hence to make the URL pretty (i.e. drop the port 8080 from the URL) i added a load balancer config to allow traffic to come in on a given url on port 80 and be redirected to port 8080 on the internal webservers. This isn't really a issue if you don't mind ports in your URL's.
I have 2 web projects in my solution:
Our marketing/public site, which is a small website build with ASP.NET WebPages 2.
Our admin application which is a MVC4 application.
They are currently deployed in IIS 7.0 as
/wwwmywebsitecom (root for the public website)
---/admin (root for the MVC4 app)
---/Content
---/Scripts
..etc
The reasons to separate the public site from the admin part is to make sure the first load FAST and doesn't wait for the heavy setup mechanism that is triggered by the mvc4 app (bundles & minification, webapi routes, index creation, initial setup, etc).
My goal is to package these apps and deploy it to our test server by using MsBuild and MsDeploy. Right now I'm doing this by hand but for obvious reasons I need to automate the process. (Planning on including a CI server after I have this part figured out).
I have read several posts but none of them address this type of nested scenario.
Is it possible?
Any help would be more than appreciated.
Thanks,
R.
Assuming the admin folder on the remote server is marked as an "application", you should just be able to deploy both sites one after another.
When one updates an ASP.NET MVC app in IIS the framework keeps the connections open. All responses to the connections are sent once IIS has caught up. Unfortunately this can take some time (eg. 15 seconds). Is there any way to update part of the app without affecting connections to another part.
An example use case: if you have a web chat app and you want to make a minor change to one section of the website, can it be done without 'pausing' the connections to the chat app.
If you can physically separate the code into its own folder, I.E. (c:/inetpub/wwwroot/myapp and then c:/inetpub/wwwroot/myapp/chatapp), you could define "chatapp" as its own application within the IIS website, and then create a new application pool just for that application. I had to do this before because the project I was running needed to have part of the IIS site on a different recycle schedule due to performance issues, also it crashed a lot so it was advantageous for it to have its own process so it didn't take everything else down with it :)
We are using IIS7 to host an asp.net web-based application.
In this environment administrators and developers can deploy code to the application on a regular basis.
The new code or app goes as a DLL to the ASP.NET bin folder. Upon deployment of the new DLL, IIS restarts the process, impacting (slowing down) all online users.
Is there a way to configure IIS to run the process in the background and once ready make the switch from old state into new without impacting the users?!
Thanks in advance for your feedback!
IIS already does this, that's what recycling is all about. IT's loading the DLL's while the old version of the application is still running. only after this is completed the recycling is complete.
However loading the DLL's is only part of getting web applications ready, there might also be initial loads like loading/caching the user db etc.
These actions are not part of the recycle process, they happen after all DLL's reloaded and the recycling is already completed.
A while back I ran into this issue with an application that had a huge startup time due to heavy db activity/caching during startup. So I was interested if there is some functionality that allows us to execute code before the recycle is marked as completed, so that the application is first considered recycled when everything is ready to run. Basically what I wanted is some kind of staging functionality.
I was in contact with the IIS team regarding this issue, sadly they told me that no such functionality exists, nor is it planned.
To solve this you could try do the following:
Use alternating deploys:
You setup 2 Websites with separate application pools. One of them is the LIVE website the other one is the STAGED website. If you want to deploy changed you simply deploy to the STAGED website. After everything is loaded/cached etc. you switch the URL settings of the web applications to reroute incoming requests from the LIVE to the STAGED one. So the LIVE one becomes the new STAGED and the other way around. The next deploy would then go to the new STAGED again and so on.
UPDATE
Apparently they have created a IIS Module that provides this functionality by now:
IIS Application Warm-Up Module for IIS 7.5
The IIS team has released the first beta test version of the
Application Warm-Up Module for IIS 7.5. This makes warming up your
applications even easier than previously described. Instead of writing
custom code, you specify the URLs of resources to execute before the
Web application accepts requests from the network. This warm-up occurs
during startup of the IIS service (if you configured the IIS
application pool as AlwaysRunning) and when an IIS worker process
recycles. During recycle, the old IIS worker process continues to
execute requests until the newly spawned worker process is fully
warmed up, so that applications experience no interruptions or other
issues due to unprimed caches. Note that this module works with any
version of ASP.NET, starting with version 2.0.
For more information, see Application Warm-Up on the IIS.net Web site.
For a walkthrough that illustrates how to use the warm-up feature, see
Getting Started with the IIS 7.5 Application Warm-Up Module on the
IIS.net Web site.
See:
http://www.asp.net/whitepapers/aspnet4
If you use ASP.NET 4 Auto Start feature:
You can still choose to auto-recycle the worker processes from time to
time. When you do that, though, the app will immediately restart and
your warm up code will execute (unlike today - where you have to wait
for the next request to-do that).
The main difference between Warm Up and Auto Start feature is that the Warm Up Module is part of the recycling process. Rather than blocking the application for requests, while running the init code.
Only thing you get by using the Auto Start feature is that you don't have to wait for a user to hit the page, which does not help your case.
See the Gu's blog post:
http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
UPDATE 2:
Sadly the Warmup Module has been discontinued for IIS 7/7.5:
http://forums.iis.net/t/1176740.aspx
It will be part of IIS8 though (It's now called Application Initialization Module):
http://weblogs.asp.net/owscott/archive/2012/03/01/what-s-new-in-iis-8.aspx
UPDATE 3:
As pointed out in the comments the Warmup Module resurfaced for IIS 7.5 as Application Initialization Module for IIS 7.5 after IIS 8 was released:
http://www.iis.net/downloads/microsoft/application-initialization
The first part of ntziolis answer is a wee bit inaccurate. The worker process isn't being recycled or restarted, it just keeps running. If this were the case, then in shared pool environments you would have sites knocked out every time a new one was deployed.
When you deploy a new ASP.NET application it's the site's "Application Domain" within the worker process is torn down, not the pool process.
In addition pool recycling is a completely separate concept to deployment
At this point in time in the commercial life of ASP.NET, during a deployment, a site will be in an inconsistent state until all of the site is deployed. There is still no good story about this from Microsoft at this time for single site on a single server deployments.
This is why ASP.NET has the special App_Offline.htm page. It's there so you can enable that page, deploy and then turn it off.
The second part of ntziolis answer is nearly correct but you don't need two sites or two application pools. You just need two file system folders that switch between being the physical folders for the site...if you're on a single server and not behind a load balancer or ARR.
If your sites were on a web server behind a load-balancer or ARR then having two different sites would make sense, you could route requests from one site to the other and round-robin on each deploy.
Obviously if there is a large amount of user generated content (uploaded files and the like) then you'd map a virtual directory in your site to a common location for this data.
In larger scale deployments where your app is running across (for example) a load-balanced environment you can do more sophisticated deployments.
For related questions please see:
How Do I deploy an application to IIS while that web application is running
Publishing/uploading new DLL to IIS: website goes down whilst uploading
Is smooth deployment possible with componentized ASP.NET MVC apps?