Un team di amministratori di sistema IT che ha esperienza nell'uso di shell scripting per risolvere i loro problemi, sta pensando di iniziare a utilizzare Ansible.
Ci sono differenze sostanziali e buoni motivi per iniziare a usare Ansible vs. per continuare a scrivere script di shell?
Risposte:
Non ho mai usato Ansible ma da alcune settimane cerco di capire cosa potrebbe essere Ansible buono in confronto agli scrips della shell - Il che dimostra, almeno nel mio caso, che le campagne pubblicitarie ossessionanti che gestiscono sono efficaci! Dopo molti tentativi falliti, il che dimostra come la loro documentazione non riesca a rispondere a una delle domande più ovvie, penso di aver finalmente capito:
Ora, guardiamo il video introduttivo e andiamo a caso come potenziale nuovo utente attraverso il materiale introduttivo su Ansible e confrontiamolo con ciò che un programmatore esperto di shell può produrre subito.
La mia conclusione è che oltre allo scripting della shell, Ansible offre essenzialmente 1. La possibilità di verificare che un sistema sia d'accordo con uno stato desiderato, 2. la capacità di integrarsi con Ansible Tower, che è un sistema a pagamento che sembra includere capacità di monitoraggio. In alcuni casi importanti, come quando si implementa il modello di server immutabile, il punto 1 probabilmente non è molto utile, quindi l'elenco è piuttosto sottile.
La mia conclusione è che i vantaggi offerti da Ansible rispetto allo shell-scripting, come presentato dalla documentazione, potrebbero essere sensati in alcuni casi ottimistici ben coperti dai moduli disponibili, ma sono piccoli o addirittura ipotetici nel caso generale. Per un abile programmatore di shell, probabilmente questi benefici sono probabilmente controbilanciati da altri aspetti del compromesso.
Ma questo forse dimostra solo quanto male sia il materiale introduttivo!
C'è un video di avvio rapido . Si inizia con una pagina in cui si afferma che ... beh, queste non sono realmente affermazioni, si tratta di elenchi puntati, un artefatto comunemente usato per sospendere il giudizio critico nelle presentazioni (poiché la logica non è mostrata, non può essere criticata!)
1.1 Automazione leggibile dall'uomo - Le specifiche sono documenti tecnici, come potrebbe
name: upgrade all packages
yum:
name: '*'
state: latest
essere più facile da leggere rispetto all'invocazione yum corrispondente trovata in uno script di shell? Inoltre, chiunque abbia avuto contatti con AppleScript muore ridendo quando legge “automazione leggibile dall'uomo”.
1.2 Non sono richieste competenze di codifica speciali - Che cos'è la codifica se non la scrittura di specifiche formali? Hanno condizionali, variabili, quindi, come non codifica? E perché avrei bisogno di qualcosa che non posso programmare, che d'ora in poi sarebbe inflessibile? L'affermazione è felicemente inaccurata!
1.3 Compiti eseguiti in ordine - Beh, forse alcuni appassionati di codegolf sono a conoscenza di linguaggi che eseguono compiti in disordine, ma l'esecuzione di compiti in ordine sembra quasi eccezionale.
1.4 Diventa produttivo rapidamente - I programmatori shell specializzati sono produttivi ora. Questa contro-argomentazione è seria tanto quanto l'argomento iniziale.
Un popolare trucco da venditore per vendere artefatti è ingannare le persone nel credere che acquisiranno il "potere" di questi artefatti. La storia della pubblicità di automobili o bevande isotoniche dovrebbe fornire un elenco convincente di esempi.
Qui Ansible può eseguire la “distribuzione di app” - ma sicuramente lo script di shell lo fa, “gestione della configurazione” ma questa è una semplice affermazione dello scopo dello strumento, non una funzionalità, e “orchestrazione del flusso di lavoro” che sembra un po 'pretenziosa ma nessun esempio va oltre ciò che GNU Parallel può fare.
Per popolare la colonna, hanno scritto in tre modi diversi che questo ha solo bisogno di ssh, che, come tutti sanno è un demone e non ha nulla a che fare con questi agenti che pervadono la gestione della configurazione mondiale!
Il resto del video introduce inventari, che sono elenchi statici di risorse (come server) e mostra come distribuire Apache su tre server contemporaneamente. Questo in realtà non corrisponde al modo in cui lavoro, in cui le risorse sono altamente dinamiche e possono essere enumerate dagli strumenti della riga di comando forniti dal mio provider cloud e consumati dalle mie funzioni shell utilizzando l' |operatore pipe . Inoltre, non distribuisco Apache su tre server contemporaneamente, piuttosto, costruisco un'immagine di istanza master che uso quindi per avviare 3 istanze che sono repliche esatte l'una dell'altra. Quindi la parte "orchestrante" dell'argomentazione non sembra molto pertinente.
EC2 è il servizio di elaborazione di Amazon, l'interazione con esso è supportata da alcuni moduli Ansible . (Vengono forniti anche altri noti provider di cloud computing):
# demo_setup.yml
- hosts: localhost
connection: local
gather_facts: False
tasks:
- name: Provision a set of instances
ec2:
key_name: my_key
group: test
instance_type: t2.micro
image: "{{ ami_id }}"
wait: true
exact_count: 5
count_tag:
Name: Demo
instance_tags:
Name: Demo
register: ec2
Lo script shell corrispondente sarebbe essenzialmente identico a YAML sostituito da JSON:
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --image-id …
}
o la versione JSON
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --cli-input-json "$(provision_a_set_of_instances__json)"
}
provision_a_set_of_instances__json()
{
cat <<EOF
{
"ImageId": …
}
EOF
}
Entrambe le versioni sono essenzialmente identiche, la maggior parte del payload è l'enumerazione dei valori di inizializzazione in strutture YAML o JSON.
La maggior parte di questa guida non mostra alcuna caratteristica davvero interessante: introduce variabili (IIRC, anche gli script di shell hanno variabili)! E un modulo Ansible gestisce mysql, quindi se invece di cercare “come faccio a creare un utente mysql con privilegi su XY "e termina con qualcosa di simile
# Create Application DB User
mysql --host "${mysql_host}" --user "${mysql_user}" --password "${mysql_password}" "${mysql_table}" <<EOF
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
EOF
cerchi "come faccio a creare un utente mysql con privilegi su XY in ansible " e finisci con
- name: Create Application DB User
mysql_user: name={{ dbuser }} password={{ upassword }}
priv=*.*:ALL host='%' state=present
La differenza probabilmente non è ancora molto significativa. In quella pagina scopriamo anche che Ansible ha un linguaggio di meta-programmazione modello
{% for host in groups['monitoring'] %}
-A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT
{% endfor %}
Quando vedo questo, mi capita di trovarmi davvero nella mia zona di comfort. Questo tipo di semplice meta-programmazione per linguaggi dichiarativi è esattamente lo stesso paradigma teorico dei Makefile BSD! Che mi è capitato di aver programmato ampiamente Questo estratto ci mostra che la promessa di lavorare con il file YAML è rotta (quindi non posso far funzionare i miei playbook attraverso un parser YAML, ad es .). Ci mostra anche che Ansible deve discutere l'arte sottile dell'ordine di valutazione: dobbiamo decidere se le variabili sono espanse nella "parte dichiarativa" della lingua o nella meta-parte "imperativa" della lingua. Qui la programmazione della shell è più semplice, non esiste una meta-programmazione, a parte l' approvvigionamento esplicito eval o di script esterni. L'ipotetico estratto di shell equivalente sarebbe
enumerate_group 'monitoring' | {
while read host; do
…
done
}
la cui complessità rispetto alla variante Ansible è probabilmente tollerabile: usa solo i semplici, regolari, noiosi costrutti del linguaggio.
Infine, incontriamo quella che risulta essere la prima caratteristica davvero interessante di Ansible: “Le risorse Ansible sono modelli di stato desiderato. Pertanto, non dovrebbe essere necessario testare l'avvio dei servizi, l'installazione dei pacchetti o altre cose del genere. Ansible è il sistema che garantirà che queste cose siano dichiaratamente vere. Invece, asserisci queste cose nei tuoi playbook. ”Ora inizia a essere un po 'interessante, ma:
A parte una manciata di situazioni standard prontamente implementate dai moduli disponibili, dovrò alimentare da solo i bit che implementano il test, che probabilmente implicherà alcuni comandi di shell.
Il controllo della conformità delle installazioni potrebbe non essere molto rilevante nel contesto in cui è implementato il modello di server immutabile: in cui tutti i sistemi in esecuzione sono generalmente generati da un'immagine principale (immagine di istanza o immagine docker per esempio) e mai aggiornati - sono sostituiti da nuovo invece.
Il materiale introduttivo di Ansible ignora la questione della manutenibilità. Con praticamente nessun sistema di tipi, lo shell-scripting ha la facilità di manutenibilità di JavaScript, Lisp o Python: i refactoring estesi possono essere raggiunti con successo solo con l'aiuto di una vasta suite di test automatizzati - o almeno progetti che consentono facili test interattivi. Detto questo, mentre lo script di shell è la lingua franca dalla configurazione e manutenzione del sistema, quasi ogni linguaggio di programmazione ha un'interfaccia con la shell. È quindi assolutamente possibile sfruttare il vantaggio di manutenibilità dei linguaggi avanzati, usandoli per incollare insieme i vari bit di bit di configurazione della shell. Per OCaml, ho scritto Rashell ciò fornisce essenzialmente una mano di schemi di interazione comuni per i sottoprocessi, il che rende sostanzialmente banale la traduzione degli script di configurazione in OCaml.
A parte Ansible, la struttura molto debole dei playbook e la presenza di una funzionalità di meta-programmazione rendono la situazione essenzialmente grave come lo è per gli script di shell, con i punti negativi che non è ovvio come scrivere test unitari per Ansible e l'argomento dell'introduzione ad hoc di un linguaggio di livello superiore non può essere imitato.
La documentazione di Ansible attira l'attenzione sulla necessità di scrivere passaggi di configurazione idempotenti. Più precisamente, i passaggi di configurazione devono essere scritti in modo tale che la sequenza di passaggi aba possa essere semplificata in ab , ovvero non è necessario ripetere il passaggio di configurazione. Questa è una condizione più forte dell'idempotenza. Poiché Ansible consente ai playbook di utilizzare comandi shell arbitrari, Ansible stesso non è in grado di garantire il rispetto di questa condizione più forte. Questo si basa solo sulla disciplina del programmatore.
In questo modo, anche se Ansible presenta alcuni vantaggi intrinseci, i vantaggi dell'uso di strumenti familiari (in questo caso script di shell) devono essere superiori. Non credo che ci sia una risposta chiara a questo.
Se il team riesce a realizzare le cose che Ansible offre con shell:
allora potrebbero probabilmente attenersi a ciò che sanno.
Dopotutto, puoi implementare "guardie" in BASH. Puoi trovare molti lavori BASH esistenti là fuori per risolvere una varietà di attività di configurazione del server (essenzialmente qualsiasi file Docker là fuori ha il 90% di codice di installazione bash). Puoi avvicinarti molto a ciò che Ansible / Salt / Chef-Zero ti offre, senza dover effettivamente trasferire l'intera soluzione esistente su quegli strumenti.
È un atto di bilanciamento tra le tendenze di NIH (non inventate qui) e il lancio di buoni script stabiliti a favore di una soluzione più solida.
Un'ultima considerazione da tenere a mente: in che modo la tua pila di tecnologia misura quando cerchi di reclutare più persone nel team. Trovare persone con esperienza Ansible è molto più facile che trovare persone che hanno esperienza nel tuo particolare strumento di scripting CM sviluppato in casa. Questo non è strettamente un aspetto tecnico, più culturale. Vuoi essere la strana organizzazione che inventa il proprio Ansible o vuoi essere l'org ragionevole che trova lo strumento giusto per il lavoro? Queste decisioni influiscono sulla tua capacità di attirare talenti.
La risposta di cui sopra copre parte di essa ma manca uno degli elementi importanti: il design convergente. Ho scritto qualche parola su questo nel contesto di Chef su https://coderanger.net/thinking/ ma la versione breve è che uno script bash è un insieme di istruzioni, mentre un playbook Ansible (o ricetta dello Chef, Salt stato, ecc.) è una descrizione dello stato desiderato. Documentando lo stato desiderato anziché i passaggi che si desidera eseguire per arrivarci, è possibile far fronte a molti più stati iniziali. Questo è stato il cuore di Promise Theory, come è stato delineato molto tempo fa in CFEngine, e un progetto che noi (gli strumenti di gestione della configurazione) abbiamo appena copiato da allora.
tl; dr Il codice Ansible dice quello che vuoi, il codice bash dice come fare una cosa.
Una cosa degna di nota è che avrai meno problemi nell'esecuzione dei tuoi libri di gioco sensibili anche su host remoti. Poiché è il motivo principale per l'esecuzione di ansible. Quando si utilizza lo scripting della shell, è comunque necessario disporre di un modo per eseguire lo scripting dell'hosting sull'host remoto.
È il 2019 e ho appena trascorso alcuni giorni su una curva di apprendimento sensibile ed ecco la verità assoluta: Ansible non vale la pena.
non è finito, non funziona su Windows e la combinazione di configurazione YAML e messaggi di errore fuorvianti ti farà sanguinare gli occhi. Sembra quasi deliberatamente terribile e lo dico sul serio. È chiaramente il prodotto di un redhat sysadmins frustrato progetto lato sviluppatore. Probabilmente un hipster.
Se non ne richiedi nessuna. Oltre le funzionalità di provisioning, esegui il provisioning solo su un determinato sistema operativo. Per amor di Dio, scrivi un shell.script decente.
A partire da ora, l'intero progetto mi ricorda i primi forum di Linux in cui è stato detto a nessuno di RTFM e deriso per aver chiesto perché qualcuno non potesse scrivere una GUI per configurare le impostazioni grafiche. Semplicemente non capisci vero? Dovresti restare alle finestre ... forse mi accoppierò ... felice VI-ing.
Usa Docker. In preferenza a qualsiasi cosa. Docker è scandalosamente semplice e potente.
Ma cosa succede se è assolutamente necessario effettuare il provisioning su stagno preesistente? Quali sono le vere alternative?
Bene ... non ce ne sono ancora. Ma te lo prometto, a meno che Ansible non stia meglio, ci saranno presto. Perché non importa quanto duramente i fanbo lo spingano e perdonino i suoi fallimenti ... è un 5 su 10 per lo sforzo.
SCP crea uno script bash e risparmia il problema.