Infrastruktur als Code und VSTS

Geschrieben von Peter Groenewegen und Pascal Naber für das Xpirit Magazin

Ihr Team ist dabei, eine neue Anwendungsfunktion zu entwickeln, und die Infrastruktur muss angepasst werden. Der erste Schritt besteht darin, eine Datei in Ihrem Versionskontrollsystem zu ändern, die Ihre Infrastruktur beschreibt. Wenn die geänderte Definitionsdatei in Ihrem Versionskontrollsystem gespeichert wird, löst sie einen neuen Build und eine neue Veröffentlichung aus. Ihre neue Infrastruktur wird in Ihrer Testumgebung bereitgestellt, und der gesamte Prozess zur Bereitstellung der neuen Infrastruktur dauerte nur wenige Minuten, obwohl Sie nur eine Definitionsdatei geändert und die Infrastruktur selbst nicht angefasst haben. Klingt das wie ein Traum? Es wird Infrastructure as Code genannt. In diesem Artikel erklären wir Ihnen, was Infrastructure as Code (IaC) ist, welche Probleme es löst und wie Sie es mit Visual Studio Team Services (VSTS) anwenden können.

Infrastruktur in früheren Zeiten Wir haben die Art und Weise, wie unsere Infrastruktur behandelt wird, radikal geändert. Vor der Umstellung auf IaC sah es so aus: Unser Operations-Team war für die Infrastruktur der Anwendung zuständig. Dieses Team ist aufgrund all seiner Aufgaben sehr beschäftigt, so dass wir Änderungen an der Infrastruktur rechtzeitig beantragen müssen. Die Infrastruktur für die DTAP-Umgebung wurde teilweise von Hand und teilweise mithilfe von sieben PowerShell-Skripten erstellt. Die Reihenfolge, in der die Skripte ausgeführt werden, ist wichtig und es gibt nur einen IT-Profi, der über die erforderlichen Kenntnisse verfügt. Diese PowerShell-Skripte sind auf mehrere Personen verteilt und werden teilweise auf lokalen Rechnern gespeichert. Der andere Teil der Skripte ist auf einer Netzwerkfreigabe gespeichert, so dass jeder IT-Profi darauf zugreifen kann. Im Laufe der Zeit werden viele verschiedene Versionen der PowerShell-Skripte erstellt, da sie von der Person abhängen, die sie ausführen möchte, und von dem Projekt, für das sie ausgeführt werden.

Abbildung 1: Eine typische Netzwerkfreigabe

Die Konfiguration der Umgebung erfolgt ebenfalls von Hand. Dieser Vorgang führt zu den folgenden Problemen:

• Es dauert zu lange, bis die Änderungen umgesetzt werden.
• Die Erstellung der Umgebung nimmt viel Zeit in Anspruch und birgt ein hohes Risiko, nicht nur weil manuelle Schritte leicht vergessen werden können. Die Reihenfolge der PowerShell-Skripte ist wichtig, aber nur eine einzige Person kennt diese Reihenfolge.
• Darüber hinaus werden die Skripte zu einem bestimmten Zeitpunkt ausgeführt und regelmäßig aktualisiert. Es ist jedoch unklar, ob die Umgebung bei einer erneuten Erstellung dieselbe sein wird.
• Einige Skripte befinden sich auf dem Arbeitscomputer des IT-Profis, manchmal, weil es das Fachgebiet dieser Person ist, und manchmal, weil die Skripte kein Produktionscode sind. In jedem Fall hat niemand sonst Zugriff darauf.
• Einige Skripte werden gemeinsam genutzt, aber im Laufe der Zeit werden viele Versionen desselben Skripts erstellt. Es ist nicht klar, was sich geändert hat, warum es geändert wurde und wer es geändert hat.
• Es ist auch nicht klar, was die neueste Version des Skripts ist. (Siehe Abbildung 1)
• Die PowerShell-Skripte enthielten eine Menge Code. Der Code beinhaltet nicht nur die Erstellung von Ressourcen, sondern prüft auch, ob Ressourcen bereits vorhanden sind und aktualisiert sie gegebenenfalls.
• Der gesamte Prozess der Bereitstellung der Infrastruktur ist ein ziemliches Hin und Her.

Wie Sie sehen, ist die Erstellung von Infrastrukturen ein fehleranfälliger und riskanter Vorgang, der sich ändern muss, um qualitativ hochwertige, reproduzierbare Infrastrukturen zu liefern.

Definition von Infrastruktur als Code Infrastructure as Code ist der Prozess der Verwaltung und Bereitstellung der Computerinfrastruktur und ihrer Konfiguration durch maschinenverarbeitbare Definitionsdateien. Dabei wird die Infrastruktur wie ein Softwaresystem behandelt, wobei die Software

Merkmale von Infrastructure as Code Unser Beispiel für die Bereitstellung der Infrastruktur weist die folgenden Merkmale auf, die in den folgenden Abschnitten erläutert werden:

• Deklarativ
• Eine einzige Quelle der Wahrheit
• Erhöhen Sie Wiederholbarkeit und Testbarkeit
• Verringern Sie die Zeit für die Bereitstellung
• Verlassen Sie sich weniger auf die Verfügbarkeit von Personen zur Erfüllung von Aufgaben
• Verwenden Sie bewährte Softwareentwicklungsverfahren für die Bereitstellung der Infrastruktur
• Idempotentes Provisioning und Konfiguration

Deklarativ

Abbildung 2: Schematische Visualisierung von Imperativ und Deklarativ

Eine Praxis in Infrastructure as Code ist es, Ihre Definitionen in zu schreiben. Definition von Infrastructure as Code Infrastructure as Code ist der Prozess der Verwaltung und Bereitstellung von Computerinfrastrukturen und deren Konfiguration durch maschinenverarbeitbare Definitionsdateien. Dabei wird die Infrastruktur wie ein Softwaresystem behandelt, wobei Software deklarativ und nicht imperativ eingesetzt wird. Sie definieren den gewünschten Zustand der Infrastruktur und lassen das System die Arbeit machen, um dieses Ziel zu erreichen. In der Azure Cloud können Sie deklarative Code-Definitionsdateien als ARM-Vorlagen verwenden. Neben den nativen Tools können Sie auch Tools von Drittanbietern wie Terraform verwenden, um deklarative Dateien in Classic Azure und AzureRM bereitzustellen. PowerShell-Skripte verwenden eine imperative Methode. In PowerShell geben Sie an, wie Sie Ihre Ziele erreichen wollen. Eine einzige Wahrheitsquelle Die Dateien der Infrastrukturdeklaration werden in einem Repository zur Quellcodekontrolle abgelegt. Dies ist die einzige Quelle der Wahrheit. Alle Teammitglieder können die Dateien einsehen, daran arbeiten und ihre eigene Version der Infrastruktur starten. Sie können sie testen und dann Änderungen an die Versionskontrolle übergeben. Alle Änderungen stehen unter Versionskontrolle und können mit Arbeitsaufgaben verknüpft werden. Das Repository der Versionskontrolle gibt Aufschluss darüber, was geändert wurde und von wem. Der Link zum Workitem kann Ihnen sagen, warum es geändert wurde. Es ist auch klar, was die neueste Version der Datei ist. Teammitglieder können problemlos gemeinsam an derselben Datei arbeiten. Erhöhen Sie die Wiederholbarkeit und Testbarkeit Wenn eine Änderung in die Versionskontrolle übertragen wird, wird ein Build initiiert, der die Änderung testen und anschließend ein Artefakt veröffentlichen kann. Dies löst eine Freigabe aus, die Ihre Infrastruktur bereitstellt. Infrastructure as Code macht Ihren Prozess wiederholbar und testbar. Nachdem Sie Ihre Infrastruktur bereitgestellt haben, können Sie Standardtests durchführen, um zu sehen, ob die Bereitstellung korrekt erfolgt ist. Änderungen können in einer DTAP-Pipeline bereitgestellt und getestet werden. Dadurch wird Ihr Prozess der Bereitstellung der Infrastruktur zuverlässig, und wenn Sie erneut bereitstellen, erhalten Sie immer wieder die gleiche Umgebung. Verringern Sie die Bereitstellungszeit Alles ist automatisiert, um die Infrastruktur zu erstellen. Dies führt zu kurzen Bereitstellungszeiten. In vielen Fällen hat eine Bereitstellung in einer Cloud-Umgebung eine Vorlaufzeit von 5 bis 10 Minuten, verglichen mit einer Bereitstellungszeit von Tagen, Wochen oder sogar Monaten. Erreicht wird dies durch das Überspringen manueller Aufgaben und Wartezeiten in Kombination mit hochwertigen, bewährten Vorlagen. Die Automatisierung schafft eine Umgebung, die nicht von Hand angefasst werden sollte. Sie behandelt Ihre Server wie Vieh statt wie Haustiere*. Bei Problemen müssen Sie sich nicht mehr bei der Infrastruktur anmelden, um zu sehen, was schief läuft, und versuchen, das Problem zu finden und zu beheben. Löschen Sie einfach die Umgebung und stellen Sie die Infrastruktur neu bereit, um die ursprüngliche funktionierende Version zu erhalten. Verlassen Sie sich weniger auf die Verfügbarkeit von Personen zur Durchführung von Aufgaben In unserem Team kann jeder die Infrastruktur ändern und bereitstellen. Damit entfällt die Abhängigkeit von einem separaten Betriebsteam. Durch die geteilte Verantwortung kümmert sich das gesamte Team und ist in der Lage, die Infrastruktur für die Anwendung zu optimieren. Dies führt zu einer effizienteren Nutzung der vom Team bereitgestellten Infrastruktur. Operations verbringt jetzt mehr Zeit mit der Entwicklung von Software als mit der manuellen Konfiguration der Infrastruktur. Der Betrieb bewegt sich mehr in Richtung DevOps.

Haustiere gegen Vieh ist eine weit verbreitete Metapher dafür, wie IT-Betriebe mit Servern in der Cloud umgehen sollten. Server sind wie Haustiere. Sie geben ihnen einen Namen und wenn sie krank werden, pflegen Sie sie wieder gesund. Server sind wie Vieh. Man nummeriert sie und wenn sie krank werden, holt man sich einen neuen.

Nutzen Sie bewährte Softwareentwicklungspraktiken für die Bereitstellung der Infrastruktur Wenn Sie Infrastructure as Code anwenden, können Sie bewährte Softwareentwicklungspraktiken für die Bereitstellung der Infrastruktur nutzen. Indem Sie Ihre Infrastruktur auf die gleiche Weise handhaben wie Ihren Code, können Sie den gesamten Prozess rationalisieren. Sie können Ihre Infrastruktur bei jeder Änderung starten und testen. Die Verwendung von Source Control im Team ist ein Muss. Die darin enthaltenen Quellen sollten sich immer in einem Zustand befinden, in dem sie ausgeführt werden können. Daraus ergibt sich die Notwendigkeit von Tests wie z.B. Unit-Tests. Idempotente Provisionierung und Konfiguration Wenn Sie eine idempotente Provisionierung und Konfiguration für die Provisionierung erstellen, können Sie Ihre Releases jederzeit erneut ausführen. ARM-Vorlagen sind idempotent. Das bedeutet, dass das Ergebnis jedes Mal, wenn sie ausgeführt werden, genau dasselbe ist. Die Konfiguration wird auf das festgelegt, was Sie in Ihren Definitionen konfiguriert haben. Da die Definitionen deklarativ sind, müssen Sie sich keine Gedanken darüber machen, wie Sie zum Ziel kommen; das System findet das für Sie heraus. Erstellen einer Infrastructure as Code-Pipeline mit VSTS Es gibt viele Tools, die Sie zur Erstellung einer Infrastructure as Code-Pipeline verwenden können. In diesem Beispiel zeigen wir Ihnen, wie Sie eine Pipeline erstellen, die eine ARM-Vorlage mit einer Visual Studio Team Service (VSTS) Build- und Release-Pipeline bereitstellt. Die ARM-Vorlage wird in einem Git-Repository in VSTS abgelegt. Wenn Sie die Vorlage ändern, wird ein Build ausgelöst und der Build veröffentlicht die ARM-Vorlage als Artefakt. Anschließend wird die Vorlage durch die Freigabe in einer Azure-Ressourcengruppe bereitgestellt oder angewendet.

Abbildung 3: VSTS Versionskontrolle, Build und Freigabe

Voraussetzung Um mit der Erstellung von Infrastructure as Code mit VSTS zu beginnen, benötigen Sie ein VSTS-Konto. Wenn Sie noch kein VSTS-Konto haben, können Sie eines auf der Website visualstudio.com erstellen. Dies ist für bis zu 5 Benutzer kostenlos. Innerhalb des von Ihnen erstellten VSTS-Kontos legen Sie dann ein neues Projekt mit einem Git-Repository an. Der nächste Schritt besteht darin, einige Infrastrukturdefinitionen in das Repository zu übertragen. ARM-Vorlage ARM-Vorlagen sind eine deklarative Möglichkeit, Ihre Infrastruktur zu beschreiben. ARM-Vorlagen sind json-Dateien, die Ihre Infrastruktur beschreiben und 4 Abschnitte enthalten können: Parameter, Variablen, Ressourcen und Ausgabe. Um mit ARM-Vorlagen zu beginnen, lesen Sie bitte Resource Manager Template Walkthrough. Sie können ARM-Vorlagen selbst erstellen, indem Sie den Projekttyp Cloud ? Azure-Ressourcengruppe in Visual Studio wählen. Die Community hat bereits eine Vielzahl von Vorlagen erstellt, die Sie wiederverwenden oder als guten Ausgangspunkt nehmen können. Die ARM-Vorlagen der Community finden Sie in den Azure Quickstart Templates. ARM-Vorlagen werden auf Azure und auch On-Premise mit Microsoft Azure Stack unterstützt. In unserem Beispiel wollen wir eine Web App mit einer SQL Server-Datenbank bereitstellen. Die Dateien für diese Konfiguration heißen 201-web-appsql-database. Laden Sie die ARM-Vorlage und die Parameterdateien herunter und pushen Sie sie in Ihr Git Source Control Repository in Ihrem VSTS-Projekt. VSTS Build Jetzt sind Sie bereit, den Build zu erstellen. Navigieren Sie zur Registerkarte Build in VSTS und fügen Sie ein neues Build hinzu. Verwenden Sie Ihr Git-Repository als Quelle. Vergewissern Sie sich, dass Sie die kontinuierliche Integration aktiviert haben. Dadurch wird der Build gestartet, wenn der Code in das Git-Repository übertragen wird. Als Minimum muss der Build Ihre Dateien in einem Artefakt namens Drop veröffentlichen. Fügen Sie dazu einen Schritt Copy Publish Artifact zu Ihrem Build hinzu und konfigurieren Sie ihn wie folgt:

Abbildung 4: ARM-Vorlage in Git

Abbildung 5: Konfiguration des Artefakts "Veröffentlichen" kopieren

VSTS Release Der nächste Schritt ist die Verwendung von VSTS Release für die Bereitstellung Ihrer Infrastruktur auf Azure. Dazu navigieren Sie zu Release und fügen ein neues Release hinzu. Benennen Sie die erste Umgebung in Entwicklung um und fügen Sie die Aufgabe Azure Resource Group Deployment zur Entwicklungsumgebung hinzu. Mit dieser Aufgabe können Sie Ihre ARM-Vorlage in einer Azure-Ressourcengruppe bereitstellen. Um Ihre Aufgabe zu konfigurieren, müssen Sie einen ARM Service Endpunkt zu VSTS hinzufügen. Wie Sie das tun, lesen Sie im folgenden Blogpost: Erstellen eines Azure Service Principal und eines VSTS ARM Endpunkts. Jetzt können Sie die restlichen Informationen eingeben, d.h. den Namen der ARM-Vorlage und den Namen der Parameterdatei (Abb. 6):

Abbildung 6: Konfiguration der Azure-Ressourcengruppe

Abbildung 7: Klonen einer Umgebung in Release

DTAP Zu diesem Zeitpunkt haben Sie nur eine Entwicklungsumgebung. Jetzt werden Sie eine Test-, Abnahme- und Produktionsumgebung hinzufügen. Der erste Schritt besteht darin, die anderen Umgebungen im VSTS Release Manager zu erstellen. Fügen Sie Umgebungen hinzu, indem Sie auf die Schaltfläche Umgebung hinzufügen klicken oder indem Sie die Entwicklungsumgebung klonen.

Infrastructure as Code hilft Ihnen, in kürzester Zeit eine robuste und zuverlässige Infrastruktur aufzubauen.

Jede Umgebung benötigt eigene Parameter, daher müssen Sie für jede DTAP-Umgebung eine Parameter-Json-Datei erstellen. Jede Umgebung erhält ihre eigene azuredeploy.{environment}.parameters.json-Datei, wobei {environment} für Entwicklung, Test, Abnahme oder Produktion steht.

Abbildung 8: Konfigurieren Sie jede Umgebung mit einer anderen Parameterdatei

Die Bereitstellung kann nach Ihren Wünschen geändert werden. Stellen Sie zum Beispiel pro DTAP-Umgebung eine eigene Ressourcengruppe in Azure bereit. Jetzt haben Sie Ihre erste Version einer Infrastructure as Code-Bereitstellungspipeline. Die Pipeline kann auf verschiedene Weise erweitert werden. Der Build kann mit Tests erweitert werden, um sicherzustellen, dass die Infrastruktur so konfiguriert ist, wie sie sein soll. Die Freigabe kann durch das Hinzufügen von Genehmigern erweitert werden, wodurch sichergestellt wird, dass eine Umgebung nur nach Genehmigung durch eine oder mehrere Personen bereitgestellt wird. Fazit Infrastructure as Code hilft Ihnen, in kürzester Zeit eine robuste und zuverlässige Infrastruktur aufzubauen. Bei jeder Bereitstellung wird die Infrastruktur genau gleich sein. Sie können die von Ihnen verwendeten Ressourcen ganz einfach ändern, indem Sie den Code ändern und nicht die Infrastruktur. Wenn Sie Infrastructure as Code anwenden, sollte alles automatisiert werden, was viel Zeit, manuelle Konfiguration und Fehler spart. Alle Konfigurationen sind gleich, und es gibt keine Überraschungen mehr, wenn Sie Ihre Anwendung für die Produktion freigeben. Alle Änderungen an der Infrastruktur sind in der Versionskontrolle einsehbar. Die Versionskontrolle gibt einen guten Einblick, warum und was von wem geändert wurde. Ein DevOps-Team, das Infrastructure as Code anwendet, ist bei der Ausführung seiner Anwendung auf sich allein gestellt. Das Team ist für alle Aspekte der Umgebung, die es nutzt, verantwortlich. Alle Teammitglieder haben die gleichen Befugnisse und Verantwortlichkeiten, um alles am Laufen zu halten, und jeder ist in der Lage, Änderungen schnell zu beheben, zu testen und bereitzustellen.