Información de lista

¡Hola!

Muchas gracias por su interés en Ansible. Sinceramente, significa mucho para nosotros.

Esta parece ser una pregunta de usuario y nos gustaría dirigir este tipo de cosas a la lista de correo o al canal de IRC.

• IRC: #ansible en irc.freenode.net
• lista de correo: https://groups.google.com/forum/#!forum/ansible -project

Si puede pasar por allí, se lo agradeceríamos. Esto nos permite mantener el rastreador de problemas para errores, solicitudes de extracción, RFE y similares.

Gracias una vez más y esperamos verte en la lista o en el IRC. ¡Gracias!

@bcoca cerrar errores con copia y pasado ayudará a construir metas comunitarias. Ese es un informe de error válido, no un pero.

El hecho de que ansible asuma que Python 2 está instalado en /usr/bin/python es un error, bastante crítico.

@ssbarnea -

https://www.zigg.com/2014/using-virtualenv-python-local-ansible.html tiene una solución decente que parece estar funcionando tanto para acciones directamente con hosts: localhost como para llamar a local_action

@ssbarnea @pauricthelodger ¿Todavía tienen problemas con esto?

Acabo de tener un libro de jugadas que ha funcionado durante meses (años) y comenzó a fallar en local_action: ec2_elb al registrar una instancia con ELB y usar el inventario ec2.py .

Me pasa cuando ejecuto desde MacOS con Ansible 2.0.0.2, 2.0.1 y 2.1.0.

Todavía no he probado las recomendaciones del artículo de 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 , todavía me trabaja con esto en mi archivo de inventario:

[localhost]
localhost ansible_connection=local ansible_python_interpreter=python

¡Avísame si eso te ayuda!

@pauricthelodger Puedo confirmar que esto funcionó para mí en las versiones ansible 2.0.0.2, 2.0.1 y 2.1.0. ¡Gracias de nuevo!

¿Alguna razón por la que esto está cerrado? Sigue siendo un problema en 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 solución alternativa del archivo de inventario lo supera, pero sigue siendo un problema.

@rolette Ansible usa el valor predeterminado /usr/bin/python (no es lo mismo que /usr/local/bin/python ). Mi consejo: use virtualenv ( virtualenv .venv )

y su inventario de 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 Gracias por otra solución alternativa, pero lo que estoy buscando es una solución para ansible para que funcione correctamente en OS X en lugar de requerir que todos los que se encuentren con el problema dediquen tiempo a buscar una solución.

no es una solución alternativa, es cómo funciona Python. Simplemente tiene que decirle a Ansible dónde está su ejecutable de Python si no desea usar la ubicación predeterminada /usr/bin/python .

ghostrider negativo ... Curiosamente, todos los demás programas de Python se las arreglan para funcionar bien sin requerir un virtualenv.

Las rutas de codificación rígida a los ejecutables se rompen en muchos entornos. Sin embargo, por lo general, no se trata de plataformas completas como este error en particular.

Seamos correctos, la forma correcta de llamar a Python es a través de #!/usr/bin/env python y no a través de una ruta codificada. Hay una excepción a esta regla, los scripts de shell de virtualenvs donde se prefiere tener una ruta completa en lugar de usar env .

En MacOS utilizando el sistema por defecto de Python env pasa a resolución de /usr/bin/python pero esto no quiere decir que debemos ver /usr/bin/python en el guión instalado.

Una cosa que usé con el tiempo fue evitar usar los scripts de shell y llamar a ansible como módulo.

@ssbarnea De acuerdo, excepto que #!/usr/bin/env python hace lo correcto dentro de virtualenvs, por lo que todavía no hay razón para codificar la ruta.

Obtuve el mismo error al usar el módulo ec2_tag en ansible.

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

libro de jugadas:

  - 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

Pero trabaja con 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

Mismo error con la etiqueta 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 }}'

No estoy seguro de que esté conectado pero, en caso de que ayude a las personas en el futuro, acabo de notar lo siguiente en el registro de cambios de desarrollo en Ansible 2.3:

Se agregó 'ansible_playbook_python' que contiene 'ejecutable python actual', puede estar en blanco en algunos casos en los que Ansible no se invoca a través de la CLI estándar (limitación sys.executable).

Si está en Mac y ha instalado otras copias de Python a través de Homebrew, puede ejecutar estos comandos para instalar boto en el sistema Python:

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

Esto resolvió el problema. ¡¡Gracias!!

Estoy usando Arch Linux y el valor predeterminado parece ser Python 3, mientras que Ansible parece estar usando Python 2 de forma predeterminada.
Entonces, la solución de @rsanchez me funciona si reemplazo python con python2 explícitos.
Gracias.

Además de la solución de @rsanchez al escenario donde podría haber múltiples copias de python en tu mac, otra forma es decirle a ansible qué python usar a través de la variable "ansible_python_interpreter".

Supongamos que / usr / bin / python no tiene boto en su ruta y el python en / usr / local / bin / python (instalado a través de homebrew) lo tiene ("import boto" funciona mientras está en la réplica). Luego puede configurar " ansible_python_interpreter = / usr / local / bin / python " en el archivo de inventario.

También lo configura en la línea de comando con la opción "

Estaba teniendo el mismo problema, pero con netaddr .

Ansible estaba usando una versión de Python absolutamente aleatoria instalada en mi máquina:

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

Luego utilicé el truco /usr/local/opt/python/bin/python2.7 -m pip install netaddr para instalarlo.

Me pregunto si las variables de entorno de Python como PYTHON_HOME y PYTHON_PATH ayudarían con este problema, pero no sé demasiado sobre ellas.

Cuando ingenuamente hice una compilación de Docker para ansible 2.3.1.0 con algo como

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

Tengo el error

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

Eh, interesante. Por supuesto, puedo configurar el intérprete para algo codificado de forma rígida, o encontrar alguna otra solución alternativa, pero es importante tener en cuenta, como se dijo antes, que _ ninguna otra aplicación de Python tiene este problema_. Es justo señalar que la forma en que ansible ordena las tareas a los hosts (incluso localhost sin ssh) es copiando un ejecutable de Python, pero, sin embargo, ese ejecutable debe respetar la configuración del entorno.

Para levantarse en una tribuna por un segundo, la ignorancia de la práctica estándar es un problema recurrente con ansible. He tenido tantos desafíos con el uso de los módulos de AWS con tokens de sesión (para asumir roles o autenticación de mfa) que tiendo a usar awscli para todo lo posible. Lo tonto es que si hubieran dejado que boto manejara la resolución de credenciales en lugar de inyectar su propia solución 2/3 de pasarlas, habrían tenido lo mejor de ambos mundos. Por supuesto, las credenciales locales no estarían disponibles desde hosts remotos, pero 1) si no tuvieran sus propias credenciales, ¿cuál sería el punto de ejecutar la tarea de forma remota de todos modos, ya que de todos modos solo llegaría a una API pública y eso? en la mayoría de los casos, podría hacerse con la misma facilidad a nivel local; y 2) si tuvieran sus propias credenciales, probablemente querrá recogerlas. No relacionado, pero otro ejemplo de los implementadores de ansible procediendo en ignorancia de una mejor práctica que podrían haber seguido y deberían haber seguido. Es fácil para mí decirlo, no estoy tratando de implementar ansible: P

Como solución temporal lo hice:

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

Tengo pip, botocore y boto3 integrados en python3, no el predeterminado de Mac OS /usr/bin/python . Como solución adecuada, podría intentar configurar ansible_python_interpreter como una variable de entorno.

¿Alguna razón por la que esto está cerrado? Todavía tengo este problema en 2.5 devel.

Mi solución alternativa de opción nuclear fue piratear la instalación ansible en los paquetes de mi sitio, porque no quiero recordar pasar vars adicionales cada vez. Puede hacer una mueca de dolor, no me grite, proceda bajo su propio riesgo, sin garantía expresa o implícita.

Para encontrar los archivos:

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

Para arreglar todos los shebangs de Python:

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

Me había enfrentado a algún error al hacer esto
fatal: [localhost]: ¡FALLÓ! => {"cambiado": falso, "msg": "se requiere boto para este módulo"}
pero boto ya está instalado
así que usé este comando (porque estoy usando la mac)
sudo / usr / bin / python -m pip install boto
y agregué una línea más en env / hosts
ansible_pyhton_interpreter = / usr / bin / python
entonces su trabajo

cualquiera puede sugerir cuál es la razón por la que aparece este error, ya lo había instalado boto entonces por qué necesito este comando
sudo / usr / bin / python -m pip install boto

@ jawad486 , también uso una Mac y he hecho una práctica para ejecutar ansible exclusivamente con Docker. Ha evitado por completo problemas con la búsqueda de módulos y ha hecho posible la ejecución confiable de cualquier versión de ansible, nueva o antigua, simultáneamente. No puedo decir lo mismo de ningún otro método con brew, virtualenv o el Python incorporado. Monto en ~ / .aws y ~ / .ssh según sea necesario.

@ jawad846 Vuelve a leer las publicaciones sobre este tema. Es un error. ansible codifica incorrectamente la ruta a Python en lugar de obtenerla del entorno.

En ansible 2.5.1 este problema aún persiste (en Linux) y los diferentes módulos se comportan de manera diferente. He usado la solución alternativa de @pauricthelodger con la ansible_python_interpreter=python en el archivo de hosts. Esto hace que ec2_vpc_net y ec2_vpc_subnet funcionen, pero ec2_vpc_igw falle con {"changed": false, "msg": "boto is required for this module"} . Lo cual es extrañamente divertido porque todos estos módulos son parte del mismo conjunto y se usan juntos.

Profundizando en esto, encontré que ec2_vpc_net y ec2_vpc_subnet usan boto3, pero ec2_vpc_igw usan boto v2. Por lo tanto, deberá instalar en su virtualenv AMBOS boto3 y boto2. Luego modifiqué todos los encabezados shebang con una versión modificada del script sed de

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"

Donde vp es la ruta virtualenv local que estoy usando.

Sigue siendo un problema en 2.5.2 también

@ timm088 Acabo de solucionar ese problema en mi macbook.
ejecutar "qué pitón". debería proporcionarle la ruta, en mi caso era "/ usr / local / bin / python".
Luego vaya a su archivo de inventario, pegue esa ruta en ansible_python_interpreter.
Así es como se ve mi archivo de hosts de inventario:
[local]
localhost ansible_connection = local ansible_python_interpreter = / usr / local / bin / python /

Debería funcionar ahora.

Supongo que los desarrolladores de Ansible no han visto ninguna de las discusiones en curso ya que se cerró automáticamente 4 días después de su apertura. Finalmente pude publicar una pregunta en la lista de correo para ver si podemos solucionarlo de esa manera.

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