Listeninformationen

Hallo!

Vielen Dank für Ihr Interesse an Ansible. Es bedeutet uns aufrichtig viel.

Dies scheint eine Benutzerfrage zu sein, und wir möchten diese Art von Dingen entweder an die Mailingliste oder den IRC-Kanal weiterleiten.

• IRC: #ansible auf irc.freenode.net
• Mailingliste: https://groups.google.com/forum/#!forum/ansible -project

Wenn Sie dort vorbeischauen können, würden wir uns freuen. Dies ermöglicht es uns, den Issue Tracker für Bugs, Pull Requests, RFEs und dergleichen zu führen.

Nochmals vielen Dank und wir freuen uns, Sie auf der Liste oder im IRC zu sehen. Danke!

@bcoca Fehler mit Copy und Past zu schließen wird beim Aufbau von Community-Zielen helfen. Das ist ein gültiger Fehlerbericht, kein Aber.

Die Tatsache, dass ansible davon ausgeht, dass Python 2 auf /usr/bin/python installiert ist, ist ein Fehler, ein ziemlich kritischer.

@ssbarnea - tun hat , den Kopf abgeschlagen, seit ich localhost explizit zur Host-Datei hinzugefügt habe, um es in das Limit-Muster aufzunehmen.

https://www.zigg.com/2014/using-virtualenv-python-local-ansible.html hat eine anständige Lösung, die sowohl für Aktionen direkt mit hosts: localhost als auch für den Aufruf von local_action zu funktionieren scheint.

@ssbarnea @pauricthelodger Habt ihr immer noch Probleme damit?

Ich hatte gerade ein Playbook, das seit Monaten (Jahren) funktioniert, bei local_action: ec2_elb fehlgeschlagen, wenn eine Instanz bei ELB registriert und das Inventar von ec2.py .

Tritt bei mir auf, wenn ich unter MacOS mit Ansible 2.0.0.2, 2.0.1 und 2.1.0 laufe.

Ich habe die Zigg-Artikelempfehlungen noch nicht ausprobiert.

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 , arbeite immer noch damit in meiner Inventardatei:

[localhost]
localhost ansible_connection=local ansible_python_interpreter=python

Lass es mich wissen, wenn das etwas für dich bringt!

@pauricthelodger Ich kann bestätigen, dass dies bei mir auf den ansible-Versionen 2.0.0.2, 2.0.1 und 2.1.0 funktioniert hat. Danke noch einmal!

Gibt es einen Grund, warum dies geschlossen ist? Es ist immer noch ein Problem unter 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

Die Problemumgehung für die Inventardatei geht vorbei, ist aber immer noch ein Problem.

@rolette Ansible verwendet standardmäßig /usr/bin/python (nicht dasselbe wie /usr/local/bin/python ). Mein Rat - benutze virtualenv ( virtualenv .venv )

und Ihr localhost-Inventar: 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 Vielen Dank für eine weitere Problemumgehung, aber was ich suche, ist eine Lösung für Ansible, damit es unter OS X ordnungsgemäß funktioniert, anstatt dass jeder, der auf das Problem stößt, Zeit damit verbringen muss, eine Problemumgehung zu finden.

Es ist kein Workaround - so funktioniert Python. Sie müssen Ansible einfach mitteilen, wo sich Ihre ausführbare Python-Datei befindet, wenn Sie nicht den Standardspeicherort /usr/bin/python möchten.

negativer Ghostrider ... Seltsamerweise schafft es jedes andere Python-Programm, gut zu funktionieren, ohne dass eine Virtualenv erforderlich ist.

Hartkodierte Pfade zu ausführbaren Dateien brechen in vielen Umgebungen ab. Normalerweise sind es jedoch nicht ganze Plattformen wie dieser spezielle Fehler.

Seien wir richtig, der richtige Weg zum Aufrufen von Python ist über #!/usr/bin/env python und nicht über einen hartcodierten Pfad. Es gibt eine Ausnahme von dieser Regel, die Shell-Skripte von virtualenvs, bei denen es bevorzugt wird, einen vollständigen Pfad zu verwenden, anstatt env .

Unter MacOS, das das Standardsystem Python verwendet, wird die Umgebung zufällig in /usr/bin/python aber dies bedeutet nicht, dass wir im installierten Skript /usr/bin/python sehen sollten.

Eine Sache, die ich im Laufe der Zeit verwendet habe, war, die Shell-Skripte zu vermeiden und ansible als Modul aufzurufen.

@ssbarnea Einverstanden, außer dass #!/usr/bin/env python innerhalb von virtualenvs das Richtige tut, also immer noch kein Grund, den Pfad fest zu kodieren.

Erhielt den gleichen Fehler, wenn das Modul ec2_tag in Ansible verwendet wurde.

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

Spielbuch:

  - 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

Aber arbeite mit 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

Gleicher Fehler mit ec2_elb Tag:

  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 }}'

Ich bin mir nicht sicher, ob es verbunden ist, aber für den Fall, dass es den Leuten weiterhilft, habe ich gerade Folgendes im Entwicklungs-Changelog unter Ansible 2.3 bemerkt:

'ansible_playbook_python' hinzugefügt, das 'aktuelle ausführbare Python-Datei' enthält. Es kann in einigen Fällen leer sein, in denen Ansible nicht über die Standard-CLI aufgerufen wird (sys.executable-Beschränkung).

Wenn Sie einen Mac verwenden und andere Kopien von Python über Homebrew installiert haben, können Sie diese Befehle ausführen, um Boto auf dem System-Python zu installieren:

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

Dies löste das Problem. Danke schön!!

Ich verwende Arch Linux und standardmäßig scheint Python 3 zu sein, während Ansible standardmäßig Python 2 verwendet.
Also funktioniert die Lösung von python durch explizites python2 ersetze.
Danke.

Zusätzlich zu der Lösung von @rsanchez für das Szenario, in dem möglicherweise mehrere Python-Kopien auf Ihrem Mac vorhanden sind, besteht eine andere Möglichkeit darin, ansible über die Variable "ansible_python_interpreter" mitzuteilen, welche Python verwendet werden soll.

Angenommen, /usr/bin/python hat kein Boto in seinem Pfad und das Python unter /usr/local/bin/python (über Homebrew installiert) hat es ("import boto" funktioniert in der Repl). Sie können dann " ansible_python_interpreter= /usr/local/bin/python " in der Inventardatei

Außerdem stellen Sie es in der Befehlszeile mit der Option "

Ich hatte das gleiche Problem, aber mit netaddr .

Ansible verwendete eine absolut zufällige Python-Version, die auf meinem Computer installiert war:

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"
}

Ich habe dann einfach den /usr/local/opt/python/bin/python2.7 -m pip install netaddr Trick verwendet, um es zu installieren.

Ich frage mich, ob Python-Umgebungsvariablen wie PYTHON_HOME und PYTHON_PATH bei diesem Problem helfen würden, aber ich weiß nicht allzu viel darüber.

Als ich naiv einen Docker-Build für ansible 2.3.1.0 mit so etwas wie . gemacht habe

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

Ich habe den Fehler

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

Hm, interessant. Natürlich kann ich den Interpreter auf ein fest codiertes Ding einstellen oder eine andere Problemumgehung finden, aber es ist wichtig zu beachten, dass _keine anderen Python-Apps dieses Problem haben_. Es ist nur fair darauf hinzuweisen, dass die Art und Weise, wie Ansible die Aufgaben an Hosts ( sogar localhost ohne ssh ) verteilt, das Kopieren einer ausführbaren Python-Datei ist - aber dennoch sollte diese ausführbare Datei die Umgebungseinstellungen respektieren.

Um für eine Sekunde auf eine Seifenkiste zu steigen, ist die Unkenntnis der Standardpraxis ein wiederkehrendes Problem mit Ansible. Ich hatte so viele Herausforderungen bei der Verwendung der AWS-Module mit Sitzungstoken (für Rollenübernahme oder mfa-Authentifizierung), dass ich dazu neige, awscli für alles Mögliche zu verwenden. Die dumme Sache ist, wenn sie nur boto die Auflösung der Anmeldeinformationen übernehmen lassen würden, anstatt ihre eigene 2/3-Lösung zu injizieren, um sie weiterzugeben, hätten sie das Beste aus beiden Welten gehabt. Zugegeben, die lokalen Anmeldeinformationen wären von Remote-Hosts nicht verfügbar, aber 1) wenn sie keine eigenen Anmeldeinformationen hätten, was wäre dann der Sinn, die Aufgabe aus der Ferne auszuführen, da sie sowieso nur eine öffentliche API treffen würde und das? könnte in den meisten Fällen genauso gut lokal durchgeführt werden; und 2) wenn sie ihre eigenen Anmeldeinformationen haben, möchten Sie sie wahrscheinlich abholen. Nicht damit verbunden, aber ein weiteres Beispiel dafür, dass ansible Implementierer in Unkenntnis einer bewährten Vorgehensweise vorgehen, die sie hätten verfolgen können und hätten befolgen sollen. Für mich leicht zu sagen, ich versuche nicht, ansible zu implementieren :P

Als temporäre Lösung habe ich:

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

Ich habe Pip, Botocore und Boto3 in Python3 integriert, nicht die Mac OS-Standardeinstellung /usr/bin/python . Als richtige Lösung könnte ich versuchen, den ansible_python_interpreter als Umgebungsvariable festzulegen.

Gibt es einen Grund, warum dies geschlossen ist? Habe dieses Problem immer noch auf 2.5 devel.

Mein Workaround für die Nuklearoption bestand darin, die Ansible-Installation in meinen Site-Paketen zu hacken, weil ich nicht daran denken möchte, jedes Mal zusätzliche Vars zu übergeben. Sie dürfen zusammenzucken, mich nicht anschreien, gehen auf eigenes Risiko, keine ausdrückliche oder stillschweigende Garantie.

So finden Sie die Dateien:

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

So beheben Sie alle Python-Shebangs:

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

Ich war dabei auf einen Fehler gestoßen
fatal: [localhost]: FEHLGESCHLAGEN! => {"changed": false, "msg": "Boto für dieses Modul erforderlich"}
aber boto ist schon installiert
Also habe ich diesen Befehl verwendet (weil ich den Mac verwende)
sudo /usr/bin/python -m pip install boto
und ich habe eine weitere Zeile in env/hosts hinzugefügt
ansible_pyhton_interpreter=/usr/bin/python
also seine arbeit

Jeder kann vorschlagen, was der Grund für diese Fehlermeldung ist, ich hatte bereits boto installiert, warum ich diesen Befehl brauche
sudo /usr/bin/python -m pip install boto

@jawad486 , ich benutze auch einen Mac und habe es sich zur Gewohnheit gemacht, Ansible ausschließlich mit Docker zu betreiben. Es hat Probleme beim Auffinden von Modulen vollständig vermieden und es ermöglicht, jede Version von ansible, ob neu oder alt, gleichzeitig zuverlässig auszuführen. Ich kann das gleiche von keiner anderen Methode mit brew, virtualenv oder dem integrierten Python sagen. Ich mounte nach Bedarf in ~/.aws und ~/.ssh.

@jawad846 Lesen Sie die Beiträge zu diesem Thema noch einmal durch. Es ist ein Fehler. ansible codiert den Pfad zu Python falsch hart, anstatt ihn aus der Umgebung zu beziehen.

In ansible 2.5.1 besteht dieses Problem immer noch (unter Linux) und verschiedene Module verhalten sich unterschiedlich. Ich habe @pauricthelodger- Workaround mit der Einstellung ansible_python_interpreter=python in der Hosts-Datei verwendet. Dies führt dazu, dass ec2_vpc_net und ec2_vpc_subnet funktionieren, aber ec2_vpc_igw mit {"changed": false, "msg": "boto is required for this module"} fehlschlägt. Was seltsam komisch ist, da diese Module alle Teil desselben Sets sind und zusammen verwendet werden.

Als ich das genauer untersuchte, stellte ich fest, dass ec2_vpc_net und ec2_vpc_subnet Boto3 verwenden, aber ec2_vpc_igw Boto v2 verwenden. Daher müssen Sie sowohl boto3 als auch boto2 in Ihrer virtuellen Umgebung installieren. Dann habe ich alle Shebang-Header mit einer modifizierten Version des sed-Skripts von @benauthor gemunged . Ich habe es in meinem Makefile so eingerichtet, dass es nach dem Erstellen des Virtualpythons ausgeführt wird, also:

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"

Wobei vp der lokale virtualenv-Pfad ist, den ich verwende.

Auch bei 2.5.2 noch ein Problem

@timm088 Ich habe dieses Problem gerade in meinem MacBook behoben.
Führen Sie "welche Python" aus. Es sollte Ihnen den Pfad angeben, in meinem Fall war es "/usr/local/bin/python".
Gehen Sie dann zu Ihrer Inventardatei und fügen Sie diesen Pfad in ansible_python_interpreter ein.
So sieht meine Inventory-Hosts-Datei aus:
[lokal]
localhost ansible_connection=local ansible_python_interpreter=/usr/local/bin/python/

Es sollte jetzt funktionieren.

Ich gehe davon aus, dass die Ansible-Entwickler keine der laufenden Diskussionen gesehen haben, seit es 4 Tage nach dem Öffnen automatisch geschlossen wurde. Ich bin endlich dazu gekommen, eine Frage in die Mailingliste zu stellen, um zu sehen, ob wir das auf diese Weise beheben können.

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