We have 3 components that we want to map to our domain like this:
a static website: example.com
an asp.net app used for account settings: example.com/account
some .net webservices used in other apps: example.com/web
We want to use AWS's Elastic Beanstalk to host the entire structure, preferably in the same environment.
And if we were to have all the components in the same Visual Studio project, it would be quite easy. But the static website is prone to a lot of changes and we don't want those changes directly pushed to production to mess with the other 2 components.
The best scenario for us would be to have 3 separate VS projects, each of them publishing separately and independently to the EBS environment:
the static websites VS project should be able to publish in the root
w/o interfering with the /account and /web folders
the ASP.NET user account VS project should be able to publish
directly to /account without messing with the root files
the .NET webservices VS project should be able to publish directly to
/web without messing with the root files
My questions:
Is this possible? And if there is a way, how should we deal with
versioning?
Should we use other AWS services that can help us reach our goal architecture?
Our fallback plan is to host the static website in S3 and use subdomains for the apps: account.example.com and web.example.com.
For your requirements I would suggest using S3 for static website, and Elastic Beanstalk for other 2 components.
Here one more decision you have to take is either to use a single Beanstalk Environment or Multiple. This decision you can take based the requirements for scalability of each service running in Benastalk.
Another important service you can use is AWS Cloudfront, to be used infront of all 3 components, which can be configured to do the url routing for example.com/ and also cache static content in edge locations. This will also help to setup SSL certificates if needed (Which is free for CloudFront). Also if you use Cloudfront you don't need subdomains, which works best for web apps since it don't need CORS with preflight requests.
Related
I'm wondering if anyone with bigger brains has tackled this.
I have an application where each customer has a separate webapp in Azure. It is Asp.net MVC with a separate virtual directory that houses ServiceStack. The MVC isn't really used, the app is 99% powered by ServiceStack.
The architecture works fine, but as we get more customers, we have to manage more and more azure webapps. Whilst we can live with this, the world of Containers is upon us and now that ServiceStack supports .net core, I have a utopian view of deploying hundreds of containers, and each request for any of my "Tenants" can go to any Container and be served as needed.
I think I have worked out most of how to refactor all elements, but there's one architectural bit that I can't quite work out.
It's a reasonably common requirement for a customer of ours to "Try" a new feature or version before any other customers as they are helping develop the feature. In a world of lots of Containers on multiple VMs being served by a nginx container (or something else?) on each VM, how can you control the routing of requests to specific versioned containers in a way that doesn't require the nginx container to be redeployed (or any downtime) when the routing needs changing - e.g. can nginx route requests based on config in Redis?
Any advise/pointers much appreciated.
G
Whilst it isn't Azure-specific we've published a step-by-step guide to publishing ServiceStack .NET Core Docker Apps to Amazon EC2 Container Service which includes no-touch nginx virtual host management by running an Instance of jwilder/nginx-proxy Docker App to automatically generate new nginx Virtual Hosts for newly deployed .NET Core Docker Apps.
The jwilder/nginx-proxy isn't AWS-specific and should work for any Docker solution that explains how it works in its introductory blog post.
Using nginx-proxy is a nice vendor-neutral solution for hosting multiple Docker instances behind the same nginx reverse-proxy, but for Scaling your Docker instances you'll want to use the orchestration features in your preferred cloud provider, e.g. in AWS you can scale the number of compute instances you want in your ECS cluster or utilize Auto Scaling where AWS will automatically scale instances based on usage metrics.
Azure's solution for mangaging Docker Instances is Azure Container Service which lets you scale instance count using the Azure acs command-line tool.
Our company is working on the same thing. We were working with kubernetes and building our own reverse proxy with nodejs. This reverse proxy would read customer settings from a certain cache and redirect you to the right environment.
But Depending on the architecture i would advice to just have 2 environments running with both there relative urls: 1 for production and one for the pilot/test environment. Whenever a customer goes to the pilot environment url he will use the same database but just an upgraded version of the WebApp.
Of course this will not work if working with an ORM and database migrations are included. (Which is probably the case when you are using servicestack)
I setup a Kentico CMS to host multiple sites and I'd like to know if it would be a good practice to setup multiple website in IIS using the same code base? I'm using IIS 8 on Windows 2012 R2
Chel,
I don't think having multiple IIS applications point to a single codebase is a good idea. Kentico will add/update/delete several files within your application folder as part of it's normal processing. Having multiple IIS applications performing this action on the same folder on the file system will introduce complications and errors due to file permissions and access rights.
You could set up your solution a few ways, depending on how you wanted to manage your applications.
Single IIS application / Host Headers
In this scenario, you would have a single IIS application / folder. All sites would be delivered from the same codebase. All traffic would be redirected to the same IP. In your IIS configuration, you would use host headers for each URL you wanted to send to your site. In Kentico, you would have a license / domain alias for each site you wanted to server.
PROS
This set up would give you a single codebase to manage your applications. This can simplify a good bit of your maintenance and hot fixing.
CONS
If you have to restart any of your sites for any reason, all of your sites will go down at once.
Separate codebase / IIS application for each site
In this setup, you would replicate your codebase for each site you wanted to deliver. You would create an IIS application for each codebase, configured for the appropriate URL. Each domain would be directed to the appropriate IIS application.
PROS
Can isolate your application. Can provide the ability to use different .NET frameworks / configurations for each app.
CONS
Several codebases to maintain. Updates to all sites require duplication of code across all codebases.
Personally, I would recommend option 1 if all of your sites are on the same .NET framework and it is not critical if they have to be restarted. If any of them are critical LOB applications, you may consider branching that one application off to it's own IIS application pool / codebase.
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.
What is the best practice of configuration management for web applications that are published to Amazon Beanstalk?
Now configuration of our web application is separated among several files. One of them is web.config, where we have basic connection strings.
Others are custom xml files with configuration of different application modules. These files are mapped to config classes via default xml serialization.
The simplest way is to add these configs into Visual Studio's project. But this solution produces several questions:
We do not want our production settings be visible to newcome team members.
We want to be able to switch between different configurations of application - we have our local server with SQL Server, which is used for development as it is faster and more responsive than Amazon's instances we use.
We can consider moving all application and its modules settings into System.Configuration format and use config file transformations, having two solution build configurations - one for Amazon and one for dev environment. But this means we would have not to forget to switch to Amazon solution configuration before publishing project. Is it possible to set solution configuration that will be used to publish to Amazon by default?
For a long time I have been performing dated deploys to our IIS servers, basically this means that each deploy gets its own dated folder within the web site folder (c:\sites\my-site\20140824-1236 for example). I then redirect the web app to the new deployment folder.
This gives us a quick role back capability if things go pear shaped.
The problem is that we are looking at moving deployment over to the new web deploy techniques, while we have been using the new techniques within QA and UAT for a while - the standard behaviour is to simply replace the files at the location defined within the IIS web site.
Before I go and start looking at remote PowerShell to re-configure IIS before executing the web deploy.. does anyone know how I can achieve this using standard web deploy.. maybe with msbuild extensions or something?
How about using the automatic backup capabilities in Web Deploy v3?
http://www.iis.net/learn/publish/using-web-deploy/web-deploy-automatic-backups