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.
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!
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.
Sull'autore
Altri risultati simili a questo
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Serie originali
Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende