{"id":35513,"date":"2019-10-31T22:04:46","date_gmt":"2019-10-31T19:04:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira\/"},"modified":"2019-10-31T22:04:46","modified_gmt":"2019-10-31T19:04:46","slug":"ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira","title":{"rendered":"Ansible: Updates in den Schl\u00fcsselentscheidungen zur Automatisierung Ihrer Welt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Ansible-Community bietet st\u00e4ndig neuen Content \u2013 von Plugins und Modulen bis hin zu zahlreichen neuen Aufgaben f\u00fcr diejenigen, die sich um Ansible k\u00fcmmern. Da neuer Code so schnell wie m\u00f6glich in die Repositories integriert werden muss, gelingt es nicht immer, die Fristen einzuhalten, und der Start einiger marktreifen Produkte wird auf die n\u00e4chste offizielle Version von Ansible Engine verschoben. Bis vor kurzem hatten Endnutzer nur eine M\u00f6glichkeit, neuen Ansible-Content zu erhalten \u2013 zusammen mit einer neuen Version von Ansible Engine.<\/p>\n

\"Ansible:
\n
\nUm diese Unannehmlichkeit zu beseitigen, hat die Ansible-Community an flexibleren M\u00f6glichkeiten zur Erstellung und Verbreitung von Content gearbeitet.
\n<\/a><\/noindex><\/p>\n

Red Hat Ansible Engine 2.8: Auf dem Weg zu neuen Methoden zur Verarbeitung von Ansible-Content<\/h3>\n

\nIn Antwort auf die Nutzeranfragen wurden in Ansible Engine 2.8 \u00c4nderungen eingef\u00fchrt, die die Verarbeitung von Inhalten betreffen, die nicht Teil des offiziellen Releases sind<\/b>. Diese \u00c4nderungen erm\u00f6glichen eine neue Art der Content-Zustellung f\u00fcr die Benutzer, die nicht von den Verantwortlichen von Ansible abh\u00e4ngt, wenn es um die Verwaltung sowohl des Ansible-Contents als auch des Codes der Plattform selbst geht.<\/p>\n

In k\u00fcnftigen Versionen wird es Content Creators erm\u00f6glicht, Inhalte in Form von speziellen Paketen, sogenannten Collections, bereitzustellen, die an dem entsprechenden Ausf\u00fchrungsort auf dem Ansible-Control-Node oder auf dem verwalteten Knoten installiert werden k\u00f6nnen. Der Creator der Collections wird die Ausf\u00fchrungsdetails direkt im Paket mithilfe von Rollen und Playbooks definieren. Dank der oben genannten \u00c4nderungen im Ansible Engine werden Collections zu einem der Werkzeuge, die die Ver\u00f6ffentlichung von Inhalten von der Ver\u00f6ffentlichung offizieller Versionen des Ansible Engine entkoppeln.<\/b>.<\/p>\n

Neue Become-Konstruktion<\/h4>\n

\nDie Become-Konstruktion existiert schon seit l\u00e4ngerem, aber seit Version 2.8 wird das Wort BECOME standardm\u00e4\u00dfig im Ansible Engine verwendet, um ein Passwort beim Erh\u00f6hen der Berechtigungen (sudo-Berechtigungen auf *nix-Systemen oder Enable-Modus auf Netzwerkger\u00e4ten) anzufordern. Mit anderen Worten, jetzt ist BECOME ein Standardwerkzeug zur Erh\u00f6hung der Berechtigungen, das bereits eigenst\u00e4ndig mit dem Zielsystem umgeht.<\/p>\n

So sieht ein Beispiel f\u00fcr die Verwendung aus:<\/p>\n

ansible-playbook --become --ask-become-pass site.yml\nBECOME Passwort:\n<\/code><\/pre>\n
\nZus\u00e4tzlich ist im Ansible Engine 2.8 das BECOME-Plugin verf\u00fcgbar, das wie doas unter Linux und runas unter Windows funktioniert und Aktionen im Namen eines bestimmten Benutzers ausf\u00fchren kann. F\u00fcr die Erh\u00f6hung der Berechtigungen auf Netzwerkger\u00e4ten wird das become-Plugin enable verwendet.<\/p>\n
Suche nach dem Python-Interpreter<\/h4>\n
\nSie haben m\u00f6glicherweise mit einem solchen Fehler zu tun gehabt:<\/p>\n
\/usr\/bin\/python: bad interpreter: No such file or directory\n<\/code><\/pre>\n
\nDas Problem ist, dass in fr\u00fcheren Versionen von Ansible Engine standardm\u00e4\u00dfig davon ausgegangen wurde, dass der Haupt-Python-Interpreter im Verzeichnis \/usr\/bin\/python liegt. Ab Version 2.8 sucht Ansible den Interpreter auf jedem Zielsystem, zun\u00e4chst indem es die Tabelle der Pfade und Namen der ausf\u00fchrbaren Dateien des Haupt-Python-Interpreters in verschiedenen Distributionen abgleicht und anschlie\u00dfend geordnete Listen von Ersatzinterpreteren verwendet. Weitere Informationen finden Sie in der Anleitung zum Portieren auf Ansible 2.8<\/a><\/noindex>.<\/p>\n
Retry-Dateien werden standardm\u00e4\u00dfig nicht mehr erstellt.<\/h4>\n
\nHaben Sie schon lange nach .retry-Dateien auf der Festplatte gesucht? Wenn Sie Ansible schon eine Weile verwenden, gibt es sicherlich viele davon, die nur Speicherplatz beanspruchen. Ab Version 2.8 erstellt Ansible Engine standardm\u00e4\u00dfig keine dieser Dateien mehr (dies kann r\u00fcckg\u00e4ngig gemacht werden, indem die verwendete ansible.cfg-Datei bearbeitet wird).<\/p>\n
Aktualisierte Play Recap<\/h4>\n
\nAusschnitt aus Anleitungen zur Migration auf Ansible 2.8<\/a><\/noindex>:<\/p>\n
Die Play Recap z\u00e4hlt jetzt auch Aufgaben (tasks) mit den Status ignored und rescued sowie ok, changed, unreachable, failed und skipped, dank zweier neuer Statistikz\u00e4hler im Standard-Callback-Plugin. Failed-Aufgaben, die mit dem Flag ignore_errors: yes markiert sind, werden als ignored gez\u00e4hlt. Failed-Aufgaben, f\u00fcr die anschlie\u00dfend die rescue-Sektion bearbeitet wurde, z\u00e4hlen als rescued. Beachten Sie, dass rescued-Aufgaben im Gegensatz zu fr\u00fcheren Ansible-Versionen nicht mehr als failed z\u00e4hlen.<\/p><\/blockquote>\n
\nIn der Play Recap-Tabelle nach der Ausf\u00fchrung des Playbooks wurden zus\u00e4tzliche Spalten f\u00fcr skipped, rescued und ignored bei den Hosts hinzugef\u00fcgt:<\/p>\n
\"Ansible:<\/p>\n
Clouds und Container<\/h4>\n
\nIn Version 2.8 wurden Verbesserungen und Erg\u00e4nzungen an den Cloud- und Containermodulen f\u00fcr die Arbeit mit Amazon Web Services, Microsoft Azure, Google Cloud, Digital Ocean, podman<\/a><\/noindex> und kubevirt<\/a><\/noindex>. Es ist auch erw\u00e4hnenswert, dass TOML-Dateien jetzt als Inventory-Quelle verwendet werden k\u00f6nnen.<\/p>\n
Paramiko<\/h4>\n
\nNutzen Sie Red Hat Ansible Network Automation? Ansible Engine 2.8 enth\u00e4lt kein paramiko mehr und ist nicht von ihm abh\u00e4ngig. Standardm\u00e4\u00dfig verwendet Ansible Engine ssh. Wenn Sie paramiko ben\u00f6tigen, k\u00f6nnen Sie es mit dem Befehl pip install paramiko installieren.<\/p>\n
Wenn Sie Unterst\u00fctzung bei der Verwendung von paramiko im Rahmen Ihres Red Hat-Abonnements ben\u00f6tigen, wenden Sie sich bitte an den Artikel in der Wissensdatenbank. Paramiko-Paket fehlt nach neuen Ansible Engine-Installationen.<\/a><\/noindex>.<\/p>\n
So hat die neue Version von Red Hat Ansible Engine eine beeindruckende Liste von Verbesserungen und \u00c4nderungen erhalten, die Sie im Detail einsehen k\u00f6nnen. hier<\/a><\/noindex>.<\/b><\/p>\n
Red Hat Ansible Tower 3.5: mehr Automation.<\/h3>\n
\nSeit Ende Mai steht die neue Version von Red Hat Ansible Tower 3.5 zur Verf\u00fcgung, die mehrere bedeutende Verbesserungen f\u00fcr die Automatisierung bietet. Dar\u00fcber m\u00f6chten wir sprechen, falls Sie noch nicht die Gelegenheit hatten, sie selbst zu \u00fcberpr\u00fcfen.<\/p>\n
Also, zuerst die wichtigsten Punkte:<\/p>\n