È possibile eseguire comandi sull'host Ansible?
Il mio scenario è che voglio fare un checkout da un server git che è ospitato internamente (e non è accessibile al di fuori del firewall aziendale). Quindi voglio caricare il checkout (tarball) sul server di produzione (ospitato esternamente).
Al momento, sto cercando di eseguire uno script che esegue il checkout, lo archivia e quindi esegue lo script di distribuzione, ma se potessi integrarlo in Ansible sarebbe preferibile.
Risposte:
Sì, puoi eseguire comandi sull'host Ansible. È possibile specificare che tutte le attività in una riproduzione vengano eseguite sull'host Ansible oppure è possibile contrassegnare le singole attività da eseguire sull'host Ansible.
Se desideri eseguire un'intera riproduzione sull'host Ansible, specifica hosts: 127.0.0.1e connection:localnel gioco, ad esempio:
- name: a play that runs entirely on the ansible host
hosts: 127.0.0.1
connection: local
tasks:
- name: check out a git repository
git: repo=git://foosball.example.org/path/to/repo.git dest=/local/path
Vedi Playbook locali nella documentazione Ansible per maggiori dettagli.
Se desideri eseguire una singola attività sul tuo host Ansible, puoi utilizzare local_actionper specificare che un'attività deve essere eseguita localmente. Per esempio:
- name: an example playbook
hosts: webservers
tasks:
- ...
- name: check out a git repository
local_action: git repo=git://foosball.example.org/path/to/repo.git dest=/local/path
Vedere Delegazione nella documentazione Ansible per maggiori dettagli.
Modifica: puoi evitare di dover digitare il connection: localtuo gioco aggiungendo questo al tuo inventario:
localhost ansible_connection=local
(Qui useresti "localhost" invece di "127.0.0.1" per fare riferimento al gioco).
Modifica: nelle versioni più recenti di ansible, non è più necessario aggiungere la riga sopra al tuo inventario, ansible presume che sia già lì.
ansible-playbook -K playbook.ymldove -K per root
Ho trovato un paio di altri modi in cui puoi scrivere questi che sono un po 'più leggibili IMHO.
- name: check out a git repository
local_action:
module: git
repo: git://foosball.example.org/path/to/repo.git
dest: /local/path
O
- name: check out a git repository
local_action: git
args:
repo: git://foosball.example.org/path/to/repo.git
dest: /local/path
shellmodulo.
Vorrei condividere che Ansible può essere eseguito su localhost tramite shell:
ansible all -i "localhost," -c local -m shell -a 'echo hello world'
Questo potrebbe essere utile per compiti semplici o per l'apprendimento pratico di Ansible.
L'esempio di codice è tratto da questo buon articolo:
È possibile utilizzare delegate_toper eseguire comandi sul proprio host Ansible (host amministratore), da dove si esegue la riproduzione Ansible. Per esempio:
Elimina un file se esiste già sull'host Ansible:
- name: Remove file if already exists
file:
path: /tmp/logfile.log
state: absent
mode: "u+rw,g-wx,o-rwx"
delegate_to: 127.0.0.1
Crea un nuovo file sull'host Ansible:
- name: Create log file
file:
path: /tmp/logfile.log
state: touch
mode: "u+rw,g-wx,o-rwx"
delegate_to: 127.0.0.1
becomeè True per l'attività, si lamenterà di sudo e simili. Ciò potrebbe accadere direttamente sull'attività o essere ereditato altrove.
Espandendo la risposta di @gordon, ecco un esempio di sintassi leggibile e passaggio di argomenti con il modulo shell / comando (questi differiscono dal modulo git in quanto ci sono argomenti obbligatori ma in formato libero, come notato da @ander)
- nome: "viene generato il tarball di rilascio"
azione_locale:
modulo: shell
_raw_params: git archive --format zip --output release.zip HEAD
chdir: "file / cloni / webhook"
Dalla documentazione Ansible :
Delega Questo non è in realtà un aggiornamento in sequenza specifico, ma si presenta frequentemente in questi casi.
Se desideri eseguire un'attività su un host con riferimento ad altri host, utilizza la parola chiave "delegate_to" su un'attività. Questo è l'ideale per posizionare i nodi in un pool con bilanciamento del carico o per rimuoverli. È anche molto utile per controllare le finestre di interruzione. Tieni presente che non ha senso delegare tutte le attività, eseguire il debug, aggiungere_host, includere, ecc. Vengono sempre eseguiti sul controller. Anche usarlo con la parola chiave 'serial' per controllare il numero di host eseguiti contemporaneamente è una buona idea:
---
- hosts: webservers
serial: 5
tasks:
- name: take out of load balancer pool
command: /usr/bin/take_out_of_pool {{ inventory_hostname }}
delegate_to: 127.0.0.1
- name: actual steps would go here
yum:
name: acme-web-stack
state: latest
- name: add back to load balancer pool
command: /usr/bin/add_back_to_pool {{ inventory_hostname }}
delegate_to: 127.0.0.1
Questi comandi verranno eseguiti su 127.0.0.1, che è la macchina che esegue Ansible. C'è anche una sintassi abbreviata che puoi usare in base alle attività: 'local_action'. Ecco lo stesso playbook come sopra, ma usando la sintassi abbreviata per delegare a 127.0.0.1:
---
# ...
tasks:
- name: take out of load balancer pool
local_action: command /usr/bin/take_out_of_pool {{ inventory_hostname }}
# ...
- name: add back to load balancer pool
local_action: command /usr/bin/add_back_to_pool {{ inventory_hostname }}
Un modello comune consiste nell'usare un'azione locale per chiamare "rsync" per copiare in modo ricorsivo i file sui server gestiti. Ecco un esempio:
---
# ...
tasks:
- name: recursively copy files from management server to target
local_action: command rsync -a /path/to/files {{ inventory_hostname }}:/path/to/target/
Nota che devi avere chiavi SSH senza passphrase o un agente ssh configurato perché funzioni, altrimenti rsync dovrà chiedere una passphrase.
ansible your_server_name -i custom_inventory_file_name -m -a "uptime"
Il modulo predefinito è il modulo di comando, quindi la commandparola chiave non è richiesta.
Se è necessario eseguire qualsiasi comando con privilegi elevati, utilizzare -balla fine dello stesso comando.
ansible your_server_name -i custom_inventory_file_name -m -a "uptime" -b
puoi provare in questo modo
sudo: nonello scenario della delegazione