Infrastruktur-als-Code-Tools
- 15 Minuten
Der Zweck eines Konfigurationsverwaltungssystems in jeder Branche, einschließlich der Informationstechnologie, besteht darin, die Prozesse zum Erstellen, Gestalten und Zusammensetzen eines optimal entwickelten Produkts zu verwalten und aufrechtzuerhalten. Es gibt zwei Hauptmethoden:
- Die imperative Methode
- Die deklarative Methode
Die imperative Methode
Die imperative Methode, bei der die genaue Abfolge von Anweisungen aufgezeichnet wird, die für die Bereitstellung und Wartung einer Ressource (z. B. eines virtuellen Computers, eines Anwendungscontainers, eines Speicherrepositorys oder eines Benutzerprofils) gemäß geschriebener Spezifikationen erforderlich sind. Hier ist der Endzustand der Infrastruktur das Ergebnis der Ausführung dieser Anweisungen in der angegebenen Reihenfolge.
Die deklarative Methode
Die deklarative Methode, bei der der Endzustand der Infrastruktur vollständig definiert wird. Das System, das diese Infrastruktur aufrechterhält, muss einen Ablaufplan der Vorgänge zusammenstellen, dessen Endergebnis der deklarierte Zustand ist.
Die Wahl, die Unternehmen bei einer Plattform für die Konfigurationsverwaltung und einer Infrastructure-as-Code-Methodik treffen, bezieht sich auf das, was sie für Aufrechterhaltung und Erweiterbarkeit für am wichtigsten halten: ihre Methoden oder ihre Ziele. Beide Ansätze haben Vor- und Nachteile. In dieser Lektion werden die Grundhaltung und Methodik der wichtigsten Plattformen zur Konfigurationsverwaltung untersucht und die Plattformen selbst kurz vorgestellt.
Azure Resource Manager-Vorlagen
Das Azure Resource Manager-Vorlagensystem von Microsoft ist ein Instrument zur Generierung einer expliziten Spezifikation für eine oder mehrere Cloudressourcen. Eine Azure Resource Manager-Vorlage ist als vollständiges Inventar der Werte und Parameter konzipiert, die zur Ausführung von Azure-Anweisungen für die Bereitstellung neuer und die Aktualisierung bestehender Ressourcen benötigt werden. Dieses Inventar wird in JSON ausgedrückt, einem Format, das in der Softwareentwicklung fast allgegenwärtig geworden ist. Azure Resource Manager-Vorlagen sind exklusiv für Azure und können keine Ressourcen für eine Multicloud-Infrastruktur angeben.
Azure Resource Manager-Vorlagen können von Hand generiert werden, aber häufiger werden sie über das Azure-Portal generiert (und bearbeitet) oder Tools wie Visual Studio und Visual Studio Code verwendet. Abbildung 4 zeigt eine Vorlage für die Bereitstellung eines Azure-Speicherkontos. Die Vorlage besteht aus den folgenden Abschnitten:
Ein Parameterabschnitt , der Parameterwerte definiert, z. B. den Namen des Speicherkontos, den der Benutzer beim Ausführen der Vorlage eingibt, sowie optionale Standardwerte und zulässige Werte
Ein Ressourcenabschnitt , der die Azure-Ressourcen definiert, die von der Vorlage erstellt oder aktualisiert werden
Eine Azure Resource Manager-Vorlage kann auch andere Abschnitte enthalten, einschließlich eines Funktionsabschnitts zum Definieren wiederverwendbarer Funktionen, die von der Vorlage ausgeführt werden (z. B. eine Funktion, die einen eindeutigen Kontonamen mit integrierten Programmierausdrücken generiert, die von Azure Resource Manager unterstützt werden), einen Variablenabschnitt , der Variablen definiert, die in der Vorlage verwendete Variablen definieren, und einen Ausgabeabschnitt , der den Wert oder die Werte definiert, die beim Ausführen der Vorlage zurückgegeben werden. Vorlagen bestehen häufig aus Hunderten oder sogar Tausenden von Zeilen. Die Vorlage in Abbildung 4 ist zwar einfach, veranschaulicht jedoch einige der wichtigsten Merkmale von Azure Resource Manager-Vorlagen. Dazu gehören die Fähigkeit, die Parameter zu definieren, die ein Benutzer angeben muss, sowie Einschränkungen für die Eingaben festzulegen. Außerdem die Fähigkeit, die Ressourcen zu definieren, aus denen eine Lösung besteht. Und schließlich die Fähigkeit, die vom Benutzer bereitgestellten Eingaben zu verwenden, um Attribute für die zu erstellenden oder zu aktualisierenden Ressourcen festzulegen.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"storageAccountType": {
"type": "string",
"defaultValue": "Standard_LRS",
"allowedValues": [
"Standard_LRS",
"Standard_GRS"
],
"metadata": {
"description": "Storage Account type"
}
},
"storageAccountName": {
"type": "string"
}
},
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"name": "[parameters('storageAccountName')]",
"location": "[resourceGroup().location]",
"apiVersion": "2018-07-01",
"sku": {
"name": "[parameters('storageAccountType')]"
},
"kind": "StorageV2"
}
]
}
Abbildung 4: Einfache Azure Resource Manager-Vorlage für die Bereitstellung eines Azure-Speicherkontos.
Azure Resource Manager-Vorlagen können mit CLI- oder PowerShell-Befehlen, von in C# und anderen Programmiersprachen geschriebenen Anwendungen oder im Azure-Portal ausgeführt werden. Abbildung 5 zeigt, wie die Vorlage in Abbildung 4 im Portal angezeigt wird. Das Portal stellt die Benutzeroberfläche zum Erstellen einer Ressourcengruppe oder zum Auswählen einer vorhandenen Gruppe bereit und generiert eine Schnittstelle für die eingaben, die im Parameterabschnitt der Vorlage definiert sind . In diesem Fall wird der Name und typ des Speicherkontos, dessen letzterer aus einer Dropdownliste ausgewählt wird, die aus der Aufzählung in der allowedValues Vorlage generiert wird, und nicht aus der Freiform eingegeben.
Abbildung 5: Azure Resource Manager-Vorlage im Azure-Portal gerendert.
Das Erstellen eines Speicherkontos im Azure-Portal erfordert normalerweise viele Eingaben. Durch die Vorlage werden diese auf die für eine bestimmte Bereitstellung benötigten reduziert. Stellen Sie sich eine komplexere Vorlage vor, mit der Dutzende zusammengehöriger Ressourcen bereitgestellt werden, die Hunderte von Parametern erfordern, die aber den gesamten Prozess auf drei von vier vom Benutzer eingegebene Parameter und einen einfachen Klick auf eine Schaltfläche reduziert. Darüber hinaus ist ein Azure Resource Manager-Vorlage idempotent, was bedeutet, dass sie bei jeder beliebigen Ausführung das gleiche Ergebnis liefert. Mit ihrer Hilfe werden neue Ressourcen bereitgestellt und vorhandene aktualisiert.
Eine Azure Resource Manager-Vorlage bietet eine vollständige, eindeutige und idempotente Definition einer Ressource oder einer Ressourcengruppe, die zur Automatisierung von Bereitstellungen und Updates genutzt werden kann. Azure Resource Manager-Vorlagen sind ein Beispiel für Infrastructure-as-Code, das einen deklarativen Ansatz zur Definition von Cloudinfrastruktur verfolgt.
Marionette
Das Konzept von Infrastructure-as-Code sollte ursprünglich für Cloudplattformen im Allgemeinen gelten, einschließlich öffentlicher Clouds sowie Hybrid-Cloud-Plattformen wie VMware vCloud und OpenStack. Azure Resource Manager-Vorlagen sind Azure-spezifisch, aber Puppet ist eine vollwertige Plattform zur Konfigurationsverwaltung, die auf allen Cloudplattformen funktioniert. Puppet ist die moderne Form der Experimente von Luke Kanies aus dem Jahr 2006, bei denen er eine Abstraktionsschicht über die Betriebsumgebung mehrerer Server gelegt hat. Sein Engine ist ein Konfigurationsmanager mit den Hauptaufgaben:
- Verarbeiten der Eingabe einer Spezifikation für den optimalen, gewünschten Zustand eines Systems zur Bereitstellung einer Anwendung oder eines Diensts
- Bestimmen der Abfolge von Schritten, die zum Bereitstellen eines Systems nötig sind, das sich (nahezu) in diesem Zustand befindet
- Ausführen der erforderlichen Schritte zum Erreichen dieses Zustands
Kurz gesagt, was ein Skript in einem anderen Konfigurations-Manager für die Automatisierung zu definieren und zu erhalten versuchen würde, erstellt Puppet als Ergebnis seiner Berechnungen.
Puppet verwaltet die Konfiguration von Ressourcen und Diensten über einen Cluster von Servern über einen zentralen Controllerknoten, der als Master bezeichnet wird, der durch Replikate gesichert wird. Wie der Name andeutet, richtet die Puppet-Plattform eine Master-/Agent-Beziehung zwischen zentralen Knoten und einer variablen Anzahl von Clientknoten ein, auf denen Puppet-Agents installiert sind.
Anstatt wie bei Azure Resource Manager-Vorlagen JSON zu verwenden, arbeitet Puppet mit Anweisungen, die von der Programmiersprache Ruby inspiriert sind, in der Puppet ursprünglich geschrieben wurde. Eine Reihe von Anweisungen für Puppet, die eine Aufgabe zur Infrastrukturverwaltung darstellt (z. B. die Bereitstellung eines Servers mit Linux, MySQL und anderen Komponenten eines LAMP-Stapels), wird durch ein Modul dargestellt, das tatsächlich ein Verzeichnis mit mehreren Dateien in einer bestimmten Struktur enthält. Das Wichtigste dieser Dateien ist das Manifest, das in einer domänenspezifischen Sprache (DSL) geschrieben wird, die für Puppet einzigartig ist. Dieses DSL ist technisch keine Programmiersprache, da er nicht die Schritte angibt, die ein Dolmetscher oder Prozessor ausführen muss, um eine Aufgabe auszuführen.
Wie Abbildung 6 zeigt, ist die Architektur eines Systems, auf dem die Puppet-Plattform ausgeführt wird, überraschend schlicht. Ein Knoten in Puppet ist wie ein Knoten in Kubernetes oder OpenStack ein physischer oder virtueller Server, der Teilnehmer der gemeinsamen Plattform ist. Es gibt Master- und Agent-Knoten. Auf den Servern, die der Master verwaltet, sind aktive Agents installiert. Die Kommunikation erfolgt über SSH-Kanäle. Üblicherweise werden diese Kanäle durch ein lokales Subnetz abgesichert, das zum externen Internet hin geschlossen ist. Module für Puppet-Anweisungen können in einem Repository gespeichert und aus diesem abgerufen werden, obwohl diese Verbindung nicht privat sein muss. Puppet selbst erkennt das Repository nicht als Agent oder Knoten.
Abbildung 6: Standardbereitstellungsarchitektur von Puppet.
Chef
Chef arbeitet mit Agents, die in der Lage sind, ein System in Echtzeit zu überprüfen und dessen Konfiguration und Status zu melden. Die grundlegende Bereitstellungsarchitektur ist einfach (Abbildung 7). Der Server ist so konzipiert, dass er auf einer Arbeitsstation remote betrieben werden kann. Alle Knoten einschließlich des Servers werden mit Chef geladen, obwohl die Funktionalität auf sie verteilt ist. Clientknoten erhalten über die Arbeitsstation des Administrators skriptgesteuerte Anweisungen vom Server.
Abbildung 7: Standardmäßige Bereitstellungsarchitektur von Chef.
Viele Metaphern in Chef stammen aus der Küchensprache. Ein Kochskript wird als Rezept bezeichnet. Die Anweisungen sind in Ruby geschrieben und nicht in einer auf Ruby basierenden domänenspezifischen Sprache, sodass Entwickler, die mit Ruby vertraut sind, damit gleich klarkommen. Alle Rezepte sind in einem Kochbuch enthalten, das als Liefermittel des Chefs dient. Um die Konfiguration für eine Klasse von Aufgaben zu verwalten, schreibt ein Operator entweder ein Cookbook oder bezieht eines aus einem öffentlichen Repository. Der clientseitige Interpreter für diese Anweisungen ist ein Agent namens Knife, der auf jedem Serverknoten installiert ist. Knife empfängt per CLI Anweisungen über SSH.
Im Gegensatz zu Puppet ist ein Chef-Rezept ein Programm, das getestet, optimiert und dann gespeichert wird. Allerdings ist die Art und Weise, wie es geschrieben ist, etwas abstrakter als alle systemabhängigen Skripts, die wir zuvor gesehen haben. Der Einsatz von Ruby ist mehr symbolisch, wobei Knife fähig ist, abstrakte Anweisungen in konkrete umzuwandeln. Diese Anweisungen sind keine Deklarationen wie in Puppet oder Aussagen zu Zielen, Zielvorgaben oder gewünschten Zuständen, sondern vielmehr imperative Befehle. Beispielsweise können auf Serverknoten in einem Rechenzentrum jeweils unterschiedliche Linux-Distributionen installiert sein. Ein Rezept kann Knife anweisen herauszufinden, welche Linux-Version auf einem Knoten installiert ist, und in einer Bedingungsklausel anzugeben, welche Edition eines Pakets für diese Version am besten geeignet ist. Es kann auch Anpassungen an der lokalen Konfigurationsdatei des Pakets vornehmen.
Die Anweisungen von Chef an Knife sind explizit. Bei Chef geht es darum, die Methoden zu definieren und dann zu verfeinern, mit denen eine funktionierende Version einer Lösung erreicht und gepflegt wird. Eine ständige Verfeinerung ist immer noch möglich. Anweisungssequenzen müssen nicht in Stein gemeißelt werden, wie dies oft bei eigenständigen Skripts der Fall ist. Aber zumindest gibt es eine Methodik, um den Weg zu leiten. Es kann bewusst erfolgen, ohne bestehende Prozesse zu unterbrechen, insbesondere wenn diese Prozesse – oder genauer gesagt, ihre Rezepte – so aufgebaut sind, dass sie resilient sind, und um zu testen, ob sich bestimmte Bedingungen geändert haben, bevor wichtige Änderungen an Konfigurationen vorgenommen werden. Gleichwohl hat Chef über die Jahre evolutionäre Weiterentwicklungen erfahren, die strukturelle Änderungen seiner eigenen Rezepte erforderlich machten.
Red Hat Ansible
Ansible ist ein Tool zur Konfigurationsverwaltung, das einige Eigenschaften mit Puppet gemeinsam hat, obwohl es auch wie z. B. Azure Resource Manager-Vorlagen das Konzept einer vollständigen Inventarliste vertritt. Ziel ist ein einzelnes Skript, das einen bestimmten Dienst oder eine Anwendung in einer beliebigen Serverinfrastruktur installiert, konfiguriert und wartet. Sie basiert auf dem Konzept der Pushkonfiguration. Im Gegensatz zu der Situation mit Puppet und Chef, in der clientseitige Agents Anforderungen für aktualisierte Konfigurationen von einem zentralen Server stellen, gibt es keine Remote-Agents im Ansible-System.
Konfigurationsaufgaben für jeden Knoten (nicht "Clients", da keine direkte Beziehung zwischen ihnen und dem Server besteht) basieren auf allgemeinen Playbooks. Ein Playbook ist tatsächlich eine Datenbank, kein Anleitungsskript, das die Bedingungen enthält, die erfüllt sein müssen, damit eine Konfiguration abgeschlossen ist, zum Beispiel für die Installation der Komponenten eines LAMP-Stacks. Der Ansible-Server passt das Playbook an die Besonderheiten und Eigenheiten jedes Knotens an, wobei er die Inventardatenbank der Infrastruktur als Leitfaden verwendet.
Sowohl Playbook als auch Inventar sind in YAML geschrieben, einer Sprache, die ursprünglich als Alternative zu JSON für die Codierung von Daten geschaffen wurde. Abbildung 8 zeigt ein Segment eines Playbooks aus einem Open-Source-Ansible-Repository1, das Benutzer für MySQL einrichtet, sobald das zugehörige Paket installiert wurde. Es gibt keine Anweisungssyntax, sondern nur Schlüssel und Werte. Da diese Werte Übergangszustände darstellen – in diesem Fall für jeden Benutzer in MySQL – findet der Ansible-Server die beste Methode, um diese Änderungen auf die Liste des Systems anzuwenden, das er konfiguriert. Wie einige Befürworter von Ansible argumentierten, kann dies als eine Art Konfiguration des gewünschten Zustands angesehen werden, solange dieser Zustand etwas ist, das mit YAML explizit ausgedrückt werden kann.
- name : Ensure mysql started
become: yes
service: name=mysql state=started enabled=yes
- name: Update MySQL root password for all root accounts
mysql_user: name=root
host={{ item }}
password={{ mysql_root_password }}
login_user=root
login_password=""
state=present
with_items:
- 127.0.0.1
- ::1
- localhost
Abbildung 8: Beispiel eines Ansible-Skripts in YAML.
Zusammenfassung
Die Konfigurationsverwaltung vereinfacht das Verwalten von Cloudressourcen vergleichbar mit der Arbeit eines Mähdreschers, der das Einholen des Getreides vom Feld vereinfacht. Eine CM-Plattform erhebt die Rolle der Serververwaltung von einer Aufgabe zu einem Beruf. Sie ist sich immer des großen Ganzen bewusst und findet Wege, neue Konfigurationen in bestehende Systeme zu integrieren, anstatt nur auf deren Auswirkungen zu reagieren.
In dieser Lektion haben wir die wichtigsten Plattformen zur Konfigurationsverwaltung untersucht und Kontext rund um den Begriff Infrastructure-as-Code bereitgestellt. Aber selbst diese Plattformen bieten nicht alle Funktionen, die Administratoren benötigen, um Cloudlösungen effizient und effektiv zu verwalten. Den nächsten Schritt nach oben stellen Orchestrierungsplattformen dar, von denen eine der beliebtesten Terraform ist, die nicht von ungefähr das Thema der nächsten Lektion ist.
Literatur
- GitHub Ansible-LAMP-Stack-Playbook. https://github.com/jasodeep/ansible-lamp-stack-playbook.
Überprüfen Sie Ihr Wissen
Feedback
War diese Seite hilfreich?
No
Benötigen Sie Hilfe zu diesem Thema?
Möchten Sie versuchen, Ask Learn zu verwenden, um Sie durch dieses Thema zu klären oder zu leiten?