Informações da lista

Oi!

Muito obrigado pelo seu interesse no Ansible. Sinceramente, significa muito para nós.

Esta parece ser uma pergunta do usuário, e gostaríamos de direcionar esse tipo de coisa para a lista de discussão ou para o canal IRC.

• IRC: #ansible em irc.freenode.net
• lista de correspondência: https://groups.google.com/forum/#!forum/ansible -project

Se você puder passar por aí, nós agradeceríamos. Isso nos permite manter o rastreador de problemas para bugs, solicitações de pull, RFEs e similares.

Obrigado mais uma vez e esperamos vê-lo na lista ou IRC. Obrigado!

@bcoca fechando bugs com cópia e passado vai ajudar a construir os objetivos da comunidade. Esse é um relatório de bug válido, não um mas.

O fato de o ansible assumir que o python 2 está instalado em /usr/bin/python é um bug, bastante crítico.

@ssbarnea -

https://www.zigg.com/2014/using-virtualenv-python-local-ansible.html tem uma solução decente que parece estar funcionando tanto para ações diretamente com hosts: localhost ou chamando local_action

@ssbarnea @pauricthelodger Vocês ainda estão tendo problemas com isso?

Acabei de fazer um manual que funcionou por meses (anos) e começou a falhar em local_action: ec2_elb ao registrar uma instância com ELB e usar o inventário ec2.py .

Acontece para mim ao executar do MacOS com Ansible 2.0.0.2, 2.0.1 e 2.1.0.

Ainda não experimentei as recomendações do artigo 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 , ainda trabalhando para mim com isso em meu arquivo de inventário:

[localhost]
localhost ansible_connection=local ansible_python_interpreter=python

Avise-me se isso ajudar em alguma coisa.

@pauricthelodger , posso confirmar que funcionou comigo nas versões do ansible 2.0.0.2, 2.0.1 e 2.1.0. Obrigado novamente!

Algum motivo para estar fechado? Ainda é um problema no 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

A solução alternativa para o arquivo de inventário foi superada, mas ainda é um problema.

@rolette Ansible usa /usr/bin/python padrão (não o mesmo que /usr/local/bin/python ). Meu conselho - use o virtualenv ( virtualenv .venv )

e seu inventário 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 Obrigado por outra solução alternativa, mas o que estou procurando é uma correção para o ansible para que funcione corretamente no OS X em vez de exigir que todos que se deparam com o problema gastem tempo rastreando uma solução alternativa.

não é uma solução alternativa - é como o python funciona. Você tem que simplesmente dizer ao Ansible onde está seu executável python, se não quiser usar o local padrão /usr/bin/python .

ghostrider negativo ... Curiosamente, todos os outros programas python funcionam bem sem exigir um virtualenv.

Caminhos embutidos em código para executáveis ​​são interrompidos em vários ambientes. Normalmente, não são plataformas inteiras como este bug em particular.

Vamos ser corretos, a maneira certa de chamar o python é via #!/usr/bin/env python e não via um caminho codificado. Há uma exceção a esta regra, os scripts de shell do virtualenvs onde é preferível ter um caminho completo em vez de usar env .

No MacOS usando o sistema Python padrão, o env passa a resolver para /usr/bin/python mas isso não significa que devemos ver /usr/bin/python no script instalado.

Uma coisa que usei ao longo do tempo foi evitar o uso de scripts de shell e chamar ansible como um módulo.

@ssbarnea Concordo, exceto que #!/usr/bin/env python faz a coisa certa dentro do virtualenvs, então ainda não há razão para codificar o caminho.

Obteve o mesmo erro ao usar o módulo ec2_tag no ansible.

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

livro de cantadas:

  - 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

Mas trabalhe com 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

Mesmo erro com a tag 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 }}'

Não tenho certeza se está conectado, mas, caso ajude as pessoas no caminho, acabei de notar o seguinte no changelog devel em Ansible 2.3:

Adicionado 'ansible_playbook_python' que contém o 'executável Python atual', ele pode ficar em branco em alguns casos nos quais Ansible não é invocado por meio da CLI padrão (limitação sys.executable).

Se você estiver no Mac e tiver instalado outras cópias do Python via homebrew, poderá executar estes comandos para instalar o boto no sistema python:

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

Isso resolveu o problema. Obrigada!!

Estou usando o Arch Linux e o padrão parece ser python 3, enquanto o Ansible parece estar usando o python 2 por padrão.
Portanto, a solução de @rsanchez funciona para mim se eu substituir python por python2 explícito.
Obrigado.

Além da solução de @rsanchez para o cenário em que pode haver várias cópias de python em seu mac, outra maneira é dizer ao ansible qual python usar por meio da variável "ansible_python_interpreter".

Suponha que / usr / bin / python não tenha boto em seu caminho e o python em / usr / local / bin / python (instalado via homebrew) o tenha ("import boto" funciona enquanto estiver no repl). Você pode então definir " ansible_python_interpreter = / usr / local / bin / python " no arquivo de inventário.

Além disso, você define na linha de comando com a opção " --extra-vars = 'ansible_python_interpreter = / usr / local / bin / python' ".

Eu estava tendo o mesmo problema, mas com netaddr .

Ansible estava usando alguma versão python absolutamente aleatória instalada em minha 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"
}

Então, usei o truque /usr/local/opt/python/bin/python2.7 -m pip install netaddr para instalá-lo.

Estou me perguntando se variáveis ​​de ambiente Python, como PYTHON_HOME e PYTHON_PATH ajudariam nesse problema, mas não sei muito sobre elas.

Quando eu ingenuamente fiz uma compilação do docker para ansible 2.3.1.0 com algo como

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

Eu entendi o erro

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

Huh, interessante. Claro que posso definir o interpretador para alguma coisa codificada, ou encontrar alguma outra solução alternativa, mas é importante observar, como disse antes, que _nenhum outro aplicativo Python tem esse problema_. É justo salientar que a maneira como o ansible encaminha as tarefas para os hosts (mesmo localhost sem ssh) é copiar um executável python - mas, mesmo assim, esse executável deve respeitar as configurações do ambiente.

Para se levantar por um segundo, a ignorância da prática padrão é um problema recorrente com o ansible. Tive tantos desafios ao usar os módulos AWS com tokens de sessão (para atribuição de função ou autenticação mfa) que costumo usar awscli para tudo o que é possível. A bobagem é que, se eles tivessem apenas deixado o boto lidar com a resolução de credenciais em vez de injetar sua própria solução 2/3 de repassá-los, eles teriam o melhor dos dois mundos. Concedido, as credenciais locais não estariam disponíveis a partir de hosts remotos, mas 1) se eles não tivessem suas próprias credenciais, qual seria o ponto de executar a tarefa remotamente de qualquer maneira, já que só atingiria uma API pública de qualquer maneira e que poderia facilmente ser feito localmente na maioria dos casos; e 2) se eles tivessem suas próprias credenciais, você provavelmente gostaria de buscá-los. Não relacionado, mas outro exemplo dos implementadores do ansible procedendo na ignorância de uma melhor prática que poderiam e deveriam ter seguido. Fácil para mim dizer, não estou tentando implementar o ansible: P

Como solução temporária, fiz:

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

Tenho pip, botocore e boto3 integrados ao python3, não o padrão do Mac OS /usr/bin/python . Como uma correção adequada, posso tentar definir o ansible_python_interpreter como uma variável de ambiente.

Algum motivo para estar fechado? Ainda tendo esse problema no 2.5 devel.

Minha solução alternativa para a opção nuclear foi hackear a instalação do ansible em meus pacotes de site, porque não quero me lembrar de passar vars extras todas as vezes. Você pode estremecer, não grite comigo, prossiga por sua conta e risco, sem garantia expressa ou implícita.

Para encontrar os arquivos:

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

Para consertar todos os 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"

Eu tinha enfrentado algum erro ao fazer isso
fatal: [localhost]: FALHOU! => {"alterado": falso, "msg": "boto necessário para este módulo"}
mas o boto já está instalado
então usei esse comando (porque estou usando mac)
sudo / usr / bin / python -m pip install boto
e adicionei mais uma linha em env / hosts
ansible_pyhton_interpreter = / usr / bin / python
então é trabalho

qualquer um pode sugerir qual é o motivo de receber estes erro, já tinha instalado o boto então porque preciso deste comando
sudo / usr / bin / python -m pip install boto

@ jawad486 , eu também uso um Mac e adotei o hábito de executar o ansible exclusivamente com docker. Ele evitou completamente os problemas de localização de módulos e tornou possível a execução confiável de qualquer versão do ansible, nova ou antiga, simultaneamente. Não posso dizer o mesmo de qualquer outro método com brew, virtualenv ou o Python embutido. Eu monto em ~ / .aws e ~ / .ssh conforme necessário.

@ jawad846 Leia as postagens sobre esse assunto. É um bug. ansible codifica incorretamente o caminho para python em vez de obtê-lo do ambiente.

No ansible 2.5.1, esse problema ainda persiste (no Linux), e diferentes módulos se comportam de maneira diferente. Usei a solução alternativa ansible_python_interpreter=python no arquivo hosts. Isso faz com que ec2_vpc_net e ec2_vpc_subnet funcionem, mas ec2_vpc_igw falhe com {"changed": false, "msg": "boto is required for this module"} . O que é estranhamente engraçado porque esses módulos fazem parte do mesmo conjunto e são usados ​​juntos.

Investigando isso, descobri que ec2_vpc_net e ec2_vpc_subnet usam boto3, mas ec2_vpc_igw usam boto v2. Portanto, você precisará instalar em seu virtualenv AMBOS o boto3 e o boto2. Em seguida, mudei todos os cabeçalhos de shebang com uma versão modificada do script sed de @benauthor . Eu configurei em meu Makefile para ser executado após construir o virtualpython, desta forma:

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"

Onde vp é o caminho virtualenv local que estou usando.

Ainda é um problema no 2.5.2 também

@ timm088 Acabei de corrigir esse problema no meu macbook.
execute "which python". ele deve fornecer o caminho, no meu caso era "/ usr / local / bin / python".
Em seguida, vá para o arquivo de inventário, cole esse caminho em ansible_python_interpreter.
Esta é a aparência do meu arquivo de hosts de inventário:
[local]
localhost ansible_connection = local ansible_python_interpreter = / usr / local / bin / python /

Deve funcionar agora.

Estou assumindo que os desenvolvedores do Ansible não viram nenhuma das discussões em andamento desde que foi fechado automaticamente 4 dias depois de ser aberto. Finalmente consegui postar uma pergunta na lista de e-mails para ver se podemos consertá-la dessa forma.

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