Coloures-pic - Fotolia
Terraform versus Ansible: Wie unterscheiden sich die Tools?
Es gibt einige Überschneidungen zwischen beiden Tools, doch sie sind für unterschiedliche Anwendungsfälle gedacht. Wie sich Ansible und Terraform parallel einsetzen lassen.
Softwareentwickler werden oft dazu aufgefordert, die von IaC-Plattformen wie Terraform und Ansible benötigte Logik zu implementieren. Aber um die YAML-, JSON- oder DSL-Datei, die Docker-Container hochfahren oder Kubernetes-Cluster herunterfahren soll, richtig zu schreiben, muss ein Entwickler die Art und den Zweck der Tools verstehen, die er kodieren will.
Ansible und Terraform sind zwei Angebote, die häufig als Infrastructure-as-Code-Plattformen (IaC) verwendet werden. Obwohl die beiden Tools unterschiedliche Zwecke verfolgen, gibt es doch einige Überschneidungen, was oft zu Verwirrung führt.
Hier untersuchen wir, was Softwareentwickler wissen müssen, wenn sie Terraform und Ansible gegenüberstellen.
Kurz gesagt: Terraform ist eine Open-Source-IaC-Plattform. Im Gegensatz dazu ist Ansible ein Open-Source-Konfigurationsmanagement-Tool. Entwickler können Ansible und Terraform gleichzeitig verwenden; das eine ersetzt nicht unbedingt die Notwendigkeit für das andere.
Wie Terraform funktioniert
Terraform, das von HashiCorp entwickelt wurde, bietet eine Syntax zur Definition von Infrastruktur und Diensten, die entweder vor Ort oder in der Cloud gehostet werden können. Sie können das DevOps Tool verwenden, um alles zu konfigurieren, von Azure-Diensten über Virtuelle Maschinen, die in VMware ESXi laufen, bis hin zu DNS-Einträgen in Cloudflare.
Terraform-Benutzer definieren mit einer Programmiersprache namens HashiCorp Configuration Language (HCL), wie Ressourcen erstellt, aktualisiert, ersetzt und gelöscht werden sollen. HCL ist eine interpretierte Sprache, die fehlerverzeihender und einfacher zu bedienen ist als Alternativen wie Java oder Kotlin. HCL wurde so konzipiert, dass DevOps-Profis mit minimaler Codierungserfahrung die Syntax schnell erlernen können.
Wie Ansible funktioniert
Im Gegensatz zu Terraform ist Ansible ein Konfigurationsmanagement-Tool, das von Red Hat entwickelt wurde. Wenn man es oberflächlich betrachtet, ist es Terraform sehr ähnlich. Zum Beispiel können Sie ebenfalls damit Azure-Ressourcengruppen erstellen.
Im Gegensatz zu Terraform verwendet Ansible jedoch YAML, einen Daten-Serialisierungsstandard für Programmiersprachen, um zu definieren, wie die Ressourcen bereitgestellt werden sollen. Auf der linken Seite sehen Sie einen Screenshot mit Ansible-Beispielcode zum Erstellen einer Azure-Ressourcengruppe.
In den Terraform- und Ansible Code-Beispielen haben wir die Tools verwendet, um eine Cloud-Ressource zu erstellen. In der Praxis ist dies allerdings eher die Aufgabe eines IaC-Tools wie Terraform, im Gegensatz zu einem Konfigurationsmanagement-Tool wie Ansible. Nur weil Sie mit Ansible Ressourcen erstellen können, heißt das nicht unbedingt, dass Sie das auch tun sollten.
Wie man Terraform und Ansible kombiniert
DevOps-Profis sollten immer das beste Tool für den Job verwenden. Ansible und Terraform sind komplementäre Tools, die häufig zusammen verwendet werden. Die Entscheidung, Ansible und Terraform in Ihren DevOps Stack aufzunehmen, ist keine Entweder-oder-Entscheidung.
Verwenden Sie Terraform, um Ressourcen und Services zu erstellen. Dann verwenden Sie Ansible, um die von Terraform erstellten Ressourcen zu konfigurieren.
Stellen Sie sich zum Beispiel vor, Sie müssen eine Amazon EC2-Instanz (Elastic Compute Cloud) für die Infrastruktur bereitstellen. Und auf dieser Instanz müssen Sie einen MySQL-Server installieren und ihn mit einer Vielzahl von Port-Einstellungen, Sicherheitseinschränkungen und Parametern zur Leistungsoptimierung konfigurieren.
In diesem Szenario sollten Sie Terraform verwenden, um zu definieren, wie Sie eine virtuelle Maschine als EC2-Instanz in der AWS-Cloud erstellen. Anschließend verwenden Sie Ansible, um die MySQL-Datenbank zu installieren und zu konfigurieren. Wie Sie sehen können, adressieren Ansible und Terraform zwei unterschiedliche DevOps-Anliegen. Sie sind komplementär, nicht konkurrierend.
