Il blog di Red Hat
Blog menu
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:
-
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".
-
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.
-
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:
-
Il pacchetto httpd deve essere installato nei server web, abilitato e avviato.
-
Su ogni web server è disponibile una pagina predefinita che mostra il testo "Welcome to <hostname> on <ip address>".
-
Ogni web server dispone di account utente con privilegi di accesso appropriati per la gestione dei contenuti.
-
Il pacchetto MariaDB deve essere installato nei server dei database, abilitato e avviato.
-
L'host del server di registro deve essere configurato in modo da accettare i messaggi di registro remoti.
-
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:
-
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.
-
-
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!
È 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.
