Ansible: Vários arquivos no diretório padrão da função

você pode ter um main.yml em tasks , que inclui outros arquivos, mesmo em subdiretórios de tasks , por exemplo, para configurar seus dois componentes principais foo e bar dessa grande função:

- include: foo/main.yml
- include: bar/main.yml

Usar um módulo include_vars para variáveis ​​de função padrão anula a razão pela qual as variáveis ​​padrão existem, a saber, sendo usadas para fornecer "padrões de último recurso" que podem ser facilmente substituídos por outras partes da função / manual.

A ideia de vários arquivos no diretório defaults/ estava sendo discutida anteriormente no IRC, concluímos que analisar o diretório defaults/ forma semelhante aos diretórios inventory/group_vars/ e inventory/host_vars/ seria bom ter. O código necessário já existe e, com sorte, pode ser facilmente adaptado para os padrões de função.

+1

+1

Seria bom tê-lo!

+1

Sim, apenas assumi que os padrões / * foram encontrados e carregados automaticamente como mencionado acima. Parece que a solução alternativa sugerida (incluindo arquivos de padrões adicionais em tarefas) substituirá as variáveis ​​de inventário devido à

Precedência de variável Ansible 2.x

    role defaults [1] (loading all role defaults here critical)
    inventory vars [2]
    inventory group_vars
    inventory host_vars
    playbook group_vars
    playbook host_vars
    host facts
    registered vars
    set_facts
    play vars
    play vars_prompt
    play vars_files
    role and include vars (hack coming in here will override everything above)
    block vars (only for tasks in block)
    task vars (only for the task)
    extra vars (always win precedence)

Isso pode estar relacionado a # 8121

+1

+1

Definitivamente, um recurso obrigatório devido às restrições de precedência de variáveis.
Isso também permite definir um arquivo de padrões por classe de variáveis ​​e manter uma separação limpa; por exemplo, em rede, isso me permitiria definir um arquivo de padrões para IPv4, um para IPv6, um para SNMP e assim por diante ...
Por fim, parece necessário ser capaz de colocar esses arquivos em pastas diferentes em "padrões".

Apenas acertei este eu mesmo, então, definitivamente +1

Este é realmente um PITA.
Se eu pudesse sugerir uma solução, seria adicionar uma opção, semelhante a include_vars , mas em meta/main.yml , para especificar a ordem de carregamento.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Isso permitiria a opção de padronizar para ["main.yml"] e não quebrar o código existente, dando aos desenvolvedores a capacidade de definir variáveis ​​granulares com base em contextos de sua escolha.

Esquisito. Eu suspeitava totalmente que isso funcionaria fora da caixa. Uma das poucas vezes em que o ansible viola um pouco o princípio da menor surpresa ...

Definitivamente +1

Por vars/ o mesmo, mas parece que # 2958 estava se decidindo contra isso

O exemplo de @cornfeedhobo corresponde exatamente ao meu caso de uso. Ao usar include_vars, estou evitando substituições fáceis de quaisquer variáveis ​​individuais por execuções.

Outra opção de interface seria:

• Adicione uma opção ao módulo include_vars, 'as_default', que processa o arquivo incluído como se estivesse nos padrões.

Para mim, realmente parece estranho / contra-intuitivo que haja um diretório "padrões" com um único arquivo nele.
Quero dizer, você já viu um módulo python com um único arquivo __main__.py nele?

E é exatamente por isso que pensei intuitivamente que a funcionalidade mencionada neste tíquete já estava presente. "Claro que posso ter vários arquivos padrão, há um diretório para isso"

include_role permite que você especifique arquivos 'alternativos' agora http://docs.ansible.com/ansible/include_role_module.html via defaults_from option

Acabei de entrar em uma situação em que a divisão de defaults/main.yml é desejada. Adicionado meu 👍 ao problema.

O mesmo aqui, eu também preciso
+1

+1

@bcoca é uma boa adição e adiciona flexibilidade, mas não aborda o problema aqui e coloca o ônus sobre o redator do manual, quando a intenção é capacitar a função para definir padrões sãos facilmente.

Por favor, reveja meu comentário acima

Sim, este é um recurso muito útil para evitar arquivos com 2k linhas.
+1

+1

+1

👍

+1

+1

+1
O mesmo problema aqui. main.yml muito grande, dividido em vários arquivos. Presumimos que "simplesmente funcionaria" e carregaria todos os vars nos arquivos sob os padrões /, já que é um diretório. nojoy.

+1

+1

+1

👍

+1

+1

👍

Vocês podem rejeitar todos os comentários +1, mas duvido muito que vocês possam rastrear o número de assinantes, então adicionar +1 ainda é uma maneira decente de mostrar o apoio desejado.

Até que a atenção do problema esteja claramente ligada ao número de assinantes de um problema, espere sempre ver os comentários +1.

O que você pode esperar é que a equipe ansible bloqueie os comentários do problema, então não seja um spammer e não os defenda, por favor.

O que você pode esperar é que a equipe ansible bloqueie os comentários do problema, então não seja um spammer e não os defenda, por favor.

Eles poderiam fazer isso, mas este é um problema central para ser capaz de desenvolver funções adequadamente, especialmente desde a introdução de include_role no 2.x ao lado do antigo método de inclusão roles . Se você projetar sua função para ser compatível com include_role , o que é preferível, pois torna o desenvolvimento muito mais modular e flexível do que o antigo método roles sozinho, então você terá para rastrear incluindo seus próprios padrões como tarefas em seus manuais, passe a responsabilidade para o usuário final, que não deve saber como fazer isso para que sua função funcione corretamente, ou rastreie a plataforma / distribuição / lançamento como um nível aninhado de seu variáveis ​​de função que complica o inferno fora do desenvolvimento (embora funcione como eu criei uma função que pode suportar 20 versões de plataforma diferentes aqui ). Você já tentou escrever uma função que realmente suporte mais do que algumas plataformas? Não é nenhuma surpresa porque a maioria dos papéis no Ansible Galaxy não o fazem, esse problema é provavelmente o número um na lista da IMO.

Então, se eles bloquearem isso, não responderem a um problema de um ano atrás e sinalizarem para a comunidade que eles não estão interessados ​​em discutir questões críticas que estão impedindo as pessoas de criar soluções reais, então eles definitivamente podem esperar que as pessoas não cumpram ao redor e continue usando o produto. Se eles responderem e derem uma ideia se concordam que é um problema, talvez as pessoas parem de marcar com +1 para chamar a atenção para o problema.

Isso é apenas um problema porque eles lançaram include_role sem pensar em como realmente usá-lo na prática afetaria os padrões. Forçar alguém a escolher entre usar roles e include_role para fazer uma função funcionar corretamente ou adicionar trabalho extra para permitir que ambas funcionem simultaneamente é o cerne da questão aqui.

Meus 2 centavos.

PS Se você está downvoting + 1s porque você não quer as notificações .... aperte o botão de cancelar no canto superior direito e você não vai recebê-los mais.

OK, este assunto é importante para você. Eu entendi o ponto. Para mim também. É por isso que estou inscrito, BTW, e é por isso que não quero cancelar, e é por isso que eu votei contra spammers, e é por isso que votei positivamente no comentário original , que é a maneira civilizada de mostrar apoio _preguiçoso_ a ele.

Eu gostaria de acrescentar minha voz à solicitação dessa capacidade e detalhar meu caso de uso. Além da capacidade simples de separar grandes main.yml, a capacidade de fazer algo assim seria ótimo:

- name: Some name
  include_default_vars:
  with_first_found:
    - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"
   - main.yml

O que espero conseguir com isso é [como exemplo] uma função openssh que dê suporte a todas as opções ssh_config e sshd_config e ofereça suporte a vários sistemas operacionais e versões [ou seja, Debian 8/9, EL6 / 7, etc], mas que se chamado sem vars definido pelo usuário, irá construir com segurança a configuração para as configurações padrão OS_majorversion, mas que pode ter QUALQUER opção disponível sobrescrita pelo usuário.

Da forma como está agora, se eu colocar esses padrões do sistema operacional em include_vars, a precedência é muito alta e o usuário não pode substituir essas configurações no inventário, ou em group_vars / all ou em group_vars / groupname ou em host_vars etc.

Tenho certeza de que há uma maneira de fazer isso agora, mas qualquer coisa em que possa pensar é terrivelmente desagradável e feia e seria difícil de manter. Além disso, pelo menos até este ponto, ninguém que eu encontrei #ansible tem nenhuma ideia melhor sobre como fazer isso de uma maneira elegante e sustentável.

Adicionar esse recurso permitiria isso e pode ajudar a resultar em papéis de maior qualidade disponibilizados no github / galáxia.

@ ralphie02 não, isso não

Vars / feature_idea semelhantes: https://github.com/ansible/ansible/issues/11639

Este é realmente um PITA.
Se eu pudesse sugerir uma solução, seria adicionar uma opção, semelhante a include_vars , mas em meta/main.yml , para especificar a ordem de carregamento.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Isso permitiria a opção de padronizar para ["main.yml"] e não quebrar o código existente, dando aos desenvolvedores a capacidade de definir variáveis ​​granulares com base em contextos de sua escolha.

Eu realmente acho que esta é uma boa solução, não há nenhuma maneira realmente fácil agora de ter um conjunto diferente de padrões por os / version / etc. Essa implementação também mantém a compatibilidade com versões anteriores, portanto também é uma boa escolha.

Em linha com @abedwardsw (comentário antes):
A proposta antiga de @cornfeedhobo (15: +1 @ doubletwist13 ) seria realmente útil para muitas funções que conheço, em particular as bastante complexas:
https://github.com/hortonworks/ansible-hortonworks

Referências diretas aos seus comentários:

• https://github.com/ansible/ansible/issues/14248#issuecomment -254059046
• https://github.com/ansible/ansible/issues/14248#issuecomment -329027052

Veja também a proposta de @geerlingguy (de 2016!), E meu comentário lá (que tenta reunir questões relacionadas): https://github.com/ansible/proposals/pull/21#issuecomment -470048538