2. I progetti SW
All’inizio c’erano due figure:
● Gli sviluppatori che facevano il SW
● I sistemisti che lo installavano e lo configuravano.
Fino a quando!!!!
...anche i sistemisti hanno cominciato a scrivere SW.
- Script Shell: installare e configurare automaticamente
3. SW per il deploy dei sistemi
Oggi:
i sistemi software diventano sempre più complessi
distribuiti, in cloud, in continuo sviluppo
e deployment.
Gli script non bastano più:
● non sono robusti
● difficili da comprendere
● tutti diversi tra loro
4. Facilità - Velocità - Affidabilità
I sistemi sviluppati con metodologia agile, sono complessi,
distribuiti e in cloud e pertanto occorre:
● Un modo semplice per installare e configurare i server nuovi
o quelli già esistenti;
● Un modo di "sincronizzare" la configurazione ad una
baseline;
● Ricreare una stessa macchina tante volte quanto necessita:
in modo veloce, affidabile e senza sforzo;
● Un modo per gestire i “deployment” complessi che consenta
anche di orchestrare servizi interconnessi;
5. Infrastructure as Code
Forse avete sentito parlare del concetto di "infrastruttura
come codice", mantra della cultura DevOps.
(http://sdarchitect.wordpress.com/2012/12/13/infrastructure-as-code/)
Questa cultura ha fatto emergere tool popolari come Chef o
Puppet. Tuttavia questi tools si sono rivelati
incredibilmente complessi da utilizzare
anche per i casi più semplici
6. Infrastructure as Data: Ansible
Ansible è un motore di orchestrazione semplice e radicale che rende le
applicazioni ed i sistemi più facile da installare e distribuire.
●
●
●
Si evita di scrivere script o codice personalizzato per distribuire e
aggiornare le applicazioni
Usa un linguaggio che si avvicina ad un inglese semplice
Usa SSH, senza agenti da installare su sistemi remoti
Ansible è il modo più semplice per automatizzare ed orchestrare:
●
●
●
Installazione di applicazioni distribuite
Gestione della configurazione
Gestire un ciclo continuo di installazione e sviluppo
7. Ansible
Creato da Michael De Haan
Open Source: https://github.com/ansible/ansible/
(ora anche supportato da AnsibleWorks)
● Documentato molto bene
● Supportato da una community molto attiva di
sviluppatori
9. Come funziona - Step 1: Gli hosts
[local]
127.0.0.1
[webserver]
www.webserv1.it
www..webserv2.it
[database]
10.0.1.123
Definizione dei gruppi di
host su cui si eseguiranno
i comandi o interi playbook
10. Come funziona - Step 2: i Comandi
[local]
127.0.0.1
Host
[webserver]
www.webserv1.it
www..webserv2.it
[database]
10.0.1.123
Esempi di comandi
ansible all -m ping
ansible webserver -a "/usr/bin/command arg1 arg2" --limit
$ ansible database -i hosts -a "ls -lsa /usr"
10.0.1.123 | success | rc=0 >>
total 56
4 drwxr-xr-x 10 root root 4096 Apr 10 2012 .
4 drwxrwxr-x 22 root admin 4096 Jul 26 08:29 ..
20 drwxr-xr-x 2 root root 20480 Oct 10 15:39 bin
4 drwxr-xr-x 2 root root 4096 Jan 27 2012 games
4 drwxr-xr-x 31 root root 4096 Jul 26 11:18 include
4 drwxr-xr-x 40 root root 4096 Oct 7 16:07 lib
4 drwxr-xr-x 10 root root 4096 Apr 10 2012 local
4 drwxr-xr-x 2 root root 4096 Oct 7 16:08 sbin
4 drwxr-xr-x 81 root root 4096 Aug 28 14:32 share
4 drwxr-xr-x 2 root root 4096 Jan 27 2012 src
$
11. Come funziona - Step 3: Playbook
● File in formato YAML (http://en.wikipedia.org/wiki/YAML)
● Formato dichiarativo della vostra configurazione
● Si possono specificare diversi “playbook” che si
riferiscono a vari gruppi di macchine
La cosa grande è che con Ansible i playbook sono per la
maggior parte idempotenti. Possono essere eseguiti molte
volte il risultato non cambia.
12. Idempotenza (idempotent)
In informatica, un'operazione idempotente è quella che non ha alcun effetto
aggiuntivo se viene eseguita più di una volta con gli stessi parametri di
ingresso. Cioè non non importa quante volte si chiama l'operazione il risultato
sarà lo stesso
Le operazioni idempotenti sono spesso utilizzati nella progettazione di protocolli
di rete, dove una richiesta di eseguire un'operazione di accadere viene
garantita almeno una volta, ma potrebbe anche verificarsi più di una volta. Se
l'operazione è idempotente, allora non c'è nulla di male nell’eseguire
l'operazione due o più volte il risultato sarà sempre lo stesso.
13. Come funziona - Step 3: Playbook
l’insieme dei task che devono essere svolti per fare il
Playbook
--- hosts: all
user: root
vars_files:
- vars/settings-default.yml
tasks:
- name: PHP configuration file, php.ini
action: template src=templates/etc-php5-apache2-php-ini.
j2 dest=/etc/php5/apache2/php.ini
notify: Restart Apache
handlers:
- name: Restart Apache
action: service name=apache2 state=restarted
deploy di un sistema sono registrati in un Playbook
ansible in formato YAML.
I playbook vengono poi eseguite sugli host.
Le componenti principali di un “playbook” Ansible
sono:
●
Definizione degli Host
●
Le “Variable” che sono usate nei “playbook” o
nei “template”
●
I “Task” che saranno eseguiti nel “playbook”
●
Gli “Handlers” che gestiscono le risposte di
cambiamento sul sistema fatto dai task.
14. Task
Esempio di Playbook
--
Ogni play contiene una lista di task che vengono
eseguiti uno alla volta sugli host a cui si applica il
play
- hosts: webserver
user: root
Module
sudo: no
Ansible dispone di una serie di moduli (‘‘module
library’) che possono essere eseguiti direttamente
sugli host remoti utilizzandoli nei playbook.
tasks:
- name: install apache2
action:
apt
pkg=apache2 state=latest
notify:
Handler
- name: Make sure index.html is present for the default virtual host
Eseguono delle operazioni quando si verificano
eventi eventi a seguito di un task che ha causato dei
cambiamenti
action: copy src=files/index.html dest=/var/www/index.html
Le azioni “notify” hanno dei trigger che sono eseguiti
una sola volta anche se la notifica viene da più task.
- start apache2
- name: Make sure index.html is owned by www-data
Ad esempio può accadere che apache richieda un
action: file path=/var/www/index.html owner=www-data group=www-data perchè è cambiata la sua configurazione e
restart
questo viene fatto una sola volta anche se più tsk
handlers:
- name: start apache2
action: service name=apache2 state=started
hanno cambiato la sua configurazione.
16. Infrastructure as Data:
Ansible
La configurazione automatica delle macchine è abbastanza facile con Ansible.
E’ possibile configurare una singola macchina o tutta una serie con un processo
riproducibile.
●
●
●
Tu descrivi la tua infrastruttura (in modo dichiarativo)
Definisci la sua versione
“Applichi” la descrizione alla tua infrastruttura:
l’esecuzione la fa Ansible