i am a newbie and am planning to host iis server for my client in azure with auto-scale functionality.
we will test modules and update once in a week in iis server, my question is how to sync the files between vms while on auto-scaling and if we can use auto-scale only for identicals vms, then please suggest me the solution for this scenario. we will start min 2 max 10 vms in auto-scale.
Regards,
Kumar B
I first would ask why a VM, things do get more complicated using VMs. Scale Set would help support this however you still will have issues when you want to deploy new code. You said IIS so I am presuming Windows. Desired State Configuration is a great choice you can make a PowerShell script that will "configure" your VM for you, and potentially pull in any code updates. This is also where things like chef/puppet/salt can come into play to ensure the server is configured.
You could look at creating a custom image that every time you deploy new code gets baked into the image. Then you are basically doing a rolling update where you spin up a new server and then destroy one until they all have been updated. Technically this could be done, either way, just if they are baked into the image you would have a quicker start time.
https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-deploy-app
https://adamtheautomator.com/azure-vm-scale-sets-powershell/
Automatic - VMs may be rebooted in a random order even taking all VMs temporarily down at the same time.
Rolling - The scale set deploys updates to instances in batches with an optional pause time between batches.
Manual - Nothing happens to existing VMs when an update is initiated.
What files are you trying to sync if they are not code files, Azure Files would be a great fit as that supports SMB or you could just use cloud storage.
You can deploy your application to a virtual machine scale set using desired state configuration. See: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-deploy-app
Not what you asked, but you should consider why you are hosting your app in IIS on VMs. If you are using Azure, then Azure App Service may be a better fit. See: https://learn.microsoft.com/en-us/azure/app-service/
Related
Currently, we are hosting five websites on a Linux VM. The websites reside in their separate directories and are hosted by Nginx. The SSL is terminated at Azure Application gateway which sends the traffic to the VM. If a file is updated in a remote repository, the local copy is updated by a cron task which is a simple Bash script running git pull and few additional lines. Not all five websites need to be updated at the same time.
We created the image of the VM and provisioned a VMSS set up.
What could be the easiest or standard way of deploying the codes to the VMSS? The codes also need some manual changes each time due to client's requirements.
Have a look into Azure Durable Functions as an active scripted deployment manager.
You can configure your Durable Function to be triggered via a cron schedule, then it can orchestrate a series of tasks, monitoring for responses from the deployment targets for acceptable response before continuing each step or even waiting for user input to proceed.
By authoring your complex workflow using either of C#/JavaScript/Python/PowerShell you are only limited by your own ability to transform your manual process into a scripted one.
Azure Functions is just one option of many, it really comes down to the complexity of your workflow and the individual tasks. Octopus Deploy is a common product used to automate Azure application deployments and may have templates that match your current process, I go straight to Durable Functions when I find it too hard to configure complex steps that involve waiting for specific responses from targets before proceeding to the next step, and I want to use C# to evaluate those responses or perhaps reuse some of my application logic as part of the workflow.
It's pretty easy to do autoscaling with Azure web apps, and there's something called Virtual Machine Scale Sets (but that's still in beta and not working properly yet), so I'm wondering: how can we do autoscaling using normale Azure VMs?
1) I was thinking we could create a load balancer, availability set and VMs, pre-provision them and turn some off. But aside from using the API to build a DIY scaler: how can I automatically turn on more machines if the current set exceeds a certain threshold? Does Azure offer anything for this? How do big companies that use Azure handle this?
2) How can I make sure that the machines are all consistent and have the latest version of our software installed on it? Even if the machine has been offline for months?
Well, those are 2 separate questions. Nonetheless:
You can use VM Scale Sets to do that. Here's a nice compilation of resources
VM Scale sets can kinda achieve that, but not exactly. If the VM was offline nothing can configure it (at least in Azure). You can use Powershell DSC\Ansible\Chef\whatever to configure VM once it comes up. If you are using plain VM Scale Sets you would need to upgrade VM before bringing it up.
I thought one of the advantages of Azure was that I could turn services on and off depending on when I want them to be available.
However I cant see how to pause my App Service Plan.
Is it possible?
I want to use the S1 tier so that I can play with what it offers. However I want to be able to pause the cost accumulation when I am not using it.
I see from the app service pricing help that an app will still be billed for even though it is in the stopped state.
Yet the link also clearly states that I only pay for what I use. So how does that work?
If you put your hosting plan onto the free tier, you will stop being charged for it. However if you have things like deployment slots and certificates these will be deleted.
The ability to turn services on and off, is more to do with being able to scale services, so if you need 50 servers for an hour you can easily do that.
What you can do to make your solution temporary is to create a deployment script, using Powershell or Resource manager Templates then you can deploy your solution for exactly as long as you need it and then delete it again when you don't. In this sense you can turn your services on and off at a whim.
Azure provides building blocks for you to create the solution you need, it is up to you to figure out how to best use those building blocks to create the solution you seek.
Edited to answer extended question.
If you want to use the S1 pricing plan, and not have it charge when you are not using it, the only way of achieving that is by using automation. Fortunately, this is reasonably trivial to achieve.
If you look at this template it is pretty much all configured to deploy a website from Github to Azure on demand. If you edit that to configure it to your needs you can have a new Azure website online with 2 minutes of running the script.
Then you would have another script that deleted it once you had finished.
Doing it this way you would loose no functionality, and probably learn quite a bit about what is possible with Azure along the way.
App Service Plan
An app service plan is the hardware that a web app runs on. In the free and shared tier your web apps share an instance with other web apps. In the other tiers you have a dedicated virtual machine. It is this virtual machine that you pay for. In that case it is irrelevant whether or not you have web apps running on your app service or not, you still have a virtual machine running and you will be charged for that.
To change the App Service Plan via PowerShell, you can run the following command
Set-AzureRmAppServicePlan -ResourceGroupName $rg -Name $AppServicePlan -Tier Free
I was able to accomplish this using the dashboard by selecting the App Service Plan, clicking Scale up (App Service Plan), and then from there if you click Dev/Test you can select the Free tier.
As others have mentioned, you need to script this. Fortunately, I created a repository with one-click deployment to your Azure resources.
https://github.com/jraps20/jrap-AzureVerticalScaling
The steps are intended to be as simple and generic as possible:
Execute the one-click deployment from the repo readme
Select the subscription, resource group etc.
Deploy resource to Azure
Set up your schedule to scale up and scale down as-needed
The scripting relies on runbooks and variables to maintain the previous state of each App Service Plan and App Services within those plans. Some App Services cannot be scaled due to specific settings being used (AlwaysOn, Use32BitWOrkerProcess, ClientCertEnabled, etc.). In those cases, the previous values are stored as variables prior to down scaling and then the original values are reapplied when the services are scaled up.
For more clarity, I have written a blog post that goes into detail. The post is pertaining to Sitecore, but applies to any App Service setup- Drastically Reduce Azure PaaS Hosting Costs in Non-Prod Environments With Scheduled Vertical Scaling. It also includes a brief video tutorial to show its use case.
Myself and others have been using this repository/approach for well over a year and it works great. I mostly use it for POC's to reduce costs when I'm not actively working on something. However, its main intention was for targeting non-prod environments to save costs during non-work hours.
Azure App Service Plan is just an logical concept of a set of features and capacity that you can share across multiple apps. I don`t think you can "pause" a plan, instead you can pause your service. and depends on billing model of each service, you might or might not get charged.
Pausing = Delete or lower tier.
Scripting is the key.
Design Diagram
Use scripts to create (also consider shared resources)
Delete using scripts
Use scripts to recreate.
eg: If we use resource group properly per environment then
Export-AzureRmResourceGroup will create a template for us (everything in the resource group will be pulled out as script). So we can delete it and recreate it anytime.
To pause a VM and stop billing you need to shut is down and deallocate it. Just shutting down still has the capacity reserved as if its running.
Storage can't be shutdown - it can be moved to lower cost tiers.
It is possible to delete azure app hosting plan to stop being charged, but I am wondering if it's possible to disable it somehow. If you delete it, then you lose configuration, etc. But I did not find any options to kind of turn it off, and then put it back online (I suppose it's possible with virtual machines e.g.), or reduce the instance count to 0 somehow. Did someone find a way to do it?
P.S. Sometimes it's possible to switch to free plan, but e.g. it won't work when you have deployment slots, etc.
The only way to 'turn off' an Azure App Hosting Plan is to delete it! While it is up and running you will be charged.
The best solution you've got is to shrink it down to a single small server. The price for that is reasonably low.
The alternative is to automate the whole thing, If you keep the sites you host in Github etc you can create a hosting plan and deploy deployment slots etc from a script. You can host the scripts in Azure Automation, and it becomes a few minutes to redeploy your site. Although this does take a little time to create.
We have a few servers in Azure that are running the same service. We would like them to be part of the same availability set. How do you add these servers together in the same availability set if they were not created in the same cloud service when they were created?
It looks like I would need to rebuild these VM's? If so that kinda sucks.
Please let me know if anyone knows a better way.
Thanks in advance.
Once a VM is created, it can't join an availability set.
However, the image for the VM is available in storage. So, new VMs can be spun up, using the image, this time adding them to the set. And rebuilding the VM from scratch is not needed.
Edit:
I've used the method above to bring up a VM, but I had forgotten that if your VM is running already, capture is the way to go. I'd suggest these steps:
Capture the image of your current VM. This will run sysprep on it, so you will want to be careful with it. (spin up a test VM and play with the steps until you feel confident to move to a production box)
Then when you create a new VM, specify your captured image and your availability set. Then the machine will come up with all your services running in the new set.