Odpowiedź: Czy dostępna jest inna opcja sprawdzania otwartych portów przez telnet?

Jestem nowy w Ansible. Oto moje zadanie ...

Mam ponad 400 hostów i muszę sprawdzić, czy 5 różnych portów jest otwartych od ich końca do naszego serwera internetowego.

Indywidualnie mogłem się zalogować i uruchomić:

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

..i tak dalej..

Jakiego modułu lub wtyczki można użyć w Ansible, abym mógł to zautomatyzować i poprosić o raportowanie wyników (portów otwartych lub zamkniętych) z powrotem na mój serwer Ansible?

Możesz użyć modułu Ansible wait_for , który sprawdza, czy określony port TCP jest otwarty.

Ponieważ w tym przypadku wszystkie porty powinny być już otwarte, możemy użyć minimalnego „nie”. ponownych prób, wystarczy na pokrycie problemów z siecią:

- 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

Domyślnie Ansible będzie sprawdzać co sekundę (konfigurowalne w Ansible 2.3 za pomocą sleepatrybutu), więc będzie to sprawdzać 3 razy na port.

Uruchom to w podręczniku z zapasami ponad 400 hostów - Ansible sprawdzi równolegle, że wszystkie hosty mogą uzyskać dostęp mywebserver.comdo tych portów.

• równoległość zależy od ustawienia widelców w twoim ansible.cfg.

Używamy ignore_errors: yestutaj, aby wszelkie błędy były oznaczone na czerwono, ale nie przerywały wykonywania.

Otwarte porty są zgłaszane jako okpozycje w danych wyjściowych, a zamknięte porty są zgłaszane jako failed(musisz użyć -vvflagi, ansible-playbookaby zobaczyć to wyjście).

Dokładna regulacja wydajności

Jeśli potrzebujesz bardziej szczegółowych danych wyjściowych dla przypadków sukcesu i niepowodzenia, kod musi być bardziej złożony, dodając drugie zadanie:

• wait_forzadanie musi registerbyć zmienną
• drugie zadanie generuje dane wyjściowe przy użyciu debugwarunku sukcesu / niepowodzenia (np. przy użyciu wyrażenia warunkowego Jinja2 )
• następnie musisz umieścić oba te zadania w pliku dołączonym (bez with_itemspętli) i napisać główne zadanie playbook, które używa include..., with_itemsaby wywołać plik dołączany raz na port.

AFAIK nie ma wbudowanego modułu do tego celu, ale możesz użyć 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]

Do tego samego możesz użyć modułu wait_for

przykład cytowany z dokumentacji:

- 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

Do takich zadań używamy naszego narzędzia dda-serverspec ( https://github.com/DomainDrivenArchitecture/dda-serverspec-crate ). Możesz określić swoje oczekiwania

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

i przetestuj te oczekiwania w stosunku do localhost lub zdalnego przez ssh. W przypadku testów zdalnych musisz zdefiniować cele:

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

Możesz uruchomić test przez java -jar dda-serverspec.jar --targets targets.edn serverspec.edn