Introduzione ad Ansible

Cos’è Ansible: Ansible è uno strumento open source per l'automazione. Fornisce una piattaforma semplice, ​a​gentless​ e potente che permette di automatizzare tutti i processi di una infrastruttura indipendentemente dal tipo di infrastruttura e dal tipo di processo. La sua flessibilità​ e v​ersatilità ​lo rendono lo strumento giusto per gestire casi di utilizzo che tipici come: • Provisioning • Configuration Management • Application Deployment • Multi­Tier Orchestration Perché Ansible: Una caratteristica fondamentale Ansible è l’essere a​gentless: ​i requisiti sono solamente s​sh e p​ython​ (ormai installato di default in ogni sistema unix like). Non ha bisogno di agenti remoti, Ansible a​utonomamente ​trasferisce m​oduli​ ed esegue t​ask ​nel sistema remoto dei quali ha bisogno inoltre pulisce l’ambiente quando ha terminato. Ansible ha una serie di v​antaggi​ che lo rendono migliore rispetto ai competitor: • è i​dempotente ,​una volta eseguito correttamente un task possiamo rilanciarlo più volte ma tale task non sarà eseguito di nuovo • non ho bisogno di un ulteriore server​ (da configurare e gestire a sua volta) per configurare e gestire i miei server • sfrutta il sistema di a​utenticazione già esistente: ssh. ​Non ho bisogno di installare nè di integrare un ulteriore sistema di autenticazione aggiungendo inutili strati ulteriori • necessita solo di p​ython, ​installato ormai di default in ogni sistema unix like • non necessita la conoscenza di specifici linguaggi di programmazione per poterlo usare • è di facile adozione in quanto estremamente s​emplice • è estendibile via m​oduli • tutti i file di configurazione sono di tipo Y​AML ​quindi modificabili semplicemente con qualsiasi editor di testo Fondamenti: Inventory: È il file che contiene tutte le informazioni strutturate dei vostri server. [web] vg01.ibuildings.ws vg02.ibuildings.ws [db] vg03.ibuildings.ws Specificando “web” andremo ad eseguire le operazioni solo sui server vg01 e vg02, specificando “db” esegueremo l’operazione solo in vg03 mentre specificando la keyword “all” eseguiremo l’operazione su tutti i server. → ansible all ­i hosts ­m ping vg01 \| success >> {“changed“: false,“ping“: “pong“ } vg02 \| success >> { “changed“: false, “ping“: “pong“} vg03 \| success >> { “changed“: false, “ping“: “pong“} Abbiamo eseguito su tutti i server a​ll ​specificati nel file di inventory h​ost​ il modulo p​ing​ (che pinga i server per vedere se sono raggiungibili). Variables: Sono v​ariabili​ definite dal s​istema, ​dall’u​tente ​o ricavate in​ real time​ che possono essere usate da Ansible. → cat group_vars/all ­­­ ansible_ssh_user: vagrant ansible_become: true Istruisce Ansible ad usare l’utente vagrant per connettersi via ssh ed ad usare sudo per eseguire tutti i comandi. Le variabili possono essere s​pecificate ​anche nei t​ask ​per essere poi usate successivamente dalle altre istruzioni o templates. Tasks: Combina un’a​zione ​(formata da un modulo ed i suoi argomenti) con un nome ed eventualemente altri parametri opzionali ­ name: Install Apache2 apt: name=apache2 state=present “a​pt”​ è un m​odulo ​e serve per gestire pacchetti in sistemi debian like. Nello specifico controlla se apache2 è installato ed in caso negativo lo installa. “g​et_url”​ è un altro m​odulo,​ nell’esempio successivo è usato per scaricare drush ed inserirlo nella directory giusta con i permessi corretti. ­ name: Download and install drush get_url: url=http://files.drush.org/drush.phar dest=/usr/local/bin/drush mode=0755 Templates: Sono f​ile ​parsati da Ansible che s​ostituirà​ le v​ariabili​ necessarie quando necessario. → cat roles/mysql­server/templates/.my.cnf [client] user=root password={{ mysql_root_pass }} La variabile “mysql_root_pass” nel template sarà sostituita dal valore specificato in questo caso nel play (ma potevo specificarlo anche a riga di comando). # install mysql­server ­ hosts: db roles: ­ mysql­server ­ drupal­db vars: mysql_root_pass: toor mysql_drupal_db: drupal mysql_drupal_user: drupal mysql_drupal_pass: drupal tags: ­ mysql­server Nota: Le s​ostituzioni ​delle variabili vengono effettuate anche nelle altre istruzioni come i t​ask ​e non solo nei file di templates. ­ name: create db for drupal mysql_db: name=drupal state=present login_user=root login_password=“{{ mysql_root_pass }}“ collation=utf8mb4_unicode_ci encoding=utf8mb4 Il task precedente crea un db di nome “drupal” specificando collation ed encoding. Per far questo ha bisogno delle credenziali di accesso al db, l’utente è root standard mentre la password è contenuta in una variabile. Handlers: Esegue un’a​zione​ quando s​pecificato.​ Il seguente task copia il file di configurazione di nginx e notifica l’handler “restart nginx” ­ name: template configuration file template: src=nginx.conf dest=/usr/local/nginx/nginx.conf notify: ­ restart nginx L’handler “restart nginx” è ovviamente: ­ name: restart nginx service: name=nginx state=restarted Da notare che anche “service” è un modulo. Tags: Servono a s​pecificare ​un p​articolare​ play, role o task. # install web deps ­ hosts: web roles: ­ web ­ drupal tags: ­ web Roles: Sono u​nità di organizzazione​ di Ansible, contengono tasks, templates, variables, etc. Sono utili perchè permettono di: • dividere ​la configurazione in più pezzi riutilizzabili tra vari progetti • mantenere​ una struttura pulita • condivisione​ su Ansible Galaxy • riusabili​ e riciclabili La struttura di un role è organizzata come segue: roles/ nginx/ tasks/ main.yml handlers/ main.yml templates/ nginx.conf mysite.conf files/ bar.txt foo.sh vars/ main.yml defaults/ main.yml Playbooks: Un playbook è un g​ruppo di play. ​Il play rappresenta il m​apping ​tra un insieme di h​ost ​e le istruzioni ​che saranno eseguite in quegli host. vars: http_port: 80 remote_user: root tasks: ­ name: ensure nginx is at the latest version yum: name=nginx state=latest ­ name: write the nginx config file template: src=nginx.conf dest=/usr/local/nginx/nginx.conf notify: ­ restart nginx ­ name: ensure nginx is running (and enable it at boot) service: name=nginx state=started enabled=yes handlers: ­ name: restart nginx service: name=nginx state=restarted Il playbook di esempio eseguirà tutti i task specifici negli host definiti come “webservers” nel file di inventory. L’esempio specifico è a titolo esemplificativo e non è una best practice in quanto è consigliabile dividere i task in role. ­­­ ­ hosts: webservers vars: http_port: 80 roles: ­ nginx ­ php­fpm ­ hosts: dbservers roles: ­ mysql I playbook si eseguono semplicemente attraverso l’istruzione: ansible­playbook example_playbook.yml ­vvvv Note: Un m​odulo​ utile è “c​ommand” ​che permette di eseguire comandi arbitrati negli host specificati. → ansible all ­i hosts ­m command ­a “whoami“ vg01 | success | rc=0 >> root vg02 | success | rc=0 >> root vg03 | success | rc=0 >> root Playbook di esempio: All’indirizzo https://github.com/and9000/ansible_example ​è presente un playbook di esempio funzionante.​ Tale playbook configura 2 macchine, vg01 come server web installando apache, php e drupal e vg02 come db server installandoci mysql. Ovviamente è possibile modificando il file di inventory “hosts” cambiare il nome delle macchine. La struttura è la seguente: hosts roles drupal­db templates my.cnf tasks main.yml drupal tasks main.yml mysql­server  templates my.cnf tasks main.yml handlers main.yml web tasks main.yml handlers main.yml mysql­client tasks main.yml example_playbook_1.yml group_vars all Nel file di hosts sono specificate le macchine interessate: → cat hosts [web] vg01 [db] vg02 Nello specifico sono 2 macchine su vagrant configurate correttamente per l’accesso con chiave per l’utente vagrant. Ansible poi userà sudo per eseguire tutti i comandi necessari. → cat group_vars/all ­­­ ansible_ssh_user: vagrant ansible_become: true Il playbook è eseguito con: → ansible­playbook ­i hosts example_playbook_1.yml Una corretta esecuzione produrrà al termine dell’output le seguenti righe: PLAY RECAP ******************************************************************** vg01 : ok=10 changed=7 unreachable=0 failed=0 vg02 : ok=12 changed=8 unreachable=0 failed=0 Eseguendo nuovamente il playbook si nota che non viene più eseguito nessun task in quanto sono tutti terminato correttamente precedentemente e non sono stati modificati: PLAY RECAP ******************************************************************** vg01 : ok=9 changed=0 unreachable=0 failed=0 vg02 : ok=11 changed=0 unreachable=0 failed=0 Playbook: → cat example_playbook_1.yml ­­­ # install web deps ­ hosts: web roles: ­ web ­ drupal tags: ­ web # install mysql­client ­ hosts: web:db roles: ­ mysql­client tags: ­ mysql­client # install mysql­server ­ hosts: db roles: ­ mysql­server ­ drupal­db vars: unreachable=0 unreachable=0 failed=0 failed=0 mysql_root_pass: toor mysql_drupal_db: drupal mysql_drupal_user: drupal mysql_drupal_pass: drupal tags: ­ mysql­server Ci sono 5 role: • web (installa apache, php, etc.) • mysql­client (installa mysql­client) • mysql­server (installa mysql­server) • drupal (installa drupal) • drupal­db (crea il db e l’utente per drupal) Ogni ruolo è eseguito solamente negli host necessari, specificando le variabili d’ambiente utili (per esempio quelle del db). Inoltre sono presenti t​ag​ per permettere l’e​secuzione selettiva​ dei p​lay.​ Alla fine dell’esecuzione all’indirizzo “h​ttp://vg01/drupal”​ sarà presente un drupal scaricato pronto per l’installazione con il db già creato (i dati relativi alla connessione sono impostati tramite variabili). Conclusioni: Ansible​ semplicemente è uno strumento che permette di a​utomatizzare q​ualsiasi processo i​n qualsiasi s​istema.​ Abbraccia A​nsible:​b​atteries included!​