Tutorial Ansible per principianti: playbook, comandi ed esempio

Cos'è Ansible?

ansible è uno strumento di automazione e orchestrazione open source per il provisioning del software, la gestione della configurazione e la distribuzione del software. Ansible può facilmente eseguire e configurare anche sistemi simili a Unix Windows sistemi per fornire infrastrutture come codice. Contiene il proprio linguaggio di programmazione dichiarativo per la configurazione e la gestione del sistema.

Ansible è popolare per la sua semplicità di installazione, facilità d'uso per quanto riguarda la connettività ai client, la mancanza di agenti per i client Ansible e la moltitudine di competenze. Funziona collegandosi tramite SSH ai client, quindi non è necessario un agente speciale sul lato client e, inviando i moduli ai client, i moduli vengono quindi eseguiti localmente sul lato client e l'output viene rinviato al server Ansible.

Poiché utilizza SSH, può connettersi molto facilmente ai client tramite SSH-Keys, semplificando però l'intero processo. I dettagli del client, come nomi host o indirizzi IP e porte SSH, sono archiviati in file chiamati file di inventario. Una volta creato un file di inventario e popolato, ansible può utilizzarlo.

Perché utilizzare Ansible?

Ecco alcuni importanti vantaggi/vantaggi derivanti dall'utilizzo di Ansible

• Uno dei vantaggi più significativi di Ansible è che è gratuito per tutti.
• Non sono necessarie particolari competenze da amministratore di sistema per installare e utilizzare Ansible e la documentazione ufficiale è molto completa.
• La sua modularità per quanto riguarda plug-in, moduli, inventari e playbook rendono Ansible il compagno perfetto per orchestrare ambienti di grandi dimensioni.
• Ansible è molto leggero e coerente e non sono presenti vincoli relativi al sistema operativo o all'hardware sottostante.
• È anche molto sicuro grazie alle sue funzionalità senza agente e all'uso delle funzionalità di sicurezza OpenSSH.
• Un altro vantaggio che incoraggia l'adozione di Ansible è la sua curva di apprendimento fluida determinata dalla documentazione completa e da una struttura e una configurazione facili da apprendere.

Storia di Ansible

Ecco alcuni importanti punti di riferimento della storia di Ansible:

• Nel febbraio 2012 è iniziato il progetto Ansible. È stato sviluppato per la prima volta da Michael DeHaan, il creatore di Cobbler e Func, Fedora Unified Network Controller.
• Inizialmente chiamata AnsibleWorks Inc, la società che finanzia lo strumento Ansible è stata acquisita nel 2015 da RedHat e in seguito, insieme a RedHat, è passata sotto l'ombrello di IBM.
• Al momento, Ansible è incluso in distribuzioni come Fedora Linux, RHEL, Centos e Oracle Linux.

Termini importanti utilizzati in Ansible

• Server Ansible

  Il computer su cui è installato Ansible e da cui verranno eseguite tutte le attività e i playbook

• Moduli

  Fondamentalmente, un modulo è un comando o un insieme di comandi Ansible simili destinati ad essere eseguiti sul lato client

• Task

  Un'attività è una sezione composta da un'unica procedura da completare

• Ruolo

  Un modo per organizzare le attività e i file correlati da richiamare in seguito in un playbook

• Fatto

  Informazioni recuperate dal sistema client dalle variabili globali con l'operazione di raccolta fatti

• Inventario

  File contenente dati sui server client ansible. Definito negli esempi successivi come file hosts

• Giocare

  Esecuzione di un playbook

• Handler

  Attività che viene chiamata solo se è presente un notificante

• Notifier

  Sezione attribuita a un'attività che chiama un gestore se l'output viene modificato

• Etichetta

  Nome impostato su un'attività che può essere utilizzata in seguito per emettere solo quell'attività specifica o quel gruppo di attività.

Installazione Ansible in Linux

Una volta che hai confrontato e valutato le tue opzioni e hai deciso di optare per Ansible, il passo successivo è installarlo sul tuo sistema. Seguiremo le fasi di installazione in diversi modi Linux distribuzioni, quelle più popolari, nel prossimo piccolo tutorial.

Installa Ansible sui sistemi Centos/RedHat

Passo 1) Installa il repository EPEL

[root@ansible-server ~]# sudo yum install epel-release

Passo 2) Installa il pacchetto ansible

[root@ansible-server ~]# sudo  yum install -y ansible

Installa ansible su Ubuntu/Sistemi Debian

Passo 1) Eseguire un aggiornamento ai pacchetti

$ sudo apt update

Passo 2) Installa il pacchetto software-properties-common

$ sudo apt install software-properties-common

Passo 3) Installa l'archivio del pacchetto personale ansible

$ sudo apt-add-repository ppa:ansible/ansible

Passo 4) Installa ansible

$ sudo apt update
$ sudo apt install ansible

Comandi ad hoc Ansible

Uno dei modi più semplici in cui è possibile utilizzare Ansible è utilizzare comandi ad hoc. Questi possono essere utilizzati quando si desidera impartire alcuni comandi su un server o su un gruppo di server. I comandi ad hoc non vengono memorizzati per usi futuri ma rappresentano un modo veloce per interagire con i server desiderati.

Per questo tutorial Ansible, verrà configurato un semplice file host di due server, contenente host1 e host2.

Puoi assicurarti che gli host siano accessibili dal server ansible eseguendo un comando ping su tutti gli host.

[root@ansible-server test_ansible]# ansible -i hosts all -m ping
host1 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
host2 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Spiegazione:

1. Stato del comando, in questo caso SUCCESS
2. Host su cui è stato eseguito il comando
3. Il comando emesso tramite il parametro -m, in questo caso ping
4. Con il parametro -i puoi puntare al file host.

Se necessario, puoi eseguire lo stesso comando solo su un host specifico.

[root@ansible-server test_ansible]# ansible -i hosts all -m ping --limit host2
host2 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Spiegazione:

1. Il parametro Limit può essere utilizzato per inviare comandi solo su host specifici nel file dell'host
2. Nome dell'host come definito nel file di inventario

Se è necessario copiare rapidamente un file su più destinazioni, è possibile utilizzare il modulo di copia in ansible che utilizza SCP. Quindi il comando e il suo output appaiono come di seguito:

[root@ansible-server test_ansible]# ansible -i hosts all -m copy -a "src=/root/test_ansible/testfile dest=/tmp/testfile"
host1 | SUCCESS => {
    "changed": true,
    "checksum": "da39a3ee5e6b4b0d3255bfef95601890afd80709",
    "dest": "/tmp/testfile",
    "gid": 0,
    "group": "root",
    "md5sum": "d41d8cd98f00b204e9800998ecf8427e",
    "mode": "0644",
    "owner": "root",
    "size": 0,
    "src": "/root/.ansible/tmp/ansible-tmp-1562216392.43-256741011164877/source",
    "state": "file",
    "uid": 0
}
host2 | SUCCESS => {
    "changed": true,
    "checksum": "da39a3ee5e6b4b0d3255bfef95601890afd80709",
    "dest": "/tmp/testfile",
    "gid": 0,
    "group": "root",
    "md5sum": "d41d8cd98f00b204e9800998ecf8427e",
    "mode": "0644",
    "owner": "root",
    "size": 0,
    "src": "/root/.ansible/tmp/ansible-tmp-1562216392.6-280302911361278/source",
    "state": "file",
    "uid": 0
}

Spiegazione:

1. Modulo di copia definito
2. Gli argomenti del modulo, in questo caso, sono il percorso assoluto di origine e il percorso assoluto di destinazione.
3. Output del comando Ansible che riflette il successo del comando copy e altri dettagli come i checksum sha1 o md5 per il controllo dell'integrità dei file e metadati come proprietario, dimensione o permessi. È semplice avere un pacchetto installato su un gruppo di server. Ansible ha diversi moduli che interagiscono con gli installer usati, come yum, apt, dnf, ecc.

Nel prossimo esempio scoprirai come installare un pacchetto tramite il modulo yum su due host Centos.

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=present'
host1 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [


"Loaded plugins: fastestmirror\nLoading mirror speeds from cached hostfile\n * base: mirror.netsite.dk\n * elrepo: mirrors.xservers.ro\n * epel: fedora.mirrors.telekom.ro\n * extras: centos.mirrors.telekom.ro\n * remi-php70: remi.schlundtech.de\n * remi-safe: remi.schlundtech.de\n * updates: centos.mirror.iphh.net\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version                Repository       Size\n================================================================================\nInstalling:\n ncdu            x86_64            1.14-1.el7             epel             51 k\n\nTransaction Summary\n================================================================================\nInstall  1 Package\n\nTotal download size: 51 k\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Installing : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nInstalled:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}
host2 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nLoading mirror speeds from cached hostfile\n * base: mirror.netsite.dk\n * elrepo: mirrors.leadhosts.com\n * epel: mirrors.nav.ro\n * extras: centos.mirrors.telekom.ro\n * remi-php70: mirrors.uni-ruse.bg\n * remi-safe: mirrors.uni-ruse.bg\n * updates: centos.mirror.iphh.net\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version                Repository       Size\n================================================================================\nInstalling:\n ncdu            x86_64            1.14-1.el7             epel             51 k\n\nTransaction Summary\n================================================================================\nInstall  1 Package\n\nTotal download size: 51 k\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Installing : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nInstalled:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}

Spiegazione:

1. In questo esempio viene utilizzato il modulo Yum
2. Definisce gli argomenti del modulo e, in questo caso, sceglierai il nome del pacchetto e il suo stato. Se lo stato è assente, ad esempio, il pacco verrà perquisito e se trovato, rimosso
3. Quando colorato in giallo, vedrai l'output del comando ansible con lo stato modificato, il che significa in questo caso che il pacchetto è stato trovato e installato.
4. Stato del comando yum install emesso tramite ansible. In questo caso è stato installato il pacchetto ncdu.x86_64 0:1.14-1.el7.

Naturalmente, tutte le opzioni del programma di installazione di yum possono essere utilizzate tramite ansible, inclusi aggiornamento, installazione, versione più recente o rimozione.

Nell'esempio seguente è stato emesso lo stesso comando per rimuovere il pacchetto ncdu precedentemente installato.

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=absent'
host1 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be erased\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version               Repository        Size\n================================================================================\nRemoving:\n ncdu            x86_64            1.14-1.el7            @epel             87 k\n\nTransaction Summary\n================================================================================\nRemove  1 Package\n\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Erasing    : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nRemoved:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}
host2 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be erased\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version               Repository        Size\n================================================================================\nRemoving:\n ncdu            x86_64            1.14-1.el7            @epel             87 k\n\nTransaction Summary\n================================================================================\nRemove  1 Package\n\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Erasing    : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nRemoved:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}

Spiegazione:

1. L'output del comando yum mostra che il pacchetto è stato rimosso.

Un'altra caratteristica utile ed essenziale che ansible usa per interagire con il server del client è quella di raccogliere alcuni dati sul sistema. Quindi, recupera informazioni su hardware, software e versioning dal sistema e memorizza ogni valore in una variabile che può essere utilizzata in seguito.

Se sono necessarie informazioni dettagliate sui sistemi da modificare tramite ansible, è possibile utilizzare il comando successivo. Il modulo di installazione raccoglie dati dalle variabili di sistema.

I comandi del playbook Ansible utilizzano il formato YAML, quindi non è necessaria molta sintassi, ma è necessario rispettare il rientro. Come dice il nome, un playbook è una raccolta di opere teatrali. Tramite un playbook è possibile designare ruoli specifici ad alcuni host e altri ruoli ad altri host. In questo modo, puoi orchestrare più server in scenari molto diversi, il tutto in un unico playbook.

Per avere tutti i dettagli precisi prima di continuare con gli esempi di playbook Ansible, dobbiamo prima definire un task. Queste sono le interfacce per i moduli Ansible per ruoli e playbook.

Ora impariamo il playbook Ansible attraverso un esempio con un playbook con un gioco, contenente più attività come di seguito:

---

- hosts: group1
  tasks:
  - name: Install lldpad package
    yum:
      name: lldpad
      state: latest
  - name: check lldpad service status
    service:
      name: lldpad
      state: started

Nell'esempio del playbook Ansible riportato sopra, il gruppo1 di host nel file host è destinato all'installazione del pacchetto lldpad utilizzando il modulo yum e successivamente il servizio lldpad creato dopo l'installazione viene avviato utilizzando il modulo di servizio utilizzato principalmente per interagire con l'ensemble systemd.

Spiegazione:

1. Gruppo di host su cui verrà eseguito il playbook
2. Il modulo Yum viene utilizzato in questa attività per l'installazione di lldpad
3. Il modulo di servizio viene utilizzato per verificare se il servizio è attivo e funzionante dopo l'installazione

Ogni playbook ansible funziona con un file di inventario. Il file di inventario contiene un elenco di server divisi in gruppi per un migliore controllo di dettagli come Indirizzo IP e porta SSH per ciascun host.

Il file di inventario che puoi utilizzare per questo esempio di playbook Ansible è simile al seguente. Esistono due gruppi, denominati gruppo1 e gruppo2, ciascuno contenente rispettivamente host1 e host2.

[group1]
host1 ansible_host=192.168.100.2 ansible_ssh_port=22
[group2]
host2 ansible_host=192.168.100.3 ansible_ssh_port=22

Spiegazione:

1. Nome del gruppo
2. Nome host, con indirizzo IP e porta ssh, in questo caso quella predefinita, 22.

Un altro utile esempio di playbook Ansible contenente questa volta due riproduzioni per due host è il successivo. Per il primo gruppo di host, gruppo1, sarà abilitato selinux. Se è abilitato, verrà visualizzato un messaggio sullo schermo dell'host.

Per il secondo gruppo di host, il pacchetto httpd verrà installato solo se ansible_os_family è RedHat e ansible_system_vendor è HP.

Ansible_os_family e ansible_system_vendor sono variabili raccolte con l'opzione Gare_facts e possono essere utilizzate come in questo esempio condizionale.

---

- hosts: group1
  tasks:
  - name: Enable SELinux
    selinux:
      state: enabled
    when: ansible_os_family == 'Debian'
    register: enable_selinux

  - debug:
      Imsg: "Selinux Enabled. Please restart the server to apply changes."
    when: enable_selinux.changed == true

- hosts: group2
  tasks:
  - name: Install apache
    yum:
      name: httpd
      state: present
    when: ansible_system_vendor == 'HP' and ansible_os_family == 'RedHat'

Spiegazione:

1. Esempio della clausola quando, in questo caso, quando il tipo di sistema operativo è Debian. La variabile ansible_os_family viene raccolta tramite la funzionalità Gare_facts.
2. L'output dell'attività viene registrato per un utilizzo futuro, con il nome Enable_selinux
3. Un altro esempio della clausola quando. In questo caso, verrà visualizzato un messaggio per l'utente host se SELinux era effettivamente abilitato in precedenza.
4. Un altro esempio della clausola quando composta da due regole

Oltre ai compiti, ci sono anche alcuni compiti particolari chiamati gestori. I gestori devono avere un nome univoco in tutto il playbook. Funzionano allo stesso modo di un'attività normale, ma un gestore può essere avvisato tramite un notificatore.

Se un gestore non riceve una notifica durante l'esecuzione del playbook, non verrà eseguito. Tuttavia, se più di un'attività invia notifica a un gestore, questa verrà eseguita solo una volta al termine di tutte le attività.

Nell'esempio mostrato di seguito, puoi vedere come un'attività specifica ha una sezione di notifica che richiama un'altra attività. Se l'output della prima attività viene modificato, verrà chiamata un'attività del gestore. L'esempio migliore è modificare un file di configurazione e successivamente riavviare quel servizio specifico.

---

- hosts: group2
  tasks:
  - name: sshd config file modify port
    lineinfile:
     path: /etc/ssh/sshd_config
     regexp: 'Port 28675'
     line: '#Port 22'
    notify:
       - restart sshd
handlers
    - name: restart sshd
      service: sshd
        name: sshd
        state: restarted

In questo caso, se la prima attività, "sshd config file modification port", viene modificata, il che significa che se la porta non è 28675 in primo luogo, verrà modificata e l'attività notificherà al gestore con lo stesso nome di essere eseguita e riavvierà il servizio sshd.

Spiegazione:

1. Esempio di notificatore
2. Esempio di gestore

Ruoli ansibili

Quando si ha a che fare con playbook estesi, è più semplice suddividere le attività in ruoli. Ciò aiuta anche a riutilizzare i ruoli in futuro. I ruoli sono una raccolta di attività che possono essere spostate da un playbook a un altro ed eseguite in modo indipendente ma solo tramite un file di playbook.

I ruoli vengono archiviati in directory separate e hanno una struttura di directory particolare.

[root@ansible-server test2]# tree
.
`-- role1
    |-- defaults
    |   `-- main.yml
    |-- handlers
    |   `-- main.yml
    |-- meta
    |   `-- main.yml
    |-- README.md
    |-- tasks
    |   `-- main.yml
    |-- tests
    |   |-- inventory
    |   `-- test.yml
    `-- vars
        `-- main.yml

7 directories, 8 files

Il file yaml nella directory defaults contiene un elenco di variabili predefinite da utilizzare insieme al playbook. La directory dei gestori viene utilizzata per archiviare i gestori. Si suppone che la meta-directory contenga informazioni sull'autore e sulle dipendenze dei ruoli. Nella directory delle attività è presente il file yaml principale per il ruolo.

La directory tests contiene un file di playbook yaml di esempio e un file di inventario di esempio e viene utilizzata principalmente a scopo di test prima di creare il ruolo effettivo.

La directory vars contiene il file yaml in cui verranno definite tutte le variabili utilizzate dal ruolo. I modelli di directory e i file di directory devono contenere file e modelli che verranno utilizzati dalle attività nel ruolo.

Per creare l'albero delle directory per un ruolo, dovresti usare il seguente comando con l'ultimo parametro, il nome del ruolo:

[root@ansible-server test2]# ansible-galaxy init role1

Ansible funziona bene anche con i modelli. Come linguaggio per i template, utilizza Jinja2.

Nel prossimo esempio scoprirai come appare un modello jinja2 di base e lo utilizzerai in un ruolo.

In fase di esecuzione, a seconda, diciamo, in quale datacenter si trova il tuo server, puoi selezionare tra più di un nameserver, ciascuno corrispondente a un datacenter, utilizzando la variabile "resolver_ip_addresses".

{% for resolver in resolver_ip_addresses %}
nameserver {{ resolver }}
{% endfor %}

options timeout:1
options attempts:5
options rotate

In questo esempio, nella directory playbook, sono definite alcune variabili, inclusa una variabile denominata risolutore_ip_addresses con valori diversi a seconda del datacenter.

- name: Set resolver for server
  template:
    src: dns.j2
    dest: /etc/resolv.conf
    group: root
    owner: root
    mode: "0644"
    tag: resolver	

Spiegazione:

1. Nome del modello da utilizzare. Il modello si trova nella directory dei modelli nel percorso del ruolo
2. Percorso di destinazione del nome file da sostituire con il modello, sul lato client.
3. Autorizzazioni del file di destinazione

Le attività dei ruoli possono anche avere un campo tag, a cui è attribuito un nome. Più di un'attività può condividere lo stesso tag. Quando si esegue un playbook ansible, è possibile specificare anche il tag, in modo che tali attività vengano eseguite.

Caso di studio Ansible

In questa sezione analizzeremo un caso di studio di un playbook ansible essenziale che ha tre ruoli. Lo scopo di questo è quello di dare un esempio pratico di ciò di cui abbiamo parlato prima. Alcuni degli esempi utilizzati in precedenza in questo tutorial sul playbook Ansible verranno adattati e utilizzati in questo playbook.

Di seguito è riportata la struttura delle directory del playbook. Il file Yaml che verrà utilizzato sarà p4.yml.

[root@ansible-server test_ansible]# ls -lrth
total 16K
-rw-r--r--. 1 root root   0 Jul  3 10:13 testfile
-rw-r--r--. 1 root root 203 Jul  3 13:30 p1.yml
-rw-r--r--. 1 root root 125 Jul  3 15:00 hosts
-rw-r--r--. 1 root root 488 Jul  3 16:40 p2.yml
-rw-r--r--. 1 root root 188 Jul  4 17:33 p4.yml
drwxr-xr-x. 5 root root  47 Jul  4 17:35 roles
[root@ansible-server test_ansible]# cd roles
[root@ansible-server roles]# ls -lrth
total 12K
drwxr-xr-x. 9 root root 4.0K Jul  4 12:52 httpd
drwxr-xr-x. 9 root root 4.0K Jul  4 13:55 selinux
drwxr-xr-x. 9 root root 4.0K Jul  4 16:54 resolver

Il playbook ha tre ruoli, uno chiamato risolutore che imposta un nameserver specifico sui server copiando un file dal server alla destinazione /etc/resolv.conf. Un altro si chiama httpd e installa il pacchetto httpd con il modulo yum, mentre il terzo abilita SELinux e avvisa l'utente registrato di riavviare il sistema. Ogni ruolo è stato creato utilizzando il comando ansible-galaxy.

Ruolo del risolutore, attività main.yml:

Ruolo Httpd, attività main.yml:

Ruolo Selinux, attività main.yml:

Di seguito è definito il playbook p4.yml. Verrà eseguito su tutti gli host se non diversamente specificato nella riga di comando, verrà eseguito come utente root sulla porta 22 (SSH), raccoglierà i dati prima di eseguire i ruoli ed eseguirà tutti e tre i ruoli menzionati in precedenza. Ogni ruolo può essere eseguito in modo indipendente specificando il tag nella riga di comando ansible-playbook con il parametro –t.

---

- hosts: all
  user: root
  port: 22
  gather_facts: True
  roles:
    - { role: selinux, tags: selinux }
    - { role: httpd, tags: httpd }
    - { role: resolver, tags: resolver }

Esecuzione del playbook p4.yml su due host e interpretazione dell'output. Lo stesso comando può essere eseguito con il parametro –check per un'esecuzione di prova. Nel caso in cui desideri utilizzare l'autenticazione tramite password, utilizza il parametro -k.

Spiegazione:

1. Comando Ansible-playbook che esegue p4.yml
2. Playbook salta il ruolo SELinux perché è già abilitato.
3. Ansible ha rilevato che il pacchetto httpd è già installato, quindi restituisce ok.
4. Il risolutore è stato impostato e lo stato del risolutore di ruoli è stato modificato.

Foglio informativo sui comandi Ansible

Installa il repository EPEL sui sistemi Centos/RHEL

[root@ansible-server ~]# sudo yum install epel-release

Installa il pacchetto ansible sui sistemi Centos/RHEL

[root@ansible-server ~]# sudo  yum install -y ansible

Esegui un aggiornamento ai pacchetti su Debian/Ubuntu di riferimento

$ sudo apt update

Installa il pacchetto software-properties-common su Debian/Ubuntu di riferimento

$ sudo apt install software-properties-common

Installa l'archivio personale dei pacchetti ansible su Debian/Ubuntu di riferimento

$ sudo apt-add-repository ppa:ansible/ansible

Installa ansible su Debian/Ubuntu di riferimento

$ sudo apt update
$ sudo apt install ansible

Emettere un comando ping su tutti i server definiti nel file di inventario denominato host

 
[root@ansible-server test_ansible]# ansible -i hosts all -m ping

Emettere un comando ping solo su host2

[root@ansible-server test_ansible]# ansible -i hosts all -m ping --limit host2

Copia il file "testfile" su tutti gli host nel file di inventario

[root@ansible-server test_ansible]# ansible -i hosts all -m copy -a "src=/root/test_ansible/testfile dest=/tmp/testfile"

Installa il pacchetto ncdu su tutti gli host

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=present'

Rimuovi il pacchetto ncdu su tutti gli host

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=absent'

Costruisci la struttura di directory per il ruolo denominato role1.

[root@ansible-server test2]# ansible-galaxy init role1

Playbook p4.yml eseguito a secco

[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml --check

Esegui il playbook p4.yml con l'autenticazione della password per tutti gli host

[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml -k

Sintesi

In un mondo in cui la tecnologia cambia rapidamente e cresce a una velocità incredibile, gli amministratori di sistema e gli ingegneri DevOps devono pensare a diversi approcci per automatizzare le attività di routine e orchestrare grandi pool di server.

Mentre ce ne sono molti alternativa ad Ansible (Chef, Puppet) là fuori che fanno la stessa cosa con alcune differenze, Ansible è riuscita a superarli con la sua semplicità, maggiore sicurezza e, cosa più importante, la sua curva di apprendimento fluida. Grazie a queste qualità e alla rapida adozione di Ansible, abbiamo creato un tutorial ricco di esempi in modo che tu possa avere una prima esperienza ancora più fluida nel lavorare con Ansible.

In questo tutorial sulle nozioni di base di Ansible, abbiamo descritto ansible e parlato un po' della sua storia. Abbiamo accennato ai punti di forza di Ansible e ai vantaggi che ansible può apportare all'automazione e all'orchestrazione di infrastrutture di diverse dimensioni. Abbiamo definito i termini essenziali utilizzati da Ansible e definito la struttura dei playbook Ansible. Esempi approfonditi hanno accompagnato tutte le informazioni con spiegazioni dettagliate.