Share
Questa è la seconda parte di un tutorial in due parti su Ansible. La prima parte è qui. In questa parte, verranno illustrati i ruoli (i blocchi predefiniti di Ansible), le variabili, i loop, come utilizzare i ruoli nei playbook e come organizzare i ruoli in una struttura di directory.
Quando gestisci decine, centinaia o più server, probabilmente molti di loro devono essere configurati in modo simile. Diversi gruppi di server come server Web o server di database richiedono una propria configurazione speciale, ma potrebbero anche condividere alcune altre funzionalità comuni. Ovviamente è possibile copiare semplicemente le attività, ma questo diventa molto veloce quando si ha a che fare con un'infrastruttura complicata.
I ruoli ansiosi sono il biglietto. I quaderni possono includere ruoli. I ruoli possono dipendere da altri ruoli e le best practice di Ansible consigliano il raggruppamento degli host nel file di inventario in base ai loro ruoli. I ruoli sono la spina dorsale di una seria infrastruttura gestita da Ansible. Come al solito, inizierò con un esempio e presenterò molte delle funzionalità dei ruoli attraverso l'esempio.
Mi piacciono molto gli alias e le funzioni di shell perché non riesco a ricordare tutti gli switch e le opzioni arcani per ogni comando, e anche perché consente di risparmiare un sacco di digitazione. Mi piace anche avere alcuni strumenti come htop e tmux su ogni server a cui mi collego.
Ecco un file che contiene alcuni dei miei alias e funzioni preferiti. Lo chiamerò '.gigirc'. A proposito, se ti sei mai chiesto che cosa significhi il suffisso 'rc' in tutti quei file rc, significa 'Esegui comandi'.
alias sv = "sudo vim" alias py = "python" alias pi = "pip install" # Elenco di directory in un formato piacevole alias lla = "ls -lAGh" # Trova file di dimensione zero alias lsz = "find. -type f - dimensione 0 -exec ls \; " # Rimuovi tutti i file * .pyc in modo ricorsivo alias rmpyc = "trova. -Name" * .pyc "-print0 | xargs -0 rm" # Utilizzo del disco che ordina anche i risultati per dimensione e salva in un file alias dus = "du - Pscmx * | sort -nr | tee disk_usage.txt "alias g =" git "alias gci =" git commit -a "alias gcia =" git commit -a --amend "alias gb =" git branch "alias gbd =" git branch -D "alias gco =" git checkout "alias gpu =" git pull --rebase "alias gg =" git grep -i "alias gs =" git status "alias gd =" git diff "alias gl =" git log --oneline "# Mostra tutti i file e le directory non tracciabili nella dir attuale alias ng =" git clean -n -d. " # Recupera e traccia la funzione del ramo remoto gfr checkit git --track -b $ 1 origine / $ 1 # Crea il ramo git remoto (e anche locale) dalla funzione master gbr gco master gb $ 1 g push -u origine $ 1
Definiamo un ruolo chiamato "comune" che crea un utente chiamato "gigi", aggiunge una chiave pubblica ssh, copia il file ".gigirc" e aggiunge una riga alla fine di "~ / .bashrc" che esegue questo file e infine installa i pacchetti comuni vim, htop e tmux (definiti nel file 'vars / main.yml').
Presenterò un lotto di nuove cose qui: quattro diversi moduli, variabili e loop. Inoltre, i ruoli sono generalmente distribuiti su più file in una struttura di directory standard. Ti mostrerò un paio di file e poi spiegherò la struttura delle directory. Ecco il file 'tasks / main.yml':
Accentsconagua
--- - nome: crea un utente di nome gigi user: nome = gigi - nome: aggiungi chiave pubblica authorized_key: user = gigi key = "lookup ('file', '~ / .ssh / id_rsa.pub')" - nome : Copia il file .gigirc nella directory home del nuovo utente gigi copy: src = ~ / .gigirc dest = / home / gigi / .gigirc owner = gigi group = gigi mode = 0644 - name: Esegui .gigirc da .bashrc lineinfile: dest = / home / gigi / .bashrc line = "source /home/gigi/.gigirc" - nome: installa i pacchetti comuni apt: name = item state = installed update_cache = true force = yes with_items: COMMON_PACKAGES Ed ecco il file vars / main.yml che contiene la definizione della variabile 'COMMON_PACKAGES' usata per specificare quali pacchetti comuni installare.
--- PACCHI COMMON: - vim - htop - tmux
Il modulo utente può gestire gli account utente. Qui lo uso per creare l'utente 'gigi'.
Il modulo authorized_key serve per aggiungere / rimuovere chiavi autorizzate SSH. Qui lo uso per aggiungere la mia chiave pubblica per l'utente 'gigi'.
Il modulo lineinfile può essere utilizzato per sostituire o aggiungere singole linee a un file. In questo caso, lo uso per generare il file ".gigirc" da ".bashrc", quindi tutti i fantastici alias e le funzioni in ".gigirc" sono sempre disponibili in qualsiasi sessione interattiva.
Infine, il modulo apt ha un sacco di opzioni per la gestione dei pacchetti apt. Qui installo solo alcuni pacchetti comuni.
Il COMMON_PACKAGES vedi nell'ultima attività per l'installazione di pacchetti comuni è una variabile. Ansible ti consente di utilizzare variabili definite quasi ovunque: libri di gioco, inventario, ruoli, file dedicati e persino variabili d'ambiente. Vi sono molte più informazioni sulle variabili nella documentazione.
Ansible è dichiarativo, quindi non supporta cicli espliciti. Ma c'è una pletora di with_xxx che ti permette di eseguire operazioni ripetute su alcune strutture come un elenco di utenti, pacchetti. o linee in un file. Puoi anche ripetere le operazioni fino a quando alcune condizioni sono vere o ottenere l'indice dell'elemento corrente. Ulteriori informazioni sono disponibili nella documentazione.
Ecco come può essere una tipica struttura di directory dei ruoli:
Comune
├── gestori
│ └── main.yml
─── meta
│ └── main.yml
├── compiti
│ └── main.yml
├── modelli
└── vars
├── Debian.yml
├── Ubuntu.yml
└── main.yml
Il file 'tasks / main.yml' è il luogo in cui sono definite tutte le attività. Ogni attività corrisponde a un comando Ansible che in genere utilizza un modulo.
Il file 'meta / main.yml' conterrà un elenco di altri ruoli da cui dipende il ruolo corrente. I compiti di tali ruoli verranno eseguiti prima del ruolo corrente, quindi può essere sicuro che tutti i suoi prerequisiti siano soddisfatti.
Il file 'handlers / main.yml' è dove mantieni i tuoi gestori, come il gestore che hai visto in precedenza che avvia Nginx dopo l'installazione.
La directory templates è dove si conservano i modelli Jinja2 di configurazione e altri file che si desidera compilare e copiare nel sistema di destinazione.
La directory vars contiene varie variabili e può contenere condizionalmente valori diversi per diversi sistemi operativi (caso d'uso molto comune).
È importante notare che Ansible è molto flessibile e puoi mettere qualsiasi cosa quasi ovunque. Questa è solo una possibile struttura che ha senso per me. Se guardi le strutture di directory degli altri, potresti vedere qualcosa di completamente diverso. Questo è assolutamente soddisfacente. Non essere allarmato. Ansible non è prescrittivo, sebbene fornisca indicazioni per le migliori pratiche.
I ruoli risolvono il problema, ma i playbook sono il modo in cui effettivamente lavori. I quaderni di gioco sposano l'inventario e i ruoli e specificano quali ruoli giocare su quale host. Ecco come appare un playbook con ruoli:
--- - host: tutti i ruoli: - ruoli / comuni
L'esecuzione del playbook produce il seguente output:
ansible-playbook -i ospita playbook_with_roles.yml --sudo PLAY ************************************* ************************************** TASK [setup] ******** ************************************************** ********* ok: [larry] ok: [moe] ok: [ricci] TASK [ruoli / comune: crea un utente chiamato gigi] ************** ******************* modificato: [ricci] modificato: [moe] modificato: [larry] TASK [ruoli / comune: Aggiungi chiave pubblica] ****** ************************************* modificato: [larry] modificato: [curly] changed: [ moe] TASK [ruoli / comune: copia il file .gigirc nella home directory del nuovo utente gigi] *** modificato: [moe] modificato: [larry] modificato: [curly] TASK [ruoli / comune: installa pacchetti comuni ] ********************************** modificato: [curly] => (item = [u'vim ' , u'htop ', u'tmux']) modificato: [moe] => (item = [u'vim ', u'htop', u'tmux ']) modificato: [larry] => (item = [ u'vim ', u'htop', u'tmux ']) PLAY RECAP ******************************** ************************************* Ricci: ok = 5 modificato = 4 un raggiungibile = 0 non riuscito = 0 larry: ok = 5 modificato = 4 non raggiungibile = 0 non riuscito = 0 moe: ok = 5 modificato = 4 non raggiungibile = 0 non riuscito = 0
Ansible è un ottimo strumento. È leggero Può essere utilizzato in modo interattivo con comandi ad-hoc e si adatta molto bene a sistemi di grandi dimensioni. Ha anche un sacco di slancio e una grande comunità. Se gestisci o anche solo lavori con server remoti, vuoi Ansible.
