Informations sur la liste

Salut!

Merci beaucoup de l'intérêt que vous portez à Ansible. Cela signifie sincèrement beaucoup pour nous.

Cela semble être une question d'utilisateur, et nous aimerions diriger ce genre de choses vers la liste de diffusion ou le canal IRC.

• IRC : #ansible sur irc.freenode.net
• liste de diffusion : https://groups.google.com/forum/#!forum/ansible -project

Si vous pouvez vous y arrêter, nous vous en serions reconnaissants. Cela nous permet de garder le suivi des problèmes pour les bogues, les demandes d'extraction, les RFE et autres.

Merci encore et au plaisir de vous voir sur la liste ou sur IRC. Merci!

@bcoca fermer les bogues avec copie et passé va aider à construire des objectifs de communauté. C'est un rapport de bogue valide, pas un mais.

Le fait qu'ansible suppose que python 2 est installé sur /usr/bin/python est un bogue, assez critique.

@ssbarnea - Je me suis aussi cogné la tête contre ce problème de nuisance pour tout ce qui concerne ec2 depuis que j'ai ajouté explicitement localhost au fichier hôte pour l'inclure dans le modèle de limite.

https://www.zigg.com/2014/using-virtualenv-python-local-ansible.html a une solution décente qui semble fonctionner à la fois pour les actions directement avec hosts: localhost ou en appelant local_action

@ssbarnea @pauricthelodger Avez-vous toujours des problèmes avec ça?

Je viens d'avoir un playbook qui a fonctionné pendant des mois (années) commence à échouer sur local_action: ec2_elb lors de l'enregistrement d'une instance avec ELB et de l'utilisation de l'inventaire ec2.py .

Cela se produit pour moi lors de l'exécution depuis MacOS avec Ansible 2.0.0.2, 2.0.1 et 2.1.0.

Je n'ai pas encore essayé les recommandations d'articles zigg.

TASK [AWS - Register instances with the load balancer] *************************
fatal: [10.x.x.x -> localhost]: FAILED! => {"changed": false, "failed": true, "msg": "boto required for this module"}

$ which python
/usr/local/bin/python

$ pip list boto | grep boto
boto (2.38.0)
boto3 (1.1.4)
botocore (1.2.10)

$ ansible --version
ansible 2.0.0.2

$ python -V
Python 2.7.9

@stevenscg , je travaille toujours avec ceci dans mon fichier d'inventaire :

[localhost]
localhost ansible_connection=local ansible_python_interpreter=python

Faites-moi savoir si cela fait quelque chose pour vous!

@pauricthelodger Je peux confirmer que cela a fonctionné pour moi sur les versions ansible 2.0.0.2, 2.0.1 et 2.1.0. Merci encore!

Une raison pour laquelle c'est fermé ? C'est toujours un problème sur OS X (Sierra) :

$ which python
/usr/local/bin/python

$ pip list boto | grep boto
boto (2.45.0)
botocore (1.5.1)

$ ansible --version
ansible 2.2.1.0

$ python -V
Python 2.7.12

La solution de contournement du fichier d'inventaire le dépasse, mais reste un problème.

@rolette Ansible utilise par défaut /usr/bin/python (pas la même chose que /usr/local/bin/python ). Mon conseil - utilisez virtualenv ( virtualenv .venv )

et votre inventaire localhost : inventory/localhost :

#!/bin/bash
ROOT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )/.."
echo "{
  \"localhost\": {
    \"ansible_connection\": \"local\",
    \"ansible_python_interpreter\": \"${ROOT_DIR}/.venv/bin/python\"
  }
}"

@wojtek-oledzki Merci pour une autre solution de contournement, mais ce que je recherche est un correctif pour ansible afin qu'il fonctionne correctement sur OS X au lieu d'exiger que tous ceux qui rencontrent le problème passent du temps à rechercher une solution de contournement.

ce n'est pas une solution de contournement - c'est ainsi que fonctionne python. Vous devez simplement indiquer à Ansible où se trouve votre exécutable python si vous ne souhaitez pas utiliser l'emplacement par défaut /usr/bin/python .

ghostrider négatif... Curieusement, tous les autres programmes python parviennent à fonctionner correctement sans nécessiter de virtualenv.

Les chemins de codage en dur vers les exécutables sont interrompus dans de nombreux environnements. Cependant, ce ne sont généralement pas des plates-formes entières comme ce bogue particulier.

Soyons corrects, la bonne façon d'appeler python est via #!/usr/bin/env python et non via un chemin codé en dur. Il y a une exception à cette règle, les scripts shell de virtualenvs où il est préférable d'avoir un chemin complet au lieu d'utiliser env .

Sur MacOS utilisant le système par défaut Python, l'env se résout en /usr/bin/python mais cela ne signifie pas que nous devrions voir /usr/bin/python dans le script installé.

Une chose que j'ai utilisée au fil du temps était d'éviter d'utiliser les scripts shell et d'appeler ansible en tant que module.

@ssbarnea D'accord, sauf que #!/usr/bin/env python fait ce qu'il faut dans virtualenvs, donc toujours aucune raison de coder en dur le chemin.

Vous avez la même erreur lorsque vous utilisez le module ec2_tag dans ansible.

TASK [Retrieve all tags on an instance] ****************************************
fatal: [10_12_26_12]: FAILED! => {"changed": false, "failed": true, "msg": "boto required for this module"}

livre de jeu :

  - name: Get instance ec2 facts
    action: ec2_facts
    register: ec2_facts

  - name: Retrieve all tags on an instance
    ec2_tag:
      region: '{{ ansible_ec2_placement_region }}'
      resource: '{{ ansible_ec2_instance_id }}'
      state: list
    register: ec2_tags

Mais travaillez avec local_action

  - name: Get instance ec2 facts
    action: ec2_facts
    register: ec2_facts

  - name: Get resource tags from ec2 facts
    #sudo: false
    local_action: ec2_tag resource={{ec2_facts.ansible_facts.ansible_ec2_instance_id}} region={{ec2_facts.ansible_facts.ansible_ec2_placement_region}} state=list
    register: ec2_tags

Même erreur avec la balise ec2_elb :

  pre_tasks:
    - name: Gathering ec2 facts
      action: ec2_facts
    - name: Trackor Instance de-register
      become: no
      local_action:
        module: ec2_elb
        region: "{{ ansible_ec2_placement_region }}"
        instance_id: "{{ ansible_ec2_instance_id }}"
        state: absent
        wait_timeout: 30
        ec2_elbs: '{{ trackor_elb_name }}'

Je ne suis pas sûr que ce soit connecté, mais au cas où cela aiderait les gens sur la route, je viens de remarquer ce qui suit dans le journal des modifications de développement sous Ansible 2.3 :

Ajout de 'ansible_playbook_python' qui contient 'current python exécutable', il peut être vide dans certains cas où Ansible n'est pas invoqué via la CLI standard (limitation sys.executable).

Si vous êtes sur Mac et que vous avez installé d'autres copies de python via homebrew, vous pouvez exécuter ces commandes pour installer boto sur le système python :

sudo /usr/bin/python -m easy_install pip
sudo /usr/bin/python -m pip install boto

Cela a résolu le problème. Merci!!

J'utilise Arch Linux et la valeur par défaut semble être python 3 tandis qu'Ansible semble utiliser python 2 par défaut.
Donc, la solution de @rsanchez fonctionne pour moi si je remplace python par python2 explicite.
Merci.

En plus de la solution de

Supposons que /usr/bin/python n'ait pas de boto dans son chemin et que le python de /usr/local/bin/python (installé via homebrew) l'ait ("import boto" fonctionne pendant le repl). Vous pouvez ensuite définir " ansible_python_interpreter= /usr/local/bin/python " dans le fichier d'inventaire.

Vous le définissez également sur la ligne de commande avec l' option "

J'avais le même problème, mais avec netaddr .

Ansible utilisait une version de python absolument aléatoire installée sur ma machine :

ansible all -i ./.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory -m debug -a "var=ansible_playbook_python"
elastic0 | SUCCESS => {
    "ansible_playbook_python": "/usr/local/opt/python/bin/python2.7"
}

J'ai ensuite utilisé l'astuce /usr/local/opt/python/bin/python2.7 -m pip install netaddr pour l'installer.

Je me demande si les variables d'environnement python telles que PYTHON_HOME et PYTHON_PATH aideraient ce problème, mais je n'en sais pas trop à leur sujet.

Quand j'ai naïvement fait un docker pour ansible 2.3.1.0 avec quelque chose comme

FROM python:2.17
RUN pip install --upgrade pip
RUN pip install boto3 botocore ansible>=2.3.1.0 awscli

j'ai l'erreur

fatal: [127.0.0.1]: FAILED! => {"changed": false, "failed": true, "msg": "boto3 and botocore are required for this module"}

Euh, intéressant. Bien sûr, je peux définir l'interpréteur sur une chose codée en dur, ou trouver une autre solution de contournement, mais il est important de noter, comme dit précédemment, qu'aucune autre application Python n'a ce problème. Il est juste de souligner que la façon dont ansible rassemble les tâches vers les hôtes (même localhost sans ssh) consiste à copier un exécutable python - mais néanmoins, cet exécutable doit respecter les paramètres de l'environnement.

Se lever une seconde sur une caisse à savon, la méconnaissance des pratiques standard est un problème récurrent avec ansible. J'ai eu tellement de problèmes avec l'utilisation des modules AWS avec des jetons de session (pour l'hypothèse de rôle ou l'authentification mfa) que j'ai tendance à utiliser awscli pour tout ce qui est possible. Ce qui est idiot, c'est que s'ils avaient simplement laissé boto gérer la résolution des informations d'identification au lieu d'injecter leur propre solution aux 2/3 de les transmettre, ils auraient eu le meilleur des deux mondes. Certes, les informations d'identification locales ne seraient pas disponibles à partir d'hôtes distants, mais 1) s'ils n'avaient pas leurs propres informations d'identification, quel serait l'intérêt d'exécuter la tâche à distance de toute façon, car cela n'atteindrait de toute façon qu'une API publique et que pourrait tout aussi bien être fait localement dans la plupart des cas ; et 2) s'ils avaient leurs propres informations d'identification, vous voudriez probablement les récupérer. Sans rapport, mais un autre exemple de mise en œuvre ansible procédant dans l'ignorance d'une meilleure pratique qu'ils auraient pu et auraient dû suivre. Facile pour moi à dire, je n'essaie pas d'implémenter ansible :P

En tant que correctif temporaire, j'ai fait :

[local]
localhost              ansible_connection=local     ansible_python_interpreter=/usr/local/bin/python3

J'ai pip, botocore et boto3 intégrés à python3, pas la valeur par défaut /usr/bin/python Mac OS

Une raison pour laquelle c'est fermé ? Toujours avec ce problème au niveau 2.5.

Ma solution de contournement pour l'option nucléaire consistait à pirater l'installation ansible dans mes packages de site, car je ne veux pas me souvenir de passer des vars supplémentaires à chaque fois. Vous pouvez grimacer, ne me criez pas dessus, procédez à vos risques et périls, sans aucune garantie expresse ou implicite.

Pour trouver les fichiers :

python -c "import ansible; print ansible.__path__"

Pour réparer tous les shebangs python :

 grep -lir "/usr/bin/python" /path/to/my/site-packages/ansible/* | xargs sed -i '' "s|/usr/bin/python|/usr/bin/env python|g"

J'avais rencontré une erreur en faisant cela
fatal : [localhost] : ÉCHEC ! => {"changé": false, "msg": "boto requis pour ce module"}
mais boto est déjà installé
j'ai donc utilisé cette commande (parce que j'utilise le mac)
sudo /usr/bin/python -m pip install boto
et j'ai ajouté une ligne de plus dans env/hosts
ansible_pyhton_interpreter=/usr/bin/python
donc son travail

n'importe qui peut suggérer quelle est la raison de cette erreur, j'avais déjà installé boto alors pourquoi j'ai besoin de cette commande
sudo /usr/bin/python -m pip install boto

@jawad486 , j'utilise également un Mac et j'ai pris l'habitude d'exécuter ansible exclusivement avec docker. Il a complètement évité les problèmes de recherche de modules et a permis d'exécuter de manière fiable n'importe quelle version d'ansible , nouvelle ou ancienne, simultanément. Je ne peux pas en dire autant de toute autre méthode avec brew, virtualenv ou le Python intégré. Je monte dans ~/.aws et ~/.ssh si nécessaire.

@jawad846 Relisez les articles sur ce problème. C'est un bug. ansible code de manière incorrecte le chemin d'accès à python au lieu de l'obtenir à partir de l'environnement.

Dans ansible 2.5.1, ce problème persiste (sous Linux) et différents modules se comportent différemment. J'ai utilisé la solution de contournement @pauricthelodger avec le ansible_python_interpreter=python dans le fichier hosts. Cela fait fonctionner ec2_vpc_net et ec2_vpc_subnet, mais ec2_vpc_igw échoue avec {"changed": false, "msg": "boto is required for this module"} . Ce qui est étrangement drôle car ces modules font tous partie du même ensemble et sont utilisés ensemble.

En creusant cela, j'ai découvert que ec2_vpc_net et ec2_vpc_subnet utilisent boto3, mais ec2_vpc_igw utilise boto v2. Ainsi, vous devrez installer dans votre virtualenv DEUX boto3 et boto2. Ensuite, j'ai modifié tous les en-têtes shebang avec une version modifiée du script sed de @benauthor . Je l'ai configuré dans mon Makefile pour qu'il s'exécute après la construction du virtualpython, ainsi :

grep -lir "/usr/bin/python" vp/local/lib/python2.7/site-packages/ansible/* | xargs sed -i "s@/usr/bin/python@/usr/bin/env python@g"

Où vp est le chemin virtualenv local que j'utilise.

Toujours un problème sur 2.5.2 également

@timm088 Je viens de
exécutez "quel python". il devrait vous fournir le chemin, dans mon cas c'était "/usr/local/bin/python".
Ensuite, accédez à votre fichier d'inventaire, collez ce chemin dans ansible_python_interpreter.
Voici à quoi ressemble mon fichier d'hôtes d'inventaire :
[local]
localhost ansible_connection=local ansible_python_interpreter=/usr/local/bin/python/

Cela devrait fonctionner maintenant.

Je suppose que les développeurs d'Ansible n'ont vu aucune des discussions en cours depuis sa fermeture automatique 4 jours après son ouverture. J'ai finalement eu le temps de poster une question sur la liste de diffusion pour voir si nous pouvions la résoudre de cette façon.

https://groups.google.com/forum/#!topic/ansible-project/WCqmyKB46qQ