RHCE Ansible Series #2:Esecuzione di comandi ad hoc

Nella prima parte della serie Ansible, hai conosciuto Ansible e hai imparato a installarlo.

In questo tutorial imparerai come gestire l'inventario statico in Ansible. Comprenderai anche varie impostazioni di configurazione di Ansible.

Inoltre, esplorerai alcuni moduli Ansible e potrai eseguire comandi Ansible Ad-Hoc.

Prima di vedere tutto questo, vorrei ringraziare tutti i membri di LHB Pro. Questa serie Ansible è possibile con il loro supporto. Se non sei ancora un membro pro, valuta la possibilità di optare per l'abbonamento.

Creazione di un utente Ansible

Anche se puoi utilizzare l'utente root in Ansible per eseguire comandi e playbook ad-hoc, non è assolutamente consigliato e non è considerato la migliore pratica a causa dei rischi per la sicurezza che possono sorgere consentendo l'accesso ssh all'utente root.

Per questo motivo, si consiglia di creare un utente Ansible dedicato con privilegi sudo (a tutti i comandi) su tutti gli host (controllo e host gestiti).

Ricorda, Ansible usa SSH e Python per fare tutto il lavoro sporco dietro le quinte, quindi ecco i quattro passaggi che dovresti seguire dopo aver installato Ansible:

1. Crea un nuovo utente su tutti gli host.
2. Concedi i privilegi sudo al nuovo utente su tutti i nodi.
3. Genera chiavi SSH per il nuovo utente sul nodo di controllo.
4. Copia la chiave pubblica SSH nei nodi gestiti.

Quindi, senza ulteriori indugi, iniziamo con la creazione di un nuovo utente chiamato elliot su tutti gli host:

[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot

Dopo aver impostato elliot password su tutti gli host, puoi passare al passaggio 2; puoi concedere elliot sudo privilegia tutti i comandi senza password aggiungendo la seguente voce a /etc/sudoers file:

[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers

Ora accedi come utente elliot sul tuo nodo di controllo e genera una coppia di chiavi ssh:

[[email protected] ~]$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/elliot/.ssh/id_rsa):       
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/elliot/.ssh/id_rsa.
Your public key has been saved in /home/elliot/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Xf5bKx0kkBCsCQ/7rc6Kv6CxCRTH2XJajbNvpzel+Ik [email protected]
The key's randomart image is:
+---[RSA 3072]----+
|        .oo .    |
|  . ooo  . o     |
| . = *=.o   o    |
|  o =.o+ . o . . |
| . . .. S . . o  |
|.     .. . . . . |
|.. .   oo.o   o o|
|. = o oo++.  . +.|
| + ..++Eoo.   o. |
+----[SHA256]-----+

Infine, puoi copiare elliot chiave ssh pubblica a tutti gli host gestiti utilizzando ssh-copy-id comando come segue:

[[email protected] ~]$ ssh-copy-id node1
[[email protected] ~]$ ssh-copy-id node2
[[email protected] ~]$ ssh-copy-id node3
[[email protected] ~]$ ssh-copy-id node4

Ora dovresti essere in grado di accedere a tutti i nodi gestiti senza che ti venga richiesta una password; ti verrà chiesto solo di inserire una passphrase ssh (se non l'hai lasciata vuota, ah-ah).

Creazione del tuo inventario Ansible

Un file di inventario Ansible è fondamentalmente un file che contiene un elenco di server, un gruppo di server o indirizzi IP che fa riferimento a quegli host che desideri vengano gestiti da Ansible (nodi gestiti).

Gli /etc/ansible/hosts è il file di inventario predefinito. Ora ti mostrerò come creare i tuoi file di inventario in Ansible.

Creazione di una directory di progetto

Non vuoi pasticciare con /etc/ansible directory; dovresti tenere tutto in /etc/ansible intatto e praticamente usalo come riferimento quando crei file di inventario, modifichi i file di configurazione del progetto Ansible, ecc.

Ora creiamo una nuova directory di progetto Ansible denominata in /home/elliot denominato riproduzioni che utilizzerai per archiviare tutte le tue cose relative ad Ansible (playbook, file di inventario, ruoli, ecc.) che creerai da questo momento in poi:

[[email protected] ~]$ mkdir /home/elliot/plays

Nota che tutto ciò che creerai da questo punto in avanti sarà sul nodo di controllo.

Creazione di un file di inventario

Passa a /home/elliot/plays directory e crea un file di inventario denominato myhosts e aggiungi tutti i nomi host dei tuoi nodi gestiti in modo che finisca per assomigliare a questo:

[[email protected] plays]$ cat myhosts 
node1
node2
node3
node4

Ora puoi eseguire il seguente comando Ansible per elencare tutto i tuoi host in myhosts file di inventario:

[[email protected] plays]$ ansible all -i myhosts --list-hosts
  hosts (4):
    node1
    node2
    node3
    node4

Il -i l'opzione è stata utilizzata per specificare myhosts file di inventario. Se ometti -i opzione, Ansible cercherà host in /etc/ansible/hosts file di inventario invece.

Tieni presente che sto usando nomi host qui e che tutti i nodi (vms) che ho creato in Azure si trovano sulla stessa sottorete e non devo preoccuparmi del DNS poiché è gestito da Azure.

Se non disponi di un server DNS funzionante, puoi aggiungere le voci dell'indirizzo IP/nome host del tuo nodo in /etc/hosts , di seguito è riportato un esempio:

Creazione di gruppi host e sottogruppi

Puoi organizzare i tuoi host gestiti in gruppi e sottogruppi. Ad esempio, puoi modificare myhosts per creare due gruppi test e prod come segue:

[[email protected] plays]$ cat myhosts 
[test]
node1
node2

[prod]
node3
node4

Puoi elencare gli host in prod gruppo eseguendo il comando seguente:

[[email protected] plays]$ ansible prod -i myhosts --list-hosts
  hosts (2):
    node3
    node4

Ci sono due gruppi predefiniti in Ansible:

1. tutti - contiene tutti gli host nell'inventario
2. non raggruppato:contiene tutti gli host che non sono membri di alcun gruppo (a parte tutti).

Aggiungiamo un host immaginario node5 ai i miei host file di inventario per dimostrare il separato gruppo:

[[email protected] plays]$ cat myhosts 
node5

[test]
node1
node2

[prod]
node3
node4

Nota che ho aggiunto node5 fino all'inizio (e non alla fine) di myhosts file, altrimenti sarebbe considerato un membro del prod gruppo.

Ora puoi eseguire il comando seguente per elencare tutti i non raggruppati host:

[[email protected] plays]$ ansible ungrouped -i myhosts --list-hosts
  hosts (1):
    node5

Puoi anche creare un gruppo (principale) che contiene sottogruppi (figli). Dai un'occhiata al seguente esempio:

[[email protected] plays]$ cat myhosts 
[web_dev]
node1

[web_prod]
node2

[db_dev]
node3

[db_prod]
node4

[development:children]
web_dev
db_dev

[production:children]
web_prod
db_prod 

Lo sviluppo gruppo contiene tutti gli host che si trovano in web_dev più tutti i membri che sono in db_dev . Allo stesso modo, la produzione gruppo contiene tutti gli host che si trovano in web_prod più tutti i membri che sono in db_prod.

[[email protected] plays]$ ansible development -i myhosts --list-hosts
  hosts (2):
    node1
    node3

[[email protected] plays]$ ansible production -i myhosts --list-hosts
  hosts (2):
    node2
    node4

Configurazione di Ansible

In questa sezione imparerai le più importanti impostazioni di configurazione di Ansible. Durante l'intera serie, discuterai di altre impostazioni di configurazione quando se ne presenta la necessità.

Il /etc/ansible/ansible.cfg è il file di configurazione predefinito. Tuttavia, ti consigliamo anche di non pasticciare con /etc/ansible/ansible.cfg e usalo come riferimento. Dovresti creare il tuo file di configurazione Ansible nella directory del tuo progetto Ansible.

La ansible --version comando ti mostrerà quale file di configurazione stai attualmente utilizzando:

[[email protected] plays]$ ansible --version
ansible 2.9.14
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/elliot/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.8 (default, Dec  5 2019, 15:45:45) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]

Come puoi vedere dall'output, /etc/ansible/ansible.cfg è attualmente in uso poiché non hai ancora creato il tuo ansible.cfg file nella directory del progetto.

Il /etc/ansible/ansible.cfg contiene un insieme di varie impostazioni e sezioni di configurazione di Ansible:

[[email protected] plays]$ wc -l /etc/ansible/ansible.cfg 
490 /etc/ansible/ansible.cfg

Le due sezioni più importanti che devi definire nel tuo file di configurazione Ansible sono:

1. [predefinito]
2. [privilegio_escalation]

In [predefiniti] sezione, ecco le impostazioni più importanti di cui devi essere a conoscenza:

• inventario - specifica il percorso del tuo file di inventario.
• utente_remoto - specifica l'utente che si collegherà agli host gestiti ed eseguirà i playbook.
• forchette - specifica il numero di host che Ansible può gestire/elaborare in parallelo; il valore predefinito è 5.
• controllo_chiave_host - specifica se si desidera attivare/disattivare il controllo dell'host delle chiavi SSH; l'impostazione predefinita è True.

Nella [privilege_escalation] sezione, è possibile configurare le seguenti impostazioni:

• diventa - specificare dove consentire/disabilitare l'escalation dei privilegi; l'impostazione predefinita è False.
• diventa_metodo - specificare il metodo di escalation dei privilegi; l'impostazione predefinita è sudo.
• diventa_utente - specificare l'utente che si diventa tramite l'escalation dei privilegi; l'impostazione predefinita è root.
• diventa_ask_pass - specificare se richiedere o meno la password per l'escalation dei privilegi; l'impostazione predefinita è False.

Tieni presente che non è necessario salvare in memoria nessuna di queste impostazioni. Sono tutti documentati in /etc/ansible/ansible.cfg .

Ora crea il tuo ansible.cfg file di configurazione nella directory del progetto Ansible /home/elliot/plays e configurare le seguenti impostazioni:

Ora esegui ansible --version comanda ancora una volta; dovresti vedere che il tuo nuovo file di configurazione è ora attivo:

[[email protected] plays]$ ansible --version
ansible 2.9.14
  config file = /home/elliot/plays/ansible.cfg
  configured module search path = ['/home/elliot/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.8 (default, Dec  5 2019, 15:45:45) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]

Esecuzione di comandi ad hoc in Ansible

Fino a questo punto, hai appena installato, configurato il tuo ambiente e configurato Ansible. Ora inizia il vero divertimento!

Un comando ad-hoc di Ansible è un ottimo strumento che puoi utilizzare per eseguire una singola attività su uno o più nodi gestiti. Un tipico comando ad-hoc di Ansible segue la sintassi generale:

ansible host_pattern -m module_name -a "module_options"

Il modo più semplice per capire come funzionano i comandi ad-hoc di Ansible è semplicemente eseguirne uno! Quindi, vai avanti ed esegui il seguente comando ad hoc:

[[email protected] plays]$ ansible node1 -m command -a "uptime"
Enter passphrase for key '/home/elliot/.ssh/id_rsa':
node1 | CHANGED | rc=0 >>
18:53:01 up 5 days, 18:03,  1 user,  load average: 0.00, 0.01, 0.00

Mi è stato chiesto di inserire la passphrase della mia chiave ssh e quindi è stato visualizzato il tempo di attività di node1! Ora, controlla la figura seguente per aiutarti a comprendere ogni elemento del comando ad hoc che hai appena eseguito:

Probabilmente lo avresti indovinato ormai; moduli disponibili sono script riutilizzabili e autonomi che possono essere utilizzati dall'API Ansible , o dall'ansible o sensibile - libro di gioco programmi.

Il modulo di comando è uno dei tanti moduli che Ansible ha da offrire. Puoi eseguire ansible-doc -l comando per elencare tutti i moduli Ansible disponibili:

[[email protected] plays]$ ansible-doc -l | wc -l
3387

Attualmente sono disponibili 3387 moduli Ansible e aumentano di giorno in giorno! Puoi passare il comando in qualsiasi modo desideri eseguire come opzione al modulo di comando Ansible.

Se non hai una passphrase della chiave ssh vuota (proprio come me); quindi dovresti eseguire ssh-agent per evitare l'inutile mal di testa di ricevere una passphrase ogni volta che Ansible tenta di accedere ai tuoi nodi gestiti:

[[email protected] plays]$ eval `ssh-agent`
Agent pid 218750
[[email protected] plays]$ ssh-add
Enter passphrase for /home/elliot/.ssh/id_rsa: 
Identity added: /home/elliot/.ssh/id_rsa ([email protected])

Test della connettività

Potresti voler testare se Ansible può connettersi a tutti i tuoi nodi gestiti prima di entrare nelle attività più serie; per questo, puoi usare il ping modulo e specifica tutti i tuoi host gestiti come segue:

[[email protected] plays]$ ansible all -m ping 
node4 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}
node3 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}
node1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}
node2 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}

Come puoi vedere con tutto il SUCCESSO in uscita. Si noti che il ping di Ansible il modulo non ha bisogno di alcuna opzione. Alcuni moduli Ansible richiedono opzioni e altri no, proprio come nel caso dei comandi Linux.

Documentazione dei moduli Ansible

Se qualcuno mi chiedesse cosa ti piace di più di Ansible; Direi rapidamente che è la documentazione. Ansible è molto ben documentato ed è tutto comodamente dal tuo terminale.

Se desideri come utilizzare un modulo Ansible specifico, puoi eseguire ansible-doc seguito dal nome del modulo.

Ad esempio, puoi visualizzare la descrizione del ping modulo e come usarlo eseguendo:

[[email protected] plays]$ ansible-doc ping

Questo aprirà il ping pagina della documentazione del modulo:

Durante la lettura della documentazione dei moduli, prestare particolare attenzione per vedere se qualche opzione è preceduta dal segno di uguale (=). In questo caso, è un'opzione obbligatoria che devi includere.

Inoltre, se scorri fino in fondo, puoi vedere alcuni esempi di come eseguire i comandi ad hoc o i playbook Ansible (di cui parleremo più avanti).

Comando vs Shell vs Raw Modules

Ci sono tre moduli Ansible che le persone spesso confondono tra loro; questi sono:

1. comando
2. conchiglia
3. crudo

Questi tre moduli raggiungono lo stesso scopo; eseguono comandi sui nodi gestiti. Ma ci sono differenze fondamentali che separano i tre moduli.

Non puoi utilizzare il piping o il reindirizzamento con il comando modulo. Ad esempio, il seguente comando ad hoc genererà un errore:

[[email protected] plays]$ ansible node2 -m command -a "lscpu | head -n 5"
node2 | FAILED | rc=1 >>
lscpu: invalid option -- 'n'
Try 'lscpu --help' for more information.non-zero return code

Questo perché comando il modulo non supporta pipe o reindirizzamento. Puoi invece usare il modulo shell se vuoi usare pipe o reindirizzamento. Esegui di nuovo lo stesso comando, ma questa volta usa la shell modulo invece:

[[email protected] plays]$ ansible node2 -m shell -a "lscpu | head -n 5"
node2 | CHANGED | rc=0 >>
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              1
On-line CPU(s) list: 0

Funziona come un incantesimo! Ha visualizzato correttamente le prime cinque righe dell'output del comando lscpu su node2.

Ansible utilizza gli script SSH e Python dietro le quinte per fare tutta la magia. Ora, il grezzo il modulo usa solo SSH e bypassa il sottosistema del modulo Ansible. In questo modo, quel modulo grezzo funzionerebbe correttamente sul nodo gestito anche se python non è installato (sul nodo gestito).

Ho manomesso i miei binari Python su node4 (per favore non farlo da solo) così posso imitare uno scenario di cosa accadrà se esegui la shell o comando modulo su un nodo su cui non è installato Python:

[email protected]:/usr/bin# mkdir hide
[email protected]:/usr/bin# mv python* hide/

Ora controlla cosa accadrà se eseguo un Ansible ad-hoc con la shell o comando modulo destinato al nodo4:

[[email protected] plays]$ ansible node4 -m shell -a "whoami"
node4 | FAILED! => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "module_stderr": "Shared connection to node4 closed.\r\n",
    "module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
}

[[email protected] plays]$ ansible node4 -m command -a "cat /etc/os-release"
node4 | FAILED! => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "module_stderr": "Shared connection to node4 closed.\r\n",
    "module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
    "msg": "The module failed to execute correctly, you probably need to set the interpreter.\nSee stdout/stderr for the exact error",
    "rc": 127
}

ricevo errori! Ora cercherò di ottenere lo stesso compito; ma questa volta userò il grezzo modulo:

[[email protected] plays]$ ansible node4 -m raw -a "cat /etc/os-release"
node4 | CHANGED | rc=0 >>
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
Shared connection to node4 closed.

Come puoi vedere, il modulo grezzo è stato l'unico modulo su tre a svolgere l'attività con successo. Ora tornerò a correggere il pasticcio che ho fatto su node4:

[email protected]:/usr/bin/hide# mv * ..

Ho creato questa tabella di seguito per riassumere i diversi casi d'uso per i tre moduli:

Descrizione	Comando	Shell	Grezza
Esegui comandi semplici	Sì	Sì	Sì
Esegui comandi con reindirizzamento	No	Sì	Sì
Esegui comandi senza Python	No	No	Sì

Bene! Questo ci porta alla fine del secondo tutorial di Ansible.

Resta sintonizzato per il prossimo tutorial mentre imparerai come creare ed eseguire playbook Ansible. Non dimenticare di diventare un membro :)