In der Wolke

Azure Scripting – Der Weg zur Umgebung via Doppelklick

Die Anforderung, eine reproduzierbare Umgebung für eine Serverapplikation wie z.B. für SharePoint in Azure aufzusetzen, ist nicht unüblich. Tools wie der AutoSPInstaller bieten bereits Möglichkeiten, skriptgesteuert eine passende Umgebung ohne besonders viel Aufwand aufzubauen und später auch nahezu identisch für Staging-Systeme bereitzustellen. Danach noch mit SPDocKit kontrollieren ob wirklich alles identisch ist und fertig ist das Staging-System.

Der „Doppelklick – warten – läuft – Experte“

Der Doppelklick-Faktor für SharePoint in einer OnPremise Umgebung existiert demnach bereits. Jedoch ist es trotz Einsatz dieser Helfer immer noch unabdingbar, dass ein Grundverständnis für die Applikation vorhanden ist und man wissen muss, was man da eigentlich automatisiert. Ansonsten erzielt man lediglich den Effekt, dass man die Umgebung gegen die Wand fährt – geplant und automatisiert. Doch was ist mit der Ebene unter der eigentlich Applikation? Wie kann ich sicherstellen, dass die Infrastruktur ebenfalls reproduzierbar ist? Und wie kann ich das Ganze zeitgemäß in der Cloud nutzen?

Diese Fragen sollen durch die Darstellung dieses Erfahrungsberichts im Grundsatz beantwortet werden. Die Zielsetzung war es, die Basisbausteine für eine beliebigen Serverapplikation in Azure aufzusetzen. Dazu wurde eine Umgebung mit einem Domänencontroller und einem aufgenommen Domänenmember als minimale Umgebung definiert. So sollten alle prinzipiellen Mechanismen mindesten ein Mal berücksichtigt werden. Und weils so schön ist, soll alles mit einem ausgiebigen Doppelklick-Faktor versehen werden und automatisiert ablaufen. Im Folgenden werde ich weniger auf die eigentlichen Skriptzeilen eingehen, sondern eher eine Art Ablaufplan vorstellen.

Classic vs. Resource Manager

Auf der Suche nach den ersten Trampelpfaden, die benutzt werden könnten, stellte sich schnell die Frage nach dem „richtigen“ Deploymentmodell. Zur Auswahl standen das Classic- und das ResourceManager Modell. Innerhalb der ersten Skriptzeilen kam noch der unbewusste Versuch auf, beide miteinander zu kombinieren. Der Versuch endete ziemlich schnell in einer Sackgasse, sodass das neuere Modell via ResourceManager konsequente Anwendung fand.

Der Weg zum Ziel

Die bekannten Infrastrukturelemente aus der OnPremise Umgebung waren relativ schnell erstellt. Allerdings bringt die Cloud an der ein oder anderen Stelle ganz eigene Konzepte mit, und es werden Komponenten benötigt, die OnPremise nicht notwendig sind. Um einen Überblick zu bekommen, welche Komponenten zu welchem Zeitpunkt benötigt werden, habe ich mir einen schematischen Ablaufplan erstellt:

In der Flussskizze zeigen sich Elemente, die cloudspezifisch sind:

Ich muss zugeben, dass sich diese Darstellung des Ablaufs erst im Laufe der Entwicklung ergab. Besonders die Einsicht zum Bedarf einer Extension kam relativ spät.

Das Zielsystem

Ein Verständnis für die einzelnen Komponenten ist jetzt aufgebaut. Doch wie sieht es mit den Abhängigkeiten dieser Elemente aus?

Um dieser Frage eine Antwort gegenüber zu stellen wird nachstehend eine visuelle Aufbereitung des Zielsystems gezeigt. Denn manchmal sagt ein Bild mehr als 1000 Worte:

Das gezeigte Strukturgramm entspricht nicht ganz dem Best Practice Ansatz von Microsoft. Im Abschnitt „Wie geht’s weiter?“ werden noch einige mögliche Verbesserungspotenziale aufgezeigt.

Stolpersteine

Bevor die Idealvorstellung erfolgt möchte ich noch kurz auf ein paar Stolpersteine eingehen, die im Laufe der Entwicklung aus dem Weg geräumt werden mussten.

Join von Member via Erweiterung

Beim Join des Members muss ein kleiner Umweg genommen werden. Es bedarf einer VM-Extension, um den Join zwischen zwei Azure VMs realisieren zu können. Leider ist dieses Kapitel – im Gegensatz zum Rest – derzeit nicht gut dokumentiert. Daher möchte ich an dieser Stelle auch einen kleinen Einblick in die Skriptzeilen darstellen:

Remote Powershell Sessions

Auch bis die erste Remote Powershell Session in einer Azure VM funktionierte hat es etwas gedauert. Daher auch hier ein paar Zeilen wie ich das Problem lösen konnte:

Probleme mit dem KeyVault, wenn man nicht Besitzer ist

Zwischenzeitlich habe ich die MPN Subscription eines Kollegen genutzt und hatte dabei erhebliche Berechtigungsprobleme mit dem KeyVault. Leider habe ich es nicht hinbekommen diese zu lösen, sondern konnte lediglich durch manuelle Handgriffe eine Lösung finden. Sobald ich die Berechtigung für Key und Secret wie folgt eingestellt hatte, konnte ich mein Skript problemlos weiterführen.

Key:

Secret:

Wenn hier jemand weiterhelfen kann wäre ich sehr dankbar. Die derzeitigen Zeilen lauten:

Viel Bewegung in der Azure API

Und zum Abschluss noch ein genereller Stolperstein, der leider nicht komplett aus dem Weg geräumt werden kann: Bei Ausführung des Skripts werden immer wieder gelbe Warnhinweise gegeben, dass sich in naher Zukunft bei einigen Befehlen etwas ändern wird. Demnach ist viel Bewegung in der API und es ist nicht garantiert, dass ein geschriebenes Skript auch noch nächste Woche funktioniert.

Wie geht’s weiter?

Natürlich muss die Umgebung noch in der Anzahl der VMs erweitert werden. Allerdings gilt: umso größer die Umgebung wird, desto ratsamer ist es, einen Jump-Server in die Umgebung einzubauen. Alle Verbindungen zu den VMs laufen dann über diesen Jump-Server. Somit wird nur eine öffentliche IP und ein Network Interface benötigt und es ergibt sich auch nur noch ein potenzieller Attack-Point für die gesamte Umgebung. Das Ganze hat dann zwar etwas von „Inception“ und man muss Level drei der PowerShell Session bedienen um alles handhaben zu können, aber es entspricht auch den Best Practice Ansätzen von Microsoft.

Ist die Umgebung erst ein mal erstellt lässt sich ein Automatisierungsskript aus Azure exportieren. Dies kann für Dokumentationszwecke missbraucht werden oder für eine Reproduktion der Umgebung. Bei der Reproduktion ist zu beachten, dass trotzdem einige Namen geändert werden müssen. So ist beispielsweise der Name des Storage Account zwangsweise einzigartig. Zudem lassen sich nicht alle Elemente mit diesem Skript exportieren. Die genutzte VM-Extension kann z.B. darüber nicht wiederhergestellt werden.

Ich hoffe mit diesen Einblick konnte eine kleine Unterstützung, für alle die auch mal für Azure Skripte erstellen möchten, dargeboten werden. Zum Abschluss gibt’s noch ein kleines Video vom Durchlauf des Skripts. Viel Spaß.

 

2 thoughts on “Azure Scripting – Der Weg zur Umgebung via Doppelklick

  1. Danke für die gute Aufbereitung an dieser Stelle! Ich konnte schon bei der BASS den entsprechenden Vortrag sehen. Ich denke, dass eine automatisierte Bereitstellung in Azure wichtig ist, egal ob Entwicklungssystem(e) oder Kundendeployment. Cool wäre ein Tool, bei dem man sich die Umgebung zusammenstellen kann. Aus SharePoint-Sicht zum Beispiel für eine OnPremise-Demo-Umgebung in Azure: 1 Domain-Controller, 1 SQL-Server, 2 Applikationsserver mit (…), 2 Web-Frontendserver, 1 Exchange, 1 Office Web und 2 bis 5 Client-VMs mit entsprechend eingerichteten AD und Exchange – Konten. Interessant wäre die Geschichte auch für eine Online-Demo-Umgebung: Neuer Tenant, Benutzer einrichten, Client-VMs passend aufsetzen. Fertig!

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.