Por favor, não vamos chamá-lo de how . Isso é ainda pior de ler do que become: true . Mas a funcionalidade sob ele parece ótima.

inclui correção para #10695

Excelente. No interesse do bikeshedding, talvez chame de looping: .

:+1:

+1

+1 especialmente para paralelização dentro do host!

:+1:

:+1:
mas não vamos chamá-lo de "como"

então aqui está uma solução alternativa para interromper uma tarefa de loop após a primeira falha

- hosts: localhost
  vars:
    myvar:
        - 1
        - 2
        - 3
        - 4
        - 5
  tasks:
    - name: break loop after 3
      debug: msg={{item}}
      failed_when: item == 3
      register: myresults
      when: not (myresults|default({}))|failed
      with_items: "{{myvar}}"

@bcoca não está funcionando do final (ansible 1.9.3 ubuntu )

TAREFA: [quebrar loop após 3] * * * * * * * * * * * * * * * ** *
ok: [localhost] => (item=1) => {
"falhou": falso,
"failed_when_result": falso,
"item 1,
"msg": "1"
}
ok: [localhost] => (item=2) => {
"falhou": falso,
"failed_when_result": falso,
"artigo": 2,
"msg": "2"
}
falhou: [localhost] => (item=3) => {"failed": true, "failed_when_result": true, "item": 3, "verbose_always": true}
mensagem: 3
ok: [localhost] => (item=4) => {
"falhou": falso,
"failed_when_result": falso,
"item": 4,
"msg": "4"
}
ok: [localhost] => (item=5) => {
"falhou": falso,
"failed_when_result": falso,
"item": 5,
"msg": "5"
}

ah, sim, vai funcionar como está no 2.0 pois no 1.9 o registro não ocorre até que o loop seja feito.

+1 em garfos

+1
talvez em vez de "como", loop_details ou options?

+1

+1, usar wait_for de localhost para esperar que 100 hosts EC2 apareçam está me matando...

+1 por motivo semelhante ao senderista

+1

:+1:

Tanto squash quanto forks seriam recursos incríveis que acelerariam imensamente a execução do Ansible.

Eu também substituiria how por algo como loop_details , loop_settings , loop_options ou algo semelhante.

loop_control , já em 2.1 com a parte label implementada.

squash pode simplesmente desaparecer, pois é fácil apenas passar uma lista para os módulos que o suportam:

apt: name={{listofpackages}}

e evite o loop completamente

http://docs.ansible.com/ansible/playbooks_loops.html#loop -control

+1 garfos

+1 garfos

Eu tive um caso de uso para uma nova configuração para uma quebra condicional break_when

+1 forks e espero que também funcione para paralelizar sequências de tarefas a serem executadas como em:
- include: service.yml
with_items: "{{services|default([])}}"

Caso contrário, já existe o async/async_status .

+1 garfos

Eu esperando os módulos openstack iterarem através de with_ loops em mais de 100 itens...

+1 em garfos. Poderia usar isso para copiar AMIs para todas as regiões da AWS.

+1 em garfos. Por favor! torná-lo parte do loop_control

+1 em garfos

+1 em garfos

+1, precisa de garfos também :-)

+1 em garfos

+1 em garfos

Forks seria incrível, +1

Eu sempre sento em silêncio não querendo contribuir com o spam, porque é difícil avaliar entre projetos se é bem-vindo ou não, mas parece que o trem da bifurcação +1 saiu da estação!

+1 em garfos

+1 em garfos

+1 em garfos

:+1: nos garfos

@bcoca Saudações! Obrigado por tomar o tempo para abrir este problema. Para que a comunidade lide com seu problema de forma eficaz, precisamos de um pouco mais de informações.

Aqui estão os itens que não encontramos em sua descrição:

• Tipo de problema
• versão ansible
• Nome do componente

Defina a descrição deste problema com este modelo:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

clique aqui para obter ajuda do bot

+1 em garfos

+1 em garfos!

+1 em Forks!

+1 em garfos!

+1 em garfos!

Alguma atualização no garfo? Quando deve estar pronto?
Meu caso de uso é instanciar cerca de 20 contêineres em um servidor com with_sequence . Agora demora muito :(
Eu ficaria feliz em ajudar, mas eu precisaria de algumas dicas sobre onde colocar as mãos

@bitliner ninguém criou um PR para isso, se é isso que você está perguntando, é realmente muito difícil fazer corretamente.

quanto ao seu problema, apenas declare X hosts no inventário e faça um loop sobre hosts: em vez de with_ para criá-los em paralelo.

inventário:

[containers]
container[000:020]

hosts: containers
gather_facts: false
tasks:
   - container: state=present name={{inventory_hostname}}

ou seja, container é um módulo 'feito'.

@bcoca sua solução não está clara para mim. Para ter certeza, é isso que você quer dizer?

arquivo hosts

[containers]
192.168.1.100
192.168.1.100
192.168.1.100
192.168.1.100
... and so on based on the degree of parallelism I want to get ...

arquivo main.yml

hosts: containers
gather_facts: false
tasks:
   - container: state=present name={{inventory_hostname}}

baseado em um módulo container que devo implementar, correto? Nesse caso, eu teria todos os containers com o mesmo nome, e isso não é aceitável, correto?

Além disso, quais são os desafios para implementar o loop em paralelo corretamente?

Meu caso de uso precisa acelerar esta tarefa:

- name: "Start clients"
  docker_container:
    name: "mycontainer-{{ item }}"
    image: myimage
    links: 
      - server-{{item}}:server-{{item}}
  with_sequence: count={{ scale }}

Não posso usar a escala de composição do docker porque preciso rotear o tráfego entre os contêineres de uma maneira específica (é por isso que uso with_sequence para gerar diferentes nomes de contêiner do docker).

Eu poderia construir um módulo que pega a declaração de um container e baseado em um parâmetro de escala ele instancia remotamente vários containers em paralelo. Isso faz sentido? Você tem alguma ajuda para entender como chamar/reutilizar no myModule o módulo docker_container e quais são as APIs que o Ansible oferece para rodar algo em paralelo?

@bitliner você não seguiu minhas instruções, eu tinha nomes exclusivos no inventário (usando o intervalo para funcionar como uma sequência). Como os nomes são únicos no inventário, você acabou de declarar o mesmo nome N vezes, mas ainda tem um host, o que não causa seu segundo problema em nomes duplicados de contêineres, pois você apenas faz um loop em 1 host.

De qualquer forma, se você quiser acompanhar seu problema, use ML ou IRC, pois seria um pouco fora do tópico para este ticket.

@bcoca Como posso ter um host se você declarou 20 hosts?

[containers]
container[000:020]

vai se conectar a container001 , container002 , etc.

Funciona por ter nomes únicos, mas o que não está claro para mim é por que você diz que ainda tenho um host (em vez de 20).
hosts:containers significa para mim 20 hosts, não apenas um. O que estou ignorando nesta solução?

@bitliner causa isso:

[containers]
192.168.1.100
192.168.1.100
192.168.1.100
192.168.1.100

não é 4 hosts, mas 1

também neste momento isso está praticamente fora do tópico, se você quiser continuar recebendo ajuda sobre isso, vá para IRC ou ML

eu resolvi usando

[containers]
ip[000:020] ansible_host=192.168.1.100

e

- name: "Start containers"
  docker_container:
    name: "my-container-{{ inventory_hostname }}"

Uma dúvida: imagem para adicionar um comando fork , a alteração consistiria em reescrever o método run_loop para fazer com que ele gerencie o nível de paralelismo e assincronia ?

e então começa a ficar 'divertido' ...:

• o fork do loop conta contra o --forks global, faça isso por controle remoto?
• o que fazer com loops quando os itens dependem de itens anteriores (não apenas execução de tarefas, mas condicionais, etc)?
• como lidar com problemas de simultaneidade quando vários forks são executados no mesmo host? ou seja, eles atualizam o mesmo arquivo
• como lidamos com a limpeza? agora eles podem reutilizar dirs tmp .. mas cada execução limpa depois de si mesma, agora isso pode causar problemas.

E há alguns outros problemas que eu conheço .. com certeza há muitos que eu não estarei ciente até que alguém tente implementá-lo. Eu tenho soluções para alguns, mas começa a ficar fora de controle muito rápido.

A bifurcação do @bcoca Loop não deve ser habilitada por padrão. Eu preferiria ver o padrão definido como 1 e apresentá-lo como um parâmetro forks ou serial , mas incluir um aviso. Provavelmente quebrará algum código existente. Dito isto, estou muito ansioso por esse recurso (principalmente para tarefas que exigem delegate_to )

+1 para garfos (falso por padrão)

+1 garfos

+1 garfos

+1 garfos

+1 garfos

+1 garfos

+1 para forks também, porém, entretanto, há também um novo plugin de estratégia Ansible que oferece um grande aumento de desempenho em geral, e também para loops with_items . Talvez para aqueles que desejam garfos por motivos de desempenho, valha a pena dar uma olhada:

https://github.com/dw/mitogen
https://mitogen.readthedocs.io/en/latest/ansible.html

Não consigo ver como isso melhorará exatamente os loops with_items. Este plug-in
melhora os problemas de desempenho causados ​​pelo uso de ssh como método de conexão.
Especialmente em longas distâncias e redes latentes e com grandes números
de servidores.

Isso não ajuda com as funções de nuvem AWS ou Azure em que a execução
acontece no controlador ansible e apenas executa em um conjunto de itens em
esse sistema em nuvem e não se conecta a hosts, que é o
problema principal com with_items sendo lento. Não tem nada a ver com grande conjunto
de máquinas ou latência ou qualquer coisa relacionada ao ssh. É simplesmente o fato
que ele executa funções de nuvem em um loop with_items em serial e nada
pode acelerar isso, exceto o provedor de nuvem melhorando sua velocidade ou um
execução paralela dessas funções de nuvem pelo ansible.

Também não menciona with_items no artigo, então não consigo ver como
isso vai ajudar até mesmo no mais ínfimo pouco. Você pode explicar um pouco mais
como isso poderia ajudar? Eu gostaria de saber o que estou perdendo se estou perdendo
algo aqui.

No sábado, 10 de março de 2018 às 21:58, NielsH [email protected] escreveu:

+1 para garfos também, entretanto, há também um novo Ansible
plugin de estratégia que dá um grande aumento de desempenho em geral, e também
para loops with_items. Talvez para aqueles que desejam garfos para desempenho
razões pelas quais vale a pena ver:

https://github.com/dw/mitogen
https://mitogen.readthedocs.io/en/latest/ansible.html

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372070418 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AJd59qWI9n_DNmUqpmZYiIOMZAyjJy3uks5tdEyQgaJpZM4Fx8zF
.

Na verdade, não vai ajudar em todos os casos. No entanto, a razão pela qual estou procurando por bifurcações em with_items é por causa da lentidão com o processamento de cada item individualmente (mesmo com pipeline). Às vezes eu tenho que criar um grande número (várias centenas) de diretórios baseados em host_vars, ou modelar algumas centenas de arquivos. Então, estou fazendo um loop sobre o módulo file e template principalmente.

Certa vez, testei a modelagem de 100 arquivos em 100 arquivos separados por meio de with_items vs loop sobre os itens no próprio modelo jinja e mesclando o modelo em um único arquivo grande. Tudo em um único arquivo leva 5 segundos, mas a criação de 100 arquivos de configuração separados leva 30 minutos.

O plugin que mencionei deu uma melhoria tão grande para mim que achei que valia a pena mencioná-lo aqui.

como os loops apenas executam a mesma tarefa uma vez por item, qualquer melhoria na velocidade de execução da tarefa deve se traduzir em loops mais rápidos. Isso acontece apenas para afetar 'tarefas remotas', então qualquer coisa local não verá os ganhos.

Acordado. Estou usando o ansible para executar apenas tarefas locais. Em particular, para construir uma dúzia de imagens docker. No momento, o ansible os constrói em série, então leva muito tempo e subutiliza a CPU multi-core. Eu gostaria de construir várias imagens docker em paralelo.

@gjcarneiro então não os defina como dados, defina-os como hosts e os direcione, então delegate_to: localhost para executar as ações em paralelo

Hah, obrigado pelo truque legal :) Mas ainda assim, mesmo que funcione (eu não testei), é uma maneira bastante complicada de executar tarefas em paralelo.

Então, novamente, eu posso estar usando o ansible para um propósito completamente diferente do pretendido, então de certa forma é minha culpa :(

não é realmente complicado, é como o Ansible deve usar a paralelização, por host, não por variável.

Sim, eu entendo, não é culpa do Ansible, faz sentido. Mas estou usando o Ansible como sistema de compilação (em vez de, por exemplo, make), porque o Ansible é bom como sistema de compilação na maioria das maneiras. Mas, no meu estado de espírito, pensando como um sistema de construção, "hosts" não fazem sentido. Um sistema de compilação como "make" não se preocupa com "hosts", apenas se preocupa com arquivos e tarefas. Estou forçando o Ansible a ser usado como sistema de compilação, e isso causa um pouco de dissonância cognitiva, só isso.

O Ansible se preocupa apenas com Hosts e Tarefas, considere as imagens que você está construindo 'hosts' e de repente ele se encaixa nos dois paradigmas.

Ansible é uma ferramenta de gerenciamento de configuração para muitas outras coisas, redes
dispositivos, reais e virtuais, para uma enorme quantidade de serviços em nuvem, como
bancos de dados, serviços web como pé de feijão eleastic, lambda e todos os
componentes que se aplicam a ele como componentes de segurança do IAM, enquanto o Ansible é
bom em hosts, se você ainda estiver executando principalmente VMs / hosts, basicamente
TI do início dos anos 2000. Não ofender ninguém aqui as vezes são importantes
motivos para executar VMs ou até mesmo contêineres docker, mas todos eles remontam a
motivos legados. Na verdade, mais e mais hosts vão se tornar menos
o que automatiza. IMO Se não ficarmos paralelos com_items, poderíamos como
bem sucatear ansible todos juntos.

Tendo dito que vou pensar positivo aqui e tentar usar
delegate_to para alguns serviços em nuvem, quero dizer, nunca tentei executar em mais de 200
Componentes de nuvem que preciso dessa maneira, acho que basta consultar a lista
e despeje-o em um arquivo hosts no formato hosts com ansible e tente
delegate_to: localhost Vou comentar meus resultados aqui. Se funcionar em
pelo menos podemos fazer um pull request de documentação sobre como contornar
problemas de série do loop with_item dessa maneira. Podemos ter certeza de ter um link para
-los nas seções de módulos de nuvem e seções para o docker.

Em segunda-feira, 12 de março de 2018 às 18:49, Brian Coca [email protected] escreveu:

O Ansible se preocupa apenas com Hosts e Tarefas, considere as imagens que você está
construindo 'hosts' e de repente ele se encaixa em ambos os paradigmas.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

@gjcarneiro então não os defina como dados, defina-os como hosts e os direcione, então delegate_to: localhost para executar as ações em paralelo

Esta é uma abordagem muito boa, mas não parece funcionar dentro da solução alternativa para reinicializações contínuas com simulação serial=1 (#12170). Portanto, uma opção de paralelização adicionaria muito mais flexibilidade.

sem dúvida, mas também adiciona uma enorme camada de complexidade e a necessidade de lidar com ações simultâneas em um único host ala hosts:all + lineinfile + delegate_to: localhost

Hrrm até agora eu criei um pequeno teste para delegate_to: 127.0.0.1 for
tarefas de exclusão, pois isso também é uma dor em escala de massa.

Minha cartilha está assim:

• hosts: "{{ DeploymentGroup }}"

  tarefas:

  • name: remove vm e todos os recursos associados
    azure_rm_virtualmachine:
    resource_group: "{{ host_vars[item]['resource_group'] }}"
    nome: "{{ inventário_hostname }}"
    estado: ausente

  delegado_para: 127.0.0.1

Infelizmente ele ainda tenta se conectar às máquinas listadas nos hosts para
execute a tarefa do azure azure_rm_virtualmachine.
Estou fazendo isso corretamente? Parece que está faltando alguma coisa, mas eu tentei isso
anteriormente de muitas maneiras diferentes, então só quero saber se você é capaz de fazer
esta.

Isso realmente funciona mesmo? Espero que isso seja apenas algum problema de sintaxe.

Em segunda-feira, 12 de março de 2018 às 19h55, Isaac Egglestone < [email protected]

escrevi:

Ansible é uma ferramenta de gerenciamento de configuração para muitas outras coisas,
dispositivos de rede, reais e virtuais, para uma enorme quantidade de nuvem
serviços como bancos de dados, serviços web como pé de feijão eleastic, lambda
e todos os componentes que se aplicam a ele como componentes de segurança do IAM, enquanto
O Ansible é bom em hosts se você ainda estiver executando principalmente VMs/hosts seu
basicamente na TI do início dos anos 2000. Não ofender ninguém aqui há às vezes
motivos importantes para executar VMs ou até mesmo contêineres docker, mas todos eles
derivam de volta às razões do legado. Na verdade, mais e mais hosts vão
tornar-se menos do que automatiza. IMO Se não ficarmos paralelos
with_items podemos descartar o ansible todos juntos.

Tendo dito que vou pensar positivo aqui e tentar usar
delegate_to para alguns serviços em nuvem, quero dizer, nunca tentei executar em mais de 200
Componentes de nuvem que preciso dessa maneira, acho que basta consultar a lista
e despeje-o em um arquivo hosts no formato hosts com ansible e tente
delegate_to: localhost Vou comentar meus resultados aqui. Se funcionar em
pelo menos podemos fazer um pull request de documentação sobre como contornar
problemas de série do loop with_item dessa maneira. Podemos ter certeza de ter um link para
-los nas seções de módulos de nuvem e seções para o docker.

Em segunda-feira, 12 de março de 2018 às 18:49, Brian Coca [email protected] escreveu:

O Ansible se preocupa apenas com Hosts e Tarefas, considere as imagens que você está
construindo 'hosts' e de repente ele se encaixa em ambos os paradigmas.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

Ok, desabilitar a coleta de fatos corrige esse problema, mas causa
outro, host_vars não contém mais o inventário dinâmico do Azure de
padrão em.

Então resource_group: "{{ host_vars[item]['resource_group'] }}" não
funciona no acima e precisa ser codificado para um nome de grupo de recursos.

No domingo, 18 de março de 2018 às 11h14, Isaac Egglestone <
[email protected]> escreveu:

Hrrm até agora eu criei um pequeno teste para delegate_to: 127.0.0.1 for
tarefas de exclusão, pois isso também é uma dor em escala de massa.

Minha cartilha está assim:

• hosts: "{{ DeploymentGroup }}"

  tarefas:

  • name: remove vm e todos os recursos associados
    azure_rm_virtualmachine:
    resource_group: "{{ host_vars[item]['resource_group'] }}"
    nome: "{{ inventário_hostname }}"
    estado: ausente

  delegado_para: 127.0.0.1

Infelizmente ele ainda tenta se conectar às máquinas listadas nos hosts para
execute a tarefa do azure azure_rm_virtualmachine.
Estou fazendo isso corretamente? Parece que está faltando alguma coisa, mas eu tentei isso
anteriormente de muitas maneiras diferentes, então só quero saber se você é capaz de fazer
esta.

Isso realmente funciona mesmo? Espero que isso seja apenas algum problema de sintaxe.

Em segunda-feira, 12 de março de 2018 às 19h55, Isaac Egglestone <
[email protected]> escreveu:

Ansible é uma ferramenta de gerenciamento de configuração para muitas outras coisas,
dispositivos de rede, reais e virtuais, para uma enorme quantidade de nuvem
serviços como bancos de dados, serviços web como pé de feijão eleastic, lambda
e todos os componentes que se aplicam a ele como componentes de segurança do IAM, enquanto
O Ansible é bom em hosts se você ainda estiver executando principalmente VMs/hosts seu
basicamente na TI do início dos anos 2000. Não ofender ninguém aqui há às vezes
motivos importantes para executar VMs ou até mesmo contêineres docker, mas todos eles
derivam de volta às razões do legado. Na verdade, mais e mais hosts vão
tornar-se menos do que automatiza. IMO Se não ficarmos paralelos
with_items podemos descartar o ansible todos juntos.

Tendo dito que vou pensar positivo aqui e tentar usar
delegate_to para alguns serviços em nuvem, quero dizer, nunca tentei executar em mais de 200
Componentes de nuvem que preciso dessa maneira, acho que basta consultar a lista
e despeje-o em um arquivo hosts no formato hosts com ansible e tente
delegate_to: localhost Vou comentar meus resultados aqui. Se funcionar em
pelo menos podemos fazer um pull request de documentação sobre como contornar
problemas de série do loop with_item dessa maneira. Podemos ter certeza de ter um link para
-los nas seções de módulos de nuvem e seções para o docker.

Em segunda-feira, 12 de março de 2018 às 18:49, Brian Coca [email protected]
escrevi:

O Ansible se preocupa apenas com Hosts e Tarefas, considere as imagens que você está
construindo 'hosts' e de repente ele se encaixa em ambos os paradigmas.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

Ok, modifiquei o Playbook abaixo para tentar várias coisas.

1º tentei definir delegate_facts: True caso isso tenha ajudado, mas é claro
mesmo com base na documentação, eu realmente não esperava que isso funcionasse.
2º eu configurei collect_facts: não e tentei executar a configuração para reduzir o fato
juntando-se a nada esperando que ele optasse por não se conectar de forma alguma, mas de
claro, como esperado, ele ainda tentou se conectar à máquina.
3º Tentei configurar a conexão: localhost mas estranhamente ainda quer
conectar remotamente à máquina para coletar os fatos, mesmo sabendo disso
vai executar o jogo localmente, um pouco chato lá mas eu entendo a lógica como
de que outra forma ele saberá os detalhes do host em questão sem fazer
esta..

Eu provavelmente posso usar o manual para ligar as máquinas primeiro e depois deixar
ansible login para eles e reunir os fatos desnecessários. Isso seria para que
Posso fazer com que host_vars funcione e, em seguida, exclua as máquinas. Eu gostaria de saber
se alguém tiver uma solução melhor aqui, pois isso também consome muito tempo
esforço quando tenho cem ou mais máquinas e tenho que alimentá-las
tudo para depois excluí-los.

Até agora estou vendo usando isso como uma solução em vez de um paralelo with_items
solução como tendo potencial, mas as máquinas em questão ainda precisam ser
acessível se você precisar de qualquer tipo de informação do azure_rm.py enquanto você
faça isso para que haja pelo menos uma ressalva. Isso é a menos que alguém saiba
como obter acesso a host_vars do azure que são passados ​​via padrão em
quando reunir_fatos: não

Na verdade, é claro que tenho o mesmo problema quando executo tudo isso usando um
with_items list, no entanto, eu esperava evitar esse trabalho se eu estiver
vai usar hosts novamente. A solução alternativa é despejar o azure_rm.py em um
json na linha de comando e, em seguida, carregando em uma variável para obter
acesso a eles novamente.

Se eu estiver ansioso pelo meu objetivo final aqui para modificar centenas ou mesmo milhares
de componentes sem servidor em paralelo, talvez isso seja bom, pois posso
use coisas como azure_rm_functionapp_facts
http://docs.ansible.com/ansible/latest/azure_rm_functionapp_facts_module.html
para
reunir fatos sobre eles e usá-los na peça em teoria, embora isso
ainda não foi testado.

Eu ainda não tenho nenhuma grande lógica sobre como fazer isso corretamente para criar um
solicitação de pull de documentação sobre isso, pois o método parece até agora em grande parte
depende do que você está fazendo e não tenho certeza se quero sugerir o uso do
json dump hack na documentação.

Vou esperar por algum feedback de qualquer pessoa que se importe com isso em
esta lista de problemas para decidir meu próximo passo. Enquanto isso vou usar meu hack para conseguir
meu trabalho imediato feito.

• hosts: "{{ DeploymentGroup }}"
  reunir_fatos: não
  tarefas:
  
  
  
  • configuração:
    
    collect_subset=!todos,!min
  
  
  • name: remove vm e todos os recursos associados
    
    azure_rm_virtualmachine:
    
    resource_group: "{{ host_vars[inventory_hostname]['resource_group']
    
    }}"
    
    nome: "{{ inventário_hostname }}"
    
    estado: ausente
    
    delegado_para: localhost
    
    

    delegate_facts: Verdadeiro

  
  

No domingo, 18 de março de 2018 às 12h04, Isaac Egglestone <
[email protected]> escreveu:

Ok, desabilitar a coleta de fatos corrige esse problema, mas causa
outro, host_vars não contém mais o inventário dinâmico do Azure de
padrão em.

Então resource_group: "{{ host_vars[item]['resource_group'] }}"
não funciona no acima e precisa ser codificado para um grupo de recursos
nome.

No domingo, 18 de março de 2018 às 11h14, Isaac Egglestone <
[email protected]> escreveu:

Hrrm até agora eu criei um pequeno teste para delegate_to: 127.0.0.1 for
tarefas de exclusão, pois isso também é uma dor em escala de massa.

Minha cartilha está assim:

• hosts: "{{ DeploymentGroup }}"

  tarefas:

  • name: remove vm e todos os recursos associados
    azure_rm_virtualmachine:
    resource_group: "{{ host_vars[item]['resource_group'] }}"
    nome: "{{ inventário_hostname }}"
    estado: ausente

  delegado_para: 127.0.0.1

Infelizmente ainda tenta se conectar às máquinas listadas nos hosts
para executar a tarefa do azure azure_rm_virtualmachine.
Estou fazendo isso corretamente? Parece que estou perdendo alguma coisa, mas eu tentei
isso anteriormente de muitas maneiras diferentes, então só quero saber se você é capaz de
fazem isto.

Isso realmente funciona mesmo? Espero que isso seja apenas algum problema de sintaxe.

Em segunda-feira, 12 de março de 2018 às 19h55, Isaac Egglestone <
[email protected]> escreveu:

Ansible é uma ferramenta de gerenciamento de configuração para muitas outras coisas,
dispositivos de rede, reais e virtuais, para uma enorme quantidade de nuvem
serviços como bancos de dados, serviços web como pé de feijão eleastic, lambda
e todos os componentes que se aplicam a ele como componentes de segurança do IAM, enquanto
O Ansible é bom em hosts se você ainda estiver executando principalmente VMs/hosts seu
basicamente na TI do início dos anos 2000. Não ofender ninguém aqui há às vezes
motivos importantes para executar VMs ou até mesmo contêineres docker, mas todos eles
derivam de volta às razões do legado. Na verdade, mais e mais hosts vão
tornar-se menos do que automatiza. IMO Se não ficarmos paralelos
with_items podemos descartar o ansible todos juntos.

Tendo dito que vou pensar positivo aqui e tentar usar
delegate_to para alguns serviços em nuvem, quero dizer, nunca tentei executar em mais de 200
Componentes de nuvem que preciso dessa maneira, acho que basta consultar a lista
e despeje-o em um arquivo hosts no formato hosts com ansible e tente
delegate_to: localhost Vou comentar meus resultados aqui. Se funcionar em
pelo menos podemos fazer um pull request de documentação sobre como contornar
problemas de série do loop with_item dessa maneira. Podemos ter certeza de ter um link para
-los nas seções de módulos de nuvem e seções para o docker.

Em segunda-feira, 12 de março de 2018 às 18:49, Brian Coca [email protected]
escrevi:

O Ansible se preocupa apenas com Hosts e Tarefas, considere as imagens que você está
construindo 'hosts' e de repente ele se encaixa em ambos os paradigmas.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

Eu também tenho um caso de uso para garfos, o que tornaria isso muito mais fácil. O playbook está implantando várias instâncias de openstack via terraform com ips flutuantes escolhidos aleatoriamente. Então eu itero sobre os ips para verificar se a porta 22 está aberta em cada host criado. O método atual para fazer isso é com um playbook multiplay:

- hosts: localhost
  connection: local
  gather_facts: no
  tasks:
...
  - name: Run terraform
    terraform:
      plan_file: '{{tf_plan | default(omit)}}'
      project_path: '{{terraform_path}}/{{infra}}'
      state: '{{state}}'
      state_file: '{{stat_tfstate.stat.exists | ternary(stat_tfstate.stat.path, omit)}}'
      variables: '{{terraform_vars | default(omit)}}'
    register: tf_output

  - name: Add new hosts
    with_items: '{{tf_output.outputs.ip.value}}' # configued this in terraform to output a list of assigned ips.
    add_host:
      name: '{{item}}'
      groups: new_hosts

- hosts: new_hosts
  gather_facts: no
  connection: local
  tasks:
   - name: Wait for port 22 to become available
     wait_for:
       host: '{{ansible_host}}'
       port: 22
       state: started
       timeout: 60

Isso é executado com: ansible-playbook -i localhost, deploy-test-clients.yml --extra-vars="infra=terraform_os_instances state=present"
Esta é, obviamente, uma solução limitada, pois você nem sempre tem uma lista de ips perfeitamente analisável por inventário para trabalhar.

Como muitas pessoas parecem estar lutando com o desempenho dos arquivos de modelagem localmente, talvez um módulo template_local específico possa ser criado para resolver esse problema específico. Pelo menos seria um começo... Eu mesmo tentaria, mas não teria tempo para o futuro previsível.

Mais de 30 minutos para modelar 100 arquivos que podem ser feitos em 5s com jinja é ridículo.

A modelagem do @saplla sempre acontece localmente, a única coisa que acontece remotamente é copiar o modelo e definir as permissões.

Apenas para esclarecer, estou falando sobre os usuários que desejam criar modelos de arquivos como tarefas locais, por exemplo, para alimentar outros sistemas de compilação ou, no meu caso, para implantar recursos k8s usando kubectl.

O que quero dizer é descarregar o loop e o modelo para o jinja por meio de um módulo que é um wrapper simples. O módulo poderia ter algum contexto e a definição de loop (o que normalmente seria colocado em with_nested e amigos) e apenas cortar o ansible inteiramente para essa tarefa (talvez o wrapper possa executar o jinja em paralelo se acelerar as coisas) .

Poderia ser invocado assim:

    template_parallel:
      src: "{{ item[0] }}"
      dest: "{{ tempdir }}/{{ item[1] }}-{{ item[0] | basename }}"
      context: "{{ hostvars[inventory_hostname] }}"
      nested:
      - "{{ templates.stdout_lines }}"
      - "{{ namespaces.stdout_lines }}"

O exemplo acima usa todas as variáveis ​​definidas pelo ansible como contexto, mas qualquer dict pode ser passado.

Como eu disse, não tenho tempo para trabalhar nisso agora, mas a abordagem parece viável @bcoca ?

Isso pressupõe que cada item é independente, nem sempre é o caso, você pode fazer com que os valores dos itens atuais dependam dos anteriores e/ou resultados de iterações anteriores, ou podem ser apenas cumulativos.

A maior parte do tempo gasto com templates tem a ver com os vars, não com os templates em si, já que eles precisam ser consistentes, você não ganharia muito em paralelização, a menos que estivesse disposto a mudar comportamentos que quebrariam as suposições atuais.

Além disso, os modelos já são paralelos, por host, mas não por item.

OK obrigado pelos pensamentos. Na verdade, seria bom o suficiente para o meu caso de uso e parece que também pode ser para outras pessoas neste tópico. Estou apenas usando o ansible para carregar configurações hierárquicas e arquivos de modelo localmente antes de invocar algum binário que os implante (kubectl, helm, etc). Eu ficaria feliz com um módulo de modelagem simples e leve se fosse tão eficiente que reduzisse os tempos de modelagem de minutos para segundos.

Vou tentar olhar para isso quando se tornar um problema para nós, a menos que alguém me vença.

Eu originalmente arquivei # 10695, mas vendo que isso vai demorar um pouco para acontecer, acabei abordando esses casos de uso com scripts de shell (por exemplo, basta dizer que tenho que fazer algo em 50 repositórios Git em um único host, eu uso Ansible para executar um único script uma vez que faz a coisa 50 vezes). Infelizmente, isso significa desistir de algumas das coisas que você obtém gratuitamente com o Ansible, como relatórios de alterações muito granulares, e você também precisa implementar toda a lógica "executar somente se" e ter muito cuidado com o tratamento de erros, mas é provavelmente duas ordens de magnitude mais rápido. Como tal, mesmo que acabemos obtendo uma opção "paralela" no futuro, ela pode não ser tão rápida quanto meus scripts personalizados e provavelmente não me incomodarei em mudar para ela.

@wincent um loop paralelo provavelmente ainda será sempre mais lento que um script de shell/programa dedicado, pois o Ansible faz muito mais do que apenas 'aplicar a ação'.

@bcoca : sim, isso confirma meu entendimento.

@saplla k8s_raw é melhor do que usar template para isso, você pode inserir o yaml em seu inventário, se necessário :) (não é o assunto deste PR)
qual é o estado atual sobre isso? Podemos esperar algo em 2.6 @bcoca ?
Estou gerenciando milhares de privilégios postgresql em meus clusters de banco de dados e 25 minutos é dolorosamente lento

@nerzhul Obrigado, mas não é melhor para nós. Muita magia. Precisamos de moldes.

@sapila , você sempre pode criar um destino de host por modelo para paralelizar o modelo o máximo possível e, em seguida, usar reproduções ou delegação subsequentes para entregar aos hosts reais adequados.

@bcoca um pouco hacky :)

nem um pouco, é MUITO hacky, mas funciona hoje

fechamento em favor de https://github.com/ansible/proposals/issues/140