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. In der Regel fallen diese Technologien und die damit verbundenen Aufgaben nicht in den Verantwortungsbereich von Automatisierungsingenieuren. Daf\u00fcr gibt es mehrere Gr\u00fcnde. Erstens, in vielen Organisationen fallen infrastrukturelle Fragen in den Aufgabenbereich des DevOps-Teams, und die Entwicklungsteams k\u00fcmmern sich nicht wirklich darum, wie die Pipeline funktioniert und wie alles, was damit zusammenh\u00e4ngt, aufrechterhalten werden muss. Zweitens, um ehrlich zu sein, wird die Praxis \"Infrastructure as Code (IaC)\" in vielen Unternehmen noch nicht umgesetzt. Dennoch hat sich dies definitiv zu einem beliebten Trend entwickelt, und es ist wichtig, sich um die damit verbundenen Prozesse, Ans\u00e4tze und Werkzeuge zu bem\u00fchen. Oder zumindest auf dem Laufenden zu bleiben.<\/p>\n
Lassen Sie uns mit den Gr\u00fcnden f\u00fcr diesen Ansatz beginnen. Wir haben bereits besprochen, dass wir f\u00fcr den Start von Tests in GitLab CI mindestens Ressourcen f\u00fcr den Betrieb des GitLab Runners ben\u00f6tigen. Zum Start von Containern mit Browsern\/Emulatoren m\u00fcssen wir eine VM oder einen Cluster reservieren. Neben den Testressourcen ben\u00f6tigen wir betr\u00e4chtliche Kapazit\u00e4ten zur Unterst\u00fctzung von Entwicklungs-, Staging- und Produktionsumgebungen, einschlie\u00dflich Datenbanken, automatisierten Zeitpl\u00e4nen, Netzwerkkonfigurationen, Lastenausgleich, Benutzerrechten usw. Das zentrale Problem sind die erforderlichen Anstrengungen zur Pflege all dieser Komponenten. Es gibt mehrere M\u00f6glichkeiten, wie wir \u00c4nderungen vornehmen und Updates bereitstellen k\u00f6nnen. Beispielsweise k\u00f6nnen wir im Kontext von GCP die UI-Konsole im Browser verwenden und alle Aktionen per Mausklick durchf\u00fchren. Eine alternative Methode k\u00f6nnte die Nutzung von API-Aufrufen zur Interaktion mit Cloud-Entit\u00e4ten oder der Einsatz des Befehlszeilen-Tools gcloud sein, um die gew\u00fcnschten Manipulationen durchzuf\u00fchren. Doch bei einer wirklich Vielzahl von verschiedenen Entit\u00e4ten und infrastrukturellen Elementen wird es schwierig oder sogar unm\u00f6glich, alle Operationen manuell auszuf\u00fchren. Dar\u00fcber hinaus sind all diese manuellen Aktionen unkontrolliert. Wir k\u00f6nnen sie nicht zur \u00dcberpr\u00fcfung vor der Ausf\u00fchrung einreichen, ein Versionskontrollsystem nutzen oder schnell \u00c4nderungen zur\u00fccksetzen, die zu einem Vorfall gef\u00fchrt haben. Um solche Probleme zu l\u00f6sen, haben Ingenieure automatische Bash-\/Shell-Skripte entwickelt, was nicht viel 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 zwei Werkzeuge, die zur IaC-Praxis geh\u00f6ren: Terraform und Ansible. Einige glauben, dass es sinnlos ist, sie gleichzeitig zu verwenden, da ihre Funktionalit\u00e4t \u00e4hnlich ist und sie austauschbar sind. Doch urspr\u00fcnglich werden ihnen v\u00f6llig unterschiedliche Aufgaben zugewiesen. Der Fakt, dass diese Werkzeuge sich gegenseitig erg\u00e4nzen sollten, wurde auf einer gemeinsamen Pr\u00e4sentation von Entwicklern der Unternehmen HashiCorp und RedHat best\u00e4tigt. Der konzeptionelle Unterschied besteht darin, dass Terraform ein Provisioning-Tool zur Verwaltung der Server selbst ist. W\u00e4hrend Ansible ein Konfigurationsmanagement-Tool ist, dessen Aufgabe die Installation, Konfiguration und Verwaltung der Software auf diesen Servern ist.<\/p>\n
Ein weiteres Schl\u00fcsselmerkmal dieser Werkzeuge ist der Code-Stil. Im Gegensatz zu Bash und Ansible verwendet Terraform einen deklarativen Stil, der auf der Beschreibung des gew\u00fcnschten Endzustands basiert, der durch die Ausf\u00fchrung erreicht werden soll. Wenn wir zum Beispiel 10 VMs erstellen und die \u00c4nderungen \u00fcber Terraform anwenden, erhalten wir 10 VMs. Wenn wir das Skript erneut ausf\u00fchren, passiert nichts, da wir bereits 10 VMs haben und Terraform dies wei\u00df, weil es den aktuellen Zustand der Infrastruktur in einer Statusdatei speichert. Ansible hingegen verwendet einen prozeduralen Ansatz. Wenn wir es bitten, 10 VMs zu erstellen, erhalten wir beim ersten Durchlauf auch 10 VMs, \u00e4hnlich wie bei Terraform. Aber nach dem erneuten Ausf\u00fchren haben wir bereits 20 VMs. Das ist das wesentliche Unterscheidungsmerkmal. Im prozeduralen Stil speichern wir den aktuellen Zustand nicht und beschreiben einfach die Reihenfolge der Schritte, die ausgef\u00fchrt werden sollen. Nat\u00fcrlich k\u00f6nnen wir verschiedene Situationen behandeln, einige \u00dcberpr\u00fcfungen auf die Existenz von Ressourcen und den aktuellen Zustand hinzuf\u00fcgen, aber es macht wenig Sinn, unsere Zeit zu verschwenden und Aufwand in die Kontrolle dieser Logik zu stecken. Au\u00dferdem erh\u00f6ht dies das Risiko, Fehler zu machen.\u00a0<\/p>\n
Zusammenfassend l\u00e4sst sich sagen, dass Terraform mit seiner deklarativen Notation das geeignetste Werkzeug f\u00fcr die Bereitstellung von Servern ist. F\u00fcr das Konfigurationsmanagement hingegen ist es besser, Ansible zu delegieren. Nachdem wir das gekl\u00e4rt haben, lassen Sie uns Beispiele f\u00fcr den Einsatz im Kontext der Automatisierung betrachten.<\/p>\n
Wert f\u00fcr die Automatisierungsinfrastruktur<\/h3>\n
\n Hier ist es wichtig zu verstehen, dass die Infrastruktur f\u00fcr automatisierte Tests als Teil der gesamten Infrastruktur des Unternehmens betrachtet werden sollte. Das bedeutet, dass alle IaC-Praktiken global auf die Ressourcen der gesamten Organisation angewendet werden m\u00fcssen. Wer daf\u00fcr verantwortlich ist, h\u00e4ngt von Ihren Prozessen ab. Das DevOps-Team hat in diesen Fragen mehr Erfahrung und hat einen umfassenden \u00dcberblick \u00fcber die Situation. Allerdings sind QA-Ingenieure st\u00e4rker am Aufbau der Automatisierung und der Pipeline-Struktur beteiligt, was ihnen erm\u00f6glicht, alle notwendigen \u00c4nderungen und Verbesserungsm\u00f6glichkeiten besser zu erkennen. Die beste L\u00f6sung ist, gemeinsam zu arbeiten, Wissen und Ideen auszutauschen, um das gew\u00fcnschte Ergebnis zu erreichen.\u00a0<\/p>\n
Hier sind einige Beispiele f\u00fcr die Verwendung von Terraform und Ansible im Kontext der Testautomatisierung und der zuvor besprochenen Tools:<\/p>\n
1. Die erforderlichen Eigenschaften und Parameter von VMs und Clustern \u00fcber Terraform beschreiben.<\/p>\n
2. Die f\u00fcr die Tests erforderlichen Tools mit Ansible installieren: Docker, Selenoid, Selenium Grid und die ben\u00f6tigten Versionen von Browsern\/Emulatoren herunterladen.<\/p>\n
3. Die Eigenschaften der VM, in der der GitLab Runner ausgef\u00fchrt wird, \u00fcber Terraform beschreiben.<\/p>\n
4. Mit Ansible den GitLab Runner und die notwendigen begleitenden Tools installieren, Einstellungen und Konfigurationen festlegen.<\/p>\n
Illustration des aktuellen Infrastrukturstatus<\/h3>\n
\n![\"DevOps-Tools](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Ressourcen f\u00fcr weitere Studien:<\/h3>\n
<\/p>\n