معلومات القائمة

مرحبا!

شكرا جزيلا لاهتمامك في أنسيبل. إنه يعني الكثير بالنسبة لنا بصدق.

يبدو أن هذا سؤال مستخدم ، ونود توجيه هذه الأنواع من الأشياء إما إلى القائمة البريدية أو قناة IRC.

• IRC: #ansible على irc.freenode.net
• القائمة البريدية: https://groups.google.com/forum/#!forum/ansible -project

إذا كان بإمكانك التوقف عند هذا الحد ، فنحن نقدر ذلك. يتيح لنا ذلك الاحتفاظ بمتعقب المشكلات بحثًا عن الأخطاء وطلبات السحب و RFEs وما شابه ذلك.

شكرًا لك مرة أخرى ونتطلع إلى رؤيتك في القائمة أو IRC. شكرا!

bcoca إغلاق الأخطاء مع النسخ والماضي سيساعد في بناء أهداف المجتمع. هذا تقرير خطأ صالح ، ليس ولكن.

حقيقة أن ansible تفترض أن python 2 تم تثبيته على /usr/bin/python هو خطأ ، وهو خطأ بالغ الأهمية.

ssbarnea -

https://www.zigg.com/2014/using-virtualenv-python-local-ansible.html لديه حل لائق يبدو أنه يعمل على حد سواء للإجراءات مباشرة مع hosts: localhost أو الاتصال local_action

ssbarneapauricthelodger هل ما تواجهون مشاكل مع هذا يا رفاق؟

لقد كان لدي للتو كتاب لعب عمل لأشهر (سنوات) بدأ بالفشل على local_action: ec2_elb عند تسجيل مثيل مع ELB واستخدام مخزون ec2.py .

يحدث لي عند التشغيل من MacOS مع Ansible 2.0.0.2 و 2.0.1 و 2.1.0.

لم أجرب توصيات مقالة 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 ، ما زلت أعمل مع هذا في ملف الجرد الخاص بي:

[localhost]
localhost ansible_connection=local ansible_python_interpreter=python

اسمحوا لي أن أعرف إذا كان هذا يفعل أي شيء لك!

pauricthelodger يمكنني أن أؤكد أن هذا نجح بالنسبة لي على الإصدارات 2.0.0.2 و 2.0.1 و 2.1.0. شكرا لك مرة أخرى!

أي سبب هذا مغلق؟ لا تزال مشكلة في 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

تجاوز ملف الجرد الحل البديل ، لكنه لا يزال يمثل مشكلة.

يستخدم rolette Ansible الافتراضي /usr/bin/python (ليس مثل /usr/local/bin/python ). نصيحتي - استخدم virtualenv ( virtualenv .venv )

ومخزون المضيف المحلي الخاص بك: 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 شكرًا لك على حل آخر ، ولكن ما أبحث عنه هو إصلاح غير قابل للكسر ، لذا فهو يعمل بشكل صحيح على OS X بدلاً من مطالبة كل شخص يواجه المشكلة بقضاء بعض الوقت في تعقب حل بديل.

إنها ليست حلاً - إنها طريقة عمل بايثون. عليك ببساطة إخبار Ansible بمكان ملف Python القابل للتنفيذ إذا كنت لا تريد استخدام الموقع الافتراضي /usr/bin/python .

الشبح السلبي ... الغريب أن كل برنامج بيثون آخر يدير العمل بشكل جيد دون الحاجة إلى Virtualenv.

تتكسر مسارات الترميز الثابت للملفات التنفيذية في العديد من البيئات. عادةً لا تكون منصات كاملة مثل هذا الخطأ المعين.

لنكن على صواب ، الطريقة الصحيحة لاستدعاء Python هي عبر #!/usr/bin/env python وليس عبر مسار ثابت. هناك استثناء واحد لهذه القاعدة ، البرامج النصية shell من virtualenvs حيث يفضل أن يكون لها مسار كامل بدلاً من استخدام env .

في نظام التشغيل MacOS باستخدام النظام الافتراضي Python ، يحدث env للتصحيح إلى /usr/bin/python لكن هذا لا يعني أننا يجب أن نرى /usr/bin/python في البرنامج النصي المثبت.

أحد الأشياء التي استخدمتها بمرور الوقت هو تجنب استخدام البرامج النصية للقذيفة واستدعاء ansible كوحدة نمطية.

ssbarnea متفق عليه ، باستثناء أن #!/usr/bin/env python يقوم بالشيء الصحيح داخل virtualenvs ، لذلك لا يوجد سبب لتشفير المسار بشكل ثابت.

حصلت على نفس الخطأ عند استخدام وحدة ec2_tag في غير صالح.

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

كتاب اللعب:

  - 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

لكن العمل مع 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

نفس الخطأ في علامة 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 }}'

لست متأكدًا من أنه متصل ، ولكن في حالة أنه يساعد الأشخاص على الطريق ، فقد لاحظت ما يلي في تغيير التطور تحت Ansible 2.3:

تمت إضافة "ansible_playbook_python" الذي يحتوي على "ملف Python الحالي القابل للتنفيذ" ، ويمكن أن يكون فارغًا في بعض الحالات التي لا يتم فيها استدعاء Ansible عبر CLI القياسي (قيود sys.executable).

إذا كنت تستخدم نظام Mac وقمت بتثبيت نسخ أخرى من python عبر homebrew ، فيمكنك تشغيل هذه الأوامر لتثبيت boto على نظام python:

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

هذا حل المشكلة. شكرا لك!!

أنا أستخدم Arch Linux ويبدو أن الإصدار الافتراضي هو python 3 بينما يبدو أن Ansible يستخدم python 2 افتراضيًا.
لذا فإن حل rsanchez يعمل بالنسبة لي إذا استبدلت python بـ python2 .
شكرا.

بالإضافة إلى حل rsanchez للسيناريو حيث قد يكون هناك نسخ متعددة من python على جهاز mac الخاص بك ، هناك طريقة أخرى تتمثل في إخبار ansible عن python الذي يجب استخدامه عبر المتغير "ansible_python_interpreter".

لنفترض أن / usr / bin / python لا يحتوي على boto في مساره وأن لغة python في / usr / local / bin / python (مثبتة عبر homebrew) تحتوي عليها (يعمل "استيراد boto" أثناء إجراء الرد). يمكنك بعد ذلك تعيين " ansible_python_interpreter = / usr / local / bin / python " في ملف الجرد.

كما يمكنك تعيينه في سطر الأوامر باستخدام الخيار " --extra-vars = 'ansible_python_interpreter = / usr / local / bin / python' ".

كنت أواجه نفس المشكلة ، ولكن مع netaddr .

كان Ansible يستخدم بعض إصدارات python العشوائية تمامًا المثبتة على جهازي:

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

ثم استخدمت خدعة /usr/local/opt/python/bin/python2.7 -m pip install netaddr لتثبيته.

أتساءل عما إذا كانت متغيرات بيئة Python مثل PYTHON_HOME و PYTHON_PATH ستساعد في هذه المشكلة ، لكني لا أعرف الكثير عنها.

عندما فعلت بسذاجة عامل بناء ل 2.3.1.0 ansible مع شيء مثل

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

حصلت على الخطأ

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

هاه ، مثير للاهتمام. بالطبع يمكنني تعيين المترجم الفوري على بعض الأشياء المشفرة ، أو العثور على حل بديل آخر ، ولكن من المهم أن نلاحظ كما قيل من قبل أنه لا توجد تطبيقات أخرى للبيثون بها هذه المشكلة. من العدل فقط الإشارة إلى أن الطريقة التي ينظم بها التنظيم المهام إلى المضيفين (حتى المضيف المحلي بدون ssh) هي نسخ ملف تنفيذي من نوع python - ولكن مع ذلك ، يجب أن يحترم هذا الملف القابل للتنفيذ إعدادات البيئة.

للاستيقاظ على صندوق الصابون للحظة ، فإن الجهل بالممارسة القياسية يمثل مشكلة متكررة مع عدم القدرة على التحمل. لقد واجهت الكثير من التحديات في استخدام وحدات AWS النمطية مع الرموز المميزة للجلسة (لتولي الدور أو مصادقة mfa) لدرجة أنني أميل إلى استخدام awscli لكل شيء ممكن. الشيء السخيف هو ، لو سمحوا لـ boto بالتعامل مع دقة بيانات الاعتماد بدلاً من حقن حل 2/3 الخاص بهم لتمريرها ، لكانوا قد حصلوا على أفضل ما في العالمين. منحت ، لن تكون بيانات الاعتماد المحلية متاحة من المضيفين البعيدين ، ولكن 1) إذا لم يكن لديهم بيانات الاعتماد الخاصة بهم ، فما الهدف من تشغيل المهمة عن بُعد على أي حال ، حيث إنها ستصيب فقط واجهة برمجة تطبيقات عامة على أي حال وهذا يمكن القيام به محليًا بنفس السهولة في معظم الحالات ؛ و 2) إذا كان لديهم أوراق اعتماد خاصة بهم ، فربما ترغب في الحصول عليها. غير ذي صلة ، ولكن هناك مثال آخر على المنفذين الجديرين الذين يتقدمون في جهل أفضل ممارسة كان من الممكن أن يتبعوها وكان ينبغي عليهم اتباعها. من السهل بالنسبة لي أن أقول ، أنا لا أحاول تنفيذ غير مرغوب فيه: P

كإصلاح مؤقت قمت بما يلي:

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

لدي pip و botocore و boto3 مدمجين في python3 ، وليس نظام التشغيل Mac الافتراضي /usr/bin/python . كإصلاح مناسب ، قد أحاول تعيين ansible_python_interpreter كمتغير بيئة.

أي سبب لإغلاق هذا؟ لا تزال تواجه هذه المشكلة على 2.5 devel.

كان حل الخيار النووي الخاص بي هو اختراق التثبيت غير السليم في حزم الموقع ، لأنني لا أريد أن أتذكر تمرير متغيرات إضافية في كل مرة. قد تجفل ، لا تصرخ في وجهي ، والمضي قدمًا على مسؤوليتك الخاصة ، دون أي ضمان صريح أو ضمني.

للعثور على الملفات:

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

لإصلاح جميع أنواع الثعبان:

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

لقد واجهت بعض الخطأ من خلال القيام بذلك
قاتل: [المضيف المحلي]: فشل! => {"تم التغيير": خطأ ، "msg": "boto مطلوب لهذه الوحدة"}
لكن boto مثبتة بالفعل
لذلك استخدمت هذا الأمر (لأنني أستخدم نظام التشغيل mac)
sudo / usr / bin / python -m pip install boto
وأضفت سطرًا آخر في env / hosts
ansible_pyhton_interpreter = / usr / bin / python
لذلك عملها

يمكن لأي شخص أن يقترح سبب الحصول على هذا الخطأ ، لقد قمت بالفعل بتثبيت boto ، فلماذا أحتاج إلى هذا الأمر
sudo / usr / bin / python -m pip install boto

@ jawad486 ، أنا أستخدم جهاز Mac أيضًا وجعلته ممارسة لتشغيل ansible حصريًا مع عامل الإرساء. لقد تجنب تمامًا المشكلات المتعلقة بالعثور على وحدات نمطية وأتاح إمكانية التشغيل الموثوق به لأي إصدار غير مرئي ، جديد أو قديم ، في وقت واحد. لا يمكنني قول الشيء نفسه عن أي طريقة أخرى مع brew أو virtualenv أو لغة Python المدمجة. أقوم بالتركيب في ~ / .aws و ~ / .ssh حسب الضرورة.

@ jawad846 اقرأ مرة أخرى من خلال المشاركات حول هذه المسألة. إنه خطأ. ansible بشكل غير صحيح يقوم بترميز المسار إلى Python بدلاً من الحصول عليه من البيئة.

في 2.5.1 لا تزال هذه المشكلة قائمة (على لينكس) ، والوحدات المختلفة تتصرف بشكل مختلف. لقد استخدمت pauricthelodger الحل البديل مع إعداد ansible_python_interpreter=python في ملف المضيفين. يتسبب هذا في عمل ec2_vpc_net و ec2_vpc_subnet ، لكن فشل ec2_vpc_igw مع {"changed": false, "msg": "boto is required for this module"} . وهو أمر مضحك بشكل غريب لأن هذه الوحدات كلها جزء من نفس المجموعة وتستخدم معًا.

عند البحث في هذا ، وجدت أن ec2_vpc_net و ec2_vpc_subnet يستخدمان boto3 ، لكن ec2_vpc_igw يستخدمان boto v2. وبالتالي سوف تحتاج إلى تثبيت كل من boto3 و boto2 في virtualenv. ثم قمت بدمج جميع رؤوس shebang بنسخة معدلة من نصbenauthor s sed. قمت بإعداده في ملف Makefile الخاص بي ليتم تشغيله بعد إنشاء Virtualpython ، وبالتالي:

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"

حيث vp هو مسار virtualenv المحلي الذي أستخدمه.

لا تزال مشكلة في 2.5.2 أيضًا

@ timm088 لقد
تشغيل "أي بيثون". يجب أن يوفر لك المسار ، في حالتي كان "/ usr / local / bin / python".
ثم انتقل إلى ملف الجرد الخاص بك ، الصق هذا المسار في ansible_python_interpreter.
هكذا يبدو ملف مضيفي المخزون:
[محلي]
localhost ansible_connection = local ansible_python_interpreter = / usr / local / bin / python /

يجب أن تعمل الآن.

أفترض أن مطوري Ansible لم يروا أيًا من المناقشات الجارية منذ أن تم إغلاقه تلقائيًا بعد 4 أيام من افتتاحه. لقد تمكنت أخيرًا من نشر سؤال في القائمة البريدية لمعرفة ما إذا كان بإمكاننا إصلاحه بهذه الطريقة.

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