265 votes

Comment voir le stdout des commandes ansible ?

Comment puis-je voir stdout pour les commandes ansible-playbook ? -v ne montre que la sortie ansible, pas les commandes individuelles. Ce serait génial si je pouvais comprendre comment faire cela immédiatement, ainsi si quelque chose échoue ou se bloque, je peux voir pourquoi.

par exemple

- name: print to stdout
  action: command echo "hello"

imprimerait

TASK: [print variable] ******************************************************** 

hello

0 votes

0 votes

253voto

istruble Points 5686

Je pense que vous pouvez enregistrer le résultat dans une variable, puis imprimer avec le débogage.

- name: print to stdout
  command: echo "hello"
  register: hello

- debug: msg="{{ hello.stdout }}"

- debug: msg="{{ hello.stderr }}"

33 votes

De plus, vous pouvez déboguer une variable directement avec - debug: var=hello . Parfois, cela s'avère plus utile pour les sorties multilignes ou les sorties de modules Ansible (plutôt que pour les sorties d'autres modules). command / shell sortie).

4 votes

J'ai eu du mal à obtenir une sortie Java en utilisant ceci. La solution consiste à rediriger toutes les sorties de Java vers stdout : shell: java -version 2>&1

35 votes

C'est beaucoup mieux que rien, mais vous n'obtenez que le message stdout après la commande s'est déroulée avec succès. J'avais un problème où ansible semblait se bloquer. La raison en était que j'utilisais le mauvais nom d'utilisateur pour une commande rsync, ce qui entraînait la demande de mot de passe interactif, ce qui bloquait ansible. Il était très difficile de déboguer - mais si je pouvais voir stdout en temps réel, j'aurais immédiatement réalisé ce que j'avais fait de mal. J'ADORERais cette fonctionnalité, si possible.

164voto

Mars Points 1561

Au lieu de stdout Je suggère d'utiliser stdout_lines . Pour une sortie multi-lignes, c'est beaucoup plus agréable, par ex.

- hosts: all
  tasks:
    - name: Run ls.sh and output "ls /"
      script: ls.sh
      register: out

    - debug: var=out.stdout_lines

donne

TASK: [debug var=out.stdout_lines] ******************************************** 
ok: [local] => {
    "var": {
        "out.stdout_lines": [
            "total 61", 
            "lrwxrwxrwx   1 root root     7 Feb 15  2015 bin -> usr/bin", 
            "drwxr-xr-x   6 root root  1024 Aug 24 22:08 boot", 
            "drwxr-xr-x  22 root root  3580 Sep  8 18:41 dev",  
            [...] 
            "drwxr-xr-x   9 root root  4096 Aug 25 19:14 usr", 
            "drwxr-xr-x  13 root root  4096 Feb 25  2015 var"
        ]
    }
}

En ce qui concerne la sortie en temps réel à des fins de débogage, il existe un rapport de bogue fermé. https://github.com/ansible/ansible/issues/3887#issuecomment-54672569 discuter des raisons pour lesquelles cela n'est pas possible et ne sera pas mis en œuvre.

26 votes

+1 pour le lien avec le bug de la "sortie en temps réel".

0 votes

Si je veux envoyer out.stdout_lines (comme corps de la tâche de courrier Ansible), comment puis-je l'envoyer de sorte qu'il ne ressemble PAS à ceci lorsque le courrier électronique est reçu ? [u'total 61', u'lrwxrwxrwx 1 root root 7 Feb 15 2015 bin -> usr/bin', u'drwxr-xr-x 6 root root 1024 Aug 24 22:08 boot', u'.....'] Je veux que cela ressemble à ceci, tel que vu sur le terminal

0 votes

Fatal : [127.0.0.1] : FAILED ! => {"reason" : "Erreur de syntaxe lors du chargement de YAML. \n n'a pas trouvé le <document start> attendu \n\nThe L'erreur semble être dans... un problème de syntaxe. \n\nThe La ligne incriminée semble être : \n\n\n - nom : Lancez ls.sh et affichez \"ls /\". \n Ici \n "}

33voto

Jason S Points 373

J'ai trouvé que l'utilisation du minimal stdout_callback avec ansible-playbook a donné un résultat similaire à l'utilisation d'ansible ad-hoc.

Dans votre ansible.cfg (Notez que je suis sur OS X, donc modifiez le fichier callback_plugins pour s'adapter à votre installation)

stdout_callback     = minimal
callback_plugins    = /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ansible/plugins/callback

Pour qu'une tâche telle que celle-ci

---
- hosts: example
  tasks:
   - name: Say hi
     command: echo "hi ..."

Donne une sortie comme celle-ci, comme le ferait une commande ad-hoc

example | SUCCESS | rc=0 >>
hi ...

J'utilise ansible-playbook 2.2.1.0.

0 votes

Joli plugin de callback, le post-traitement simple peut extraire la sortie standard seulement.

10voto

Faruz Points 3081

Si vous voulez vraiment regarder la sortie en temps réel, il y a un moyen détourné, au moins pour le ansible shell module.

Dans n'importe quel Shell Shell qui enveloppe votre appel à ansible, touchez et suivez un fichier journal dans une tâche de fond. Puis rediriger la sortie de la commande ansible Shell pour l'ajouter à ce fichier journal. Vous devez vous assurer de tuer le travail de queue en arrière-plan après la fin de ansible, ou il sera laissé en suspens.

Par exemple, dans un script bash qui appelle ansible :

set -m
touch /tmp/debug.log && tail -f /tmp/debug.log &
ansible-playbook ... call playbook here
kill %1   # ensure the background tail job is stopped

Puis dans un rôle ansible :

- name: Run a script and print stdout/stderr
  shell: bash -c "/run/something.sh 2>&1 >> /tmp/debug.log"

3 votes

Très intéressant et créatif. merci pour cet aperçu. il semble que je puisse appliquer cette technique à d'autres choses, ce qui est plutôt chouette.

3 votes

Honnêtement, c'est la seule réponse correcte ici...

1 votes

@MoatazElmasry J'ai eu le même problème avec Puppet bolt. Cela a fonctionné comme un charme.

2voto

dza Points 126

J'ai découvert que le simple fait de tuer un processus bloqué sur le site distant via ssh permet de récupérer le stdout. Je trouve que c'est plus court que d'écrire des solutions de contournement qui ne seront pas utilisées dans le playbook final de toute façon :

kill -9 PID

1 votes

Mais que se passe-t-il si le processus semble seulement se bloquer parce qu'ansible ne produit rien et qu'en fait il est en train de se dérouler ?

0 votes

Ouais, qu'est-ce qui est coincé si tu voles à l'aveuglette dans ce cas ? Imaginez un processus de construction CI qui prend normalement 5 heures et qui, alors que vous pensiez qu'il fonctionnait pendant 5 heures, était en fait simplement bloqué. C'est beaucoup de temps perdu.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X