Ordnung halten und Zeit sparen - Infrastruktur als Code

Bei Droptica spielen die Server, auf denen wir von uns entwickelte Websites und Anwendungen hosten, eine sehr wichtige Rolle. Durch die Implementierung von Infrastructure as Code in unserem Unternehmen ist es uns gelungen, die Stabilität und Verfügbarkeit der Dienste zu erhöhen und die Zeit zu optimieren, die für die Implementierung von Änderungen in der Infrastruktur erforderlich ist. Die automatische Serververwaltung hat mehrere unserer Prozesse erheblich vereinfacht.

Infrastructure as Code – worum geht es dabei?

Bis vor kurzem mussten die meisten Unternehmen der IT-Branche und im Bereich der Webdienstleistungen ihre eigenen Server haben, was mit viel Vorbereitung verbunden war – sie in Rechenzentren aufstellen, das Betriebssystem konfigurieren, das Netzwerk einrichten, Sicherheitsmechanismen aufstellen und sich auf die Bereitstellung von Diensten vorbereiten.

Dieser Trend ändert sich jedoch seit einigen Jahren. Wir alle erleben gerade die Cloud-Revolution – Lösungen, bei denen große Akteure auf dem Datenverarbeitungsmarkt ihre ungenutzten Ressourcen anbieten, meist in Form von virtuellen Maschinen, die mit nur wenigen Klicks bereitgestellt werden können. In diesem Fall müssen Sie sich nicht mit dem gesamten Prozess der Vorbereitung einer hardwarebasierten Umgebung auseinandersetzen, was an sich eine großartige Möglichkeit ist, Kosten zu senken. Der größte Vorteil dieser Lösung ist jedoch die schnelle und einfache Bereitstellung, die zudem durch die von den Anbietern bereitgestellten APIs automatisiert werden kann.

Hier kommt das Konzept der Infrastructure as Code ins Spiel – ein Paradigma, dessen Ziel es ist, die gesamte Umgebung in Form von Code zu definieren, der nach einem entsprechenden Prozess die beschriebene Infrastruktur vorbereitet. Wir nutzen eine solche Lösung auf unseren Drupal-Hosting-Plattformen. Dies hilft uns, uns auf Drupal-Entwicklungsdienstleistungen zu konzentrieren, anstatt auf das Servermanagement.

Und nun zur Beantwortung der Frage „Warum haben wir uns bei Droptica für die Implementierung von IaC entschieden?“ Nun, es gibt viele Gründe, aber die wichtigsten unter ihnen sind:

• Speichern des Serverstatus im Repository – was im Code steht, spiegelt den tatsächlichen Zustand wider und ist zudem klar und verständlich, nicht nur für Administratoren;
• Möglichkeit, zu jedem Zeitpunkt in der Geschichte zurückzukehren – wenn der Code im Repository gespeichert ist, kennen wir die gesamte Historie der Änderungen und können problemlos zwischen ihnen wechseln;
• solche Darstellung ist leicht validier- und testbar, und die Technologien, die wir verwenden, bieten uns solche Mechanismen;
• Bereitstellungsautomatisierung, die die Vorbereitung und Bereitstellung von Servern in der Produktionsumgebung weiter beschleunigt.

Wie beginne ich?

Die Implementierung von Infrastructure as Code wurde in unserem Fall auf zwei Schritte reduziert – die Software zu finden, die unsere Annahmen erfüllt, und den Code vorzubereiten, der die Umgebung widerspiegelt.

Im ersten Schritt haben wir zwei grundlegende Bedingungen definiert:

• Unterstützung mehrerer Cloud-Plattformen – bei Droptica sind wir nicht auf eine spezifische Lösung beschränkt. Wir testen ständig neue Produkte auf dem Markt, um unseren Kunden immer interessantere und stabilere Lösungen zu bieten (derzeit nutzen wir unter anderem Dienstleistungen von AWS, Digital Ocean und Linode).
• Unveränderliche Infrastruktur – unser Ziel ist es, den aktuellen Zustand der Umgebung in einem Repository zu speichern, damit er jederzeit abgerufen und wiederhergestellt werden kann. Wir können daher keine Situation haben, in der es Änderungen am Zustand der Infrastruktur gab, die nicht zuvor im Code enthalten waren – was eine praktische Definition des Paradigmas der unveränderlichen Infrastruktur ist. 

Werkzeugauswahl

Es gibt viele Werkzeuge auf dem Markt, die die Implementierung von Infrastructure as Code ermöglichen. In unseren Überlegungen haben wir mehrere davon berücksichtigt, darunter Ansible, CloudFormation und Terraform, für das wir uns letztendlich entschieden haben.

Obwohl die Hauptaufgabe von Ansible nicht die Orchestrierung von Umgebungen ist, sondern die Verwaltung von Konfigurationen, verfügt das Werkzeug über Module, die es ermöglichen, mit Cloud-Computing-Diensten zu arbeiten. Diese Lösung scheint sehr praktisch zu sein. Sowohl der Code, der für die gewünschte Form der Infrastruktur verantwortlich ist, als auch dessen anschließende Konfiguration können in einem einzigen Repository gespeichert und verwaltet werden. Im Gegensatz zu den beiden anderen verwendet Ansible jedoch einen prozeduralen Codestil, in dem wir die auszuführenden Aufgaben Schritt für Schritt spezifizieren. In einigen Fällen kann dies zu nicht intuitiven Änderungen im Code führen, wie im folgenden Beispiel gezeigt.
Der vereinfachte Code in Ansible, der 10 virtuelle Maschinen erstellt, sieht so aus:

 - ec2: count: 10 image: ami-v1 instance_type: t2.micro 

Und derselbe in Terraform:

 resource "aws_instance" "example" { count = 10 ami = "ami-v1" instance_type = "t2.micro" }

Nach dem Ausführen beider Codebeispiele erreichen wir das gleiche Ergebnis – es werden 10 virtuelle Server in AWS bereitgestellt. Was passiert jedoch, wenn Sie sich entscheiden, die Anzahl auf 15 zu erhöhen?

Im Falle von Ansible wird der aktuelle Status nirgends gespeichert, sodass Sie genau diese Menge bereitstellen, wenn Sie die Anzahl der Server im Code auf 15 erhöhen. Am Ende haben Sie 25, weshalb die Anzahl der im Code enthaltenen neuen Maschinen 5 betragen sollte:

 - ec2: count: 5 image: ami-v1 instance_type: t2.micro 

Sowohl CloudFormation als auch Terraform speichern Informationen über den aktuellen Zustand der Infrastruktur, sodass die Änderung kosmetisch und viel intuitiver ist:

 resource "aws_instance" "example" { count = 15 ami = "ami-v1" instance_type = "t2.micro" }

Aus diesem Grund haben wir uns gegen die Verwendung von Ansible entschieden. Cloud Formation wurde aus einem viel einfacheren Grund ausgeschlossen – es ist ein Werkzeug, das für AWS gedacht ist und daher unsere erste Bedingung nicht erfüllt – es funktioniert nicht mit vielen Anbietern. 

Wie funktioniert Terraform?

In diesem Teil des Artikels präsentieren wir einen kurzen praktischen Leitfaden, der Ihnen erlaubt, Ihre ersten Schritte auf dem Gebiet der Automatisierung und Implementierung von IaC zu unternehmen. Wir konzentrieren uns auf Ubuntu, da wir dieses Umfeld bei Droptica täglich nutzen.

Installation

Terraform ist inzwischen in den offiziellen Ubuntu / Debian-Repositories zu finden, aber der Entwickler bietet fertige Pakete an, die einfach entpackt und installiert werden können.

 wget https://releases.hashicorp.com/terraform/0.11.2/terraform_0.11.2_linux_amd64.zip unzip terraform_0.11.2_linux_amd64.zip cp terraform /usr/local/bin 

Plug-in-Installation

Nicht alle Cloud-Anbieter werden nativ unterstützt, daher müssen Sie möglicherweise Plug-ins für einige von ihnen installieren, etwa Linode und OVH. In den meisten Fällen sind diese Verfahren in den Repositories gut beschrieben, wie in den folgenden zwei Fällen:

• Linode – https://github.com/btobolaski/terraform-provider-linode
• OVH – https://github.com/remijouannet/terraform-provider-ovh

Die kompilierten Plug-ins sollten in das Verzeichnis  ~/.terraform.d/plugins kopiert werden

Beschreibung des ersten Servers

Die Verwendung von Terraform ist wirklich einfach! Der oben gezeigte Code reicht um die erste virtuelle Maschine in AWS zu erstellen, aber lassen Sie uns mit einem etwas komplizierteren Problem beschäftigen.

 resource "aws_instance" "server-01" { ami = "ami-0d77397e" availability_zone = "eu-west-1a" instance_type = "t2.large" root_block_device { volume_type = "gp2" volume_size = "120" delete_on_termination = "true" } tags { Name = "server-01" Org = "droptica" } }

Das obige Beispiel führt ebenfalls zur Erstellung eines neuen virtuellen Servers namens server-01 in AWS – dies ist durch den aws_instance-Ressourcentyp definiert. Dann müssen Sie die erforderlichen Parameter (in der AWS-Dokumentation definiert) ausfüllen:

• ami – Bildkennung (in unserem Fall Ubuntu Server 16.04);
• availability_zone – Region und Zone, in der der Server bereitgestellt wird;
• instance_type – Typ und Größe der Instanz.

Im root_block_device-Abschnitt können Sie die Parameter der Festplatte spezifizieren, die mit dieser Instanz verbunden wird; in diesem Fall wählen wir den grundlegenden gp2-Typ mit einer Größe von 120 GB.

Ausführen des Codes

Nach den notwendigen Vorbereitungen ist der Code bereit zur Ausführung. Bevor jedoch Änderungen in der Zielumgebung implementiert werden, lohnt es sich, die Liste der Schritte zu lesen, die vorgenommen werden. Dies ermöglicht Ihnen, mögliche Fehler im Code zu erkennen. Um dies zu tun, führen Sie einfach den Befehl aus:

 $ terraform plan

Wenn alles richtig ist, müssen Sie jetzt nur noch den Code ausführen und die Änderungen anwenden:

 > terraform plan aws_instance.example: Refreshing state... (ID: i-6a7c545b) (...) ~ aws_instance.example tags.%: "0" => "2" tags.Name: "" => "server-01" tags.Org: "" => "droptica" Plan: 1 to add, 0 to change, 0 to destroy.

Wenn alles richtig ist, müssen Sie jetzt nur noch den Code ausführen und die Änderungen anwenden:

 terraform apply

Was kommt als nächstes?

Die Beschreibung der Maschine selbst ist erst der Anfang, da Cloud-Computing-Dienste inzwischen so umfangreich sind, dass sie die Schaffung einer viel komplexeren Architektur ermöglichen. Bei Droptica haben wir unter anderem das Netzwerk (sowohl öffentlich als auch privat), Server, die unsere Websites hosten, Datenbanken und Lastverteiler definiert – kurz gesagt, wir haben eine zuverlässige Hosting-Plattform auf Basis von AWS geschaffen.

Für diejenigen, die alle Möglichkeiten von Terraform kennenlernen möchten, empfehle ich die Lektüre der Dokumentation, und wenn Sie es ausprobieren möchten, ist der offizielle Leitfaden der ideale Ausgangspunkt für Sie.