Seite wählen

NETWAYS Blog

Terraform – was ist das eigentlich?

Am Tag vor der OSMC finden verschiedene Workshops statt, so auch am Tag vor der OSMC 2019. Ich habe mich dazu entschieden, den Terraform Workshop zu besuchen, weil dieser am interessantesten für mich schien. Zu dem Zeitpunkt dachte ich noch nicht, dass ich in Zukunft mehr damit Arbeiten würde – doch falsch gedacht, tatsächlich habe ich mich direkt anschließend eine ganze Zeit lang damit auseinandergesetzt und vor kurzem nochmals. Ich hatte das Ziel, die Schulungsunterlagen für unsere Trainings zu prüfen und mir die User Experience anzuschauen. Dabei habe ich schnell bemerkt, dass mehr als ein Provider problematisch ist, nicht weil Terraform das nicht kann, sondern weil ein entsprechender Lehrinhalt innerhalb dieser 3 Tage mit mehr als einem Provider nur schwer zu vermitteln wäre.  

 

Jetzt zu der Frage was ist Terraform überhaupt? 

Terraform ist ein Produkt der Firma HashiCorp, welche ihren Sitz in San Francisco hat. Terraform ist nur eines der praktischen Programme des Unternehmens, weitere Programme sind Packer und Vagrant. Terraform gehört zur Gruppe IAC (Infrastructure as Code), durch diese werden Infrastrukturen durch Code verwaltet, menschliche Fehler verringert und die Produktivität gesteigert. 

 Mit Terraform lassen sich automatisiert Maschinen deployen und verwalten. Das alles geht recht einfach und schnell auf der CLI. Ein weiterer Vorteil ist, dass Terraform mit vielen unterschiedlichen Providern und Cloud Services zur Cloud Infrastructure Automation genutzt werden kann und das sogar zeitgleich. Man kann beispielsweise unsere OpenStack Maschinen verwenden, VM’s bei Amazon Web Services und Microsoft Azure haben und kann alle Maschinen über eine Terraform Instanz steuern und kontrollieren. Wie alle Produkte, die wir verwenden und lieben, ist Terraform natürlich keine Ausnahme und auch Opensource. Alle Produkte von HashiCorp sind Opensource (ausgenommen Enterprise Versionen). 

 

Man muss sich zwar erst mit Terraform vertraut machen, aber sobald man das hat, ist Terraform sehr einfach zu bedienen. Allerdings muss man sich immer fit halten, was die Programmsprache angeht, da HashiCorp in neuen Versionen gerne mal einiges ändert. Je nachdem wie man es sieht ist Terraform Vagrant für Server. Aber nicht nur große Cloud Provider lassen sich verwalten, sondern auch DNS-Dienste (hier eine detaillierte Liste mit unterstützten Providern https://www.terraform.io/docs/providers/index.html).  

 

Die Konfiguration von Terraform erfolgt über eine oder mehrere Dateien welche auf .tf enden. Wie die Datei(en) heißen, ist dabei völlig egal. Wie bereits angedeutet ist es egal, ob alles in einer Datei steht oder man mehrere Dateien hat. Es empfiehlt sich aus Gründen der Übersichtlichkeit eine Provider-, Main- und Resources.tf Datei anzulegen. In der Provider.tf (wie der Name schon verrät) wird der Provider bzw. die Provider und deren Zugangsdaten und Projekte angelegt. In der Main.tf stehen Dinge wie Image (Betriebssystem), Ressourcen, Größe der Festplatte, aber auch der SSH Key des Nutzers. In der Ressources.tf stehen Dinge wie Security Groups, Konfiguration der Subnetzeaber auch IP-Konfigurationen, usw…  

 

Sobald alles vollständig konfiguriert ist, führt man $ terraform init und $ terraform apply aus und, wenn alles richtig ist, hat man seine laufende(n) VM(s). Und das, ohne jede einzeln deployen zu müssen. Das verringert den Zeitaufwand sehr stark und minimiert die Fehlerquote. 

 

Terraform ist also gerade wenn man viel mit virtuellen Maschinen und unterschiedlichen Providern arbeitet ein sehr hilfreiches und praktisches Tool, welches sehr nützlich sein kann. Ich kann Terraform (wie auch die anderen Produkte von HashiCorp) nur empfehlen. Es ist wirklich leicht zu bedienen und erleichtert die Arbeit ungemein. 

Nathaniel Donahue
Nathaniel Donahue
Technical Service Manager

Nathaniel hat 2022 seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS erfolgreich abgeschlossen. Seitdem unterstützt er sein Team im Bereich Operations vor allem beim Betriebsconsulting. In seiner Freizeit ist Nathaniel gerne unterwegs mit Freunden oder reist in der Gegend herum. Ansonsten schnappt er sich gerne mal sein Fahrrad oder geht Schwimmen.

Terraform Changes

Hallo!

Was vielen von unseren Lesern entgeht, ist das wir auch in unserem Alltag zwischen der ganzen Softwareschreiber- und Kompilier- Tätigkeiten auch ganz viele virtuelle Maschinen und Container zum testen selbiger Software rauf und runter installieren müssen, und das Tag für Tag.

Deshalb versuchen wir uns das Leben mit dafür erstellter Software und deren arbeitserleichternden Funktionen leichter zu machen. Wie mein Kollege schon in seinem Blogpost im März mir vorgegriffen hat, benutzen wir bei der Netways Terraform. Achim wird in weiteren Artikeln darauf eingehen wie man Openstack per Terraform nach seiner Pfeife tanzen lassen kann und Ich möchte mich heute auf ein anderes Terraform Thema beziehen, nämlich dem nahen Release von Terraform 0.12.

Zu dem Zeitpunkt wo ich diese Zeilen niederschreibe, ist auf der aktuellen Website von Hashicorp noch die Aktuelle Version 0.11.13 zu finden.

Aber Terraform hat uns schon vielversprechendes gezeigt mit dem 0.12.0-beta1 pre-release.

Damit kann man schon die vielen Erleichterungen, welche der neue Terraform Release mit sich bringt erahnen und auch schon antesten. Ich versuche die Änderungen Anhand eines kleinen Beispiels zu erläutern.
Vielleicht kann ich den einen oder anderen IaaS Codeschreiber, welcher sich hierfür interessiert, etwas auf den Geschmack zu bringen schon etwas zu testen mit der neuen Version.

Hier der Unterschied zwischen einer (aktuell 0.11.13) alten Terraform Version und einer neuen Version in Terraform 0.12 durch eine Gegenüberstellung.

main.tf (Random Tiernamen Beispiel)

variable "count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "zoo_enabled" { default = "0" } variable "prefix_liste" { default = [] } resource "random_pet" "my_pet" { count = "${var.count}" prefix = "${var.zoo_enabled == "0" ? var.default_prefix : element(concat(var.prefix_liste, list (""), count.index)}" }

main.tf HCL2 Version(Random Tiernamen Beispiel)

variable "pet_count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "prefix_list" { default = [] } resource "random_pet" "my_pet" { count = var.pet_count prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix }

Die Unterschiede fallen zuerst etwas weniger ins Auge, sind aber dafür meines Erachtens tiefgreifender für Leute, die IaaS Code schreiben müssen und dienen der Lesbarkeit des Codes.

Vorteil Nummer 1:
Im alten Beispiel musste noch mit „${var.count}“ von einem String zu einer Number evaluiert werden. Mit der neuen HCL2 Schreibweise entfällt das, und es kann mit var.pet_count direkt der korrekte String oder Number Wert adressiert werden.

Vorteil Nummer 2:
Auch die Evaluierung der Liste prefix = „${var.zoo_enabled == „0“ ? var.default_prefix : element(concat(var.prefix_liste, list („“), count.index)}“  wird mit der neuen Notation der HCL2 wesentlich eingängiger. prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix ist prägnanter. Es entfällt auch die element(concat(x), list(„“), x ) Hack-Situation, um aus einer leeren Liste auch eine Liste mit einem NULL Element zum machen.

Weitere Vorteile: es gibt viel mehr was geändert worden ist, if you want to know more, klick here.

Ich hoffe ich habe euch nicht zu sehr gelangweilt mit C.O.D.E. kurz vor dem Wochenende.

Gruß David

 

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

For a Handful of (Vagrant) Boxes

Servus alle miteinand,


Wer kennt das folgende Szenario nicht? Mit viel neuer Software, welche gerade (manuell) getestet werden muss, dachte ich mir, ich baue mal schnell eine Vagrant Box auf Basis von Debian 9, um Tests unter einem Stretch durchzuführen.
Falsch gedacht !!
Anstelle eines libvirt install auf der Kommandozeile und eines tar-Befehls zum Packen des eigentlichen Box-Images,
musste ich mit einer kleinen Widrigkeiten im Bereich der Netzwerkkonfiguration kämpfen.
Aber eins nach dem anderen.
Fangen wir mit dem Image für die libvirt Maschine an:

virt-install --name=linuxconfig-vm \
--vcpus=1 \
--memory=1024 \
--cdrom=/tmp/debian-9.4.0-amd64-netinst.iso \
--disk size=10 \
--os-variant=debian9

Dies war noch der unproblematische Teil der Installation.
Danach erfolgt in der VM das nachziehen von Berechtigungen für den Vagrant User.

sudo visudo -f /etc/sudoers.d/vagrant
vagrant ALL=(ALL) NOPASSWD:ALL

Hinzufügen des Vagrant public Keys:

mkdir -p /home/vagrant/.ssh
chmod 0700 /home/vagrant/.ssh
wget --no-check-certificate \
\/keys/vagrant.pub \
-O /home/vagrant/.ssh/authorized_keys
chmod 0600 /home/vagrant/.ssh/authorized_keys
chown -R vagrant /home/vagrant/.ssh

Wenn man nicht so Wach war, um rechtzeitig im Installationsmenü schon SSH mitzuinstallieren, muss es per Hand nachgeholt werden:

sudo apt-getinstall -y openssh-server
sudo nano /etc/ssh/sshd_config
AuthorizedKeysFile %h/.ssh/authorized_keys

Danach kann das System so präpariert werden, wie man es benötigt.
Das Image der VM noch verkleinern und in box.img umbenennen:

qemu-img convert -c -O qcow2 debian9.qcow2 small.qcow2
mv small.qcow2 box.img

Alles handlich verpacken und dem Vagrant Box Store hinzufügen:

tar czvf debian9.box ./metadata.json ./Vagrantfile ./box.img
vagrant box add --name debian9 debian9.box

Hier allerdings fingen meine Probleme an.
Nach dem Packen der Box, dem Hinzufügen zum Boxstore und einem Erwartungsvollen „vagrant up“ erhielt ich „==> default: Waiting for domain to get an IP address…“, was zu keinem Erfolg führte und ich wahrscheinlich jetzt immer noch warten würde.

Nach einem erneuten Hochfahren der VM mit dem virt-manager und nachschauen, ob das network device fehl konfiguriert ist, konnte ich keinen Fehler feststellen.

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

Gefühlte Jahrtausende von Recherche später, wurde mir folgendes klar:
Debian hat in neuen Versionen eine Änderung der Device-Namen vorgenommen.
Vagrant wartet vergeblich auf „eth0“, weil ein network device Namens „ens21“ existiert, wenn ich die VM mit „vagrant up“ starte.
Also zurück in die VM und das folgende Kommandos abgesetzt:

sudo nano /etc/default/grub

Im Editor dann folgende Anpassungen vornehmen:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

Damit das auch greift, muss abschließend die Konfiguration für den Grub-Bootmanager neu erstellt werden:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Reboot. „vagrant up“ und Tada … Spannung Trommelwirbel => Tusch ! Die VM erhält eine IP und startet wie man es schon von Anfang an erwartete.
Ich hoffe ich konnte damit den ein oder anderen vor dem Verlust von allzuviel Lebenszeit bewahren.
Ein sonniges WE wünscht

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.