Auf einen Blick: Infrastructure as Code (IaC) automatisiert das IT-Infrastrukturmanagement durch Code und bietet konsistente und reproduzierbare Umgebungen. Es integriert sich in CI/CD-Pipelines und verbessert das Konfigurationsmanagement und die Skalierbarkeit.
- IaC reduziert manuelle Prozesse, minimiert Fehler und beschleunigt die Bereitstellung.
- Beliebte Tools sind Terraform, Ansible und AWS CloudFormation, die jeweils für unterschiedliche Managementbedürfnisse geeignet sind.
Infrastruktur ist eines der Kernprinzipien eines Softwareentwicklungsprozesses – sie ist direkt verantwortlich für den stabilen Betrieb einer Softwareanwendung. Diese Infrastruktur reicht von Servern, Load Balancern, Firewalls und Datenbanken bis hin zu komplexen Containerclustern. Infrastrukturaspekte sind über Produktionsumgebungen hinaus relevant, da sie sich über den gesamten Entwicklungsprozess erstrecken. Dazu gehören Werkzeuge und Plattformen wie CI/CD-Plattformen, Staging Umgebungen und Testtools. Diese Infrastrukturüberlegungen nehmen zu, je komplexer das Softwareprodukt wird. Sehr schnell wird der traditionelle Ansatz zur manuellen Verwaltung der Infrastruktur zu einer nicht skalierbaren Lösung, um den Anforderungen moderner DevOps-basierter schneller Softwareentwicklungszyklen gerecht zu werden. Und so ist Infrastructure as Code (IaC) heute zur De-facto-Lösung in der Entwicklung geworden. IaC ermöglicht es Ihnen, den wachsenden Bedarf an Infrastrukturänderungen skalierbar und nachverfolgbar zu erfüllen.
Was ist Infrastruktur als Code?
Infrastructure as Code oder IaC ist der Prozess der Bereitstellung und Verwaltung von Infrastruktur, die durch Code definiert ist, anstatt dies manuell zu tun. Da Infrastruktur als Code definiert ist, können Nutzer Konfigurationen einfach bearbeiten und verteilen und gleichzeitig den gewünschten Zustand der Infrastruktur sicherstellen. Das bedeutet, dass man reproduzierbare Infrastrukturkonfigurationen erstellen kann. Außerdem wird Infrastruktur als Code definiert:
- Ermöglicht die einfache Integration von Infrastrukturen in Versionskontrollmechanismen , um nachverfolgbare und auditierbare Änderungen der Infrastruktur zu ermöglichen.
- Bietet die Möglichkeit, umfangreiche Automatisierung für das Infrastrukturmanagement einzuführen. All diese Dinge führen dazu, dass IaC als integraler Bestandteil des SDLC in CI/CD-Pipelines integriert wird.
- Es entfällt die Notwendigkeit manueller Infrastrukturbereitstellung und -verwaltung. Dadurch können Nutzer das unvermeidliche Konfigurationsdrift der zugrundeliegenden Infrastruktur und Konfigurationen leicht verwalten und alle Umgebungen innerhalb der definierten Konfiguration halten.
Deklarativ vs. imperativ Infrastruktur als Code
Beim Umgang mit IaC-Tools gibt es zwei Hauptdifferenzierungsansätze zum Code-Schreiben. Diese beiden Ansätze sind deklarativ und imperativ. Einfach ausgedrückt:
- Ein imperativer Ansatz erlaubt es den Nutzern, die genauen Schritte für eine Änderung anzugeben, und das System weicht nicht von den festgelegten Schritten ab.
- Ein deklarativer Ansatz bedeutet im Wesentlichen, dass Nutzer nur die Endanforderung definieren müssen, und das jeweilige Tool oder die Plattform übernimmt die Schritte, um die definierte Anforderung zu erreichen.
Der deklarative Ansatz wird in den meisten Anwendungsfällen des Infrastrukturmanagements bevorzugt, da er ein größeres Maß an Flexibilität bei der Verwaltung der Infrastruktur bietet. Chef gilt als ein imperatives Werkzeug, während Terraform, Pulumi, CloudFormation, ART, Puppet alle deklarativ sind. Einzigartig ist, dass Ansible meist deklarativ ist und Unterstützung für imperative Befehle bietet.
IaC vs IaaS
Wichtig ist, dass IaC keine Ableitung von Infrastructure as a Service (IaaS) ist. Es sind zwei verschiedene Konzepte.
- Infrastructure as a Service ist einer der zentralen Cloud-Dienste: Virtualisierte Rechenressourcen – Server, Netzwerkinfrastruktur, Speicher usw. – werden über den Cloud-Dienst bereitgestellt.
- Infrastructure as Code ist ein Werkzeug, das zur Bereitstellung und Verwaltung von Infrastruktur verwendet werden kann. Es ist nicht nur auf cloudbasierte Ressourcen beschränkt. Tatsächlich wenden Sie IaC auf eine Vielzahl von Umgebungen an, einschließlich vor Ort.
Wann und wie man Infrastructure as Code verwendet
IaC mag für einfachere, weniger komplexe Infrastrukturanforderungen unnötig erscheinen, aber das ist nicht korrekt. Jede – jede – moderne Softwareentwicklungspipeline sollte Infrastructure as Code verwenden, um die Infrastruktur zu verwalten. Außerdem überwiegen die Vorteile von IaC bei weitem alle Implementierungs- und Verwaltungsaufwand.
Vorteile von IaC
Hier sind die wichtigsten Vorteile von IaC:
- Reduzierung von Schatten-IT innerhalb von Organisationen und Ermöglichung zeitnaher und effizienter Infrastrukturänderungen, die parallel zur Anwendungsentwicklung durchgeführt werden.
- Direkte Integration mit CI/CD-Plattformen.
- Ermöglicht versionskontrollierte Infrastruktur und Konfigurationsänderungen, die zu nachverfolgbaren und auditierbaren Konfigurationen führen.
- Infrastruktur mit reproduzierbaren Konfigurationen einfach zu standardisieren.
- Effektiv verwalten, Drift konfigurieren und Infrastruktur sowie Konfigurationen im gewünschten Zustand halten.
- Die Möglichkeit, das Infrastrukturmanagement einfach zu skalieren, ohne Investitionskosten oder OpEx-Ausgaben zu erhöhen. Mit IaC reduzieren Sie insgesamt CapEx- und OpEx-Ausgaben, da Automatisierung zeitaufwändige manuelle Interaktionen eliminiert und falsche Konfigurationen reduziert.
Wann sollte man IaC verwenden
Unsicher, wann man IaC nutzen sollte? Die einfachste Antwort ist, wann immer man irgendeine Art von Infrastruktur verwalten muss. Allerdings wird es mit den genauen Anforderungen und Tools komplexer. Manche erfordern ein striktes Infrastrukturmanagement, andere erfordern sowohl Infrastruktur- als auch Konfigurationsmanagement. Dann kommen plattformspezifische Fragen wie die Frage, ob das Tool die nötigen Funktionen hat, Sicherheitsimplikationen, Integrationen usw. Darüber hinaus kommt die Lernkurve ins Spiel, da Nutzer ein einfacheres und unkomplizierteres Werkzeug einem komplexen vorziehen. Die folgende Tabelle zeigt eine Kategorisierung der oben genannten Tools entsprechend ihren idealen Anwendungsfällen.
| Anwendungsfall | Werkzeuge zur Verfügung |
|---|---|
| Infrastrukturmanagement | Terraform, Pulumi, AWS CloudFormation, Azure Resource Templates |
| Konfigurationsmanagement mit etwas eingeschränkten Infrastrukturverwaltungsmöglichkeiten | Ansible, Chef, Puppe |
| Konfigurationsmanagement | CFEngine |
Ein einziges Tool reicht in den meisten Szenarien möglicherweise nicht aus. Zum Beispiel kann Terraform hervorragend für die Verwaltung von Infrastruktur über mehrere Cloud-Umgebungen hinweg geeignet sein, aber bei detaillierten Konfigurationen eingeschränkt sein. In solchen Situationen können Nutzer ein Tool wie Ansible nutzen, um die notwendigen Konfigurationen durchzuführen. Ebenso können Nutzer jedes IaC-Tool kombinieren und in ihren CI/CD-Pipelines je nach genauen Anforderungen verwenden. (Lernen Sie, wie Sie Ihre eigene CI/CD-Pipeline einrichten.)
Werkzeuge und Plattformen für Infrastruktur als Code
Unter dem großen IaC-Dach gibt es alle möglichen Werkzeuge, von dedizierten Infrastrukturmanagement-Tools über Konfigurationsmanagement, von Open-Source-Tools bis hin zu plattformspezifischen IaC-Optionen. Schauen wir uns einige der beliebtesten IaC-Tools und -Plattformen an.
Terraform
Terraform ist das führende IaC-Tool für Multi-Cloud-Infrastrukturen – und für Teams, die Terraform-Workflows mit Control-M orchestrieren müssen, ermöglicht die Integration eine geplante Infrastrukturbereitstellung als regelbaren Schritt in der Produktionsbereitstellungspipeline. Als plattformunabhängiges Tool kann Terraform verwendet werden, um alle Anwendungsfälle zur Infrastrukturbereitstellung und -verwaltung über verschiedene Plattformen und Anbieter hinweg zu erleichtern, während der gewünschte Zustand in den Konfigurationen gewährleistet wird.
Ansible
Ansible ist hervorragend im Konfigurationsmanagement in Cloud- und On-Premises-Umgebungen – und für Teams, die Enterprise-Planung und Governance benötigen, koordiniert Control-M für Ansible-Workload-Orchestrierung Ansible-AWX-Jobs in breitere Anwendungs- und Datenpipeline-Workflows. (Erfahren Sie, warum oft Ansible und Control-M verglichen werden.)
Pulumi
Pulumi ist ein relativ neues Tool, das darauf abzielt, ein entwicklerorientiertes IaC-Erlebnis zu bieten. Im Gegensatz zu anderen Tools, die Nutzer zwingen, eine bestimmte Sprache oder ein bestimmtes Format zu verwenden, bietet Pulumi die Freiheit, jede unterstützte Programmiersprache nach Belieben zu verwenden. Dieses Tool unterstützt Python, TypeScript, JavaScript, Go, C#, F#, und der Zustand wird standardmäßig über den Pulumi-Dienst verwaltet.
Koch/Puppe
Chef und Puppet sind zwei leistungsstarke Konfigurationsmanagement-Tools. Beide zielen darauf ab, Konfigurationsmanagement- und Automatisierungsfunktionen mit einigen Infrastrukturmanagement-Funktionen über die gesamte Entwicklungspipeline hinweg bereitzustellen.
- Chef wurde entwickelt, um leicht in DevOps-Praktiken mit umfangreicheren Kollaborationstools integriert zu werden.
- Puppet entwickelte sich, indem es auf die Automatisierung reiner Prozesse abzielte. Heute hat Puppet eingebaute Beobachter automatisiert, um Konfigurationsabweichungen zu erkennen.
(Siehe Puppets State of DevOps-Bericht.)
CFEngine
CFEngine ist eines der ausgereiftesten Werkzeuge, die sich ausschließlich auf das Konfigurationsmanagement konzentrieren. Obwohl es keine Möglichkeit gibt, die zugrunde liegende Infrastruktur zu verwalten, kann CDEngine selbst die komplexesten Konfigurationsanforderungen erfüllen und alles von Sicherheitshärtung bis hin zur Einhaltung abdecken.
AWS CloudFormation
CloudFormation ist das proprietäre, plattformspezifische IaC-Tool von AWS zur Verwaltung der AWS-Infrastruktur. CloudFormation ist tief mit allen AWS-Diensten integriert und kann jede AWS-Konfiguration als First-Party-Lösung ermöglichen.
Azure Resource Templates
Microsoft Azure verwendet JSON-basierte Azure Resource Templates , um IaC-Praktiken innerhalb der Azure-Plattform zu erleichtern. Diese Ressourcenvorlagen gewährleisten die Konsistenz der Infrastruktur und können für jede Art von Ressourcenkonfiguration verwendet werden. Zusätzlich zu den oben genannten gibt es spezialisierte Werkzeuge, die auf spezifische Infrastruktur- und Konfigurationsmanagementaufgaben abzielen, wie zum Beispiel:
- Packer, EC2 Image Builder und Azure Image Builder erstellen bereitstellbare, benutzerdefinierte OS-Images.
- Cloud-Init ist das branchenübliche plattformübergreifende Tool zur Initialisierung von Cloud-Instanzen. Es ermöglicht Benutzern, das Skript bei der Bereitstellung von Ressourcen (Servern) auszuführen.
- (R)?ex ist ein voll ausgestattetes Infrastruktur-Automatisierungs-Framework
(Lernen Sie Azure DevOps kennen.)
Beispiele für Infrastruktur als Code
Betrachten wir ein einfaches Szenario bei der Bereitstellung einer AWS EC2-Instanz. Im folgenden Beispiel sehen wir, wie Terraform-, Ansible- und AWS CloudFormation-Codes für diese Anforderung verwendet werden.
Terraform
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 3.27"
}
}
}
provider "aws" {
access_key = "aws_access_key"
secret_key = "aws_secret_key"
// shared_credentials_file = "/Users/.aws/creds"
region = "us-west-1"
}
resource "aws_instance" "web_server" {
ami = "ami-0123456"
instance_type = "t3.small"
subnet_id = "subnet-a000111x"
vpc_security_group_ids = "sg-dfdd00011"
key_name = "web_server_test_key"
tags = {
Name = "Web_Server"
}
}
Ansible
- hosts: localhost
gather_facts: False
vars_files:
- credentials.yml
tasks:
- name: Provision EC2 Instance
ec2:
aws_access_key: "{{aws_access_key}}"
aws_secret_key: "{{aws_secret_key}}"
key_name: web_server_test_key
group: test
instance_type: t3.small
image: "ami-0123456"
wait: true
count: 1
region: us-west-1
instance_tags:
Name: Web_Server
register: ec2
AWS CloudFormation
AWSTemplateFormatVersion: "2010-09-09"
Resources:
WebInstance:
Type: AWS::EC2::Instance
Properties:
InstanceType: t3.small
ImageId: ami-0123456
KeyName: web_server_test_key
SecurityGroupIds:
- sg-dfdd00011
SubnetId: subnet-a000111x
Tags:
-
Key: Name
Value: Web_Server
Ein Beispiel aus der Praxis: IaC für DevOps
Im Kontext der Softwareentwicklung ist eine grundlegende Einschränkung die Notwendigkeit, dass die Umgebung, in der kürzlich entwickelter Softwarecode getestet wird, genau die Live-Umgebung widerspiegelt, in der dieser Code bereitgestellt wird. Dies ist die einzige Möglichkeit sicherzustellen, dass der neue Code nicht mit bestehenden Codedefinitionen kollidiert: indem Fehler oder Konflikte entstehen, die das gesamte System kompromittieren könnten. Früher folgte die Softwareauslieferung diesem Muster:
- Ein Systemadministrator richtete einen physischen Server ein und installierte das Betriebssystem mit allen notwendigen Servicepacks und Tuning, um den Status der Hauptrechnerin zu spiegeln, die die Produktionsumgebung unterstützt.
- Dann durchläuft ein Datenbankadministrator denselben Prozess für die Support-Datenbank, und die Maschine wird an ein Testteam übergeben.
- Der Entwickler lieferte den Code/das Programm, indem er ihn auf die Testmaschine kopierte, und das Testteam führte mehrere Betriebs- und Compliance-Tests durch.
- Sobald der neue Code den gesamten Prozess durchlaufen hat, können Sie ihn in der Live-Betriebsumgebung bereitstellen. In vielen Fällen funktioniert der neue Code nicht richtig, daher sind zusätzliche Fehlersuche und Überarbeitungen notwendig.
(Verstehen Sie die Unterschiede zwischen dem Bereitstellen und Veröffentlichen von Software.) Eine manuelle Nachbildung einer Live-Umgebung lässt eine Vielzahl wahrscheinlich kleiner, aber potenziell sehr wichtiger menschlicher Fehler offen, bezüglich:
- OS-Version
- Patch-Level
- Zeitzone
- Und so weiter.
Ein Live-Environment-Klon, der mit genau demselben IaC wie die Live-Umgebung erstellt wurde, hat die absolute Garantie, dass es in der geklonten Umgebung auch live funktioniert. Stellen Sie sich einen Softwarelieferprozess vor, der getrennte Umgebungen für DEV, UAT und Production umfasst. Es scheint wenig wert zu haben, eine DEV- und UAT-Umgebung zu haben, die nicht ein exaktes Spiegelbild der Produktionsumgebung ist, da diese frühen Umgebungen entscheidend sind, um die Qualität und Produktionsbereitschaft einer Softwareversion zu messen. Die Einführung der Virtualisierung ermöglichte eine Beschleunigung dieses Prozesses, insbesondere in der Phase der Erstellung und Aktualisierung eines Testservers, der die Live-Umgebung spiegelt. Der Prozess war jedoch manuell, was bedeutete, dass ein Mensch die Maschine entsprechend und zeitnah erstellen und aktualisieren musste. Mit der Einführung von DevOps wurden diese Prozesse noch "agiler". Die Integration von Automatisierung in die Servervirtualisierungs- und Testphasen ersetzt menschliches Eingreifen und verbessert Produktivität und Effizienz. Zusammenfassend: Früher waren mehrere Arbeitsstunden und Personalressourcen erforderlich, um den Software-Deployment-Zyklus abzuschließen (Entwickler, Systemadministratoren, Datenbankadministratoren, Operationstester). Jetzt ist es möglich, dass der Entwickler alle Aufgaben allein erledigt:
- Der Entwickler schreibt den Anwendungscode und die konfigurationsmanagementbezogenen Anweisungen, die Aktionen aus der Virtualisierungsumgebung und anderen Umgebungen wie Datenbank, Appliances, Testtools, Liefertools und mehr auslösen.
- Bei der Auslieferung des neuen Codes erstellen die Konfigurationsmanagement-Anweisungen automatisch eine neue virtuelle Testumgebung mit einem Anwendungsserver plus Datenbankinstanz, die die Struktur der Live-Betriebsumgebung exakt widerspiegelt, sowohl hinsichtlich Service Packs und Versionsmanagement als auch in Live-Daten, die in diese virtuelle Testumgebung übertragen werden. (Dies ist der Infrastructure as Code-Teil des Prozesses.)
- Anschließend führt eine Reihe von Tools notwendige Compliance-Tests sowie Fehlererkennung und -behebung durch. Der neue Code ist dann bereit für die Bereitstellung in der Live-IT-Umgebung.
Schnelle, nachverfolgbare Infrastrukturänderungen
Infrastructure as Code ist zu einem wichtigen Bestandteil moderner Anwendungsentwicklungs- und Bereitstellungspipelines geworden. Es wird erreicht, indem schnelle und nachverfolgbare Infrastrukturänderungen ermöglicht werden, die direkt in CI/CD-Plattformen integriert werden. Infrastructure as Code ist für beides entscheidend:
- Erleichterung skalierbarer Infrastrukturverwaltung
- Effizientes Management der Konfigurationsabweichungen in allen Umgebungen
Der Einstieg in Infrastructure as Code mag mit vielen verschiedenen Tools und Plattformen für unterschiedliche Anwendungsfälle entmutigend erscheinen. Überwinden Sie jedoch diese Hürde, und Sie haben einen leistungsstarken Infrastruktur-Managementmechanismus griffbereit.
Verwandte Literatur
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.