Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
linux:ansible:playbook_example_13 [10.10.2022 18:45. ] – [Aufgabenstellung] django | linux:ansible:playbook_example_13 [28.11.2022 18:48. ] (aktuell) – Playbook mit Hilfe des GH-Plugin eingebunden. django | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== Ansible - weiterte | + | ====== Ansible - weitere |
{{: | {{: | ||
Zeile 5: | Zeile 5: | ||
===== Aufgabenstellung ===== | ===== Aufgabenstellung ===== | ||
- | Oft steht man vor der Herausforderung, | + | Oft steht man vor der Herausforderung, |
- | + | <WRAP center round important 60%> | |
- | + | Es soll ja zuweilen Unternehmungen geben, bei denen sich das Personal mehr oder weniger in sehr kurzen Zeitabständen die Klinge in die Hand geben, was das Prozedere dann zusätzlich vom Aufwand her nach oben treibt. :-x | |
- | Für die Grundkonfiguration in der Basisausführung der Ansible-Umgebung, | + | </ |
- | + | Möchte ein bestehender Admin sein|ihr Passwort oder Schlüssel ändern, kann dies auch zu einer zeitraubenden Tätigkeit ausarten. Was liegt also näher das Anlegen und Löschen der Konten samt Passwörter und Schlüsselmaterial sowie die Pflege dieser Daten mit Hilfe von Ansible zu automatisieren? | |
- | Mit Hilfe dieses Playbooks können alle erforderlichen Konfigurationsschritte reproduzierbar und beliebig oft abgesetzt werden. Bei Bedarf ist als also jederzeit ohne grossen Aufwand möglich den Ansible-Controll-Node neu aufzusetzen und das System für spätere Playbook-Rollouts vorzubereiten, | + | |
- | + | ||
- | Folgende Schritte sollen von dem playbook abgearbeitet werden: | + | |
- | - Kopieren der Ansible-Konfigurationsdatei / | + | |
- | - Anpassen, sprich konfigurieren der individuellen Ansible Umgebung. | + | |
- | - Ansible Directory Layout anlegen und mit Dummy-Inhalten versorgen. | + | |
- | + | ||
- | Schliesslich wollen wir unsere Zeit als Admin ja auch sinnvoll nutzen und mit möglichst geringen Aufwand zu Ziel kommen. | + | |
+ | ===== Lösung ===== | ||
- | ==== Lösung ==== | ||
<WRAP center round tip 80%> | <WRAP center round tip 80%> | ||
- | Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen des Verzeichnisses | + | Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen |
< | < | ||
+ | <WRAP center round alert 100%> | ||
+ | **Wichtig**: | ||
+ | $ ansible-vault encrypt ~/ | ||
+ | </ | ||
Anschliessend kann man direkt **[[# | Anschliessend kann man direkt **[[# | ||
</ | </ | ||
+ | ==== Vorbereitung - Admindaten im Inventory ==== | ||
+ | Dreh- und Angelpunkt unserer Admin-Verwaltung ist natürlich unser Inventory. Dank unserer Vorbereitungen ins Sachen **[[playbook_example_07|Ansible Vault]]** können wir natürlich gehashte Passwörter und SSH-keys im Inventory vorhalten, da diese dort ja sicher verwahrt vorliegen. | ||
+ | === Inventory-Hülle === | ||
+ | Wir werden uns also erst einmal unsere Admins im Inventory eine zugehörige Datei anlegen. | ||
+ | $ ansible-vault create ~/ | ||
+ | Dort legen wir als erstes mal eine Hülle für die weitere Bearbeitung an. | ||
+ | <file c++ admins> | ||
+ | - user : Vorname Nachname | ||
+ | name : User-Name | ||
+ | groups : wheel | ||
+ | ids : 1000 | ||
+ | shell : /bin/bash | ||
+ | state : present | ||
+ | pwd : <-- Ergebnis: openssl passwd -6 --> | ||
+ | key : ssh-key | ||
+ | | ||
+ | </ | ||
+ | === gehashtes Passwort === | ||
+ | Damit wir keine PLAIN-Text Passworte sondern nun gehashte Passwörter im Inventory stehen haben wollen, denn aus Sicherheitsgründen dürfen nur die Admins selbst deren Passwort kennen und sonst niemand bitten wir diese uns das gehashte Passwort mit **'' | ||
+ | | ||
+ | Password: | ||
+ | Verifying - Password: | ||
+ | $6$n9UE0JVV7T.nzFJOdSY1dHDEsbfY3$0SPNKmewfaQ0z5thaRMrrrI9Uig.nzFJOdSY1erIZbw5yzDqeCg4S2oXa8zn2jEf9KDfjg31 | ||
+ | Ferner benötigen wir noch den SSH-Publickey den wir uns ebenso wie das gerade erstellte gehashte Passwort von unseren Admins auf einem sicheren Kommunikationsweg zukommen. | ||
+ | === Inventory Daten für unsere Admins === | ||
+ | Diese Daten übernehmen wir dann in unser Inventory: | ||
$ ansible-vault edit inventories/ | $ ansible-vault edit inventories/ | ||
+ | |||
<file c++ admins> | <file c++ admins> | ||
- user : Michael Nausch | - user : Michael Nausch | ||
Zeile 56: | Zeile 78: | ||
ids : 1002 | ids : 1002 | ||
shell : /bin/bash | shell : /bin/bash | ||
- | state : absent | + | state : present |
pwd : $6$nJVSYV9J17.SY1v0oM9fow8Do46dHDEsbfY3$0SPNKmewfaQ0z5tsafZi3haRMrrrI9Uig.OdSY1e6dHDEsbfY3$rI51ewfaQ0z5th | pwd : $6$nJVSYV9J17.SY1v0oM9fow8Do46dHDEsbfY3$0SPNKmewfaQ0z5tsafZi3haRMrrrI9Uig.OdSY1e6dHDEsbfY3$rI51ewfaQ0z5th | ||
key : ssh-ed25519 AAAAK6Pb38bv0oM9fw8DoOdSY1er4b38bNzaqK6Pb38bv0oM9fw01erIZbw5yzDqeCC5 oliver@nausch.org | key : ssh-ed25519 AAAAK6Pb38bv0oM9fw8DoOdSY1er4b38bNzaqK6Pb38bv0oM9fw01erIZbw5yzDqeCC5 oliver@nausch.org | ||
</ | </ | ||
+ | In diesem Beispiel haben wir also drei Admins mit den zugehörigen Daten. | ||
+ | ==== Playbook mit zugehörigen Rollen ==== | ||
+ | Hatten wir das **[[https:// | ||
+ | === Playbook === | ||
+ | Das Playbook an sich ist relativ unspektakulär, | ||
+ | $ vim ~/ | ||
- | <code>--- | + | {{gh> https:// |
- | - name: " | ||
- | ansible.builtin.group: | ||
- | gid: '{{ item.ids }}' | ||
- | name: '{{ item.name }}' | ||
- | state: present | ||
- | with_items: '{{ linux_admins }}' | ||
- | - name: " | + | === Rolle und Tasks === |
- | ansible.builtin.user: | + | Bevor wir unsere Rolle **'' |
- | append: true | + | $ cp -avr ~/ |
- | | + | |
- | create_home: | + | |
- | force: true | + | |
- | state: | + | |
- | group: | + | |
- | groups: | + | |
- | name: '{{ item.name }}' | + | |
- | | + | |
- | shell: '{{ item.shell }}' | + | |
- | uid: '{{ item.ids }}' | + | |
- | remove: true | + | |
- | with_items: "{{ linux_admins }}" | + | |
- | - name: " | + | Nun legen wir unseren Main-Task an. |
- | ansible.builtin.group: | + | $ vim ~/ansible/ |
- | gid: '{{ item.ids }}' | + | {{gh> https://gitlab.nausch.org/ |
- | name: '{{ item.name }}' | + | |
- | state: '{{ item.state }}' | + | |
- | with_items: '{{ linux_admins | + | |
- | - name: " | + | Was nun noch fehlt sind die beiden eigentlichen Tasks. Als erstes legen wir den Task an, mit Hilfe dessen die jeweilige(n) Admin-Gruppe(n) und User gepflegt werden. |
- | ansible.builtin.file: | + | $ vim ~/ansible/roles/admins/ |
- | | + | {{gh> https://gitlab.nausch.org/ |
- | | + | |
- | owner: '{{ item.name }}' | + | |
- | group: '{{ item.name }}' | + | |
- | mode: ' | + | |
- | when: ' item.state == " | + | |
- | with_items: '{{ linux_admins | + | |
- | - name: " | + | Zu guter Letzt legen wir noch den Task an, damit die Admins, die Mitglied der Gruppe **'' |
- | ansible.builtin.copy: | + | $ vim ~/ansible/roles/admins/ |
- | | + | {{gh> https://gitlab.nausch.org/ |
- | content: | | + | |
- | {{ item.key }} | + | |
- | | + | |
- | group: '{{ item.name }}' | + | |
- | mode: ' | + | |
- | when: ' item.state == " | + | |
- | with_items: '{{ linux_admins | + | |
- | - name: "VIM Konfig ablegen" | + | ===== Ausführung ===== |
- | | + | Mit Hilfe dieses Playbooks können alle erforderlichen Konfigurationsschritte reproduzierbar und beliebig oft abgesetzt werden. Somit können neue Admins hinzugefügt, |
- | src: files/ | + | |
- | dest: /home/{{ item.name }}/.vimrc | + | |
- | owner: '{{ item.name }}' | + | |
- | group: '{{ item.name }}' | + | |
- | mode: ' | + | |
- | when: ' item.state == " | + | |
- | with_items: '{{ linux_admins }}' | + | |
- | - name: " | + | Folgende Schritte werden also mit Hilfe des Playbooks abgearbeitet: |
- | | + | |
- | src: files/ | + | - Sicherstellen dass die Admin-User existieren. |
- | dest: /home/{{ item.name }}/.bashrc | + | - Gruppe entfernen, sofern der User zum Löschen gekennzeichnet ist mit **'' |
- | | + | - SSH-Client-Verzeichnis anlegen |
- | group: | + | |
- | mode: ' | + | - SSH-Client-Verzeichnis entfernen, sofern der User zum Löschen gekennzeichnet ist mit **'' |
- | | + | |
- | | + | |
- | - name: " | + | Entscheidend für das Anlegen bzw. Löschen eines Admins ist die Array-Variable **'' |
- | ansible.builtin.copy: | + | |
- | src: files/ | + | |
- | dest: /home/{{ item.name }}/ | + | |
- | owner: | + | |
- | group: | + | |
- | mode: '0640' | + | |
- | when: ' | + | |
- | with_items: | + | |
- | - name: " | + | Haben wir die Daten in unserem Vault entsprechend aktualisiert können wir, wie im Playbook vermerkt, das Playbook wie gewohnt aufrufen. |
- | ansible.builtin.copy: | + | Aufruf via für alles Hosts: |
- | src: files/ | + | $ ansible-playbook playbooks/admin_updates.yml |
- | dest: /home/{{ item.name }}/ | + | bzw. für einzelne Hosts: |
- | | + | $ ansible-playbook playbooks/ |
- | group: '{{ item.name }}' | + | |
- | mode: ' | + | |
- | when: ' item.state == " | + | |
- | with_items: '{{ linux_admins }}' | + | |
- | - name: " | + | Interessiert uns lediglich die erfolgreiche Abarbeitung unseres Playbook-Aufrufs können wir dies z.B. beim Host mit dem Namen **'' |
- | ansible.builtin.file: | + | $ ansible-playbook playbooks/admin_updates.yml --limit vml000137 | sed -n '/PLAY RECAP/, |
- | path: /home/{{ item.name }}/.ssh | + | |
- | | + | |
- | | + | vml000137 |
- | | + | |
+ | ===== Zusammenfassung ===== | ||
+ | <WRAP center round tip 80%> | ||
+ | Wir haben nun eine standardisiertes Verfahren für die Pflege unserer Admins, so dass aufwändiges manuelles Anlegen oder Löschen von Admin-Konten nicht mehr wichtige Ressourcen auffrisst. Auch können so unsere Admins ihre Passwörter und|oder SSH-Key sehr einfach auf Dutzenden oder vielen Hunderten Servern austauschen und aktualisieren. | ||
+ | </ | ||
- | ... | + | ====== Links ====== |
- | </code> | + | * **[[detail|zurück zum Kapitel " |
+ | * **=> [[playbook_example_10|weiter zum Kapitel " | ||
+ | * **[[start|Zurück zur " | ||
+ | * **[[wiki: | ||
+ | * **[[http:// |