Empfehlungen für die Verwendung von Infrastruktur als Code

  • Artikel

Gilt für diese Empfehlung der Prüfliste "Operational Excellence" für Azure Well-Architected Framework:

OE:05 Bereiten Sie Ressourcen und deren Konfigurationen mithilfe eines standardisierten IaC-Ansatzes (Infrastructure-as-Code) vor. Wie anderer Code auch, entwerfen Sie IaC mit konsistenten Stilen, entsprechender Modularisierung und Qualitätssicherung. Bevorzugen Sie nach Möglichkeit einen deklarativen Ansatz.

In diesem Leitfaden werden die Empfehlungen für die Verwendung von IaC als Standard für Ihre Infrastrukturbereitstellungen beschrieben. Mithilfe von IaC können Sie Ihre Infrastrukturbereitstellungen und -verwaltung in Ihre vorhandenen Softwareentwicklungsmethoden integrieren. Es bietet eine konsistente Standardmethodik für die Entwicklung und Bereitstellung für alle Komponenten Ihrer Workload. Wenn Sie sich auf manuelle Bereitstellungen verlassen, besteht für Ihre Workload das Risiko inkonsistenter Konfigurationen und eines potenziell unsicheren Entwurfs.

Definitionen

Begriff Definition
Deklarative Tools Eine Kategorie von Tools, die den Endzustand einer Bereitstellung definieren und vom System abhängig sind, um zu bestimmen, wie die Ressourcen bereitgestellt werden, um dem definierten Endzustand zu entsprechen.
Unveränderliche Infrastruktur Eine Infrastruktur, die durch eine neue Infrastruktur ersetzt werden soll, die die neue Konfiguration bei jeder Bereitstellung ausführt. Sie darf nicht geändert werden.
Imperative Tools Eine Kategorie von Tools, die die Ausführungsschritte auflisten, die zum gewünschten Endzustand führen.
Modul Eine Abstraktionseinheit zum Teilen von Ressourcengruppen zur Vereinfachung komplexer Bereitstellungen.
Veränderliche Infrastruktur Eine Infrastruktur, die geändert werden soll. Bereitstellungen ändern die Konfiguration der Infrastruktur, anstatt sie durch eine neue Infrastruktur zu ersetzen.

Wichtige Entwurfsstrategien

Wie in der Lieferkette und in den Leitfäden zur Standardisierung von Tools und Prozessen erläutert, sollten Sie eine strenge Richtlinie für die Bereitstellung von Infrastrukturänderungen (einschließlich Konfigurationsänderungen) nur über Code verwenden. Sie sollten IaC über Ihre CI/CD-Pipelines (Continuous Integration und Continuous Delivery) bereitstellen. Die Einführung dieser Richtlinien erzwingt die Konsistenz der Prozesse für alle IaC-Bereitstellungen, minimiert das Risiko von Konfigurationsabweichungen in Ihren Umgebungen und gewährleistet die Infrastrukturkonsistenz in Ihren Umgebungen. Darüber hinaus sollten Sie Ihre IaC-Entwicklungs- und Bereitstellungstools und -Prozesse in einem Stilleitfaden standardisieren. Zu den Empfehlungen für Ihren Stilleitfaden gehören:

Deklarative gegenüber imperativen Tools bevorzugen. Deklarative Tools und die zugehörigen Dateien sind insgesamt eine bessere Wahl für die Bereitstellung und Verwaltung von IaC als imperative Tools. Deklarative Tools verwenden eine einfachere Syntax für ihre Definitionsdateien und definieren nach Abschluss der Bereitstellung nur den gewünschten Zustand der Umgebung. Imperative Tools hängen davon ab, dass Sie die Schritte definieren, die erforderlich sind, um zum gewünschten Endzustand zu gelangen, sodass die Dateien viel komplexer sein können als deklarative Dateien. Deklarative Definitionsdateien tragen auch dazu bei, die technischen Schulden bei der Verwaltung von imperativem Code zu verringern, z. B. Bereitstellungsskripts, die im Laufe der Zeit anfallen können.

Verwenden Sie die nativen Tools Ihrer Cloudplattform und andere branchenerprobte Tools, die nativ in die Plattform integriert werden. Ihre Cloudplattform bietet Tools, um die Bereitstellung von IaC einfach und einfach zu gestalten. Nutzen Sie diese Tools und andere Tools von Drittanbietern, die über eine native Integration verfügen, z. B. Terraform, anstatt Eigene Lösungen zu entwickeln. Native Tools werden von der Plattform unterstützt und enthalten integrierte Funktionen für die meisten Ihrer Anforderungen. Sie werden vom Plattformanbieter ständig aktualisiert, sodass sie bei der Weiterentwicklung der Plattform nützlicher werden.

Hinweis

Wenn Cloudanbieter und Entwickler von Drittanbietern ihre Tools und APIs aktualisieren, können Sie das Risiko von unerwarteten Problemen eingehen, wenn Sie die neueste Version in Ihrer Workload verwenden. Stellen Sie sicher, dass Sie neue Versionen von Tools und APIs gründlich testen, bevor Sie sie einführen. Vermeiden Sie ebenso die Verwendung des Flags "latest" beim Aufrufen eines Tools oder einer API in Ihrem Bereitstellungscode. Achten Sie darauf, die neueste bekannte gute Version für Ihre Workload aufzurufen.

Verwenden Sie die richtigen Tools für bestimmte Aufgaben und Infrastrukturtypen. Über Bereitstellungen hinaus sind mehrere Aufgaben an einem Infrastrukturlebenszyklus beteiligt. Die Konfiguration muss beispielsweise angewendet und verwaltet werden, und das Tool, das Sie für Skriptbereitstellungen verwenden, wie Bicep, ist möglicherweise nicht das beste Tool für jeden Verwaltungsvorgang.

Ebenso erfordert die Anwendung der DSC -Konfiguration (Desired State Configuration, Desired State Configuration, DSC) für verschiedene Infrastrukturtypen möglicherweise unterschiedliche Tools. Beispielsweise gibt es bestimmte Tools wie Ansible für die Verwaltung von DSC für VMs, während Flux ein gutes Tool für die Verwaltung von DSC in Kubernetes-Clustern ist. PaaS-Dienste (Platform-as-a-Service) können verschiedene Tools für die Konfigurationsverwaltung (z. B. Azure App Configuration) bereitstellen, die über IaC verarbeitet werden können. SaaS-Dienste (Software-as-a-Service) sind möglicherweise eingeschränkter, da sie von der Plattform strenger kontrolliert werden.

Denken Sie an alle Aufgaben und Arten von Infrastruktur, die für Ihre IaC-Praktiken gelten, und standardisieren Sie Tools, die die Aufgaben erledigen, die sie erledigen müssen und die in Ihre Entwicklungs- und Verwaltungspraktiken integriert werden können.

Ihre Skripts und Vorlagen sollten flexibel genug sein, um eine Vielzahl von Umgebungen problemlos bereitzustellen. Verwenden Sie Parameter, Variablen und Konfigurationsdateien, um einen Standardsatz von Ressourcen bereitzustellen, die geändert werden können, um eine beliebige Umgebung in Ihrem Codeaufstufungsstapel bereitzustellen. Abstrakte Einstellungen wie Ressourcengröße, Anzahl, Name, Speicherorte für die Bereitstellung und einige Konfigurationseinstellungen. Achten Sie jedoch darauf, dass Sie nicht zu viel abstrahieren. Es gibt Einstellungen, die mit einem Parameter oder einer Variablen abstrahiert werden können, die sich im Laufe des Workloadlebenszyklus möglicherweise nicht oder nur selten ändern. Sie sollten nicht abstrahiert werden.

Hinweis

Vermeiden Sie die Verwendung verschiedener IaC-Ressourcen für verschiedene Umgebungen. Sie sollten beispielsweise nicht über unterschiedliche Terraform-Dateien für Produktions- und Testumgebungen verfügen. Alle Umgebungen sollten eine Datei verwenden. Sie können diese Datei bearbeiten, um sie bei Bedarf in verschiedenen Umgebungen bereitzustellen.

Strategisieren und standardisieren Sie die Verwendung von Modulen. Wie Parameter und Variablen können Module Ihre Infrastrukturbereitstellungen wiederholbar machen. Seien Sie jedoch darüber nachdenklich, wie Sie sie verwenden. Eine standardisierte Abstraktionsstrategie trägt dazu bei, dass Module so erstellt werden, dass sie bestimmte, vereinbarte Ziele erfüllen. Verwenden Sie Module, um komplexe Konfigurationen oder Kombinationen von Ressourcen zu kapseln. Vermeiden Sie Module, wenn Sie nur die Standardkonfiguration der Ressource verwenden. Darüber hinaus müssen Sie bei der Entwicklung neuer Module umsichtig sein. Verwenden Sie bei Bedarf verwaltete Open-Source-Module, z. B. in nicht sensiblen Szenarien.

Dokumentieren Sie Standards für manuelle Schritte. Es kann Schritte im Zusammenhang mit der Bereitstellung und Wartung von Infrastruktur geben, die speziell für Ihre Umgebung sind und einen manuellen Eingriff erfordern. Stellen Sie sicher, dass diese Schritte so weit wie möglich minimiert und klar dokumentiert sind. Standardisieren Sie in Ihrem Stilleitfaden und den Standardbetriebsverfahren manuelle Schritte, um sicherzustellen, dass Aufgaben sicher und konsistent ausgeführt werden.

Dokumentieren von Standards für die Verarbeitung verwaister Ressourcen. Abhängig von den Tools, die Sie für die Konfigurationsverwaltung verwenden, und deren Einschränkungen kann es vorkommen, dass eine bestimmte Ressource von Ihrer Workload nicht mehr benötigt wird und Ihre IaC-Tools die Ressource nicht automatisch entfernen können. Angenommen, Sie wechseln für eine Funktion von VMs zu einem PaaS-Dienst, und die IaC-Tools verfügen nicht über eine Logik zum Entfernen der eingestellten Ressourcen. Diese Ressourcen können verwaist werden, wenn sich das Workloadteam nicht daran erinnert, sie manuell zu löschen. Um diese Szenarien zu behandeln, standardisieren Sie eine Strategie, um nach verwaisten Ressourcen zu suchen und sie zu löschen. Sie müssen auch überlegen, wie Sie sicherstellen können, dass Ihre Vorlagen auf dem neuesten Stand sind. Untersuchen Sie die Einschränkungen Ihrer IaC-Tools, um zu verstehen, was Sie in diesen Situationen möglicherweise planen müssen.

Andere IaC-Strategien

Beachten Sie die folgenden Empfehlungen, die für die Verwendung von IaC für Ihre Workload gelten:

Verwenden Sie einen mehrstufigen Ansatz, um Ihre IaC-Pipelines innerhalb des Workloadstapels auszurichten. Wenn Sie Ihre IaC-Pipelines in Ebenen aufteilen, können Sie komplexe Umgebungen verwalten. Die Bereitstellung von Dutzenden oder Hunderten von Ressourcen als monolithisches Paket ist ineffizient und kann mehrere Probleme mit sich bringen, z. B. unterbrochene Abhängigkeiten. Die Verwendung mehrerer Pipelines, die auf Ebenen ausgerichtet sind, die aus Ressourcen bestehen, deren Bereitstellungszyklen oder Faktoren wie Die Funktionalität eng übereinstimmen, erleichtert die Verwaltung von IaC-Bereitstellungen.

Kerninfrastrukturen wie Netzwerkressourcen benötigen selten komplexere Änderungen als Konfigurationsupdates, sodass diese Ressourcen eine IaC-Pipeline mit geringer Fingereingabe bilden sollten. Je nach Komplexität Ihrer Workload verfügen Sie möglicherweise über eine oder mehrere IaC-Pipelines mit mittlerer undhoher Toucheingabe für Ressourcen. Bei Verwendung eines Kubernetes-basierten Anwendungsstapels als Beispiel kann eine Ebene mit mittlerer Toucheingabe aus clustern, Speicherressourcen und Datenbankdiensten bestehen. High-Touch-Ebenen würden aus den Anwendungscontainern bestehen, die in einem Continuous Delivery-Modus sehr häufig aktualisiert werden.

Behandeln Sie IaC und Anwendungscode gleich. Wenn Sie Ihre IaC-Artefakte wie Ihre Anwendungscodeartefakte behandeln, können Sie die gleiche Strenge für die Verwaltung von Code für alle Pipelines anwenden. Darüber hinaus sollten IaC-Entwicklungs- und Bereitstellungsmethoden Spiegel Anwendungsmethoden verwenden. Die Standards für Versionskontrolle, Verzweigung, Codeaufstufung und Qualität sollten alle identisch sein. Erwägen Sie außerdem, Ihre IaC-Ressourcen mit Ihren Anwendungscoderessourcen zusammenzuordnen. Dadurch wird sichergestellt, dass bei jeder Bereitstellung dieselben Prozesse befolgt werden, und Sie können Probleme vermeiden, z. B. versehentliche Bereitstellung der Infrastruktur vor dem erforderlichen Anwendungscode oder umgekehrt.

Arbeiten Sie mit anderen Teams in Ihrem organization zusammen, um Standardisierung und Wiederverwendbarkeit zu erreichen. Große Organisationen können manchmal über mehrere Teams verfügen, die Workloads entwickeln und unterstützen. Teamübergreifende Zusammenarbeit bei der Einigung auf Standards hilft Ihnen dabei, Bibliotheken, Vorlagen und Module wiederzuverwenden, um Effizienz und Konsistenz in Workloadumgebungen zu erzielen. Ebenso sollten IaC-Tools im gesamten organization standardisiert werden, soweit dies praktikabel ist.

Wenden Sie das Prinzip "Sicherheit als Code" an, um sicherzustellen, dass die Sicherheit Teil der Bereitstellungspipeline ist. Schließen Sie die Überprüfung von Sicherheitsrisiken und die Konfigurationshärtung als Teil des IaC-Entwicklungsprozesses ein. Überprüfen Sie Ihre IaC-Repositorys auf Schlüssel und Geheimnisse, die verfügbar gemacht werden. Ein Vorteil der Verwendung von IaC besteht darin, dass sicherheitsorientierte Teammitglieder Code vor der Bereitstellung überprüfen können, um sicherzustellen, dass die Konfiguration, die für die Freigabe durch Sicherheit genehmigt ist, tatsächlich in der Produktion bereitgestellt wird. Ausführliche Anleitungen finden Sie unter Empfehlungen zum Schützen eines Entwicklungslebenszyklus.

Testen Sie routinebasierte und nicht routinemäßige Aktivitäten. Testen Sie Bereitstellungen, Konfigurationsupdates und Wiederherstellungsprozesse, einschließlich Bereitstellungsrollbackprozessen.

Veränderbare und unveränderliche Infrastruktur

Die Wahl zwischen der Bereitstellung von veränderlicher und unveränderlicher Infrastruktur hängt von einigen Faktoren ab. Wenn Ihre Workload geschäftskritisch ist, empfiehlt es sich, eine unveränderliche Infrastruktur zu verwenden. Wenn Sie über ein ausgereiftes Infrastrukturdesign verfügen, das auf Bereitstellungsstempeln basiert, kann die Verwendung unveränderlicher Infrastruktur sinnvoll sein, da Sie Anwendungscode und neue Infrastruktur zuverlässig bereitstellen können. Umgekehrt kann die Verwendung von veränderlicher Infrastruktur eine bessere Wahl sein, wenn Ihre Methoden für die sichere Bereitstellung vorschreiben, dass das Roll-Forward mit Bereitstellungen, wenn milderbare Bereitstellungsprobleme auftreten, die bevorzugte Option ist. In diesem Fall würden Sie wahrscheinlich die Infrastruktur aktualisieren.

Überlegungen

Verstärkte Spezialisierung: In einigen Fällen bringt die Einführung neuer Sprachen in Ihrem Workloadteam eine Lernkurve mit sich, und die Anbieterbindung kann dies zu einer schlechten Wahl machen. Es ist erforderlich, Ihre Teammitglieder zu trainieren und das richtige Tool basierend auf der Toolunterstützung Ihrer Cloudanbieter zu analysieren.

Erhöhter Wartungsaufwand: Codebasis- und Toolwartungen sind erforderlich, um Ihre IaC-Implementierung aktuell und sicher zu halten. Verfolgen Sie Ihre technischen Schulden ordnungsgemäß nach und fördern Sie eine Kultur, in der schuldenmindernd belohnt wird.

Längere Zeit für Konfigurationsänderungen: Die Bereitstellung der Infrastruktur mithilfe von Befehlszeilenanweisungen oder direkt über ein Portal erfordert keine Codierungszeit und/oder Tests von Artefakten. Minimieren Sie die Bereitstellungszeit, indem Sie empfohlene Methoden wie Codeüberprüfungen und Qualitätssicherungsmethoden befolgen.

Erhöhte Komplexität der Modularisierung: Die Verwendung weiterer Module und parametrisierung erhöht die Zeit, die zum Debuggen und Dokumentieren des Systems benötigt wird, und fügt eine Abstraktionsebene hinzu. Ausgleich der Verwendung von Modularisierung zur Verringerung der Komplexität und Vermeidung von Überentwicklung.

Azure-Erleichterung

Azure Resource Manager-Vorlagen (ARM-Vorlagen) und Bicep sind native Azure-Tools für die Bereitstellung von Infrastruktur mithilfe der deklarativen Syntax. ARM-Vorlagen werden in JSON geschrieben, während Bicep eine domänenspezifische Sprache ist. Beide können problemlos in Azure-Pipelines oder GitHub Actions CI/CD-Pipelines integriert werden.

Terraform ist ein weiteres deklaratives IaC-Tool, das in Azure vollständig unterstützt wird. Sie kann zum Bereitstellen und Verwalten der Infrastruktur verwendet und in Ihre CI/CD-Pipeline integriert werden.

Sie können Microsoft Defender für Cloud verwenden, um Fehlkonfigurationen in IaC zu ermitteln.

Organisationsausrichtung

Cloud Adoption Framework bietet Anleitungen für zentrale Teams zur standardisierten Infrastruktur als Code in den Workloadteams der organization.

Weitere Informationen finden Sie unter Infrastructure as Code in the Cloud Adoption Framework.

Beispiel

Ein Beispiel für eine Virtual Desktop-Implementierung, die über bereitgestellte Resource Manager-, Bicep- oder Terraform-Dateien bereitgestellt werden kann, finden Sie in der Azure Virtual Desktop-Zielzonenbeschleunigerarchitektur und der zugehörigen Referenzimplementierung.

Checkliste für operationale Exzellenz

Weitere Informationen finden Sie im vollständigen Satz von Empfehlungen.

Checkliste für operationale Exzellenz