Automatizzare con Ansible: Guida introduttiva per amministratori di sistema

Red Hat Ansible Automation Platform: guida introduttiva

Adotta o incrementa l'automazione aziendale. Scopri come leggendo questo ebook rivolto alle organizzazioni che intendono intraprendere un percorso di automazione e alle aziende che lo hanno già intrapreso.

Scarica l'ebook

Sei un tipico amministratore di sistema con troppo lavoro da fare e troppo poco tempo per farlo? Ti spaventa anche solo l'idea di apportare una semplice modifica al server DNS o di regolare i parametri del kernel in tutta la server farm? O, peggio, di apportare modifiche basate su caratteristiche variabili dei sistemi, come la memoria installata o la versione del sistema operativo? Quando gli sviluppatori della tua azienda parlano di DevOps, ti sembra che stiano parlando in un'altra lingua?  

Red Hat Ansible Automation è uno strumento di automazione agentless comprensibile agli umani, che utilizza SSH per orchestrare la gestione delle configurazioni, il deployment delle applicazioni e il provisioning in un ambiente semplice o multilivello. Si basa sulla tecnologia open source Ansible, che è attualmente una delle tecnologie open source di automazione dell'IT più diffuse al mondo.

Questo articolo illustra i concetti di base di Ansible e i passaggi essenziali per gestire i sistemi in modo efficiente.

Ma prima di iniziare, è necessario definire alcuni termini fondamentali:

Nodo di controllo: l'host su cui viene utilizzato Ansible per eseguire attività sui nodi gestiti

Nodo gestito: un host che viene configurato dal nodo di controllo

Inventario degli host: elenco di nodi gestiti

Comando ad-hoc: semplice comando eseguito occasionalmente

Playbook: insieme di attività ripetibili per le configurazioni più complesse

Modulo: codice che esegue una determinata attività comune, come l'aggiunta di un utente, l'installazione di un pacchetto e così via.

Idempotenza: un'operazione è idempotente se, eseguendola una volta sola, si ottiene esattamente lo stesso risultato che si ottiene eseguendola ripetutamente senza effettuare altre operazioni.

Ambiente

Ai fini di questo post, viene considerato un ambiente costituito da un nodo di controllo (vm1) e da quatto nodi gestiti (vm2, vm3, vm4, vm5), tutti eseguiti in un ambiente virtuale con un'installazione minima di Red Hat Enterprise Linux 7.4. Per semplicità, il file /etc/hosts del nodo di controllo contiene le voci seguenti:

192.168.102.211 vm1 vm1.redhat.lab
192.168.102.212 vm2 vm2.redhat.lab
192.168.102.213 vm3 vm3.redhat.lab
192.168.102.214 vm4 vm4.redhat.lab
192.168.102.215 vm5 vm5.redhat.lab

Per semplicità di utilizzo, in questa dimostrazione concederò all'utente del mio sistema privilegi sudo senza password, ma le tue policy di sicurezza possono essere diverse e Ansible è in grado di gestire una vasta gamma di scenari di escalation dei privilegi. Questo account utente è stato configurato per l'escalation dei privilegi inserendo la voce seguente nel file /etc/sudoers:

%wheel ALL=(ALL) NOPASSWD: ALL

Si tratta solo di un esempio, e potrai usare la variante di configurazione sudo che preferisci.  

Infine, per questo account utente ho configurato l'autenticazione con chiave pubblica SSH, che ho testato connettendomi dal nodo di controllo a ciascuno dei nodi gestiti.

Installazione

Ansible per Red Hat Enterprise Linux 7 si trova nel canale Extras. Se utilizzi Red Hat Enterprise Linux 6, devi abilitare il repository EPEL. Per EPEL (Extra Packages for Enterprise Linux) può essere utile anche questa soluzione, disponibile nel Customer Portal. Nei sistemi Fedora, è possibile trovare Ansible nel repository di base.

Dopo la configurazione del repository appropriato, l'installazione è semplice e veloce:

[curtis@vm1 ~]$ sudo yum install -y ansible 

Controlliamo la versione:

[curtis@vm1 ~]$ ansible --version
ansible 2.4.1.0
 config file = /etc/ansible/ansible.cfg
 configured module search path = [u'/home/curtis/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
 ansible python module location = /usr/lib/python2.7/site-packages/ansible
 executable location = /bin/ansible
 python version = 2.7.5 (default, May 3 2017, 07:55:04) [GCC 4.8.5 20150623 (Red Hat 4.8.5-14)]

Come puoi notare viene utilizzato il file di configurazione predefinito e nell'installazione minima di Red Hat Enterprise Linux 7.4 deve essere presente il modulo Python.

Configurazione

Poiché i nodi gestiti sono già stati configurati con un account utente, l'escalation dei privilegi e l'autenticazione con chiave pubblica SSH, ora dobbiamo configurare il nodo di controllo.

Per configurare il nodo di controllo sono necessari un file di configurazione Ansible e un file con l'inventario degli host.

File di configurazione

Come abbiamo visto poco fa, il file di configurazione predefinito è /etc/ansible/ansible.cfg.

Puoi modificare questo file di configurazione globale o crearne una copia specifica per una determinata directory. L'ordine di posizionamento del file di configurazione è il seguente:

• ANSIBLE_CONFIG (variabile di ambiente)

• ansible.cfg (a livello di directory)

• ~/.ansible.cfg (directory home)

• /etc/ansible/ansible.cfg (globale)

In questo post utilizzerò il file di configurazione minimo nella directory home dell'account utente che abbiamo aggiunto prima:

[curtis@vm1 ~]$ cat ansible.cfg 
[defaults] 
inventory = $HOME/hosts 

Inventario degli host

Il file predefinito per l'inventario degli host è /etc/ansible/hosts, ma può essere modificato tramite il file di configurazione (come abbiamo visto prima) o utilizzando l'opzione -i del comando ansible. In questo caso utilizzeremo un semplice file di inventario statico. È possibile utilizzare anche inventari dinamici, ma questo metodo esula dall'ambito di questo post.

In questo caso, utilizzeremo il file di inventario degli host riportato di seguito:

[webservers]
vm2
vm3
[dbservers]
vm4
[logservers]
vm5
[lamp:children]
webservers
dbservers

Abbiamo definito quattro gruppi, ovvero webservers su vm2 e vm3, dbservers su vm4, logservers su vm5 e lamp, che è formato dai gruppi webservers e dbservers.

Verifichiamo che sia possibile individuare tutti gli host utilizzando questo file di configurazione:

[curtis@vm1 ~]$ ansible all --list-hosts
 hosts (4):
   vm5
   vm2
   vm3
   vm4

Ora facciamo lo stesso per i singoli gruppi, ad esempio webservers:

[curtis@vm1 ~]$ ansible webservers --list-hosts
 hosts (2):
   vm2
   vm3

Adesso che abbiamo convalidato l'inventario degli host, facciamo un rapido controllo per assicurarci che tutti gli host siano in funzione. A tale scopo, utilizziamo un comando ad-hoc che sfrutta il modulo ping:

[curtis@vm1 ~]$ ansible all -m ping
vm4 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm5 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm3 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm2 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}

Dall'output precedente possiamo vedere che tutti i sistemi hanno restituito il risultato SUCCESS, che non è stata apportata alcuna modifica e che ogni comando "ping" ha restituito il risultato "pong".

Per visualizzare l'elenco dei moduli disponibili, puoi usare il comando:

[curtis@vm1 ~]$ ansible-doc -l 

Il numero dei moduli integrati continua ad aumentare a ogni release di Ansible:

[curtis@vm1 ~]$ ansible-doc -l | wc -l 
1378 

L'ultima attività di configurazione dell'ambiente è costituita dalla configurazione di vm1 con Apache e un repository yum di Red Hat Enterprise Linux 7, per consentire ai nodi gestiti di installare ulteriori pacchetti:

[root@vm1 ~]# yum install -y httpd
[root@vm1 ~]# systemctl enable httpd
[root@vm1 ~]# systemctl start httpd
[root@vm1 ~]# mkdir /media/iso
[root@vm1 ~]# mount -o loop /root/rhel-server-7.4-x86_64-dvd.iso /media/iso
[root@vm1 ~]# ln -s /media/iso /var/www/html/rhel7

Inizia ad automatizzare

Ora che abbiamo completato la configurazione dell'ambiente e siamo pronti per cominciare, proviamo a eseguire qualche operazione effettiva con Ansible.

Poiché è necessario installare alcuni pacchetti aggiuntivi nei nodi gestiti, la prima attività da svolgere consiste nel configurare un repository yum su ciascun host, utilizzando il seguente file di configurazione:

[curtis@vm1 ~]$ cat dvd.repo
[RHEL7]
name = RHEL 7
baseurl = http://vm1/rhel7/
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
enabled = 1
gpgcheck = 1

Possiamo copiare questo file in ciascuno dei nodi gestiti utilizzando un comando ad-hoc con il modulo copy, inserendo l'opzione -m e specificando gli argomenti necessari con l'opzione -a, come mostrato di seguito:

[curtis@vm1 ~]$ ansible all -m copy -a 'src=dvd.repo dest=/etc/yum.repos.d owner=root group=root mode=0644' -b
vm5 | SUCCESS => {
   "changed": true, 
   "checksum": "c15fdb5c1183f360ce29a1274c5f69e4e43060f5", 
   "dest": "/etc/yum.repos.d/dvd.repo", 
   "failed": false, 
   "gid": 0, 
   "group": "root", 
   "md5sum": "db5a5da08d1c4be953cd0ae6625d8358", 
   "mode": "0644", 
   "owner": "root", 
   "secontext": "system_u:object_r:system_conf_t:s0", 
   "size": 135, 
   "src": "/home/curtis/.ansible/tmp/ansible-tmp-1516898124.58-210025572567032/source", 
   "state": "file", 
   "uid": 0
}
[...]

L'output generato dagli altri host è stato rimosso per brevità.

A questo punto, è opportuno osservare alcuni aspetti:

1. Ogni nodo resituisce SUCCESS e "changed" : true, per indicare che l'esecuzione del modulo è stata completata correttamente e che il file è stato creato o modificato. Se eseguiamo di nuovo il comando, l'output conterrà "changed" : false, perché il file è già presente e configurato come necessario. In pratica, Ansible apporta le modifiche necessarie solo se non sono ancora presenti, secondo un principio noto come "idempotenza".

2. Poiché è specificata l'opzione -b (descritta alla pagina http://docs.ansible.com/ansible/latest/become.html), l'attività remota utilizza l'escalation dei privilegi (ovvero sudo), che è necessaria per copiare i file nella directory /etc/yum.repos.d.

3. Per identificare gli argomenti richiesti dal modulo copy puoi utilizzare il commando seguente:

[curtis@vm1 ~]$ ansible-doc copy 

Playbook

Mentre i comandi ad-hoc sono utili per testare semplici attività isolate, per registrare una serie di attività ripetibili, da eseguire in futuro, è possibile utilizzare i playbook. Un playbook contiene uno o più play, che definiscono una serie di host da configurare e un elenco di attività da eseguire.

Nel nostro scenario dobbiamo configurare alcuni web server, alcuni server di database e un server di registro centralizzato. I requisiti specifici sono i seguenti:

1. Il pacchetto httpd deve essere installato nei server web, abilitato e avviato.

2. Su ogni web server è disponibile una pagina predefinita che mostra il testo "Welcome to <hostname> on <ip address>".

3. Ogni web server dispone di account utente con privilegi di accesso appropriati per la gestione dei contenuti.

4. Il pacchetto MariaDB deve essere installato nei server dei database, abilitato e avviato.

5. L'host del server di registro deve essere configurato in modo da accettare i messaggi di registro remoti.

6. Gli host nei gruppi webservers e dbservers devono inviare una copia dei messaggi di registro all'host del server di registro.

Il playbook che segue (myplaybook.yml) configura tutto il necessario.

Mentre esamini il playbook, ti invito a notare quanto segue:

1. Il modulo user richiede un hash della password non crittografata (per ulteriori informazioni, vedi "ansible-doc user").  A tale scopo, è possibile utilizzare il comando seguente:

   • [curtis@vm1 ~]$ python -c "from passlib.hash import sha512_crypt; import getpass; print sha512_crypt.encrypt(getpass.getpass())" Password: $6$rounds=656000$bp7zTIl.nar2WQPS$U5CBB15GHnzBqnhY0r7UX65FrBI6w/w9YcAL2kN9PpDaYQIDY6Bi.CAEL6PRRKUqe2bJYgsayyh9NOP1kUy4w.
                             

2. Il contenuto della pagina web predefinita viene creato utilizzando i dati raccolti nell'host. Tali dati possono essere individuati e utilizzati tramite il modulo setup:

[curtis@vm1 ~]$ ansible vm2 -m setup
---
- hosts: webservers
 become: yes
 tasks:
   - name: install Apache server
     yum:
       name: httpd
       state: latest
   - name: enable and start Apache server
     service:
       name: httpd
       enabled: yes
       state: started
   - name: open firewall port
     firewalld:
       service: http
       immediate: true
       permanent: true
       state: enabled
   - name: create web admin group
     group:
       name: web
       state: present
   - name: create web admin user
     user:
       name: webadm
       comment: "Web Admin"
       password: $6$rounds=656000$bp7zTIl.nar2WQPS$U5CBB15GHnzBqnhY0r7UX65FrBI6w/w9YcAL2kN9PpDaYQIDY6Bi.CAEL6PRRKUqe2bJYgsayyh9NOP1kUy4w.
       groups: web
       append: yes
   - name: set content directory group/permissions 
     file:
       path: /var/www/html
       owner: root
       group: web
       state: directory
       mode: u=rwx,g=rwx,o=rx,g+s
   - name: create default page content
     copy:
       content: "Welcome to {{ ansible_fqdn}} on {{ ansible_default_ipv4.address }}"
       dest: /var/www/html/index.html
       owner: webadm
       group: web
       mode: u=rw,g=rw,o=r
- hosts: dbservers
 become: yes
 tasks:
   - name: install MariaDB server
     yum:
       name: mariadb-server
       state: latest
   - name: enable and start MariaDB server
     service:
       name: mariadb
       enabled: yes
       state: started
- hosts: logservers
 become: yes
 tasks:
   - name: configure rsyslog remote log reception over udp
     lineinfile:
       path: /etc/rsyslog.conf
       line: "{{ item }}"
       state: present
     with_items:
       - '$ModLoad imudp'
       - '$UDPServerRun 514'
     notify:
       - restart rsyslogd
   - name: open firewall port
     firewalld:
       port: 514/udp
       immediate: true
       permanent: true
       state: enabled
 handlers:
   - name: restart rsyslogd
     service:
       name: rsyslog
       state: restarted
- hosts: lamp
 become: yes
 tasks:
   - name: configure rsyslog
     lineinfile:
       path: /etc/rsyslog.conf
       line: '*.* @192.168.102.215:514'
       state: present
     notify:
       - restart rsyslogd
 handlers:
   - name: restart rsyslogd
     service:
       name: rsyslog
       state: restarted

Esecuzione del playbook

Per eseguire il playbook possiamo utilizzare il comando seguente:

[curtis@vm1 ~]$ ansible-playbook myplaybook.yml

Dall'output che segue possiamo vedere che la configurazione del web server viene eseguita solo su vm2 e vm3 (play 1), mentre il database viene installato in vm4 (play 2) e il server di registro (vm5) viene configurato con il play 3. Infine, il play 4 configura gli host webservers e dbservers per la registrazione remota, tramite il gruppo "lamp".

PLAY [webservers] *********************************************************************
TASK [Gathering Facts] ****************************************************************
ok: [vm2]
ok: [vm3]
TASK [install Apache server] **********************************************************
changed: [vm3]
changed: [vm2]
TASK [enable and start Apache server] *************************************************
changed: [vm2]
changed: [vm3]
TASK [open firewall port] *************************************************************
changed: [vm2]
changed: [vm3]
TASK [create web admin group] *********************************************************
changed: [vm3]
changed: [vm2]
TASK [create web admin user] **********************************************************
changed: [vm3]
changed: [vm2]
TASK [set content directory group/permissions] ****************************************
changed: [vm3]
changed: [vm2]
TASK [create default page content] ****************************************************
changed: [vm3]
changed: [vm2]
PLAY [dbservers] **********************************************************************
TASK [Gathering Facts] ****************************************************************
ok: [vm4]
TASK [install MariaDB server] *********************************************************
changed: [vm4]
TASK [enable and start MariaDB server] ************************************************
changed: [vm4]
PLAY [logservers] *********************************************************************
TASK [Gathering Facts] ****************************************************************
ok: [vm5]
TASK [configure rsyslog remote log reception over udp] ********************************
changed: [vm5] => (item=$ModLoad imudp)
changed: [vm5] => (item=$UDPServerRun 514)
TASK [open firewall port] *************************************************************
changed: [vm5]
RUNNING HANDLER [restart rsyslogd] ****************************************************
changed: [vm5]
PLAY [lamp] ***************************************************************************
TASK [Gathering Facts] ****************************************************************
ok: [vm3]
ok: [vm2]
ok: [vm4]
TASK [configure rsyslog] **************************************************************
changed: [vm2]
changed: [vm3]
changed: [vm4]
RUNNING HANDLER [restart rsyslogd] ****************************************************
changed: [vm3]
changed: [vm2]
changed: [vm4]
PLAY RECAP ****************************************************************************
vm2                        : ok=11 changed=9 unreachable=0    failed=0 
vm3                        : ok=11 changed=9 unreachable=0    failed=0 
vm4                        : ok=6 changed=4 unreachable=0    failed=0 
vm5                        : ok=4 changed=3 unreachable=0    failed=0 

L'operazione è terminata.

Per verificare gli host dei web server puoi utilizzare il comando seguente:

[curtis@vm1 ~]$ curl http://vm2
Welcome to vm2 on 192.168.102.212
[curtis@vm1 ~]$ curl http://vm3
Welcome to vm3 on 192.168.102.213 

Mentre la registrazione remota può essere verificata utilizzando il comando logger sugli host dei gruppi webservers e dbservers:

[curtis@vm1 ~]$ ansible lamp -m command -a 'logger hurray it works'
vm3 | SUCCESS | rc=0 >>
vm4 | SUCCESS | rc=0 >>
vm2 | SUCCESS | rc=0 >>

Conferma sul server di registro centrale:

[curtis@vm1 ~]$ ansible logservers -m command -a "grep 'hurray it works$' /var/log/messages" -b
vm5 | SUCCESS | rc=0 >>
Jan 30 13:28:29 vm3 curtis: hurray it works
Jan 30 13:28:29 vm2 curtis: hurray it works
Jan 30 13:28:29 vm4 curtis: hurray it works

Consigli e suggerimenti

Se non conosci ancora YAML, all'inizio la sintassi può rivelarsi insidiosa, soprattutto per via della spaziatura (senza tabulazioni).

Prima di eseguire un playbook, puoi verificare la sintassi con questo comando:

$ ansible-playbook --syntax-check myplaybook.yml 

Per imparare a usare YALM e trovare facilmente i problemi di sintassi, puoi usare vim con l'evidenziazione della sintassi. Per abilitare rapidamente vim per la sintassi YAML puoi aggiungere la riga seguente al tuo file ~/.vimrc:

autocmd Filetype yaml setlocal tabstop=2 ai colorcolumn=1,3,5,7,9,80

Se desideri aggiungere altre funzionalità, come i colori, puoi trovare un plug-in di questo tipo qui.
Se preferisci usare emacs al posto di vim, abilita il repository EPEL e installa il pacchetto emacs-yaml-mode.

È possibile testare un playbook anche senza modificare realmente gli host di destinazione:

$ ansible-playbook --check myplaybook.yml 

Può essere utile anche analizzare i singoli passaggi di un playbook a mano a mano che vengono eseguiti:

$ ansible-playbook --step myplaybook.yml 

Come avviene anche per gli shell script, è possibile rendere eseguibili gli Ansible Playbook e aggiungere quanto segue all'inizio del file:

#!/bin/ansible-playbook 

Per eseguire qualsiasi comando ad-hoc della shell, puoi utilizzare il modulo command (che viene utilizzato per impostazione predefinita se non si specifica l'opzione -m). Se invece hai bisogno di utilizzare ad esempio reindirizzamenti, pipeline e così via, devi usare il modulo shell.

Per accelerare la scrittura dei playbook, consulta la sezione "EXAMPLES" nella documentazione del modulo in questione.

Nei playbook, per evitare problemi con le stringhe che contengono caratteri speciali, racchiudile fra virgolette.

La registrazione è disabilitata per impostazione predefinita. Per abilitarla, usa il parametro log_path nel file di configurazione di Ansible.

Spero che questo post ti abbia aiutato a capire come funziona Ansible e come usarlo per risparmiare tempo e fatica, utilizzando i playbook per documentare e ripetere le attività di routine in modo semplice e preciso. Per continuare a imparare, visita le pagine http://docs.ansible.com e https://www.redhat.com/it/technologies/management/ansible.

Buona automazione!

Curtis Rempel, di RHCA, è Senior Platform TAM e responsabile di un team in Canada. In precedenza è stato Red Hat Certified Instructor and Examiner (RHCI/RHCX). La sua esperienza con Linux è iniziata nel 1994 con un CD di Red Hat Linux 2.1 di Jon "maddog" Hall. Nel suo ruolo di TAM, ha fornito supporto a clienti aziendali nei settori della finanza, delle telecomunicazioni e delle linee aeree, grazie alla sua esperienza in materia di automazione, kernel e storage. Scopri di più su Curtis.

È un Red Hat Technical Account Manager (TAM) esperto dei prodotti dell'azienda, che collabora attivamente con i reparti IT alla pianificazione strategica di deployment efficaci, aiutandoli a ottimizzare prestazioni e crescita. Il TAM fa parte dell'avanzatissima organizzazione Customer Experience and Engagement di Red Hat, fornendo consulenze e indicazioni proattive che aiutano i clienti a risolvere i problemi potenziali prima che si manifestino. In caso di problemi, il tuo TAM se ne assume la responsabilità e coinvolge le risorse più adatte a risolverlo nel più breve tempo possibile, limitando al minimo le interferenze con il business.

Vieni a conoscere i TAM a un evento Red Hat Convergence nella tua zona! Red Hat Convergence è un evento gratuito, solo su invito, che offre agli utenti tecnici l'opportunità di approfondire la conoscenza dei prodotti Red Hat e scoprire nuovi modi per sfruttare le tecnologie open source al fine di raggiungere gli obiettivi di business. Questi eventi vengono organizzati nelle città di tutto il mondo, per offrire una pratica esperienza di un giorno che, oltre all'opportunità di imparare, fornisce anche la possibilità di entrare in contatto cogli esperti di Red Hat e altri tecnici del tuo settore.

Il servizio Red Hat Cloud Success è concepito per aiutare i clienti a semplificare la trasformazione dell'IT e accelerare l'adozione delle tecnologie cloud, fornendo esperienza approfondita sui prodotti, indicazioni e supporto. Dal Proof of Concept alla produzione, un tecnico altamente qualificato e specializzato in prodotti cloud collabora con il cliente allo scopo di garantire continuità e un'implementazione efficace della soluzione. Con un impegno di durata limitata, il servizio Red Hat Cloud Success può aiutarti a pianificare e distribuire efficacemente le soluzioni cloud, definendo anche una pianificazione strategica per il futuro.