Ansible Automatisierung.page 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110
  1. ---
  2. format: markdown
  3. categories: Netz-Infrastruktur, Backbone, Supernodes
  4. title: Server-Automatisierung
  5. ...
  6. # Automatisierung der Konfiguration von Supernodes/Gateways und anderer Server (als Link in ff@home einfuegen!)
  7. ## Aufbau und Konfiguration 1) Steuerungsrechner 2) Repository 3) Zielrechner
  8. ## 1) Steuerungsrechner
  9. Der Steuerungsrechner (Control Host) hält die Konfigurationen der Zielrechner (target hosts) und die Ansible Playbooks zur Anpassung der Zielrechner vor. Jeder Mitarbeiter kann sich einen Steuerungsrechner wie im Folgenden geschildert anlegen, es sind also mehrere Steuerungsrechner möglich.
  10. Ein Steuerungsrechner wird mit Python3 und Ansible in einer virtuellen venv-Umgebung konfiguriert, die angezeigt wird mit:
  11. (venv)~$ ansible --version
  12. ansible [core 2.19.3]
  13. config file = /home/m-an/git/snng-roles-l2tp/ansible.cfg
  14. configured module search path = ['/home/m-an/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  15. ansible python module location = /home/m-an/git/venv/lib/python3.12/site-packages/ansible
  16. ansible collection location = /home/m-an/.ansible/collections:/usr/share/ansible/collections
  17. executable location = /home/m-an/git/venv/bin/ansible
  18. python version = 3.12.3 (main, Nov 6 2025, 13:44:16) [GCC 13.3.0] (/home/m-an/git/venv/bin/python3)
  19. jinja version = 3.1.6
  20. pyyaml version = 6.0.3 (with libyaml v0.2.5)
  21. Die Ansibleversion des Steuerungsrechners ausserhalb der venv-Umgebung kann sich wegen Systemupdates von der der venv-Umgebung unterscheiden.
  22. Deshalb sollte nur in der venv-Umgebung mit den dort festgelegten Versionen gearbeitet werden.
  23. ## Python venv-Umgebung erstellen
  24. ✅ 1. Benötigte Pakete installieren
  25. Unter Debian heißt das Paket für virtuelle Umgebungen meist python3-venv:
  26. $ sudo apt update
  27. $ sudo apt install python3-venv
  28. ✅ 2. Virtuelle Umgebung erstellen
  29. Wechsle mit cd xyz in den gewünschten Projektordner und führe aus:
  30. ~/git/xyz $ python3 -m venv venv
  31. Dadurch entsteht ein Verzeichnis venv/, das unabhängig vom hostsystem die nötigen Python-Pakete enthält.
  32. ✅ 3. venv aktivieren
  33. ~/git/xyz $ source venv/bin/activate
  34. Du erkennst die aktivierte venv an der (venv)-Präfix in der Shell.
  35. ✅ 4. Pakete installieren
  36. Jetzt nutzt pip die isolierte Umgebung:
  37. (venv)~/git/xyz $ pip install <paketname>
  38. oder zum Beispiel:
  39. (venv)~/git/xyz $ pip install ansible (Auswahl Version darstellen?!)
  40. um genau in diese venv-Umgebung ansible zu installieren. Fehlende Python-Pakete in der venv-Umgebung müssen mit
  41. (venv)~/git/xyz $ pip install <fehlendes Python-Paket>
  42. ✅ 5. venv wieder deaktivieren, (venv) erscheint nicht mehr im Prompt:
  43. (venv)~/git/xyz $ deactivate
  44. ~/git/xyz $
  45. ## 2) Aufbau des Repository
  46. Das Repository ist unter git.ffdo.de im Verzeichnis snng-roles-l2tp zu finden. Dieses Repository ist geclont von ffdo-infrastruktur/ffdo-ansible-l2tp, um die Historie zu erhalten und das ursprüngliche Repo nicht zu verändern:
  47. ~/git/git clone https://git.ffdo.de/ffdo-infrastruktur/snng-roles-l2tp.git
  48. Das komplette Playbook zur Erstellung eines Gateways/Supernodes heisst ng-gateway.yml, über Tags können daraus einzelne Playbooks isoliert ausgeführt werden.
  49. Alle Playbooks werden unter dem mit -u angegeben Usernamen oder ohne -u mit dem angemeldeten User des Steuerungsrechners ausgeführt. Eine Anmeldung als root auf den Zielrechnern ist grundsätzlich ausgeschlossen. Eine Anmeldung für User ist nur über ssh möglich. Dafür müssen für jeden User, der das Playbook ausführen soll, der publickey auf die Zielrechner kopiert werden. Der Mitarbeiter oder User muss in die Gruppe sudo aufgenommen werden, damit eine privilege-escalation möglich ist.
  50. Das Passwort für die privilege-escalation, also für sudo ist abgeschaltet. Ein Aufruf für den Server snng-dus03 lautet dann:
  51. (venv)~/git/snng-roles-l2tp $ ansible-playbook -b ng-gateway.yml -v -l snng-dus03 -u <username>
  52. oder mit einem Tag, um nur ein oder mehrere Teile des Playbooks auszuführen:
  53. (venv)~/git/snng-roles-l2tp $ ansible-playbook -b ng-gateway.yml -v -l snng-dus03 --tags "<tagname>" -u <username>
  54. Die anderen dort vorhandenen Playbooks dienen zu Testzwecken.
  55. ## Umgang mit dem Repository und mit git
  56. Wenn nur wenige Personen im Repo arbeiten, ist es sinnvoll, vor jedem Arbeitstreffen ein git pull durchzuführen und nach Abschluss der Arbeiten ein git push.
  57. Damit werden Forks und evtl. notwendige --rebase vermieden.
  58. ## 3) Zielrechner
  59. Ein Zielrechner (target host) oder eine Ziel-VM müssen folgende Elemente als Rohzustand enthalten, damit sie per ansible konfiguriert werden können:
  60. - ein aktuelles Debian-Betriebssystem mit python3
  61. - eine ip, also einen Netzzugang
  62. - einen ssh-Zugang für die Personen, die von ihrem Steuerungsrechner aus Playbooks auf dem Zielrechner ausführen möchten
  63. - ansible selbst ist **nicht** erforderlich