Marathon<\/a><\/noindex>\u00a0<\/li>\n<\/ul>\n<\/p>\n
7. Infrastruktur als Code (IaC)<\/h2>\n
<\/p>\n
Kurze Beschreibung der Technologie<\/h3>\n
\n Und nun sind wir beim letzten Abschnitt angekommen. Normalerweise geh\u00f6ren diese Technologien und die damit verbundenen Aufgaben nicht zum Verantwortungsbereich von Automatisierungsingenieuren. Daf\u00fcr gibt es eigene Gr\u00fcnde. Erstens sind in vielen Organisationen Infrastrukturfragen unter der Kontrolle der DevOps-Abteilung, und die Entwicklungsteams k\u00fcmmern sich nicht besonders darum, wie die Pipeline funktioniert und wie alles, was damit verbunden ist, unterst\u00fctzt werden muss. Zweitens, um ehrlich zu sein, wird die Praxis \u201eInfrastruktur als Code (IaC)\u201c in vielen Unternehmen immer noch nicht angewendet. Aber es ist definitiv ein popul\u00e4rer Trend geworden, und es ist wichtig, sich in die damit verbundenen Prozesse, Ans\u00e4tze und Tools einzubringen. Oder zumindest auf dem Laufenden zu bleiben.<\/p>\n
Lassen Sie uns mit der Motivation beginnen, diesen Ansatz zu nutzen. Wir haben bereits besprochen, dass wir f\u00fcr das Starten von Tests in GitlabCI mindestens Ressourcen f\u00fcr das Starten des Gitlab Runner ben\u00f6tigen. Um Container mit Browsern\/Emulatoren zu starten, m\u00fcssen wir eine VM oder ein Cluster reservieren. Neben den Ressourcen f\u00fcr das Testen ben\u00f6tigen wir betr\u00e4chtliche Kapazit\u00e4ten zur Unterst\u00fctzung der Entwicklungs-, Staging- und Produktionsumgebungen, die auch Datenbanken, automatisierte Zeitpl\u00e4ne, Netzwerkkonfigurationen, Lastenausgleicher, Benutzerrechte und so weiter umfassen. Das Hauptproblem besteht im erforderlichen Aufwand zur Unterst\u00fctzung all dessen. Es gibt mehrere M\u00f6glichkeiten, wie wir \u00c4nderungen vornehmen und Updates bereitstellen k\u00f6nnen. Zum Beispiel k\u00f6nnen wir im Kontext von GCP die UI-Konsole im Browser verwenden und alle Aktionen durch Klicken auf Schaltfl\u00e4chen ausf\u00fchren. Eine alternative Methode k\u00f6nnte die Nutzung von API-Calls zur Interaktion mit Cloud-Entit\u00e4ten oder die Verwendung des gcloud-Befehlszeilenwerkzeugs sein, um die erforderlichen Manipulationen durchzuf\u00fchren. Doch bei einer wirklich gro\u00dfen Anzahl verschiedener Entit\u00e4ten und Infrastrukturkomponenten wird es schwierig oder sogar unm\u00f6glich, alle Operationen manuell auszuf\u00fchren. Dar\u00fcber hinaus sind all diese manuellen Aktionen nicht kontrollierbar. Wir k\u00f6nnen sie vor der Ausf\u00fchrung nicht zur \u00dcberpr\u00fcfung einreichen, kein Versionskontrollsystem verwenden und keine \u00c4nderungen schnell zur\u00fccksetzen, die zu einem Vorfall gef\u00fchrt haben. Um solche Probleme zu l\u00f6sen, haben Ingenieure automatische bash\/shell-Skripte erstellt und erstellen sie weiterhin, was nur geringf\u00fcgig besser ist als die vorherigen Methoden, da sie nicht so leicht schnell zu lesen, zu verstehen, zu warten und im prozeduralen Stil zu modifizieren sind.<\/p>\n
In diesem Artikel und praktischen Leitfaden verwende ich 2 Werkzeuge, die zur Praxis von IaC geh\u00f6ren. Dies sind Terraform und Ansible. Einige glauben, dass es keinen Sinn macht, sie gleichzeitig zu verwenden, da ihre Funktionalit\u00e4t \u00e4hnlich ist und sie austauschbar sind. Aber die Tatsache ist, dass ihnen urspr\u00fcnglich ganz unterschiedliche Aufgaben gestellt werden. Und die Tatsache, dass diese Werkzeuge sich gegenseitig erg\u00e4nzen sollen, wurde bei einer gemeinsamen Pr\u00e4sentation von Entwicklern, die die Unternehmen HashiCorp und RedHat vertreten, best\u00e4tigt. Der konzeptionelle Unterschied besteht darin, dass Terraform ein Provisioning-Tool zur Verwaltung der Server selbst ist, w\u00e4hrend Ansible ein Tool zur Konfigurationsverwaltung ist, dessen Aufgabe die Installation, Konfiguration und Verwaltung der Software auf diesen Servern ist.<\/p>\n
Eine weitere wesentliche Unterscheidungsmerkmal dieser Werkzeuge ist der Programmierstil. Im Gegensatz zu Bash und Ansible verwendet Terraform einen deklarativen Stil, der auf der Beschreibung des gew\u00fcnschten Endzustands basiert, der erreicht werden soll. Zum Beispiel, wenn wir 10 VMs erstellen und die \u00c4nderungen mit Terraform anwenden, erhalten wir 10 VMs. Wenn das Skript erneut angewendet wird, passiert nichts, da wir bereits 10 VMs haben, und Terraform wei\u00df dies, da es den aktuellen Zustand der Infrastruktur in einer State-Datei speichert. Ansible hingegen verwendet einen prozeduralen Ansatz, und wenn wir ihn bitten, 10 VMs zu erstellen, erhalten wir beim ersten Durchlauf auch 10 VMs, \u00e4hnlich wie bei Terraform. Aber nach einem erneuten Durchlauf haben wir dann bereits 20 VMs. Das ist der wesentliche Unterschied. Im prozeduralen Stil speichern wir den aktuellen Zustand nicht und beschreiben einfach die Abfolge von Schritten, die ausgef\u00fchrt werden sollen. Nat\u00fcrlich k\u00f6nnen wir verschiedene Situationen behandeln, mehrere Pr\u00fcfungen auf die Existenz von Ressourcen und den aktuellen Zustand hinzuf\u00fcgen, aber es hat keinen Sinn, unsere Zeit damit zu verbringen und M\u00fche aufzuwenden, um diese Logik zu kontrollieren. Au\u00dferdem erh\u00f6ht das das Risiko, Fehler zu machen.\u00a0<\/p>\n
Zusammenfassend l\u00e4sst sich sagen, dass Terraform und die deklarative Notation das geeignetere Werkzeug f\u00fcr das Provisioning von Servern sind. Die Aufgaben zur Verwaltung von Konfigurationen sollten besser an Ansible delegiert werden. Nachdem wir das gekl\u00e4rt haben, schauen wir uns einige Anwendungsbeispiele im Kontext der Automatisierung an.<\/p>\n
Wert f\u00fcr die Automatisierungsinfrastruktur<\/h3>\n
\n Hier ist es wichtig zu verstehen, dass die Infrastruktur zur Automatisierung von Tests als Teil der gesamten Infrastruktur des Unternehmens betrachtet werden muss. Das bedeutet, dass alle IaC-Praktiken global auf die Ressourcen der gesamten Organisation angewendet werden sollten. Wer daf\u00fcr verantwortlich ist, h\u00e4ngt von Ihren Prozessen ab. Das DevOps-Team hat mehr Erfahrung in diesen Fragen, sie sehen das gesamte Geschehen. QA-Ingenieure sind jedoch st\u00e4rker in den Prozess des Aufbaus von Automatisierung und der Pipeline-Struktur involviert, was ihnen erm\u00f6glicht, alle erforderlichen \u00c4nderungen und Verbesserungsm\u00f6glichkeiten besser zu erkennen. Die beste Option ist, gemeinsam zu arbeiten, Wissen und Ideen auszutauschen, um das gew\u00fcnschte Ergebnis zu erzielen.\u00a0<\/p>\n
Ich werde einige Beispiele f\u00fcr die Verwendung von Terraform und Ansible im Kontext der Automatisierung von Tests und der Werkzeuge, die wir zuvor besprochen haben, anf\u00fchren:<\/p>\n
1. Die notwendigen Eigenschaften und Parameter von VMs und Clustern \u00fcber Terraform beschreiben.<\/p>\n
2. Mit Ansible die erforderlichen Testwerkzeuge installieren: Docker, Selenoid, Selenium Grid und die ben\u00f6tigten Versionen von Browsern\/Emulatoren herunterladen.<\/p>\n
3. Die Eigenschaften der VM, auf der der GitLab Runner ausgef\u00fchrt werden soll, \u00fcber Terraform beschreiben.<\/p>\n
4. Mit Ansible den GitLab Runner und die erforderlichen Begleitwerkzeuge installieren, Einstellungen und Konfigurationen festlegen.<\/p>\n
Illustration des aktuellen Standes der Infrastruktur<\/h3>\n
\n![\"DevOps-Tools](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Links zum Lernen:<\/h3>\n
<\/p>\n