In Konsequenz hei\u00dft das aber auch, dass man die manuelle Installation beherrschen muss, um sie in Ansible umsetzen zu k\u00f6nnen. Oder anders gesagt: Wer die gew\u00fcnschte Umgebung nicht ohne Ansible installieren kann, dem n\u00fctzt Ansible nicht viel. Es ist vielmehr ein Hilfsmittel wie eine Kreiss\u00e4ge gegen\u00fcber der Hands\u00e4ge mit dem Schreiner. Wer das Handwerk nicht beherrscht, der wird durch die Kreiss\u00e4ge aber nicht zum Schreiner.<\/p>\n
Zur Beschreibung des gew\u00fcnschten Zustandes wird Yaml verwendet. Die Auszeichnungssprache kennen einige sicher bereits von Docker-Compose oder Kubernetes. Sie ist leicht erlernbar und abstrahiert teils Unterschiede von verschiedenen Distributionen. Falls notwendig, kann man solche auch selbst behandeln und etwa bestimmte Schritte nur f\u00fcr einzelne Distributionen\/Betriebssystemfamilien durchf\u00fchren.<\/p>\n
Gegen\u00fcber der h\u00e4ndischen Installation bietet Ansible mehrere Vorteile:<\/p>\n
Zustandsorientiert<\/h3>\n
Viele Ansible-Module sind idempotent <\/strong>– sie pr\u00fcfen also erst den aktuellen Zustand und nehmen \u00c4nderungen nur bei Bedarf vor. Auch bei mehrfacher Ausf\u00fchrung kommt es dabei zu keinen unerw\u00fcnschten Nebeneffekten.<\/p>\n Ein einfaches Beispiel:<\/p>\n F\u00fchrt man dies mehrfach aus, w\u00fcrde die Anweisung auch mehrfach in der Konfigurationsdatei stehen – je nach Anwendung verursacht dies Probleme. <\/p>\n Mit einem Shell-Skript k\u00f6nnte man zwar ein \u00e4hnliches Ergebnis wie mit Ansible erreichen, in dem entsprechende Pr\u00fcfungen durchgef\u00fchrt werden, falls notwendig. Das erh\u00f6ht allerdings die Komplexit\u00e4t und schafft schnell Redundanzen, wenn unterschiedliche Pr\u00fcfungen in verschiedenen Skripten immer wieder ben\u00f6tigt werden. Au\u00dferdem gibt es bei Shell-Skripten einige Fallstricke. Sie werden mit steigendem Umfang zunehmend fehleranf\u00e4llig.<\/p>\n Konsequent eingesetzt, ist die gesamte Installation und Einrichtung der Software in Yaml-Playbooks beschrieben. Im besten Falle versioniert man diese mit Git. Damit haben wir eine gewisse Dokumentation und k\u00f6nnen \u00fcber den Verlauf im Git-Repository sogar nachvollziehen, wann etwas ge\u00e4ndert wurde. <\/p>\n Nat\u00fcrlich k\u00f6nnte man auch hier eine h\u00e4ndische Dokumentation schlichtweg manuell dokumentieren. In der Praxis wird das aber oft vernachl\u00e4ssigt. Dies f\u00fchrt zu Systemen, die man nur schwer warten oder gar neu installieren kann, weil niemand mehr genau wei\u00df was alles darauf l\u00e4uft und wie es eingerichtet wurde.<\/p>\n Einer der wohl gr\u00f6\u00dften Vorteile liegt in der Effizient, wenn man mehrere Systeme verwaltet: Einmal geschrieben und getestet, kann ein Playbook auf 2, 10 oder 100 Systeme angewendet werden. Das spart Zeit und reduziert die Anf\u00e4lligkeit von h\u00e4ndischen Fehlern.<\/p>\n Sogar Parallel. Im Inventory gibt man die Server an. Darin lassen sich beliebige Server in Gruppen einteilen. So l\u00e4sst sich festlegen, dass etwa auf alle Server in der Gruppe „Webserver“ ein Apache2 installiert und eingerichtet wird. In der Gruppe „Datenbankserver“ dagegen eine MySQL-Instanz. Auch andere Szenarien sind denkbar, etwa alle Aktualisierungen auf s\u00e4mtlichen Testsystemen einzuspielen.<\/p>\n Ein weiterer Vorteil: Man erh\u00e4lt exakt die gleiche Umgebung. Auch das ist h\u00e4ndisch oft nicht gegeben, weil man z.B. auf einem System mal etwas ausprobiert hat oder sich nicht mehr an die genaue Installation erinnert. <\/p>\n In der Praxis ist das etwa hilfreich, um Testsysteme und Produktivumgebungen identisch zu installieren. Hier m\u00f6chte man keine (ungewollten) h\u00e4ndischen Abweichungen, da so Probleme m\u00f6glicherweise nicht vorab erkannt werden, sondern erst produktiv auftreten. Oder wenn man einen Cluster aufsetzt. Auch hier ben\u00f6tigt man mehrere Server, die alle gleich oder zumindest \u00e4hnlich aufgebaut werden sollen.<\/p>\n Auch andere Werkzeuge wie beispielsweise Puppet erm\u00f6glichen Automatisierung. Allerdings wird hier oft ein Agent auf jedem System installiert. Das hat seine Vor- und Nachteile. In gro\u00dfen Umgebungen ist eine zentrale Client-Server Verwaltung sicher hilfreich. Allerdings erh\u00f6ht es die Komplexit\u00e4t und der Agent verursacht etwas Last auf dem System.<\/p>\n Ansible dagegen ben\u00f6tigt neben SSH-Zugriff und Python keine weiteren Abh\u00e4ngigkeiten.<\/p>\n Einige der Vorteile machen je mehr Sinn, um so gr\u00f6\u00dfer\/wichtiger die Umgebung ist. Hier bietet Automatisierung die unbestreitbaren Vorteile von einer h\u00f6heren Effizienz und Konsistenz. In kleineren Umgebungen kann man das – zu Recht – hinterfragen. Hier kommt es auf den Einzelfall an, da man auch mit weniger Systemen von manchen Vorteilen profitieren kann. M\u00f6glicherweise ist der h\u00e4ndische Weg hier sinnvoll, wenn man nur sehr wenige Systeme hat und keine getrennten Testumgebungen. Auch f\u00fcr erste Gehversuche w\u00fcrde Ansible mehr Komplexit\u00e4t schaffen.<\/p>\n Wer in der IT arbeitet oder arbeiten m\u00f6chte, f\u00fcr den kann sich die Einarbeitung in Ansible aber auch aus anderen Gr\u00fcnden lohnen: Man hat Erfahrung gesammelt und belegt damit indirekt, dass man sich selbst in neue Themen einarbeiten kann. Das kann ein Pluspunkt im Lebenslauf sein. Vor allem bei jenen Unternehmen, welche die F\u00e4higkeiten des Bewerbers statt seiner formalen Abschl\u00fcsse in den Mittelpunkt stellen.<\/p>\n Im Folgenden schauen wir uns ein sehr einfaches Playbook an. Es installiert Apache2 auf einem Debian\/Raspberry Pi OS und ersetzt die Standard index.html Seite mit einer eigenen.<\/p>\n Im Attribut hosts <\/strong>k\u00f6nnten wir spezielle Gruppen angeben, auf denen das Playbook ausgef\u00fchrt werden soll. Zur Vereinfachung habe ich das hier nicht weiter eingeschr\u00e4nkt. Interessanter sind die Aufgaben: Der Bereich tasks<\/strong> enth\u00e4lt eine Liste von Aufgaben. Die erste Aufgabe installiert das APT-Paket apache2<\/strong> mit Sudo (become), d.H. im Grunde sudo apt install apache2<\/strong>. Mit update_cache <\/strong>stellen wir sicher, dass die Paketquellen aktuell sind. Dies entspricht einem Aufruf von apt update<\/strong> vor der Installation. Der Name ist jeweils frei w\u00e4hlbar und dient der Zuordnung (siehe unten).<\/p>\n Aufgabe 2 schreibt eine Zeile in die Standard-Indexdatei unter \/var\/www\/html\/index.html<\/strong>. Dies geschieht ebenfalls mit Root-Rechten. Sauberer w\u00e4re es, zuvor unseren Nutzer entsprechend zu berechtigen – auch das habe ich hier zur Vereinfachung weggelassen. Normal w\u00fcrde man in einem Inventory die IPs oder Hostnamen der Zielsysteme angeben und ggf. Gruppen definieren. F\u00fcr einen einfachen Test mit einem System reicht der h\u00e4ndische Aufruf (das Komma nach dem Hostname muss gesetzt sein). Wichtig<\/strong>: Zuvor die Authentifizierung per SSH-Schl\u00fcssel (ssh-copy-id<\/strong>) einrichten.<\/p>\n Damit haben wir ein erstes, einfaches Playbook entwickelt. In der Praxis w\u00fcrde man nun nat\u00fcrlich noch detailliertere Aufgaben einbauen, um alles was man ben\u00f6tigt entsprechend zu installieren und einzurichten. Dass Ansible wie zuvor erw\u00e4hnt zustandsorientiert ist, k\u00f6nnen wir an dieser Stelle testen, in dem man das Playbook erneut startet:<\/p>\n Dieses Mal ist alles gr\u00fcn, das hei\u00dft: Ansible hat erkannt, der gew\u00fcnschte Zustand (z.B. Apache installieren) ist bereits erreicht – daher muss nichts unternommen werden. Zuvor waren unsere beiden Aufgaben gelb, da sowohl das Apache-Paket als auch unsere eigene Indexseite noch fehlten.<\/p>\n Diese erste Einf\u00fchrung soll nur einen \u00dcberblick bieten und ist nicht auf alle Details von Ansible eingegangen. Beispielsweise Module, Variablen, Templates, Kontrollstrukturen wie Schleifen, Rollen, usw. Komplexere Playbooks strukturiert man zur besseren \u00dcbersichtlichkeit in einer Rolle. Diese kann wiederum in einem Playbook importiert werden. Anpassungen sind mit Variablen m\u00f6glich. Wer komplexere Konfigurationsdateien erstellen m\u00f6chte, greift auf Templates zur\u00fcck. Auch dort gibt es Variablen, Schleifen und weitere Hilfsmittel.<\/p>\n","protected":false},"excerpt":{"rendered":" Ansible ist ein beliebtes quelloffenes Automatisierungswerkzeug. Es kann Zeit sparen, die Qualit\u00e4t eurer Systeme verbessern und nebenbei auch dokumentieren. Dieser Beitrag bietet einen ersten Einstieg in die Automatisierung mit Ansible f\u00fcr Anf\u00e4nger. Dabei spielt es keine Rolle, ob du einen physischen\/virtuellen Server, Raspberry Pi oder Server in der Cloud automatisieren m\u00f6chtest. Wie kann ich mir …<\/p>\n","protected":false},"author":5,"featured_media":8826,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[78],"tags":[755,777,1009],"class_list":["post-8805","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software","tag-ansible","tag-automatisierung","tag-devops"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/8805","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=8805"}],"version-history":[{"count":6,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/8805\/revisions"}],"predecessor-version":[{"id":9754,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/8805\/revisions\/9754"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/8826"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=8805"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=8805"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=8805"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}echo "Test 123" >> \/etc\/httpd\/httpd.conf<\/code><\/pre>\nDokumentiert<\/h3>\n
Effizient, v.a. mit mehreren Systemen<\/h3>\n
Konsistenz<\/h3>\n
Leichtgewichtig und einfach<\/h3>\n
Warum sollte man automatisieren? Lohnt sich das?<\/h2>\n
Ansible in der Praxis<\/h2>\n
\n- name: Apache auf dem Raspberry Pi installieren\n hosts: all\n tasks: \n - name: Apache2 installieren\n become: true\n apt:\n name: apache2\n # Aktualisiert zuvor die Paketquellen (entspricht apt update)\n update_cache: yes\n\n - name: Eigene Index-Seite anlegen\n become: true\n copy:\n dest: \/var\/www\/html\/index.html\n content: "<b>Demo<\/b>: Apache-Installation per Ansible"\n<\/pre>\n<\/div>\n
ansible-playbook -i pi, --user pi playbooks\/apache_demo.yml<\/code><\/pre>\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2022\/04\/grafik-15.png\")
<\/a><\/figure>\n<\/div>\n<\/a><\/figure>\nWeitere Schritte<\/h2>\n