Der Begriff "Infrastruktur als Code" wurde in den letzten zwei Wochen mehrfach in unterschiedlichen Zusammenhängen erwähnt. Was bedeutet es konkret, Infrastruktur als Code zu haben?
TL; DR : Infrastruktur als Code ist eine Möglichkeit, Ihre Umgebung zu automatisieren und zu sichern. Im Idealfall können Sie nach einer Katastrophe Ihre Infrastruktur vollständig und automatisch wiederherstellen, indem Sie neue Ressourcen bereitstellen, die Konfiguration aus dem Code-Repository wiederherstellen und Daten aus dem Backup wiederherstellen.
Infrastruktur als Code basiert auf drei Hauptkonzepten:
Automation of Configuration Management , genannt Continuous Configuration Automation, ein von prof. Mark Burgess
Code-Repository für Änderungen an der Infrastruktur, in dem Änderungen zuerst festgeschrieben, dokumentiert, überprüft, getestet und dann durch Automatisierung bereitgestellt werden.
Managed Infrastructure Provisioning. Infrastruktur als Dienstleistung (IaaS). Entweder über Cloud Computing , Private oder Managed Cloud oder Managed Datacenter Services
Das Konfigurationsmanagement befindet sich in der 3. Generation der Tools. Auf CFEngine aufbauend wird derzeit eine Reihe neuer Tools für das automatisierte Konfigurationsmanagement in großem Umfang bereitgestellt. Die beliebtesten in alphabetischer Reihenfolge sind Ansible, CFEngine, Chef, Puppet, PowerShell DSC und SaltStack . Jede hat eine Sprache zur Beschreibung des Status Ihrer Infrastruktur, Codemodule zur Anwendung dieser Änderungen und zur Erweiterung der Tools, einige Agenten zur Ausführung dieser auf den Servern und ein zentrales Informationsrepository.
Sie arbeiten im Allgemeinen im Push- oder Pull-Modus, indem sie entweder eine Verbindung zu Servern von einem oder mehreren zentralen Standorten aus herstellen und Änderungen remote ausführen oder auf jedem Server ausgeführt werden und Informationen zum Status von einem zentralen Standort abrufen und zwar entweder im Client / Server-Modell oder in einem verteilten Weg.
Das wichtige Konzept besteht darin, dass der Systemadministrator oder der Techniker für Standortzuverlässigkeit keine direkten Änderungen an der Infrastruktur vornimmt, sondern die Automatisierung Änderungen vornimmt. Alles, was von Menschen von Hand getan wird, sollte als verderblich angesehen werden und bald durch die Automatisierung oder in strengerer Form, die die Integrität der Infrastruktur verletzt und die Zerstörung und den Wiederaufbau der betroffenen Komponenten auslöst , behoben werden.
Das Code-Repository, das idealerweise von der Repository-Haltesoftware getrennt ist, wird zur Verwaltung aller Änderungen an der Infrastruktur und der zugehörigen Automatisierung verwendet. Es sollte Konfigurationsdateien und -vorlagen, Playbooks (Kochbücher) enthalten, die den zu überprüfenden Änderungsprozess beschreiben, Code zur Erweiterung der CM-Automatisierungstools, Bereitstellungskonfigurationen, Infrastrukturtests und -warnungen, Staging- / Bereitstellungstests, Dokumentation und manuelle (noch nicht automatisierte) Prozessbeschreibungen .
Das wichtige Konzept besteht darin, Peer-Reviews für Änderungen einzuleiten, alle Änderungen aufzuzeichnen und bei unvorhersehbaren und / oder nicht getesteten Problemen automatisch zum vorherigen Status zurückzukehren, Änderungen in der Staging-Umgebung bereitzustellen und Konfigurationsänderungen zu testen sowie die automatische Bereitstellung zu ermöglichen Änderungen ohne Abweichung durch menschliches Versagen.
Das Verwalten der physischen Infrastruktur ist eine reale Aufgabe, die über die Software hinausgeht und ganz unterschiedliche Fähigkeiten erfordert. Indem Sie diese Ebene über Cloud Computing oder ein verwaltetes Rechenzentrum abstrahieren können, können Sie Ihr Team auf den Teil der Infrastrukturverwaltung konzentrieren, der einen Mehrwert für Ihr Unternehmen bietet.
Während Cloud Computing eine Möglichkeit bietet, zu einem späteren Zeitpunkt schnell zu starten und zu skalieren, erkennen Unternehmen häufig einige Vorteile und sogar erhebliche Einsparungen beim Verschieben von Teilen der Infrastruktur in ihren eigenen Rechenzentren für ein Hybridmodell. Das Besitzen oder Mieten der Hardware bedeutet nicht, dass Sie auch die Personen beschäftigen müssen, die damit umgehen. In dieser Größenordnung benötigen Sie Rechenzentren, die geografisch auf der ganzen Welt verteilt sind, und es wäre sehr teuer, Menschen mit allen erforderlichen Fähigkeiten an allen Orten zu haben. Der weltweite Flug mit ihnen erhöht die Latenz bei Änderungen und erhöht die betriebliche Ineffizienz. Dies ist ein weiterer Grund für die Auslagerung des Rechenzentrumsmanagements.
Das Wichtigste dabei ist, dass das Konzept der verwalteten physischen Infrastruktur oft vergessen oder übersehen wird , aber genauso wichtig ist. Selbst wenn Sie alles automatisiert haben und die gesamte Konfiguration in einem gesicherten Code-Repository gespeichert ist, haben Sie einen großen Engpass , der alle Vorteile der beiden anderen Schritte leicht zunichte machen kann , sofern Sie nicht die Möglichkeit einer schnellen Bereitstellung haben .
Bevor ich erkläre, was es genau ist, möchte ich eine wirklich schöne Definition direkt aus Wikipedia zitieren :
Infrastructure as Code (IaC) ist der Prozess des Verwaltens und Bereitstellens der Computerinfrastruktur (Prozesse, Bare-Metal-Server, virtuelle Server usw.) und ihrer Konfiguration durch maschinenverarbeitbare Definitionsdateien anstelle der physischen Hardwarekonfiguration oder der Verwendung einer interaktiven Konfiguration Werkzeuge.
Okay, jetzt schauen wir uns ein solches IaC-Tool an, Terraform, um das Konzept besser zu verstehen: https://www.terraform.io/
Dies ist auch, was Terraform über sich selbst sagt:
Mit Terraform können Sie die Produktionsinfrastruktur sicher und vorhersehbar erstellen, ändern und verbessern. Es ist ein Open-Source-Tool, das APIs in deklarative Konfigurationsdateien kodiert, die von Teammitgliedern gemeinsam genutzt, als Code behandelt, bearbeitet, überprüft und versioniert werden können.
Das heißt, man kann die gesamte Infra kodieren. Dies umfasst die Erstellung von Cloud-Ressourcen (/ infra) wie Serverinstanzen, Load Balancer usw. sowie die vollständigen Konfigurationen (einschließlich der grundlegenden Einstellungsänderungen, Sicherheitseinstellungen, Regionen usw.) als Code, der bearbeitet, versioniert und geändert werden kann natürlich überprüfbar.
Dies ist ein Beispiel für Terraform-Code zum Bereitstellen von AWS-Ressourcen:
resource "aws_elb" "frontend" {
name = "frontend-load-balancer"
listener {
instance_port = 8000
instance_protocol = "http"
lb_port = 80
lb_protocol = "http"
}
instances = ["${aws_instance.app.*.id}"]
}
resource "aws_instance" "app" {
count = 5
ami = "ami-408c7f28"
instance_type = "t1.micro"
}
Bonus PS : Außerdem muss man die Unterschiede zwischen Bereitstellungs- und Orchestrierungswerkzeugen verstehen . Entwickler verwechseln sich sehr oft und neigen dazu, den Fehler zu machen, zu versuchen, ein Werkzeug für das zu optimieren, wofür es nicht vorgesehen ist.