Server Installation/Ansible: Unterschied zwischen den Versionen
(→Übliche Aufgaben) |
(→Anwendungspolicy) |
||
Zeile 71: | Zeile 71: | ||
# kleinschrittige Änderungen vornehmen | # kleinschrittige Änderungen vornehmen | ||
# Änderungen im ersten Versuch nur auf einen einzigen Host anwenden (z.B. <code>ansible-playbook .... --limit HOSTNAME</code>) | # Änderungen im ersten Versuch nur auf einen einzigen Host anwenden (z.B. <code>ansible-playbook .... --limit HOSTNAME</code>) | ||
− | #* idealerweise beim ersten Versuch mit den zusätzlichen Optionen ''-- | + | #* idealerweise beim ersten Versuch mit den zusätzlichen Optionen ''--check --diff'' (keine Änderungen; Unterschiede anzeigen) |
# die Ausgabe des ansible-Playbook-Laufs sorgfältig auf erwartete und unerwartete Änderungen prüfen | # die Ausgabe des ansible-Playbook-Laufs sorgfältig auf erwartete und unerwartete Änderungen prüfen | ||
# die Wirksamkeit der Änderungen auf dem Host prüfen (funktionieren die Dienste noch?) | # die Wirksamkeit der Änderungen auf dem Host prüfen (funktionieren die Dienste noch?) |
Version vom 9. Januar 2016, 21:04 Uhr
Inhaltsverzeichnis |
Überblick
ansible ist eine Konfigurationsmanagement-Software basierend auf Python. Es benötigt für die Client-Konfiguration lediglich eine ssh-Verbindung. Auf der Client-Seite ist keine spezifische Software erforderlich.
Innerhalb von Opennet setzen wir ansible für die Konfiguration der UGW-Server ein.
Die Konfigurationsverwaltung wird durch clonen unseres ansible-Repositories und lokale Ausführung auf dem eigenen Rechner angewandt.
Konfigurationsverwaltung ist ein mächtiges Werkzeug, das durch unbedachte Nutzung großflächigen Schaden/Ausfälle produzieren kann. Siehe unseren Leitfaden für eine vorsichtige Nutzung. |
Vorbereitung
Die folgenden Schritte sind auszuführen, um die Ansible Konfigurationsverwaltung auf einen oder mehrere Hosts anzuwenden.
- Paket auf einem persönlichen Linux/Unix Host installieren (Bsp. Debian, Installation erfordert root-Rechte):
sudo apt-get install ansible
- git Repository auschecken:
git clone https://dev.opennet-initiative.de/git/on_ansible
(siehe Opennet DEV) - den eigenen SSH Schlüssel auf den zu konfigurierenden Servern autorisieren (lassen)
Verzeichnisstruktur
Im ansible-Verzeichnis gibt es mehrere Dateien und Unterverzeichnisse.
Globale Struktur
- hosts
- Diese Datei enthält das sogenannte Inventory von ansible.
- Hier werden alle Hosts aufgeführt, sowie Gruppen zugeordnet.
- playbook-*.yml
- Ein Playbook enthält Variablendefinitionen, sowie eine Liste von Aufgaben/Zuständen, die auf bestimmte Hosts angewandt werden sollen.
- Der Dateiname einer playbook-Datei spielt keine Rolle - die Playbooks werden ausschließlich manuell ausgeführt.
- host_vars/
- Für jeden Host kann hier eine gleichnamige Datei (
HOSTNAME.yml
) abgelegt werden, die Host-spezifische Einstellungen (vor allem: IPs und Interface-Namen) enthält. - roles/
- Eine Rolle ist in ansible eine Zusammenstellung von Konfigurationen, die auf gewisse Hosts angewandt werden sollen.
- Beispielsweise können alle notwendigen Einstellungen für den Betrieb eines DNS-Servers in einer eigenen Rolle zusammengefasst werden.
Rollen-spezifische Struktur
Unterhalb jedes roles-Unterverzeichnis ist die folgende Struktur üblich:
- defaults/main.yml
- Variablen, die innerhalb dieser Rolle für alle Hosts gelten sollen. Sie können durch Host-spezifische Variablen überschrieben werden.
- handlers/main.yml
- Im Anschluss an die Änderungen von Dateien müssen unter Umständen Dienste neugestartet werden. Diese Handler werden nur bei tatsächlichen Änderungen ausgeführt.
- files/
- Per Konvention werden in diesem Verzeichnis zu kopierende Dateien abgelegt. Das copy-Modul verwendet diesen Pfad automatisch als Präfix für relative Pfadangaben.
- templates/
- Per Konvention werden in diesem Verzeichnis Dateien abgelegt, die Template-Platzhalter enthalten. Das template-Modul verwendet diesen Pfad automatisch als Präfix für relative Pfadangaben.
- tasks/
- Per Konvention beinhaltet die Datei
main.yml
in diesem Verzeichnis include-Direktiven zum Einbinden weiterer Dateien in diesem Unterverzeichnis. - Die task-Dateien enthalten die Beschreibungen von herzustellenden Konfigurationen (vorhandene Pakete, Dateien, usw.).
Variablen
Host-spezifische, Rollen-spezifische oder globale Variablen können an verschiedenen Stellen mit unterschiedlicher Priorität definiert werden (siehe ansible-Dokumentation).
- Globale Variablen
- hosts-Datei in der [all:vars]-Sektion
- Rollen-spezifische Variablen für alle Hosts
- roles/*/defaults/
- Host-spezifische Variablen
- host_vars/
Übliche Aufgaben
- alle Konfigurationen anwenden:
ansible-playbook ~/ansible/playbook-ugw-server.yml
- einen einzigen Server konfigurieren:
ansible-playbook ~/ansible/playbook-ugw-server.yml --limit HOSTNAME.on-i.de
- auf anwendbare Änderungen prüfen ohne sie auszuführen:
ansible-playbook ~/ansible/playbook-ugw-server.yml --limit HOSTNAME.on-i.de --check
- Informationen (inkl. interner Variablen) eines Hosts anzeigen:
ansible -m setup HOSTNAME.on-i.de
- Dokumentation zu einem ansible-Modul anzeigen:
ansible-doc synchronize
- hübscher formatierte Doku im Netz
- Vorbereitung eines neuen verwalteten Hosts
- den Hostnamen in die hosts-Datei eintragen
- eine Datei für den Host unter host_vars/ erstellen (basierend auf der Kopie einer vorhandenen Host-Datei)
Anwendungspolicy
Folgende Abfolge von Schritten ist für eine sichere Verwendung des Werkzeugs Konfigurationverwaltung zu empfehlen:
- kleinschrittige Änderungen vornehmen
- Änderungen im ersten Versuch nur auf einen einzigen Host anwenden (z.B.
ansible-playbook .... --limit HOSTNAME
)- idealerweise beim ersten Versuch mit den zusätzlichen Optionen --check --diff (keine Änderungen; Unterschiede anzeigen)
- die Ausgabe des ansible-Playbook-Laufs sorgfältig auf erwartete und unerwartete Änderungen prüfen
- die Wirksamkeit der Änderungen auf dem Host prüfen (funktionieren die Dienste noch?)
- Änderungen auf alle Hosts anwenden
- Wirksamkeit und Funktionsfähigkeit der Dienste prüfen
- Änderungen via git committen
Rollen-Details
basic-server
Diese Rolle ist für alle opennet-Server geeignet.
Nach der ersten Anwendung wird eventuell das olsr-Routing durch die firewall-Regeln blockiert. Stelle also sicher, dass der Host auch ohne OLSR erreichbar ist. Erst die darauffolgende Rolle olsr-node öffnet die olsr-Ports. |
Ablauf
- Verteilung der ssh-Schlüssel von Administratoren und Maschinen-Accounts (z.B. Backup)
- grundlegende Firewall-Konfiguration mit ferm
- munin-Node installieren
- automatische Aktualisierung der Opennet-CA-Widerrufslisten
olsr-node
Konfiguration eines olsr-Knoten. Dazu gehört neben der olsr-Konfiguration auch Policy-Routing um sicherzustellen, dass Anfragen/Weiterleitungen aus nicht-olsr-Schnittstellen auf demselben Interface beantwortet werden.
Ablauf
- olsr installieren und konfigurieren
- Policy-Routing konfiugrieren (Routing-Tabelle anlegen, zusätzliche Routing-Regeln beim Booten erzeugen)
- ferm/firewall-Regeln: Markierung von eingehenden Paketen aus nicht-olsr-Schnittstellen (für die obigen Regeln)
ugw-server
Diese Rolle verwenden wir für die neuen UGW-Server seit 2015 (Server/erina, Server/subaru und Server/megumi).
TODO: Zertifikate erzeugen (Schlüssel und Zertifikat müssen aktuell per Hand erzeugt und auf den Server übertragen werden)
Wähle einen geeigneten Zeitpunkt für die Anwendung dieser Konfiguration aus. Vor allem die Änderung der openvpn-Konfiguration führt zu einer kurzzeitigen Trennung aller Clients. |
Ablauf
- Netzwerk-Konfiguration
- DNS-Server (bzw. Zonen-Slave)
- ugw-spezifsiche Firewall-Details
- OpenVPN (Konfiguration, Skripte, Zertifikate)
- OpenVPN-Statusseite (z.B. http://erina.opennet-initiative.de/vpnstatus)
- opennet-spezifische Munin-Plugins für UGW-Server
- Dateien für Download-Tests erzeugen
python-module
Übertrage ein paar opennet-spezifische Python-Module auf die Hosts, die für die UGW-Rolle erforderlich sind.
Ablauf
- Module kopieren
- Abhängigkeiten installieren
DNS-Slave-Server
Diese Rolle konfiguriert auf einem Server alle relevanten Details für einen DNS-Slave, der dem Hidden-Primary-Server auf Server/heartofgold folgt.
Ablauf
- Bind installieren
- geheimen DNS-Key von Server/heartofgold abholen
- Bind konfigurieren (inkl. DNS-Key)
- Firewall-Regel für tcp-Zugriff auf bind hinzufügen (für Zonen-Transfer)
- Resolv.conf auf lokalen Bind zeigen lassen