{"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 Schl\u00fcssel-L\u00f6sungen zur Automatisierung Ihrer Welt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Ansible-Community begeistert st\u00e4ndig mit neuen Inhalten \u2013 Plugins und Modulen \u2013 und schafft viel neue Arbeit f\u00fcr die, die mit der Wartung von Ansible besch\u00e4ftigt sind, da neuer Code so schnell wie m\u00f6glich in die Repositories integriert werden muss. Die Einhaltung der Fristen gelingt nicht immer und der Start einiger bereits fertiger Produkte wird bis zur n\u00e4chsten offiziellen Version der Ansible Engine verschoben. Bis vor Kurzem hatten Endbenutzer nur einen Weg, um neue Ansible-Inhalte zu erhalten \u2013 zusammen mit der neuen Version der Ansible Engine.<\/p>\n

\"Ansible:
\n
\nUm die Unannehmlichkeiten zu beseitigen, hat die Ansible-Community an flexibleren Varianten zur Erstellung und zum Erhalt von Inhalten gearbeitet.
\n<\/a><\/noindex><\/p>\n

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

\nAls Antwort auf die Anfrage der Benutzer wurden in Ansible Engine 2.8 \u00c4nderungen an der Verarbeitung von Inhalten eingef\u00fchrt, die nicht Teil des offiziellen Releases sind<\/b>. Diese \u00c4nderungen erm\u00f6glichen einen neuen Weg, Inhalte an Benutzer zu liefern, der nicht von denen abh\u00e4ngt, die Ansible bei der Verwaltung von Ansible-Inhalten sowie dem Code der Plattform unterst\u00fctzen.<\/p>\n

In zuk\u00fcnftigen Releases wird geplant, dass die Ersteller (Creators) von Inhalten diese in Form von speziellen Paketen, sogenannten Collections, bereitstellen k\u00f6nnen, die an dem daf\u00fcr vorgesehenen Ort auf dem Hauptknoten von Ansible (control node) oder auf dem verwalteten Knoten (managed node) installiert werden k\u00f6nnen. Der Ersteller von Collections wird direkt im Paket Details zur Ausf\u00fchrung mit Rollen und Playbooks festlegen. Dank der oben genannten \u00c4nderungen in Ansible Engine werden Collections eines der Werkzeuge sein, die es erm\u00f6glichen, die Ver\u00f6ffentlichung von Inhalten von der Ver\u00f6ffentlichung offizieller Versionen der Ansible Engine zu entkoppeln.<\/b>.<\/p>\n

Neue Konstruktion Become<\/h4>\n

\nDie Become-Konstruktion gibt es schon eine ganze Weile, aber seit Version 2.8 wird das Wort BECOME standardm\u00e4\u00dfig in Ansible Engine verwendet, um ein Passwort beim Erh\u00f6hen der Berechtigungen (sudo-Berechtigungen in *nix-Systemen oder den Enable-Modus auf Netzwerkger\u00e4ten) abzufragen. Mit anderen Worten, jetzt ist BECOME ein standardisiertes Tool zur Erh\u00f6hung der Berechtigungen, das 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
\nDar\u00fcber hinaus enth\u00e4lt Ansible Engine 2.8 auch das BECOME-Plugin, das wie doas unter Linux und wie runas unter Windows funktioniert und es erm\u00f6glicht, Aktionen im Namen eines bestimmten Benutzers auszuf\u00fchren. F\u00fcr die Erh\u00f6hung von Berechtigungen auf Netzwerkanwendungen wird das become-Plugin enable verwendet.<\/p>\n
Suche nach dem Python-Interpreter<\/h4>\n
\nSie haben m\u00f6glicherweise mit einem solchen Fehler zu k\u00e4mpfen 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 zu finden ist. Ab Version 2.8 sucht Ansible den Interpreter auf jedem Zielsystem, indem es zuerst die Pfad- und Dateinamentabelle des Haupt-Python-Interpreters in verschiedenen Distributionen konsultiert und anschlie\u00dfend die geordneten Listen f\u00fcr alternative Interpreter (fallback list) verwendet. Weitere Infos finden Sie in der Portierungsleitfaden f\u00fcr 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 l\u00e4nger verwenden, gibt es sicherlich viele davon, die nur n\u00fctzlichen Speicherplatz beanspruchen. Ab Version 2.8 erstellt Ansible Engine diese Dateien standardm\u00e4\u00dfig nicht mehr (was durch Bearbeiten der verwendeten ansible.cfg-Datei r\u00fcckg\u00e4ngig gemacht werden kann).<\/p>\n
Aktualisierte Play Recap<\/h4>\n
\nAusschnitt aus Portierungsleitfaden f\u00fcr Ansible 2.8<\/a><\/noindex>:<\/p>\n
Die Play Recap z\u00e4hlt jetzt Aufgaben (tasks) mit dem Status ignored und rescued sowie ok, changed, unreachable, failed und skipped, dank zwei neuer Statistikz\u00e4hler im Callback-Plugin default. Failed-Aufgaben, bei denen das Flag ignore_errors: yes gesetzt war, werden als ignored gez\u00e4hlt. Failed-Aufgaben, f\u00fcr die dann der Rettungsabschnitt (rescue) ausgef\u00fchrt wurde, werden als rescued gez\u00e4hlt. Beachten Sie, dass im Gegensatz zu fr\u00fcheren Versionen von Ansible rescued-Aufgaben nicht mehr als failed gez\u00e4hlt werden.<\/p><\/blockquote>\n
\nIn der Play Recap-Tabelle nach der Ausf\u00fchrung des Playbooks haben die Hosts zus\u00e4tzliche Spalten skipped, rescued und ignored erhalten:<\/p>\n
\"Ansible:<\/p>\n
Clouds und Container<\/h4>\n
\nIn Version 2.8 wurden Verbesserungen und Erg\u00e4nzungen in 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
\nVerwenden 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 des 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 erhielt die neue Version von Red Hat Ansible Engine eine beeindruckende Liste von Verbesserungen und \u00c4nderungen, \u00fcber die wir detaillierter informieren werden. hier<\/a><\/noindex>.<\/b><\/p>\n
Red Hat Ansible Tower 3.5: mehr Automatisierung.<\/h3>\n
\nSeit Ende Mai ist auch die neue Version Red Hat Ansible Tower 3.5 verf\u00fcgbar, die mehrere wesentliche Verbesserungen f\u00fcr die Automatisierung bietet, \u00fcber die wir sprechen werden, falls Sie sie noch nicht selbst \u00fcberpr\u00fcft haben.<\/p>\n
Also, zuerst die wichtigsten Fakten:<\/p>\n