If you need any custom configuration or setup on your Windows Azure Cloud Services you can opt to run a startup task. In essence you get a command prompt and can even execute with elevated privileges. Since this startup task runs before you have any real access to the instance you cannot at the time of execution remote into the instance and see what’s going on physically (or I guess virtually) on the box. The debugging process here is cumbersome, time consuming and requires chicken bones, voodoo dolls and patience. But there is a work around which takes a lot of the pain out of the process!
This is a post related to the Stack Overflow question “Azure Cloud Services file system access”.
Why would you use a Startup Task?
If you require an installation to be run on the box or some configuration is required before your application actually launches you would need this startup task. I have done this myself in order to for instance install .NET Framework 4.0, 4.5 and so on before it was supported out of the box on the machine.
Also another thing to understand here, in case you’re new to this, is that the virutal machine instances that host your application on the PaaS platform that is Microsoft Windows Azure will now and then reboot and/or shift you over to another instance. The reason for this is twofold; 1) Microsoft will patch your OS on the instances for you taking that maintenance task out of your way. 2) If something goes wrong with the environment where one of your instances is running, anything at all, the Platform will detect this and attempt to self heal.
This means that what ever setup you require on your Cloud Services which cannot be handled at application launch must be automated and run immediately at startup of the instance using a Startup Task.
Now as usual in my blog some suitable tunes:
(Working in the Coal mine - Lee Dorsey 1966)
Let's set the scene:
First this is a script you generally need to set up once and only once for the lifetime of your project. Perhaps upgrading it and maintaining it is in order down the line but in general this is a one time thing. What I’m saying is that this is a transitional pain which does go away.
Second you should use Power Shell! The basic setup I always use is to configure the startup task (as you can see above in the link) which is a command prompt .cmd file and then immediately call into a Power Shell script. Once you have PS with elevated privileges the machine is yours to do what every you like on! I’ve written stuff to the registry and run msi packages and so forth. Anything you like – you own the box – as long as it is automated and can be repeated over and over again.
How do I debug this?
I advice you to script this and debug it on the machine itself using Remote Desktop! Once you have the Power Shell script is setup right for what ever it is you need to do on the machine you simply copy the script into the Power Shell file you call from the startup task!
But Magnus, you said this runs before you have access to Remote Desktop into the machine?
Yes that’s right if you choose to try to debug the actual Startup Task this is right. What I am suggesting is that you debug the Power Shell script! Let me explain:
When you start an instance of a Cloud Service Microsoft provisions for you a blank image of a Virtual Machine running Windows Server. The Startup Task would run immediately after the instance boots up. Thus you can disable your Startup Task from configuration (say you remove everything from the .ps1 file) and let the instance boot up fully. After the machine has started your application will run. Now if your application is unable to start due to the fact that no startup task has run then simply replace your actual application with a dummy (File –> new Project) for now in order for the instance of your Cloud Service to be able to boot. THEN you remote into the machine and open up Power Shell. Execute your .ps1 file from the PS command prompt and see what happens! Nothing! We removed the script from the file just now remember! Doh! :) No silly I mean put your script back into the file and then execute it. See what’s wrong with it and debug it ‘til your heart’s content. Need to start over? Just launch another instance of the Cloud Service and you’ll have a brand new instance to play with. Once you have you Power Shell script running the way you like you copy it back into your application and deploy it including the script.
Even though this might seem cumbersome too remember you will only do this once per application lifecycle.
I’ve used this approach myself upon a number of occasions and it’s a pretty solid way of doing it that actually works!
Hope this helps!
No comments yet. Be the first!