I am currently trying to figure out the best architecture for my Azure VMs.
I have a production website that is hosted in IIS in 2 VMs with a load-balancer over them, this is called Prod1 and for now is the live site.
I also have the exact same setup as my "staging" (called Prod2) environment, obviously this is not live .
I wish to deploy to Prod2, test and when happy switch it to live. Thereby making Prod1 not live.
Now i can simply drop the TTL and re-point the A record on the sites Domain name to the public IP of Prod2s load balancer.
But is there a better way of doing this to enable faster switching between these?
Azure Traffic Manager would be my suggestion for a seamless blue-green deployment.
For your workloads that are running in Azure, the recommendation is to setup the Blue environment, which has the old code, and Green environment, which has the new code, in separate Azure Resource Groups.
If the endpoint is external, you can use any continuous integration and deployment tool to manage and deploy the two environments.
Once you have the environments ready you can create a Traffic Manager profile using the Azure portal, PowerShell, or CLI, with weighted round-robin as the routing method and add the endpoints corresponding to these environments.
See Dilip's full post here.
Related
I have a web application that is currently running on IIS in 3 Azure VMs. I have been working to make my application App-Services friendly, but would like to test the migration to App-Services in a safe / controlled environment.
Would it be possible to spin up the App-Service and use an Azure Load Balancer to redirect a percentage of traffic off the VM and onto the App-Service?
Is there any other technology that would help me get there?
You might be able to achieve this if you are using an App Service Environment and an internal load balancer
https://learn.microsoft.com/en-us/azure/app-service/environment/app-service-environment-with-internal-load-balancer
However, based on your description of your current setup I don't believe there is an ideal solution for this as a standard load balancer only allows for the backend ports to map to VMs. Using an Application Gateway might be another option as well
https://learn.microsoft.com/en-us/azure/application-gateway/
I would suggest you make use of the deployment and production slots available that comes a Web App. Once you have the webapp running in the dev slots, test the site to ensure all works as expected. Once it does, switch it to the production slot and reroute all traffic from the VMs to the App Service.
All in all, running an app on a Web App is quite simple. Microsoft takes away the need to manage the VM settings so you can simply deploy and run. I don't see you having any issues simply migrating. The likelihood for issues is small. You can also minimalism it by performing the migration during off hours in case you need to make any changes.
There is also some Web App migration guidance you might find useful
https://learn.microsoft.com/en-us/dotnet/azure/dotnet-howto-choose-migration?view=azure-dotnet
I have a web app that is relies on a series of azure services. Currently, to handle different environments, we have a subscription and resource groups to handle each environment that we use (dev, test, staging, production).
Right now, every web app site EXCEPT for Prod uses the default url that Azure assigns to the web app upon creation.
This has led to some issues with in house business case testers getting confused about which urls go to what environment.
I wanted to know if it is possible to create subdomains that are named according to the environment (so if prod is https://superglue.com then dev would be https://dev.superglue.com) and if we can, if there are any reasons NOT to do it this way.
THanks in advance for any help!
You could add custom domains to each of your web app service. For example, you could map a subdomain www.contoso.com by using a CNAME record in your DNS provider. Then In the Custom domains page of the web app, add the fully qualified custom DNS name www.contoso.com to the list.
You could follow these steps in the official doc. https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain#map-your-domain
Azure does not support this if you have a free F1 price tier. But if you have shared D1 price tier, you could add custom domains. With a basic price tier and above, you could add custom domains and SSL binding.
Yes, you can use Azure web app deployment slot if you want to distinguish the dev,staging and prod environment of your web app.
Deployment slots are actually live apps with their own host names. And this is a recommended way to do some tests or building up test environment on your web apps .
What's more,if you have ensure that the staging env is ready to online , you can swap it to prod environment directly of course you can swap it back to staging easily too : ).
Hope it helps .
We have an application running in Azure that consists of the following:
A Web App front end, which talks to…
A WebApi running as a Web App as well, which can (as well as a couple other services) talk to…
A Cloud Service load balanced set of VMs which Are hosting an Elasticsearch cluster.
Additionally we have the scenario were dev’s whitelist their IPs so that their localhost version of the API can hit the VMs as well.
We have locked down our Elasticsearch VM’s by adding ACLs to the exposed end point. I whitelisted the outbound IPs that were listed on my App Services. I was under the mistaken impression that these were unique to my Api. It turns out that these are shared across the scale unit in Azure. Other services running in the same scale unit, could, if they knew the endpoint, access the data exposed on the endpoint in my cluster. I need to lock this down, and I am trying to find the easiest way. These are the things I am looking at, and I would appreciate advice and/or redirection.
Elastic Shield: Not being considered. This is a product by Elastic
that is designed to secure ES. This is ideal, but at the moment it
is out of scope (due to the cost and overhead)
List item
Elastic plugins: Not being considered. The main plugins (such as
Jetty) appear to be abandoned.
Azure VPN. I originally tried to set this up, but ran into too many
difficulties. The ACLs seemed to give me what I need without much
difficulty. I am not sure if I can set this up now. The things I
don’t know are:
I don’t think I can move existing VMs into a new VPN.
I think you have to recreate the VMs in that VPN from the get go
Could I move my Web App into the VPN? How does that work?
This would prob break my developer scenario as the localhost API
would not be able to access the VPN, right?
Add a certificate to requests: It would be ideal if I could have
requests require a cert or a header token. I assume to do this I
would need to create a proxy that would run on the VMs and do the
validation before forwarding the request on to my Elasticsearch.
Anything else? Is there another option I have not thought of?
Thanks!
~john
You can create a VPN point-to-site connecting your Web App with your IaaS VMs. This is the best solution because you will be able to use just internal IPs on your IaaS.
The easiest way to do that using Azure Portal is create a Web App and, create a new VPN and VNet using "setup" option at "Your Web App" -> Settings -> Networking -> VNET Integration -> Setup -> Create New Virtual Network.
After that, create your IaaS inside this new VNet.
You also can create a ARM template to create Web App, IaaS, VPN and everything that you need. Take a look at my ARM template to create PHP+MySQL using Web App and MariaDB Cluster connected by VPN: https://github.com/juliosene/azure-webapp-php-mariadb
I have purchased a Pay-As-You-Go Azure Subscription with the lowest resources (A0 Basic, shared core and 768 MB RAM) and automatically, four services were created for me: a Storage Account, a Virtual Machine, a Cloud Service and a Directory.
On the Virtual Machine I set up my own HTTP server software written in C# using HttpListener class. I added an HTTP Endpoint connecting the private and public port 80 on TCP. Once I've done that, I was able to access my Cloud Service address (Something.CloudApp.net).
I've created a separate Cloud Service on top of 4 service I already had and now I can't figure out how to make that service use the Virtual Machine so I can access the same HTTP server from both DNS names (Something.CloudApp.net versus SomethingElse.CloudApp.net).
The service status of both services is Created if I investigate in the Microsoft Azure Portal, however, only the first service says Running in Production column in Cloud Service list. The other one doesn't. None of the Cloud Services say anything in the Staging column.
I figure I have to set the other service to run in production too, but when I want to do that, the Portal says "You have nothing deployed to the production environment.", "Upload a new production deployment", which opens a dialog prompting me to provide details for a production environment to be newly created.
Is there a way I can make my other Cloud Service use the production environment of the first service?
Is there an alternative way to make my Virtual Machine accessible through two DNS names offered by Azure (CloudApp.net)?
The cloud service is the logical container for the VM and a VM can only be in one cloud service. There is no way to get 2 different *.cloudapp.net URLs to point to the same VM. What you can do is register 2 custom domain names (www.mydomain1.com, www.mydomain2.com) and use CNAME or A Record to point both of them to the same VM.
I'm looking to set up two web roles or websites on my Azure Cloud Service.
The websites need to share the same database schema. I use NHibernate ORM, so I have to make sure that both projects are always using the same data model, or else it will cause major problems.
I've researched setting up multiple websites on a single web role (which seems odd to me, can't I just run multiple web roles, each with a single site)?
http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx
Like any good developer, I use a staging server. If I have to manually set the domain name is configuration files, how will azure know not to be sending people who visit that domain to the staging server?! I.E. If they visit blah.foo.com and I have two deployments (staging and production), is IIS going to be able to know only to send people to the production environment?
Please advise on the best way to go about doing this.
First, you can certainly have multiple web roles, each with a single site; however, each role instance will be deployed to different virtual machines. For example, if you do set up two web roles when you deploy this with one instance each then there are two virtual machines you'll be paying for. If you want the SLA to apply to your deployment you'd need to actually set the instance count to 2 for each web role, which now means you have four virtual machines running. By combining web sites onto the same web role you'll cut down on the number of instances you need to run and still get the SLA; however, that option is not without some considersations. The link you provided is how you can set up multiple websites to run on the same virtual machine when deployed. Note that there are some gotchas with using that method. I'd suggest reading Michael Collier's Tips for Publishing Multiple Sites in a Web Role.
Second, if you do NOT need to have a lot of control over the virtual machine (such as registering special components, etc.) you might want to look at Windows Azure Web Sites as an option. You can elect to take one of the paid levels of Web Sites and still have dedicated machines, but you can deploy the websites separately. I will say though, that your requirement of having both sites in lock step because they share the underlying database schema means that it will be less likely you will want to deploy separate changes, but it is still possible.
Finally, regarding the staging server. If you are testing locally you'll want to modify your hosts file to get the host names to point to your local address. Wade Wegner has a post on Running Multiple Websites in a Windows Azure Web Role. Once you deploy to Windows Azure you'd want to change your hosts file back, or comment them out. If you are using the actual idea of the Staging deployment slot you can use the same trick with the hosts file to point to the IP address of the staging deployment when testing.