Einen SQL Server 2014 aus einem Ressource Manager Template in Azure über Visual Studio Team Services deployen

Ich habe gerade ein ziemlich abgefahrenes Video von Julien Stroheker auf Channel 9 gesehen, in dem er zeigt wie man einen virtuellen Rechner unter Azure aus einem Ressource Manager Template über die Visual Studio Team Services (aka Visual Studio Online) bereitstellen kann.Das ganze läuft unter dem Motto Infrastructure As Code oder kurz IaC. Unter IaC versteht man, dass komplette virtuellen Infrastrukturen durch eine Konfigurationsdatei beschrieben werden. Diese Konfigurationsdatei kann man dann z.B. an einen Cloud-Dienst übermitteln der IaaS (Infrastructure as a Service) anbietet. Dieser Dienst baut dann entsprechend der Definitionsdatei die entsprechende Umgebung auf. Das Schöne dabei ist, dass man durch die entsprechende Konfiguration immer dieselbe Umgebung bekommt. Baut man eine Serverumgebung manuell auf kommt es immer wieder vor, dass man Schritte vergisst oder anders ausführt als zuvor. Hierdurch erhält man unterschiedliche Umgebungen. Da der Code sozusagen die Umgebung beschreibt kann man auch von einer „Exceutable Documentation“ sprechen.

Das Video von Julien hat mich dermaßen beeindruckt, dass ich mir gedacht habe „Das baue ich doch mal nach“. Und die Ergebnisse dieser Aktion stelle ich hier im Blogartikel zusammen. Als Ausgangspunkt gehe ich, genau wie Julien von den Azure Quick Start Templates von Microsoft aus. Über den Befehl

git clone https://github.com/Azure/azure-quickstart-templates

hole ich mir die Azure Quick Start Templates von git-hub auf meine lokale Festplatte in das Verzeichnis C:\temp\azuredemo. Damit das funktioniert muss natürlich die Windows Version von git installiert sein, die man hier herunterladen kann

bild01

Nachdem das soweit abgeschlossen ist kopiere ich nun den Inhalt der Ordners 101-vm-simple-windows in einen neuen, leeren Ordner den wir gleich mit den Team Foundation Services verbinden werden.
bild02

Damit wir diesen neuen Ordner in die Team Foundation Services aufnehmen können müssen wir ihn mit dem folgenden Befehl als git Projekt intialisieren:

git init

Nun müssen wir zunächst unter den Visual Studio Team Services ein neues Projekt anlegen. Besitzen Sie bisher keine Visual Studio Team Services Konto können Sie hier recht schnell eins anlegen.

bild03

Ich nenne das Projekt „VM Deployment“, wähle als Prozessvorlage „Agile“ aus und als Versionskontrollsystem natürlich git.

bild04

Es dauert nun einen kurzen Moment bis das Projekt erstellt wird.

bild05

Im folgenden Dialog wählen wir direkt „Add code“ aus, da wir unseren Code zu Visual Studio hinzufügen möchten.

bild06

Nachdem das Teamprojekt erfolgreich angelegt werden konnte müssen wir unser lokales git Repository nun mit den Visual Studio Team Services verbinden. Zum Glück zeigt uns Visual Studio Team Services schon direkt die richtige Befehle an mit denen man das Verzeichnis was wir angelegt haben in die Quellcode-Verwaltung aufnehmen kann. Mit dem Befehl

git status

können wir uns anzeigen lassen wie der Status unseres git Repositorys ist. Da wir bisher noch nichts zur Quellcode-Verwaltung hinzugefügt haben werden natürlich alle Dateien in rot angezeigt.

bild07

Über den Befehl

git add .

Können wir alle Inhalte des Ordners zum git Repository hinzufügen.

bild08

Rufen wir jetzt noch einmal git status auf, so wird angezeigt, dass alle Dateien neu zum git Repository hinzugefügt werden müssen.

bild09

Über den Befehl

git commit -m "init"

können wir den initialen Checkin vornehmen. Als nächstes nehmen wir die Änderungen in Visual Studio Team Services auf, indem wir die beiden Befehl ausführen, die in Visual Studio angezeigt werden. In meinem Fall sind dies

git remote add origin https://gdsbi.visualstudio.com/DefaultCollection/_git/VM%20Deployment
git push -u origin --all

Daraufhin werden die Dateien in Visual Studio Team Services hochgeladen. Hier muss man sich nun natürlich auch noch anmelden. Ein kleiner Tipp an dieser Stelle – man kann sich zunächst bei git nicht mit dem „normalen“ Konto anmelden mit dem man sich auch bei Visual Studio Team Services anmelden kann sondern muss oben im Bereich „Command line or another Git Client“ einen Usernamen und ein Kennwort eingeben. Erst dann funktioniert die Anmeldung an Visual Studio Team Services von der Kommandozeile aus.

bild10

Das habe ich erst nicht gesehen und daher einige erfolglose Anmeldeversuche gestartet. Aktualisiert man nun die Seite Code im Browser, so kann man den Code den wir soeben eingecheckt haben sehen. Unter Visual Studio online ist es möglich, den Code online zu editieren. Hierzu muss man lediglich die Datei anklicken die man ändern möchte und kann dann oben auf das Icon Edit klicken um den Code zu ändern. Was man sehr schon sehen kann ist, dass die Datei azuredeploy.json drei Parameter benötigt, und zwar die Parameter adminUserName, adminPassword und dnsLabelPrefix. Neben diesen Pflichtparametern gibt es auch noch den optionalen Parameter windowsOSVersion, der Standardmäßig auf „2012-R2-Datacenter“ steht. Ich ändere das jetzt einfach mal, indem ich den Code an dieser Stelle so erweitere, dass der Wert „SQL2014SP1-WS2012R2“ zugelassen ist. Außerdem setze ich diesen Wert als Standardwert.

bild11

Die Parameter werden über die Datei azuredeploy,parameters.json eingespielt. Ich ändere die Werte in „testadmin“, „Pa$$w0rd1“ und „GDSBI“.

bild12

Damit wir nun die Maschine auch unter Azure erzeugen können müssen wir dem Projekt noch eine Build Definition mitgeben. Hierzu muss man oben auf BUILD klicken. Durch einen Klick auf das Pluszeichen kann man nun eine neue Build Definition zum Projekt hinzufügen

bild13

Da wir die Build-Definition selbst anlegen wollen müssen wir auf „Empty“ klicken und dann auf „Next“

bild14

Was nun sehr wichtig ist, ist dass wir den Harken bei „Continous Integration“ setzen, d.h. jeder Check-In Vorgang löst automatisch einen Build und ein Deployment aus. Die Build Definition erstellen wir durch einen Klick auf „Create“.

bild15

Unsere neue Build Definition ist natürlich noch leer, daher müssen wir durch einen Klick auf Add build step einen neuen Build Schritt hinzufügen. Im Dialogfenster wird nun „Azure Ressource Group Deployment“ ausgewählt. Hier muss auf die Schaltfläche „Add“ geklickt werden. Danach kann das Fenster geschlossen werden.

bild16

Der Build Schritt muss konfiguriert werden. Hierzu müssen wir als erstes unser Azure Subscription als Endpunkt zu Visual Studio Team Services hinzufügen. Dafür muss man bei der Subscription auf Manage klicken.

bild20

Dann kommt man auf eine Webseite auf der man über „New Service Endpoint“ eine Azure Subscription hinzufügen kann. Im Menü muss man natürlich Azure Resource Manager auswählen.

bild21

 

Nun kommt man zu einem Dialog in dem man eine Dienstverbindung zum Azure Resource Manager einrichten kann.

bild22

Die Infos die in diesen Dialog einzutragen sind, sind ein wenig trickreich (wenn man es wie ich bisher noch nicht gemacht hat). Subscription id, Subscription Name und Tennant Id lassen sich relativ einfach mit Hilfe des folgenden PowerShell Befehls ermitteln:

Get-AzureRmSubscription -SubscriptionName "MSDN-Plattformen"

Bei mir führt dies zu folgendem Ergebnis:

bild23

Für die beiden Parameter Service Principal Id und Service Principal Key muss man im mit der Azure Subscription verknüpften Azure Active Directory eine Anwendung anlegen. Das geht wie folgt. Zunächst einmal klickt man im Azure Portal auf den Punkt Active Directory

bild24

Dort wählt man das entsprechende Active Directory aus und klickt oben auf den Punkt Anwendungen

bild25Unten kann man eine neue Anwendung hinzufügen

bild26

Nun wird ein Dialog angezeigt in dem man auswählt „Eine von meinem Unternehmen entwickelte Anwendung hinzufügen“

bild27

Bei den App-Eigenschaften muss man die Anwendungsurl eingeben. Wir wollen an dieser Stelle ja nur eine Anwendung im Active Directory anlegen und nicht wirklich eine URL für Anmeldungen oder eine APP-ID URL zur Verfügung stellen. Daher können wir hier getrost eine beliebige fiktive URL eingeben. Es wird nicht geprüft welche URL wir dort angeben. Ich habe mich einfach mal für http://gdsazuredeployment entschieden. Zum Schluss einfach auf den Harken klicken.

bild28

Auf der Seite die nun folgt wird die Client-ID angezeigt, diese benötigen wir schon mal für unseren Authentifizierungsdialog als Service Principal Id.

bild29

Den Service Principal Key können wir auf dieser Seite auch erzeugen. Dazu müssen wir nur unten bei Schlüssel eine Dauer angeben wie lange der Schlüssel gültig sein sollte. In unserem Fall wähle ich einmal zwei Jahre aus:

bild30

Damit der Schlüssel nun auch wirklich angezeigt wird muss man diese Seite noch durch einen Klick auf die Schaltfläche Speichern sichern.

bild31

Den Schlüssel sollten wir uns, wie übrigens alle anderen benötigen Information auch, kopieren und wegsichern. Nun haben wir alle Informationen zusammen die wir für das Dialogfeld brauchen und können diese eingeben und die Azure Dienstverbindung aufbauen.

 

Was uns jetzt noch am vollautomatischen Deployment von Azure-Maschinen (bzw. Ressourcen – das ganze funktioniert natürlich auch für andere Ressourcen die über den Resource Manager zur Verfügung gestellt werden können) abhält ist, dass das Anwendungskonto bisher in der Azure Subscription noch keine Berechtigungen besitzt. Um die Berechtigung schnell einrichten zu können wechsel ich in das neue Portal. dort suche ich mir unter dem Punkt Subscription die entsprechende Subscription heraus und klicke dann auf das Symbol zum bearbeiten der Azure Benutzerkontoen innerhalb der Subscription (das sind die Männlein ganz rechts im Bild).

bild32

Unter Add Access suchen wir nun als erstes einmal die Rolle Contributor aus

bild31a

Unter Add Users suche ich dann den gerade erstellten (Anwendungs-) Benutzer heraus, in meinem Beispiel Fall heißt der GDSAzureDeploy

bild33

Einen weiterführenden Artikel zum Thema wie man einen Service Verbindung in Visual Studio Team Services aufbaut kann man hier finden.

Damit ein Deployment nach Azure erfolgreich funktioniert müssen wir den Build Schritt noch zuende konfigurieren. Als Action wähle ich hier Create Or Update Resource Group aus, denn genau das soll beim Build geschehen. Ressourcen in einer Azure Resource Group sollen entweder (wenn sie noch nicht da sind) erstellt werden oder wenn bereits vorhanden sollen diese aktualisiert werden. Das hat zur Folge, dass wenn ich bereits eine virtuelle Maschine unter Azure z.B. als Standard-D1 Maschine konfigurert und deployt habe, mir aber im Nachhinein einfällt dass es vielleicht besser ist eine D2-Maschine zu haben. dann muss ich nur die entsprechende Property in der JSON-Datei ändern und die Datei einchecken. Im Hintergrund fährt der Azure Resource Manager diese Maschine dann herunter, konfiguriert sie um und fährt sie wieder hoch, ohne dass es z.B. auf den angefügten Festplatten zu Datenverlust oder so kommt. Schon sehr cool.

Als Resource Group muss man eine Azure RM Ressourcengruppe angeben und als Location die Azure Location in der die Ressource gehostet werden soll. In meinem Fall ist das West Europe. Unter Template wird die eigentliche JSON Template Datei angegeben und unter Template Parameters die Parameterdatei. Wenn wir wie oben bereits beschrieben vom einfachen VM-Template ausgehen, dann heißt die Template-Datei azuredeploy.json und die Parameterdatei azuredeploy-parameters.json. Der vollständig ausgefüllte Build Schritt sieht bei mir wie folgt aus.

bild34

Damit haben wir schon mal alles am Start was wir benötigen um nun direkt aus Visual Studio Team Services eine virtuelle Maschine in Azure zu deployen. Um zunächst die einfache Maschine aus dem Template zu deployen kann man einen  Build entweder durch eine Änderung an einer Script Datei mit nachfolgendem Speichern auslösen oder man kann neben der Build-Definition den Menübefehl Queue Build auswählen.

bild35

Man kann den Buildprozess auch im Browser nachverfolgen und wenn man alles richtig gemacht hat, dann sieht das ganze wie folgt aus:

bild36

Wechselt man nach erfolgtem Build nun in das neue Azure Portal, so lässt sich die soeben aus Visual Studio Team Services deployte virtuelle Maschine dort finden.

bild37

Wenn man nun in Visual Studio Team Services hingeht und beispielsweise in der Datei azuredeploy.json die vmSize in Standard_D3 ändert und das ganze dann abspeichert

bild38

Wird direkt ein neuer Build gestartet der die Maschine herunterfährt und als Standard-D3 Maschine wieder hochfährt.

bild39

Der geneigte Leser wird sich jetzt sicherlich denken (Übrigens – Respekt dass Sie bis hier hin durchgehalten haben): „Wo ist denn jetzt der SQL Server?“. Das ist eine gute Beobachtung, bisher haben wir ja noch keine SQL Server deployt. Um dies zu tun müssen wir das JSON-Script azuredeploy.json ein wenig umschreiben. Oben in der Datei werden die Parameter definiert. Ersetzen Sie hier den folgenden Code

    "windowsOSVersion": {
      "type": "string",
      "defaultValue": "2012-R2-Datacenter",
      "allowedValues": [
        "2008-R2-SP1",
        "2012-Datacenter",
        "2012-R2-Datacenter"
      ],
      "metadata": {
        "description": "The Windows version for the VM. This will pick a fully patched image of this given Windows version. Allowed values: 2008-R2-SP1, 2012-Datacenter, 2012-R2-Datacenter."
      }

durch

    "windowsImagePublisher": {
      "type": "string",
      "metadata": {
        "description": "The Publisher of Windows Image"
      },
      "defaultValue": "MicrosoftSQLServer"
    },
    "windowsImageOffer": {
      "type": "string",
      "metadata": {
        "description": "The offer of Windows Image"
      },
      "defaultValue": "SQL2014SP1-WS2012R2"
    },
    "windowsImageSKU": {
      "type": "string",
      "metadata": {
        "description": "The SKU Name of Windows Image"
      },
      "defaultValue": "Enterprise"
    },

    "windowsImageVersion": {
      "type": "string",
      "metadata": {
        "description": "The Version of Windows Image"
      },
      "defaultValue": "latest"

Weiter unten muss dann der folgende Code

        "storageProfile": {
          "imageReference": {
            "publisher": "[variables('imagePublisher')]",
            "offer": "[variables('imageOffer')]",
            "sku": "[parameters('windowsOSVersion')]",
            "version": "latest"
          },

Ersetzt werden durch

        "storageProfile": {
          "imageReference": {
            "publisher": "[parameters('windowsImagePublisher')]",
            "offer": "[parameters('windowsImageOffer')]",
            "sku": "[parameters('windowsImageSKU')]",
            "version": "latest"
          },

Bevor wir dieses Script laufen lassen können müssen wir die virtuelle Maschine die oben erzeugt wurde erst einmal löschen, da man bei einer vorhandenen VM nicht einfach das Image aus dem die VM erzeugt wurde ändern kann.

 

Schreibe einen Kommentar

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

%d Bloggern gefällt das: