I am eager to automate the process of swapping between WebApp slots on azure:
https://octopus.com/docs/deploying-applications/deploying-to-azure/deploying-a-package-to-an-azure-web-app/using-deployment-slots-with-azure-web-apps
but for everything to date I have tried to avoid using powershell, and stayed in a Linux/Ansible automation environment. I have looked through the ansible azure modules:
http://docs.ansible.com/ansible/latest/list_of_cloud_modules.html#azure
for something to help out here, but other than my favorite module azure_rm_deployment_module, I don't see anything that can help me automate this kind of procedure. Currently I am using Azure with all Node/Linux resources and setting up a Windows VM to invoke PowerShell (PS) commands like Switch-AzureRmWebAppSlot, seems to deviate from that plan. I could always try to debug what the PS command is doing and attempt to simulate it, however if anyone has a better solution it would be great to hear it!
No, the closest you can get is run a script to do the job (powershell\azure cli). Azure Powershell works on linux (that's what I'm using for some of my ansible tasks), alternatively Azure CLI works as well
If there is a way to use arm to perform the action, you should be good using the azure_rm_deployment module. A trick I've used in the past is to use fiddler with https tracing on while performing an action using Azure powershell. For Azure providers that use the arm endpoints, there's a good chance that this will leave you with a semi-clean log of the endpoints/json payload you need to perform the action.
It's fairly hacky, but for a long time this was the only way to get anything done with webapps outside of Powershell, due to the lackiness of Azure's documentation.
Related
I'm working on Dynamic 365 project where we have environments (Azure VM's machine (AOS, BI) ).Now for testing our monthly API release we have to test our environments(Resume, rollback senarios) for that I have to manually simulate the VM failure via adding Throw "Error" keyword in any of the desync or other file ones files generate in respective folder then ones VM failed then I go to VM and remove the Throw keyword and perform Resume/rollback operation.
Now I'm planning to automate this process via yml pipeline where my pipeline task will make failure instead of myself manually doing.
One way I can think I can write a Powershell script and make VM failure though I want to make it failure then perform Resume and Rollback operation.
Can anyone help me with the best and easy approach to achieve this..? May be without modifying file or something else.
Thanks in advance
You can write a Powershell to do this by using Azure VM run command functionality.
By this functionality, you can run your Powershell script remotely instead of RDP to your VM and run it manually.
I have a VM machine that i would like to shutdown/power off at a certain time and then restart at a certain time. I have tried this in task scheduler and obviously i can shutdown at a given time but cant then set the restart time
I would like the VM machine to shutdown at 10pm and restart at 5am and run a task scheduler task i have that restarts key services (that side of it works)
I have played around with automation tasks within azure but run into a variety of RMLogin issues
i just want the simplest way to schedule this
there is no auto-startup as far as I'm aware, so you'd have to use some sort of Automation. There is an official solution from Microsoft. Which is somewhat overkill, but should work (never tried it, tbh). There are various other scripts online that work with Azure Automation. They are easily searchable (like so).
If you go to my blog you can also find an example script that does the same, and an example of a runbook that you can trigger manually to start\stop vms
I would assume you would have gone through the below mentioned suggestion, The automation book https://learn.microsoft.com/en-us/azure/automation/automation-solution-vm-management is the way to achieve this. You can achieve auto shutdown via the portal but not restart and start.
Please check this links that talks about Start and Shut down role of the VM through REST API. You can wire up the end point with Azure Function, Puppet, or Chef to automate this process
VM - Start/Shut down Role(s): https://learn.microsoft.com/en-us/previous-versions/azure/reference/jj157189(v=azure.100)
If anything doesn't work for you I would suggest to leave your feedback.
So to simply answer your question, no, there is not a more simple way to achieve this.
If you want, you can add your feedback for this feature suggestion here
https://feedback.azure.com/forums/34192--general-feedback
My current application scenario requires me to start several VM simultaneously with some startup tasks (the startup task on each VM triggers the same script but with different parameters). Previously in EC2 I can easily start a number of EC2 instances and then use Windows task scheduler easily to trigger the executable file, read the data in user-data of each instance and then everything is done.
I tried the same approach in Azure but found a number of issues:
Tried using task scheduler and start a task "at startup", but won't work since after syspreping the user information is lost and therefore I won't be able to start the same task.
Tried gpedit.msc and specify a startup script. Won't work. I don't know why.
Tried using task scheduler and start a task at a specific time point. Won't work. I've received an error message which says "the operator or administrator has refused the request".
So what's the simplest approach to automate a startup task in Azure VM?
Did you think about using the Azure-powershell?
You could use the Start-AzureVM-cmdlet to start your VMs.
You could use the following
code-snippet for starts:
$vmuri = Get-AzureWinRMUri -ServiceName $VMName
#region start hpc-azure-nodes
Invoke-Command -ConnectionUri $vmuri -Credential $credential {
#start your tasks with the according parameters
} -ArgumentList
A considerably fancier way would be to create a head-vm in Azure and install a HPC-cluster-manager. Utilizing the HPC-cluster-manager you can provision any number of Azure computing nodes within your limit, deploy your software and start/stop your software centrally from the cluster-manager.
Additionally the HPC-cluster-manager provides a number of helpful features:
add/remove nodes
connect via rdp to each node
view logging information for your jobs
and many, many more
There is also a HPC-powershell which provides a nice environment for automation. Admittedly this approach requires somewhat more effort but in the long run it almost certainly pays off.
I think what you're looking for is PowerShell Desired State Configuration (DSC).
This is a management platform introduced in PowerShell 4.0. You can use it to configure a VM or set of servers by providing a description of the desired state for each node in the system. Basically you can describe the state you want the server to be in when it boots up and if the configuration has drifted it will correct it.
A DSC script can:
Manage registry keys
Copy files and folders
Run PowerShell scripts
Deploy software
Manage server roles
Turn Windows features on/off
Here is a quick tutorial at blog.msdn.com that will get you started.
The "Best Practice" for Azure Cloud Services describes the ugly hacks that make the most of the 1970s-era command line configuration API. (Sorry, I'm not quite old enough to realize the injustice I'm likely doing to computing in that decade.) The debugging approach is to output stdout and stderr to a file in %TEMP%.
My question is how can I access the file? Do I have to Remote Desktop in, or is there a better way, i.e. some sort of remote file system access?
I realize it's a nuisance to say the least to debug the actual Startup Task of a Cloud Service. I don't particularly enjoy it myself. There is a good way to do it though which takes a lot of the pain out of the process!
I advice you to script this and debug it on the machine itself using Remote Desktop! Once you have the script setup right for whatever it is you need to do on the machine, you simply copy the script into the startup task!
What I'm saying is remove the Startup task and let your Cloud Service launch fully. Then Remote into the instance and debug your script on the box.
I have a more lengthy explanation of this on my blog: How to set up and debug the Startup Task in a Windows Azure Cloud Service.
You'll be unable to RD there until the instance has been started. So if you have a problem during startup you're screwed with this approach. Additionally if the VM is returned to Azure (you scale out, then scale in or the VM is considered faulty) you lose all the logs.
The only reliable solution is to use permanent storage such as blob storage. This post (item 2) shows a decent implementation.
I need to be able to generate some type of Scheduling service within Windows Azure, but which is the best and most resilient?
Currently I have a Windows Service running Quartz, which works okay, but on a Windows Server. I need this to run in the cloud.
The tasks, read/write to a database and some will send emails.
I've looked over all the possible solutions in Stack Overflow, but they appear to be old and not updated to the latests Azure Platform.
Any suggestions or pointers?
The most adapted solution might be a worker role, MS has a tutorial specifically for what you're looking for: http://www.windowsazure.com/en-us/develop/net/tutorials/multi-tier-web-site/4-worker-role-a/
This would definitely a less expensive solution than instantiating a virtual machine, but might require some work.
I ended up using the Azure Mobile service and the Scheduler that come with it, which works a treat
I run a Worker Role using Quartz .NET to schedule stuff. Works great!
https://github.com/quartznet/quartznet
Obviously, that would be difficult to do on the cloud since you won't be able to install services or anything that could run in the background. A less than perfect solution would be to have a workstation under your control handle the scheduling and send updates to the web server which would then write them to the DB server. Otherwise, you should self host the website and application, etc.