Warum man die Windows Azure VM Role (meistens) nicht braucht

Für viele (und mich bis vor kurzem eingeschlossen) sind die Windows Azure Instanzen nur unzureichend Konfigurierbar. Man hat ein nacktes Windows + IIS und .NET Framework installiert. Wer andere Sachen machen will, muss die VM Role nehmen - so liesst man es meistens. Allerdings sind selbst die normalen Windows Azure Instanzen wesentlich Vielseitiger und häufig braucht man keine VM Role...

Ich brauch Ruby, Java, Node.js auf Azure...

Um es einfach zu sagen: Alles was man einfach auf einem Windows Server installieren kann, kann man auch auf einer regulären Azure Instanz zum Laufen bekommen.

Geheimrezept: Software nachinstallieren

Beim Starten einer Instanz kann man sowohl im Code darauf regieren, z.B. über den RoleEntryPoint oder über ein Startup CMD:

<ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
   <WebRole name="WebRole1">
      <Startup>
         <Task commandLine="Startup.cmd" executionContext="limited" taskType="simple">
         </Task>
      </Startup>
   </WebRole>
</ServiceDefinition>

Dadurch, dass der Startup Task einfach ein CMD aufruft kann man dort eigentlich alles machen. Steven Marx hat eine Seite zusammengestellt (http://things.smarx.com/), in dem er ein paar coole Beispiele zeigt, was man mit Azure machen kann:

Die Installscripts sehen zwar etwas... gewöhnungsbedürftig aus, aber einige nette Beispiele sind ja dabei. Hier z.B. wie man Phyton installiert:

cd %~dp0
for /f %%p in ('GetLocalPath.exe Python') do set PYTHONPATH=%%p

msiexec /i python-2.7.1.msi /qn TARGETDIR="%PYTHONPATH%" /log installPython.log

%PYTHONPATH%\python -c "import sys, os; sys.path.insert(0, os.path.abspath('setuptools-0.6c11-py2.7.egg')); from setuptools.command.easy_install import bootstrap; sys.exit(bootstrap())"
%PYTHONPATH%\scripts\easy_install Pygments-1.4-py2.7.egg

echo y| cacls %PYTHONPATH% /t /grant everyone:f

exit /b 0

Der Trick besteht darin, die Installationsmedien einfach mit auf die Azure Instanz zu deployen und beim Starten zu installieren bzw. den Dienst anzumachen, z.B. im Falle von Node.js:

var proc = new Process()
{
    StartInfo = new ProcessStartInfo(
        RoleEnvironment.GetLocalResource("Executables").RootPath + @"\node.exe",
        string.Format("server.js {0}",
            RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["HttpIn"].IPEndpoint.Port))
    {
        UseShellExecute = false,
        WorkingDirectory = RoleEnvironment.GetLocalResource("Executables").RootPath
    }
};

Vorteile dieser Variante

Bei VM Roles muss man sich selber um das Updaten des Betriebssystem kümmern. Weiter unten ist noch ein Blogpost verlinkt, der auf die Punkte SLA, Statelessness und Updating genauer eingeht. Ob die Beispiele von der Seite Best Practices sind, kann ich allerdings nicht einschätzen - es scheint zu gehen und bevor man sich intensiver auf die VM Geschichte einschießt, sollte man diese Alternative kennen.

Nachteile

Komplexe Installationen dauern natürlich... und können auch fehlschlagen. Wenn der Fabric Controller die VM verschiebt, dann ist es ungünstig, wenn es lange dauert bestimmte VMs hochzufahren - in der Zeit stehen nicht die benötigten Ressourcen zur Verfügung.

Fazit

Wenn man keine "Standard”-Azure Komponenten verwenden kann oder zusätzliche Tools installieren muss, der kann das über diverse Wege auch mit regulären Windows Azure Instanzen machen - wenn die Anwendung zu komplex ist (z.B. ein Sharepoint / TFS), dann wird es natürlich wesentlich schwieriger bis unmöglich. Ein Blick auf die Beispiele hier geben aber einen netten Einblick.

Ein guter Blogpost darüber ist auch hier zu finden:

When to deploy a VM Role in Windows Azure?