Ansible-Konfiguration

Einführung

In diesem Lab lernen Sie über Ansible-Konfigurationsdateien und wie Sie das Verhalten von Ansible anpassen können. Ansible verwendet Konfigurationsdateien, um verschiedene Einstellungen zu definieren, die seinen Betrieb steuern. Sie werden die Standardkonfiguration untersuchen, eine benutzerdefinierte Konfigurationsdatei erstellen und verstehen, wie verschiedene Konfigurationsoptionen das Verhalten von Ansible beeinflussen. Am Ende dieses Labs haben Sie praktische Erfahrungen mit der Konfiguration von Ansible für verschiedene Szenarien gesammelt, was für die Anpassung von Ansible an Ihre spezifischen Anforderungen und Umgebung von entscheidender Bedeutung ist.

Das Standardansible-Konzept verstehen

Beginnen wir damit, die Standardkonfiguration von Ansible zu untersuchen. Ansible sucht nach Konfigurationsdateien an mehreren Orten, wobei jeder Ort eine andere Priorität hat.

Zunächst überprüfen wir, ob es eine systemweite Ansible-Konfigurationsdatei gibt:

cat /etc/ansible/ansible.cfg

Sie könnten eine Fehlermeldung sehen, wenn diese Datei nicht existiert. Dies ist in vielen Umgebungen normal.

Nun schauen wir uns die Standardkonfigurationswerte von Ansible an. Wir können dies tun, indem wir folgenden Befehl ausführen:

ansible-config dump

Dieser Befehl zeigt Ihnen alle aktuellen Ansible-Konfigurationseinstellungen an. Es ist eine lange Liste, also lassen Sie uns einige wichtige Einstellungen aufschlüsseln:

• DEFAULT_HOST_LIST: Der Standardpfad zur Inventar-Datei.
• DEFAULT_REMOTE_USER: Der Standard-SSH-Benutzer, den Ansible verwendet, um sich mit Remote-Hosts zu verbinden.
• DEFAULT_BECOME_METHOD: Die Standardmethode, die Ansible für die Privilegierhöhung verwendet (z. B. sudo).

Machen Sie sich keine Sorgen, wenn Sie noch nicht alle diese Einstellungen verstehen. Je mehr Sie mit Ansible arbeiten, desto vertrauter werden Sie mit denjenigen Einstellungen, die für Ihre Bedürfnisse am relevantesten sind.

Drücken Sie Q, um die Ausgabe zu beenden.

Nun erstellen wir eine einfache Inventar-Datei, die wir in unseren nächsten Schritten verwenden können:

echo "localhost ansible_connection=local" > /home/labex/project/inventory

Dadurch wird eine minimale Inventar-Datei erstellt, in der nur der lokale Host definiert ist.

Erstellen einer benutzerdefinierten Ansible-Konfigurationsdatei

Nachdem wir nun die Standardkonfiguration verstanden haben, erstellen wir eine benutzerdefinierte Ansible-Konfigurationsdatei. Dadurch können wir die Standardeinstellungen überschreiben und das Verhalten von Ansible an unsere Bedürfnisse anpassen.

Erstellen Sie eine neue Datei namens ansible.cfg im Verzeichnis /home/labex/project:

nano /home/labex/project/ansible.cfg

Fügen Sie der Datei folgenden Inhalt hinzu:

[defaults]
inventory = /home/labex/project/inventory
remote_user = labex
host_key_checking = False
stdout_callback = yaml

[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

Lassen Sie uns diese Einstellungen aufschlüsseln:

• inventory: Gibt den Pfad zu unserer Inventar-Datei an.
• remote_user: Legt den Standard-SSH-Benutzer für Verbindungen fest.
• host_key_checking: Deaktiviert die Prüfung des SSH-Hostschlüssels, was in Testumgebungen nützlich sein kann (sollte jedoch aus Sicherheitsgründen in der Produktion aktiviert sein).
• stdout_callback: Ändert das Ausgabeformat auf YAML für bessere Lesbarkeit.
• become: Aktiviert standardmäßig die Privilegierhöhung.
• become_method: Legt sudo als Methode für die Privilegierhöhung fest.
• become_user: Gibt an, zu welchem Benutzer gewechselt werden soll, wenn die Privilegien erhöht werden.
• become_ask_pass: Deaktiviert die Aufforderung nach dem sudo-Passwort.

Speichern Sie die Datei und verlassen Sie den Editor. In nano können Sie dies tun, indem Sie Ctrl+X drücken, dann Y zum Bestätigen und Enter zum Speichern.

Nun überprüfen wir, ob Ansible unsere neue Konfigurationsdatei verwendet. Führen Sie folgenden Befehl aus:

ansible-config dump --only-changed

DEFAULT_BECOME(/home/labex/project/ansible.cfg) = True
DEFAULT_BECOME_ASK_PASS(/home/labex/project/ansible.cfg) = False
DEFAULT_BECOME_METHOD(/home/labex/project/ansible.cfg) = sudo
DEFAULT_BECOME_USER(/home/labex/project/ansible.cfg) = root
DEFAULT_HOST_LIST(/home/labex/project/ansible.cfg) = ['/home/labex/project/inventory']
DEFAULT_REMOTE_USER(/home/labex/project/ansible.cfg) = labex
DEFAULT_STDOUT_CALLBACK(/home/labex/project/ansible.cfg) = yaml
HOST_KEY_CHECKING(/home/labex/project/ansible.cfg) = False

Dieser Befehl zeigt nur die Einstellungen an, die sich von der Standardkonfiguration unterscheiden. Sie sollten die Änderungen sehen, die wir in unserer benutzerdefinierten ansible.cfg-Datei vorgenommen haben.

Testen der benutzerdefinierten Konfiguration

Nachdem wir nun unsere benutzerdefinierte Konfiguration eingerichtet haben, erstellen wir ein einfaches Playbook, um sie zu testen. Dies hilft uns zu verstehen, wie unsere Konfigurationsänderungen das Verhalten von Ansible beeinflussen.

Erstellen Sie eine neue Datei namens test_config.yml im Verzeichnis /home/labex/project:

nano /home/labex/project/test_config.yml

Aktualisieren Sie den Inhalt wie folgt:

---
- name: Test Custom Configuration
  hosts: all
  tasks:
    - name: Display remote user
      debug:
        msg: "Connected as user: {{ ansible_user }}"

    - name: Display privilege escalation info
      debug:
        msg: "Privilege escalation is {{ 'enabled' if ansible_become | default(false) else 'disabled' }}"

    - name: Show Ansible configuration
      debug:
        msg: "Inventory file: {{ lookup('config', 'DEFAULT_HOST_LIST') }}"

    - name: Check if become is enabled in ansible.cfg
      command: grep "become = True" /home/labex/project/ansible.cfg
      register: become_check
      changed_when: false
      failed_when: false

    - name: Display become setting from ansible.cfg
      debug:
        msg: "Become is {{ 'enabled' if become_check.rc == 0 else 'disabled' }} in ansible.cfg"

Dieses aktualisierte Playbook führt folgende Änderungen durch:

1. Wir haben einen Standardwert für ansible_become hinzugefügt, um den Fehler eines undefinierten Variablenfehlers zu vermeiden.
2. Wir haben zwei neue Aufgaben hinzugefügt, die die ansible.cfg-Datei direkt auf die become-Einstellung prüfen, um eine genauere Darstellung Ihrer Konfiguration zu liefern.

Nun führen wir das aktualisierte Playbook aus:

ansible-playbook /home/labex/project/test_config.yml

Dies sollte ohne Fehler ausgeführt werden und Ihnen Informationen über Ihre Ansible-Konfiguration liefern.

Darüber hinaus beheben wir die Deprecation-Warnung, indem wir unsere ansible.cfg-Datei aktualisieren:

nano /home/labex/project/ansible.cfg

Fügen Sie die folgende Zeile unter dem Abschnitt [defaults] hinzu:

interpreter_python = /usr/bin/python3

Ihre ansible.cfg-Datei sollte nun in etwa so aussehen:

[defaults]
inventory = /home/labex/project/inventory
remote_user = labex
host_key_checking = False
stdout_callback = yaml
interpreter_python = /usr/bin/python3

[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

Speichern Sie die Datei und verlassen Sie den Editor.

Nun, wenn Sie das Playbook erneut ausführen:

ansible-playbook /home/labex/project/test_config.yml

Sie sollten die Ausgabe ohne die Deprecation-Warnung sehen, und es sollten Ihre Konfigurationseinstellungen korrekt angezeigt werden.

Zusammenfassung

In diesem Lab haben Sie über Ansible-Konfigurationsdateien und wie Sie das Verhalten von Ansible anpassen können gelernt. Hier sind die wichtigsten Erkenntnisse:

1. Ansible verwendet Konfigurationsdateien, um sein Verhalten zu steuern. Die Standardkonfiguration kann mit dem Befehl ansible-config dump angezeigt werden.

2. Sie können benutzerdefinierte Konfigurationsdateien erstellen, um die Standardeinstellungen zu überschreiben. Diese Dateien werden normalerweise ansible.cfg genannt und können an verschiedenen Orten mit unterschiedlicher Priorität platziert werden.

3. Wichtige Konfigurationseinstellungen umfassen:

   • inventory: Gibt den Pfad zur Inventar-Datei an.
   • remote_user: Legt den Standard-SSH-Benutzer für Verbindungen fest.
   • host_key_checking: Steuert die Prüfung des SSH-Hostschlüssels.
   • become und verwandte Einstellungen: Steuern die Privilegierhöhung.

4. Der Befehl ansible-config dump --only-changed ist nützlich, um nur die Einstellungen anzuzeigen, die sich von der Standardkonfiguration unterscheiden.

5. Sie können Ihre Konfigurationsänderungen testen, indem Sie Playbooks erstellen und ausführen, die Konfigurationsinformationen anzeigen.

6. Die Option --config ermöglicht es Ihnen, eine bestimmte Konfigurationsdatei anzugeben, wenn Sie Ansible-Befehle ausführen. Dies kann nützlich sein für Tests oder wenn Sie für verschiedene Szenarien unterschiedliche Konfigurationen verwenden müssen.

Das Verständnis und die Möglichkeit, die Ansible-Konfiguration anzupassen, ist von entscheidender Bedeutung, um Ansible an Ihre spezifische Umgebung und Anforderungen anzupassen. Wenn Sie weiterhin mit Ansible arbeiten, werden Sie wahrscheinlich diese Einstellungen anpassen, um Ihre Automatisierungsworkflows zu optimieren.

Üben Sie, indem Sie für verschiedene Szenarien unterschiedliche Konfigurationsdateien erstellen. Beispielsweise könnten Sie eine Konfiguration für Testumgebungen erstellen, in denen die Sicherheitsrichtlinien weniger streng sind, und eine andere für Produktionsumgebungen mit strengeren Sicherheitsrichtlinien.

Denken Sie daran, dass einige Einstellungen wie das Deaktivieren von host_key_checking zwar für Tests praktisch sein können, aber in Produktionsumgebungen, in denen die Sicherheit von größter Wichtigkeit ist, sorgfältig erwogen werden sollten. Überprüfen Sie immer Ihre Ansible-Konfiguration als Teil Ihrer gesamten System-Sicherheitsstrategie.

In zukünftigen Labs werden Sie lernen, wie Sie diese Konfigurationseinstellungen in komplexeren Szenarien nutzen können, indem Sie sie mit Rollen, dynamischen Inventaren und anderen fortgeschrittenen Ansible-Funktionen integrieren.