In diesem Beitrag möchte ich Ihnen zeigen, was meiner Meinung nach der beste Weg ist, um VSTS mit Azure Resource Manager Templates einzurichten.
Einführung
Bei dem Kunden, für den ich derzeit arbeite, richten wir eine neue Azure Big Data Ingestion-Umgebung ein und wollten dabei den Ansatz Infrastructure as Code verwenden. Bei Azure geht das natürlich mit ARM-Templates. Für die Versionskontrolle, den Aufbau und die Bereitstellung verwenden wir Visual Studio Team Services (VSTS).
Über VSTS, Build- und Release-Management
Ich habe verschiedene Konfigurationen mit VSTS gesehen, einige davon, bei denen das Deployment vom Build aus erfolgt, oder direkt im Release Management ohne einen Build. Mein Ansatz ist eine klare Trennung zwischen dem Build und dem Release Management. Der Build ist für das Kompilieren, (Unit) Testen und Erstellen von Artefakten für das Deployment zuständig. Das Release Management ist für das Deployment der Artefakte verantwortlich, die während des Build-Prozesses erstellt wurden.
Fangen wir an
Für diesen Beitrag verwende ich ARM Linked Template, und die Vorlagen erstellen ein Speicherkonto, einen App Service Plan, einen App Service und eine Application Insight Resources.
Hier sind die Vorlagendateien, die ich verwendet habe:
Die Hauptvorlage ist azuredeploy.json(1), die eine der Parameterdateien(2) mit den umgebungsspezifischen Einstellungen verwendet und die verknüpften Vorlagendateien(3) zur Erstellung der Ressourcen aufruft. Für diesen Beitrag habe ich die GitHub-Quellen mit dem Build verknüpft.
Bauen Sie
1. Einrichtung
Ich habe eine Buid-Variable namens environment definiert, die ich während des Builds für die Auswahl der richtigen Template-Parameterdatei verwenden werde.
Der Kunde, für den ich arbeite, verwendet ebenfalls eine DTAP-Umgebung in Azure, so dass jede Ressourcengruppe ein Suffix mit dem Namen der Umgebung enthält. : BlogOlandese-d, BlogOlandese-t, usw..
Die Parameter sind für jede Umgebung unterschiedlich. Deshalb definieren wir diese Variable für die Auswahl der richtigen Parameter (siehe später in diesem Blogbeitrag).
2. AzureBlob Datei kopieren Aufgabe
Da wir eine verknüpfte ARM-Vorlage verwenden, müssen wir die verknüpften Dateien in einen Azure Blob Container hochladen.
Aus der Microsoft-Dokumentation: Der Resource Manager-Dienst muss auf die verknüpfte Vorlage zugreifen können. Sie können keine lokale Datei oder eine Datei, die nur in Ihrem lokalen Netzwerk verfügbar ist, für die verknüpfte Vorlage angeben. Sie können nur einen URI-Wert angeben, der entweder http oder https enthält .
Hierfür verwenden wir den Azure File Copy Task, den ich wie folgt einrichte:
Natürlich muss ein Speicherkonto vorhanden sein, und ich lade die Dateien in einen bestimmten Container hoch. Im Abschnitt output habe ich zwei Variablen definiert: storageURI und storageToken, in denen die URI und die Token, die bei dieser Aufgabe erzeugt werden, gespeichert werden, da wir sie für den nächsten Schritt benötigen.
3. Azure-Ressourcengruppen-Bereitstellungsaufgabe
Die nächste Aufgabe ist die Azure Resource Group Deployment Task, die in diesem Fall nicht richtig benannt ist, weil wir die Vorlage nicht bereitstellen, sondern nur validieren wollen. Glücklicherweise erlaubt diese Aufgabe auch die Validierung.
In diesem Schritt wählen wir nach der Auswahl des Azure-Abonnements "Ressourcengruppe erstellen oder aktualisieren"(1), geben den Namen der Ressourcengruppe an(2) und verwenden dafür die im Schritt Setup definierte Variable. Dann geben wir den Azure-Speicherort an und stellen die Hauptvorlage azuredeploy.json bereit(3). Für die Parameterdatei(4) verwenden wir wieder die Build-Variable $(environment) zur Auswahl der richtigen Umgebungsparameterdatei.
Die Parameterdateien sind wie folgt benannt: azuredeploy.parameter.d.json, azuredeploy.parameter.t.json usw...
Dann müssen wir einige zusätzliche Parameter(5) mit Hilfe der im Azure File Copy Task definierten Ausgabevariablen (storageURI, storageToken) angeben. Diese werden benötigt, weil wir in der Vorlage die Parameter _artifactsLocation und _artifactsLocationSasToken verwenden, um die Speicher-URI für die Dateien zu erstellen.
Der Container ist nicht anonym zugänglich, daher benötigen wir ein SAS-Token, um seinen Inhalt zu erhalten.
Und die wahrscheinlich wichtigste Einstellung(6) in diesem Schritt: Als Bereitstellungsmodus wählen wir "Nur Validierung". Damit wird eine Syntax-/Schemaprüfung der ARM-Vorlage durchgeführt, ohne dass die Ressourcen bereitgestellt werden. Leider tut die Validierung nicht viel mehr, aber sie ist immer noch besser als nichts, denn so wissen wir wenigstens, dass die ARM-Vorlage syntaktisch korrekt ist, wenn der Build erfolgreich war.
4. Ressourcengruppe löschen, wenn sie leer ist Aufgabe
Der Modus "Nur Überprüfung" hat ein kleines Problem: Auch wenn keine Ressource bereitgestellt wird, wird die angegebene Ressourcengruppe erstellt und nicht gelöscht, wenn sich nichts darin befindet:
Aus diesem Grund habe ich eine VSTS-Aufgabe erstellt, die die Ressourcengruppe nur dann löscht, wenn sie leer ist.
Wenn Sie eine Vorlage für eine bereits bestehende Ressourcengruppe mit Ressourcen validieren, lässt diese Aufgabe natürlich alles intakt, sie löscht die Ressourcengruppe NICHT.
5. Build-Artefakte veröffentlichen Aufgabe
Dann veröffentlichen wir die ARM-Vorlagendateien, damit sie im Release Management verwendet werden können.
Die Verantwortung für den Build-Prozess endet hier. Wir haben die Quelldateien genommen, sie validiert und ein Artefakt erstellt.
Freigabe-Management
1. Einrichtung
Im Release Management erstellen wir eine neue Release-Definition und verknüpfen sie mit dem zuvor erstellten Build-Artefakt:
Und wir fügen vier Umgebungen hinzu: Entwicklung, Test, Akzeptanz, Produktion.
Wie viele Umgebungen Sie definieren, hängt von den Bereitstellungsprozessen in Ihrem Unternehmen ab.
Wie bei der Erstellung definieren wir in jeder Umgebung eine Umgebungsvariable, die wir für die Benennung der Ressourcengruppe und die Auswahl der richtigen Umgebungsparameterdatei verwenden werden.
2. AzureBlob Datei kopieren Aufgabe
Die erste Aufgabe besteht wieder darin, die verknüpften Ressourcenvorlagendateien in einen Azure Storage Container zu kopieren. Die Einrichtung ist im Grunde dieselbe wie beim Build, aber wir ändern die Quelle(1) in das Build-Artefakt und den Containernamen(2), um den Container für den Build und die Veröffentlichung getrennt zu halten.
3. Azure-Ressourcengruppen-Bereitstellungsaufgabe
In der Versionsverwaltung wird diese Aufgabe wie der Name schon sagt verwendet: Verteilung!
Auch hier konfigurieren wir diesen Schritt genauso wie beim Build, wir ändern die Quelle der Hauptvorlage(1) und der Parameterdatei(2) und verweisen auf das Build-Artefakt. Aber dieses Mal wird der Bereitstellungsmodus(3) entweder "Inkrementell" oder "Vollständig" sein, beide Optionen werden die Ressourcen bereitstellen.
Informieren Sie sich in der Dokumentation über die Unterschiede zwischen dem inkrementellen und dem vollständigen Bereitstellungsmodus.
Und schließlich werden wir unsere Ressourcen in Azure haben:
Fazit
In diesem Blog-Beitrag haben wir verknüpfte Vorlagen verwendet. Das Gleiche lässt sich mit Vorlagen für einzelne Dateien erreichen, dann müssen die Dateien nicht in Azure Storage hochgeladen werden. Ich wollte Ihnen zeigen, wie der Build- und Release-Prozess mit ARM-Vorlagen getrennt werden kann, wobei die Zuständigkeiten für die Erstellung, Validierung und Artefakterzeugung im Build-Flow und die Bereitstellung im Release-Management-Flow liegen.
Verfasst von
Marco Mansi
Contact