| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| linux:ansible:detail [24.09.2022 13:57. ] – [Wo laufen die Ansible Scripte?] django | linux:ansible:detail [19.12.2022 09:37. ] (aktuell) – [weitere Beispiele] django |
|---|
| * //[[playbook_example_10|Wie wird sicher gestellt, dass alle Ziele auch erreichbar sind?]]// | * //[[playbook_example_10|Wie wird sicher gestellt, dass alle Ziele auch erreichbar sind?]]// |
| * //[[linux:git|Wo sollen Ansible-Daten wie Inventories, Playbooks, Rollen und Variablen vorgehalten werden?]]// | * //[[linux:git|Wo sollen Ansible-Daten wie Inventories, Playbooks, Rollen und Variablen vorgehalten werden?]]// |
| * //Wie stellen wir sicher, dass der Code einheitlich und sauber ist?// | * //[[playbook_example_11|Wie stellen wir sicher, dass der Code einheitlich]] [[lint|und sauber ist?]]// |
| | * //[[playbook_example_12|Spaß bei der Arbeit? Mitnichten, bei uns hier doch nicht, oder doch?]]// |
| * //... ?// | * //... ?// |
| Nennen wir das der Einfachheit halber kurz: **Plan A**. | Nennen wir das der Einfachheit halber kurz: **Plan A**. |
| |
| <WRAP center round tip 80%> | <WRAP center round tip 80%> |
| Alternativ könnte man aber auch, sinnlos wertvolle Arbeitszeit totschlagen, und sich in zahlreichen Besprechungsrunden austauschen und ausdiskutieren, wie man z.B. Hostinformationen aus einer **''[[https://github.com/chaos/genders|/etc/genders]]''**((aus dem Jahre 2004!)) extrahiert, in eine Inventory-Datei konvertiert und manuell mit Variablen anreichert oder sich abstimmen zu wollen, welcher Editor nun die bessere Wahl sein, **''nano''**, **''vim''** oder **''[[https://code.visualstudio.com/|vscode]]''** mit diversen add-ons nun die bessere Wahl sei. Der geneigte Leser und verantwortlich agierende Admin wird sich doch wohl eher und das auch sehr schnell im Klaren sein, dass es keinerlei Sinn macht, sich in Nebensächlichkeiten zu verlieren, sondern eher **Plan A** zum Ziel führen wird. | Alternativ könnte man aber auch, sinnlos wertvolle Arbeitszeit totschlagen, und sich in zahlreichen Besprechungsrunden austauschen und ausdiskutieren, wie man z.B. Hostinformationen aus einer **''[[https://github.com/chaos/genders|/etc/genders]]''**((aus dem Jahre 2004!)) extrahiert, in eine Inventory-Datei konvertiert und manuell mit Variablen anreichert oder sich abstimmen zu wollen, welcher Editor nun die bessere Wahl sein, **''nano''**, **''vim''** oder **''[[https://code.visualstudio.com/|vscode]]''** mit diversen add-ons nun die bessere Wahl sei. |
| | |
| | Der geneigte Leser und __verantwortlich agierende Admin__ wird sich doch wohl eher und das auch sehr schnell im Klaren sein, dass es keinerlei Sinn macht, sich in Nebensächlichkeiten zu verlieren. Vielmehr wird dieser zum Schluss kommen, dass wohl eher **Plan A** zum Ziel führen wird! Da hilft auch kein Verweis auf altbackene Slogans wie z.B. //Spezialisten wissen mehr// ... m( |
| </WRAP> | </WRAP> |
| |
| * Das Thema "Woher beziehen wir die Hostdefinitionen und deren Eigenschaften?" sehen wir uns beim **[[playbook_example_09|Konfigurationsbeispiel 4]]** etwas genauer an. | * Das Thema "Woher beziehen wir die Hostdefinitionen und deren Eigenschaften?" sehen wir uns beim **[[playbook_example_09|Konfigurationsbeispiel 4]]** etwas genauer an. |
| * Eine entscheidende Frage bei einem **Ansible-Controll-Node** ist natürlich immer die Gretchenfrage, **[[playbook_example_10|wie erreicht man von diesem alle gewünschten Ziele]]**? Muss dies zwingend eine fest definierte Maschine ein Linux-Host im Intranet bzw, in einer eigens vorgegebenen DMZ sein, der via speziale Firewall-Regeln eine Freischaltung für alle betreffenden Hosts seine Ziele erreichen kann? Oder kann man das auch anderes, einfacher und ebenso sicher bewerkstelligen? Diese Fragestellung werden wir im vierten Konfigurationsbeispiel genauer beleuchten. | * Eine entscheidende Frage bei einem **Ansible-Controll-Node** ist natürlich immer die Gretchenfrage, **[[playbook_example_10|wie erreicht man von diesem alle gewünschten Ziele]]**? Muss dies zwingend eine fest definierte Maschine ein Linux-Host im Intranet bzw, in einer eigens vorgegebenen DMZ sein, der via speziale Firewall-Regeln eine Freischaltung für alle betreffenden Hosts seine Ziele erreichen kann? Oder kann man das auch anderes, einfacher und ebenso sicher bewerkstelligen? Diese Fragestellung werden wir im vierten Konfigurationsbeispiel genauer beleuchten. |
| * Befasst man sich über einen längeren Zeitraum mit **Ansible** wird man unweigerlich feststellen, dass sich die Art und Weise wie man Playbooks verfasst unweigerlich ändert, da man unentwegt lernt und seinen Code optimiert. Feste Strukturen und Rahmenbedingungen in Form von Eigendisziplin, kann hier ungemein helfen. Arbeitet man in einem Team an verschiedenen Projekten, sind solche Leitplanken Voraussetzung, damit alle möglichst schnell verstehen, was mit Hilfe der Playbooks erreicht werden soll und kann und vor allem wie. Bei der Sicherstellung dass Code auch einheitlich, modular und wiederverwendbar wird, greifen wir bei der Erstellung von Playbooks auf Rollen und Ansible-Module zurück. Diese Themen beleuchten wir im **fünften Abschnitt** dieser Dokureihe hier. | * Befasst man sich über einen längeren Zeitraum mit **Ansible** wird man unweigerlich feststellen, dass sich die Art und Weise wie man Playbooks verfasst unweigerlich ändert, da man unentwegt lernt und seinen Code optimiert. Feste Strukturen und Rahmenbedingungen in Form von Eigendisziplin, kann hier ungemein helfen. Arbeitet man in einem Team an verschiedenen Projekten, sind solche Leitplanken Voraussetzung, damit alle möglichst schnell verstehen, was mit Hilfe der Playbooks erreicht werden soll und kann und vor allem wie. Bei der Sicherstellung dass Code auch einheitlich, modular und wiederverwendbar wird, greifen wir bei der Erstellung von Playbooks auf Rollen und Ansible-Module zurück. Diese Themen beleuchten wir im **[[playbook_example_11|fünften Abschnitt]]** dieser Doku-Reihe hier. |
| | * Beim Thema Code-Überprüfung greifen wir auf das Projekt **[[lint|Ansible-Lint]]** zurück, welches helfen kann seinen Code einheitlich, strukturiert und code-technisch sauber zu halten. Wollen wir doch damit bewährte Praktiken, Muster und Verhaltensweisen fördern sowie gleichzeitig häufige Fallstricke vermeiden, die oft genug leicht zu Fehlern führen und dabei die Wartung des Codes erschweren können. |
| |
| | ===== weitere Beispiele ===== |
| | - __**[[playbook_example_13|Admin Benutzer verwalten (v1)]]**__ \\ Oft steht man vor der Herausforderung, Admin-Konten auf unzähligen Zielsystemen anzulegen und wieder zu löschen. So sind im Zuge eines onboarding von neuen Admins jeweils Konten anzulegen und mit Passworten und Schlüsselmaterial zu versorgen. Beim Ausscheiden eines Admins, müssen dessen|ihre Konten samt Passworten und Schlüssel wieder gelöscht werden. \\ Möchte ein bestehender Admin sein|ihr Passwort oder Schlüssel ändern, kann dies auch zu einer zeitraubenden Tätigkeit ausarten. In diesem Beispiel werden wir also das Anlegen und Löschen der Konten samt Passwörter und Schlüsselmaterial sowie die Pflege dieser Daten mit Hilfe von Ansible automatisieren? |
| | - __**[[playbook_example_14|Admin Benutzer verwalten (v2)]]**__ \\ im zweiten Beispiel werden wir uns mit dem Thema: "//Wie prüfen wir die Variablen aus dem Inventory auf Validität, Plausibilität und ob diese gesetzte sind?//" Hierzu verwenden wir das Ansible Modul **[[https://docs.ansible.com/ansible/latest/collections/ansible/builtin/assert_module.html|ansible.builtin.assert]]** und verfeinern unser Playbook aus dem [[playbook_example_13|Beispiel 1]]. |
| | ====== Links ====== |
| | * **[[start|Zurück zur "Ansible"-Übersicht]]** |
| | * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]** |
| | * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]** |
django