Das öffentliche Play-Repository mit den eigentlichen Aufgaben. Dieses Repository wird auf GitHub abgelegt.
Min. ein privates Inventory-Repository mit den Verweisen, welche Devices mit dem Play kontrolliert werden sollen.
Das Inventory-Repository hat 2 Dateien:
known_hosts - für die SSH Verbindungen
main.yaml - damit Ansible weiss, welche Hosts verwaltet werden sollen.
DETAILS
Idealerweise wird ein Cluster in einem definierten Zustand gehalten. Je grösser und komplexer ein Cluster wird, desto weniger kann und soll man das von Hand machen. Genau für diese Aufgabe gibt es Ansible.
Die Ansible Best Practices machen zwar Vorschläge zum Aufbau solcher Wartungsaufgaben für ein definiertes System. Es wird zwar immer darauf verwiesen, dass Leider geben sie wenig Auskunft über die Repository Organisation.
Bei Ansible gibt es drei Komponenten, die wir beachten:
Die auszuführenden Aufgaben (das Playbook). Diese Komponente enthält in der Regel keine privaten Informationen und kann open Source sein. Entsprechend kann das Ansible Playbook als öffentliches Repository auf github.com abgelegt werden.
Die zu wartende Infrastruktur (das Inventory). Diese Komponente enthält nur spezifische Informationen für die Ausführung eines Playbooks auf den zu verwaltenden Rechnern. Das Inventory enthält Informationen über die Knoten, Nutzernamen und andere besondere Einstellungen. Diese Information darf nicht öffentlich gemacht werden, sollte aber versioniert werden. Deshalb sollte das Ansible Inventory in einem separaten privaten Repository abgelegt werden.
Die SSH-Verbindung zu den Hosts. Die SSH-Verbindung umfasst die privaten Schlüssel für die Verbindung sowie die known_hosts-Datei.
Die privaten Schlüssel sind privat für die jeweilige Verbindung und dürfen **nicht öffentlich* gemacht und auch nicht versioniert** werden werden.
Die known_hosts-Datei enthält die öffentlichen Schlüssel der im Inventory definierten Hosts. Diese Schlüssel dürfen grundsätzlich mit dem Inventory versioniert werden.
Im Ansible Jargon bezeichnet das Inventory die gesamte Struktur von Infrastrukturdefinitionen und Management-Aufgaben. Im folgenden bezeichnen wir die Aufgaben als Playbook und nur die Infrastrukturdefinitionen als Inventory.
Playbook
Dieser Teil enthält öffentliche Informationen über die Wartungsaufgaben und darf wird in einem öffentlichen Repository versioniert werden. Ein Playbook kann aus mehreren Teil-Aufgaben bestehen, die separat gehalten werden.
Falls ein Playbook private Informationen enthält (z.B. Nutzer-Management), dann müssen die nicht öffentlichen Informationen als Variablen im Inventory abgelegt werden.
Inventory
Dieser Teil enthält nicht öffentliche Informationen über die Infrastruktur und muss wird in einem privaten Repository versioniert werden.
Das Inventory besteht aus zwei Dateien:
main.yaml (für ansible)
known_hosts (für die SSH Verbindung)
Zusätzlich können weitere Konfigurationen in Verzeichnissen entsprechend der Ansible Inventory Anleitung für Variablen und Hosts abgelegt werden.
TL&DR
Wir automatisieren Aufgaben mit Ansible.
Für jede Aufgabe erstellen wir zwei Repositories.
Das Inventory-Repository hat 2 Dateien:
known_hosts
- für die SSH Verbindungenmain.yaml
- damit Ansible weiss, welche Hosts verwaltet werden sollen.DETAILS
Idealerweise wird ein Cluster in einem definierten Zustand gehalten. Je grösser und komplexer ein Cluster wird, desto weniger kann und soll man das von Hand machen. Genau für diese Aufgabe gibt es Ansible.
Die Ansible Best Practices machen zwar Vorschläge zum Aufbau solcher Wartungsaufgaben für ein definiertes System. Es wird zwar immer darauf verwiesen, dass Leider geben sie wenig Auskunft über die Repository Organisation.
Bei Ansible gibt es drei Komponenten, die wir beachten:
known_hosts
-Datei.known_hosts
-Datei enthält die öffentlichen Schlüssel der im Inventory definierten Hosts. Diese Schlüssel dürfen grundsätzlich mit dem Inventory versioniert werden.Im Ansible Jargon bezeichnet das Inventory die gesamte Struktur von Infrastrukturdefinitionen und Management-Aufgaben. Im folgenden bezeichnen wir die Aufgaben als Playbook und nur die Infrastrukturdefinitionen als Inventory.
Playbook
Dieser Teil enthält öffentliche Informationen über die Wartungsaufgaben und darf wird in einem öffentlichen Repository versioniert werden. Ein Playbook kann aus mehreren Teil-Aufgaben bestehen, die separat gehalten werden.
Falls ein Playbook private Informationen enthält (z.B. Nutzer-Management), dann müssen die nicht öffentlichen Informationen als Variablen im Inventory abgelegt werden.
Inventory
Dieser Teil enthält nicht öffentliche Informationen über die Infrastruktur und muss wird in einem privaten Repository versioniert werden.
Das Inventory besteht aus zwei Dateien:
main.yaml
(für ansible)known_hosts
(für die SSH Verbindung)Zusätzlich können weitere Konfigurationen in Verzeichnissen entsprechend der Ansible Inventory Anleitung für Variablen und Hosts abgelegt werden.
In diesem Verzeichnis liegen keine Plays.