Executando comandos no host Ansible de um manipulador

Question

Estou tentando implementar o seguinte cenário no Ansible (v1.9.1):

1. Ansible se conecta ao host remoto e usa su para se tornar root .
2. Ansible host busca arquivo de configuração remota que está prestes a ser danificado.
3. Anfitriões Ansible adiciona o arquivo just-fetched a um repositório Git que contém o diretório de destino usando git add ... .
4. O host Ansible confirma o arquivo just-fetched usando git commit ... e uma mensagem de confirmação apropriada.

Agora, (1) é totalmente compatível, pois a v1.9.0.1 e (2) são facilitadas com o módulo de busca - por padrão, armazena os arquivos em um subdiretório específico do host.

No entanto, não consegui descobrir (3) e (4). Idealmente, eu gostaria que o Ansible apenas executasse um comando local como o usuário que o iniciou em primeiro lugar. Eu poderia criar um script de shell wrapper para fazer isso, mas isso parece muito contrário à maneira Ansible de fazer as coisas.

A maioria das postagens na Internet sugere o uso do módulo local_action . O local_action , no entanto, parece ser completamente exagerado para o meu propósito - ele tenta acessar o host com o escalonamento de privilégios apropriado. Como resultado, ele falha:

fatal: [host00 -> 127.0.0.1] => Internal Error: this module does not support running commands via su

É assim que meu handler parece atualmente:

- name: stage-archive-file
  become: false
  su: false
  local_action: command git -C {{ playbook_dir }} add storage/archive
  notify: commit-archive-file

local_action parece ignorar completamente minhas tentativas de fazer não usar su , embora eu não tenha certeza se isso é algo relacionado a esse módulo específico ou ao método su em geral.

Existe uma maneira mais simples de executar um comando do processo ansible? Alternativamente, é possível de alguma forma obter local_action para trabalhar?

Parece haver um problema Ansible relacionado que pode estar impedindo que local_action funcione corretamente nesse caso . Aparentemente, local_action e delegate_to mantêm algumas configurações de conexão da tarefa "pai", mesmo que sejam completamente inválidas para o host delegado.

    

Answer 1

Embora eu espere que a causa raiz deste problema seja corrigida em uma versão Ansible futura, eu concluí minha própria solução. Basicamente eu modifiquei / hackeei um plugin de conexão despojado para o Ansible que simplesmente executa um comando no host. O processo foi o seguinte:

• No diretório do livro de exercícios, crie um subdiretório denominado connection_plugins .

• Copie o plug-in de conexão local.py da instalação do Ansible (por exemplo, /usr/lib/python2.7/site-packages/ansible/runner/connection_plugins/local.py ) para o subdiretório recém-criado com um nome diferente, como execute.py .

• Edite connection_plugins/execute.py e remova as seções de código relacionadas aos métodos de escalonamento de privilégios.

• Adicione uma entrada para localhost no arquivo de inventário com o parâmetro ansible_connection=execute .

A última etapa precisa ser modificada se local_action realmente usar um método de escalonamento de privilégios para algumas tarefas. Nesse caso, é possível deixar a entrada para localhost (se houver) inalterada, definir outro alias com o tipo de conexão execute e, em seguida, usar delegate_to: em vez de local_action: nas definições da tarefa.