Ansible: Andere Option für die Telnet-Prüfung offener Ports verfügbar?

Ich bin neu bei Ansible. Hier ist meine Aufgabe ...

Ich habe mehr als 400 Hosts und muss überprüfen, ob 5 verschiedene Ports von ihrem Ende zu unserem Webserver offen sind.

Einzeln könnte ich mich einloggen und ausführen:

telnet mywebserver.com 443
telnet mywebserver.com 80
telnet mywebserver.com 8443

..und so weiter..

Welches Modul oder Plugin könnte in Ansible verwendet werden, damit ich dies automatisieren und die Ergebnisse (ob offene oder geschlossene Ports) an meinen Ansible-Server zurückmelden kann?

Sie können das Ansible wait_for- Modul verwenden, das überprüft, ob ein bestimmter TCP-Port geöffnet ist.

Da in diesem Fall alle Ports bereits geöffnet sein sollten, können wir eine minimale Nr. Verwenden. von Wiederholungsversuchen, gerade genug, um Netzwerkprobleme abzudecken:

- name: Check all port numbers are accessible from current host
  wait_for:
    host: mywebserver.com
    port: "{{ item }}"
    state: started         # Port should be open
    delay: 0               # No wait before first check (sec)
    timeout: 3             # Stop checking after timeout (sec)
  ignore_errors: yes
  with_items:
    - 443
    - 80
    - 80443

Standardmäßig überprüft Ansible einmal pro Sekunde (konfigurierbar in Ansible 2.3 mithilfe des sleepAttributs), sodass dies dreimal pro Port überprüft wird.

Führen Sie dies in einem Playbook für Ihr Inventar von über 400 Hosts aus. Ansible überprüft parallel, ob alle Hosts mywebserver.comauf diesen Ports erreichbar sind.

• Die Parallelität unterliegt der Einstellung der Gabeln in Ihrem ansible.cfg.

Wir verwenden ignore_errors: yesdies, damit alle Fehler rot markiert sind, aber die Ausführung nicht anhalten.

Offene Ports werden als okElemente in der Ausgabe und geschlossene Ports als gemeldet failed(Sie müssen das -vvFlag on verwenden ansible-playbook, um diese Ausgabe anzuzeigen).

Feineinstellung der Ausgabe

Wenn Sie eine spezifischere Ausgabe für die Erfolgs- und Fehlerfälle wünschen, muss der Code komplexer sein und eine zweite Aufgabe hinzufügen:

• wait_forAufgabe muss registereine Variable sein
• Die zweite Task erzeugt eine Ausgabe debugbasierend auf der Erfolgs- / Fehlerbedingung (z. B. unter Verwendung des bedingten Ausdrucks Jinja2 ).
• Dann müssen Sie beide Tasks in eine Include-Datei (ohne with_itemsSchleife) einfügen und eine Haupt-Playbook-Task schreiben , die die Include-Datei einmal pro Port mit einem include... with_itemsaufruft.

AFAIK gibt es kein eingebautes Modul für diesen Zweck, aber Sie können shell+ verwenden nc:

---
- hosts: all
  tasks:
    - shell: nc -z -w 1 -G 1 my.hostname.com {{ item }} || echo "Port {{ item }} is closed"
      with_items: [80,443,8443]

Sie können wait_for für dasselbe Modul verwenden

Beispiel aus der Dokumentation zitiert:

- name: Wait 300 seconds for port 8000 of any IP to close active connections, don't start checking for 10 seconds
  wait_for:
    host: 0.0.0.0
    port: 8000
    delay: 10
    state: drained

Für solche Aufgaben verwenden wir unser Tool dda-serverspec ( https://github.com/DomainDrivenArchitecture/dda-serverspec-crate ). Sie können Ihre Erwartungen definieren

{:netcat [{:host "mywebserver.com" :port "443"} {:host "telnet mywebserver.com" :port "80"} {:host "telnet mywebserver.com" :port "8443"}]}

und teste diese erwartungen entweder gegen localhost oder remote durch ssh. Für Ferntests müssen Sie Ziele definieren:

{:existing [{:node-name "test-vm1"
:node-ip "35.157.19.218"}
{:node-name "test-vm2" :node-ip "18.194.113.138"}] :provisioning-user {:login "ubuntu"}}

Sie können den Test von ausführen java -jar dda-serverspec.jar --targets targets.edn serverspec.edn