Risposta: Altre opzioni disponibili per il controllo telnet delle porte aperte?

Sono nuovo di Ansible. Ecco il mio compito ...

Ho più di 400 host e devo verificare se 5 porte diverse sono aperte dalla loro estremità al nostro server web.

Individualmente, potrei accedere ed eseguire:

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

..e così via..

Quale modulo o plug-in potrebbe essere utilizzato in Ansible in modo da poterlo automatizzare e riportare i risultati (porte aperte o chiuse) al mio server Ansible?

È possibile utilizzare il modulo Ansible wait_for che controlla che sia aperta una porta TCP specifica.

Poiché in questo caso, tutte le porte dovrebbero essere già aperte, è possibile utilizzare un numero minimo di n. di tentativi, quanto basta per coprire i problemi di rete:

- 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

Per impostazione predefinita, Ansible verificherà una volta al secondo (configurabile in Ansible 2.3 utilizzando l' sleepattributo), quindi verrà controllato 3 volte per porta.

Eseguilo in un playbook contro il tuo inventario di oltre 400 host: Ansible verificherà in parallelo che tutti gli host possano raggiungere mywebserver.comsu quelle porte.

• il parallelismo è soggetto all'impostazione delle forcelle nel tuo ansible.cfg.

Usiamo ignore_errors: yesqui in modo che tutti gli errori siano contrassegnati in rosso ma non fermino l'esecuzione.

Le porte aperte sono riportate come okelementi nell'output e le porte chiuse sono indicate come failed(è necessario usare -vvflag on ansible-playbookper vedere questo output).

Uscita di fine tuning

Se si desidera un output più specifico per i casi di successo e fallimento, il codice deve essere più complesso, aggiungendo una seconda attività:

• wait_forl'attività deve essere registeruna variabile
• la seconda attività produce output usando in debugbase alla condizione di successo / fallimento (ad es. usando l' espressione condizionale Jinja2 )
• quindi è necessario inserire entrambe queste attività in un file include (senza alcun with_itemsciclo) e scrivere un'attività playbook principale che utilizza un include... with_itemsper chiamare il file include una volta per porta.

AFAIK non esiste un modulo integrato per questo scopo, ma puoi usare shell+ 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]

Puoi usare wait_for module per lo stesso

esempio citato dalla documentazione:

- 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

Usiamo il nostro strumento dda-serverpec ( https://github.com/DomainDrivenArchitecture/dda-serverspec-crate ) per tali compiti. Puoi definire le tue aspettative

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

e testare queste aspettative su localhost o remote tramite ssh. Per i test remoti devi definire un target:

{: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"}}

È possibile eseguire il test da java -jar dda-serverspec.jar --targets targets.edn serverspec.edn