Como usar a nova funcionalidade Constructed Inventory no Ansible Automation Platform 2.4

Nova funcionalidade: Constructed Inventory

Neste post, apresentamos a ideia de uma nova maneira mais inteligente de lidar com o inventário com base no plugin de construção do Ansible. No Ansible Automation Platform 2.4, introduzimos essa funcionalidade com total suporte, e o objetivo deste post é apresentá-la a você. 

O Constructed Inventory é sucessor da funcionalidade de Smart Inventory e agora aparece como outra opção ao criar um inventário no controller do Ansible Automation Platform. A funcionalidade usa uma lista de inventários "normais" como entrada, faz as operações definidas pelo usuário, filtra e produz um inventário resultante com o conteúdo dos de entrada.

O que é Constructed Inventory?

Constructed Inventory tem função semelhante ao Smart Inventory, pois permite que os usuários executem tarefas em hosts em vários inventários. 

No entanto, o Constructed Inventory introduz novos recursos, como a capacidade integrada de definir e usar hostvars e groupvars:

• Os grupos estão presentes no inventário construído e desempenham um papel fundamental na configuração.
• A lógica definida pelo usuário (para adicionar grupos, vars e hosts selecionados) é executada por ansible-inventory, o que o controller faz para você, e é exibida na IU na atualização do inventário.
• O formato da lógica definida pelo usuário é o estilo amplamente usado do Ansible, o jinja2.

A premissa básica é que criar um inventário construído segue a mesma ideia de escrever um playbook, ao contrário do inventário inteligente, em que era necessário pensar em como a aplicação interpretaria o inventário.

Constructed Inventory na IU

Depois de clicar em Add compile inventory, em Inventories, será exibido este menu:

Há três itens importantes que são exclusivos do inventário construído.

• Input inventories: é onde você listará os inventários existentes dos quais o inventário construído obterá o conteúdo (hosts, grupos etc.).
• Limit: é passado diretamente a ansible-inventory e permite filtrar os hosts usando a sintaxe padrão para padrões de host do Ansible.
• Source vars: é a entrada para o plugin ansible.builtin.constructed inventory.

OBSERVAÇÃO: os inventários de entrada são ordenados de modo que, em caso de conflito de nomes de host e variáveis, as variáveis do último inventário terão precedência. As variáveis são mescladas. Portanto, isso não removerá a configuração de uma variável de um inventário de entrada anterior. Se não houver conflitos de nomes de host, isso não terá importância. Então, o exemplo usado aqui mencionará a ordem.

Não se preocupe com isso agora, pois esses elementos serão abordados no exemplo abaixo.

A forma mais simples do Constructed Inventory

É preciso ter pelo menos um inventário de entrada, mas não é necessário preencher os outros campos. Em algumas situações, faz sentido informar dois ou mais inventários de entrada e deixar "Limit" e "Source vars" em branco. Então, você pode executar tarefas que trabalham com uma combinação dos conteúdos de ambos os inventários de entrada. 

Constructed Inventory: casos de uso mais avançados

Para explicar a função de Limit e Source vars, que oferece a funcionalidade mais poderosa, é útil ter um exemplo concreto.

Como configurar o Constructed Inventory

Imagine que há dois inventários provenientes do mesmo provedor de nuvem, mas que abrangem diferentes regiões e, portanto, têm conjuntos de hosts distintos. Esses inventários são mantidos separados porque têm contas, funções e locais distintos. Neste exemplo, trabalharemos com inventários de entrada simples um da Região Leste e outro da Região Oeste.

Os inventários serão adquiridos de arquivos .ini no Git, que mantemos usando uma abordagem de configuração como código com práticas de DevOps.

Primeiro, configure um novo Project e o sincronize para saber de onde conseguir as informações de inventário. Selecione Projects na IU e clique em Add:

Depois de preencher os campos e salvar, o projeto será sincronizado automaticamente:

Agora, criaremos os novos inventários que farão referência às informações dos arquivos do projeto. Em "Inventories", clique em "Create":

Agora, clique em Sources e em Add:

Preencha o campo Name da origem. Neste caso, para os hosts da Região Leste, definimos Source como Sourced from a Project, informamos em "Project" o projeto recém-adicionado e usamos o east.ini apropriado como arquivo de origem:

Depois de salvar, clique no botão Sync para receber as informações:

Depois da sincronização, você poderá conferir o que foi processado se visualizar a saída da tarefa:

Neste caso, podemos constatar que três hosts e três grupos foram descobertos e adicionados automaticamente. Você pode conferir essas informações na IU, em Hosts.

Agora, vamos fazer a mesma coisa para a Região Oeste. Deixarei isso para você fazer como um exercício seguindo o exemplo acima, mas use as informações de west.ini como origem.

Nesse cenário hipotético, queremos executar tarefas em alguns dos hosts das regiões Leste e Oeste ao mesmo tempo, com base nos critérios que definiremos.

Então, vamos criar um novo constructed inventory na IU:

Adicionamos ambos os inventários em nuvem como entradas. Em seguida, usaremos Source vars para criar um novo grupo target_group e Limit para filtrar esse grupo:

Depois de sincronizar, podemos conferir o que aconteceu na saída da tarefa:

Agora temos quatro grupos com quatro hosts, que você pode procurar em Hosts e Groups na IU para confirmar o resultado. Vamos conferir os grupos deste exemplo:

A atualização copiou os grupos "account_1234", "account_4321" e "accounts" dos inventários de entrada no inventário construído resultante. 

Também podemos constatar que o inventário construído inclui o grupo target_group, sobre o qual falaremos em breve.

Se esse inventário construído fosse usado por um template para executar uma tarefa, qualquer um dos grupos definidos poderia ser usado.

Agora, o truque principal: se você consultar Source vars no formulário do inventário construído, encontrará a definição do novo grupo target_group.

  plugin: constructed
    strict: true
    groups:
        target_group: account_alias | default("") == "product_dev"

O target_group não constava nos inventários originais das Regiões Leste e Oeste. Ele foi criado pelo plugin de inventário construído quando a atualização ocorreu. 

Nesse caso, os hosts são adicionados ao grupo quando o template jinja2 {{ account_alias | default("") == "product_dev" }} se resolve em um valor verdadeiro (como 1, “1” ou True) para um host. 

Durante a atualização, esses templates são renderizados pelo Ansible para cada host nos inventários de entrada a fim de fazer essas avaliações. No caso de inventários de entrada maiores, a atualização pode levar alguns minutos para ser concluída. 

Os inventários construídos serão atualizados automaticamente antes da execução de uma tarefa de qualquer template que a utilize. Mas se essas atualizações estiverem demorando muito, você pode diminuir a frequência na opção Update cache timeout nas configurações do inventário construído na IU. Definir essa opção com um valor > 1 armazenará em cache os resultados da atualização do inventário construído por essa quantidade de segundos.

O template jinja2 para a criação de target_group incluirá um host se, ao inspecionar esse host, o hostvar de account_alias existir e for igual a product_dev. 

A sintaxe | default é necessária caso a variável não esteja definida para alguns hosts. 

O parâmetro restricted: true determina que fazer referência a uma variável indefinida fará com que a atualização do inventário falhe, o que torna "| default" necessário. 

Uso de "|default" e do parâmetro "strict" é uma prática recomendada para nos forçar a tornar um caso indefinido em explícito.

A construção de grupos pode ser útil para adicionar dinamicamente grupos que serão referenciados por playbooks. Por que fazer isso? Às vezes, vale a pena sintetizar grupos de hostvars porque podemos fazer com grupos coisas que não são possíveis com hostvars, como usar padrões de host, como em Limit neste exemplo. 

Se você analisar todos os hosts produzidos para nosso inventário construído:

Neste exemplo, podemos constatar que host3 no inventário east e host5 no inventário west não foram incluídos. Isso ocorreu porque eles estão em uma conta diferente nos inventários de entrada (account_4321), que tem um "account_alias" que não corresponde ao valor "product_dev" especificado. Observe que, embora o grupo de account_4321 tenha sido importado para o inventário construído, nenhum host desse grupo correspondeu ao nosso requisito. Portanto, o grupo importado está vazio no nosso inventário construído.

A entrada de "Source vars" pode incluir variáveis de host, além de grupos.

O repositório do GitHub do Alan também contém outro exemplo que pode ser útil para você. No construct.yml, resolvemos o estado de um host e o atribuímos a um número de grupos com base em se ele está desligado ou faz parte de um ambiente específico (desenvolvimento). A source of truth desse arquivo .yml pode vir de outros sistemas fora do Ansible Automation Platform. Podemos usá-la para executar automações em subconjuntos de hosts imediatamente.

Dicas de depuração

Para usar o exemplo anterior, ao desenvolver um inventário construído, você deve excluir o valor de "Limit" e alterar "Source vars" para o conteúdo a seguir.

Isso executará um template semelhante de {{ account_alias | default(“”) }} e o salvar em uma variável chamada "effective_account_alias". Ao deixar Limit em branco, teremos certeza de que obteremos todos os hosts dos inventários de entrada. Assim, podemos inspecionar detalhes de alta granularidade dos critérios de inclusão em hosts individuais, como os mostrados abaixo para o host3.

Aqui, constatamos que o valor avaliado "effective_account_alias" de hostvar é "sustaining", e não "product_dev". 

O plugin de inventário construído tem várias outras opções que podem ser muito úteis e poderosas. Consulte a documentação do plugin em https://docs.ansible.com/ansible/latest/collections/ansible/builtin/constructed_inventory.html para obter mais detalhes.

Alguns outros exemplos também podem ser encontrados no guia do usuário em https://docs.ansible.com/automation-controller/4.4/html/userguide/inventories.html#ug-inventories-constructed.

Resumo:

Esperamos que você tenha tido uma ideia do uso prático da funcionalidade Constructed Inventory dentro do Ansible Automation Platform. 

Como conceitos subjacentes, como padrão de host e plugin de inventário construído, são noções gerais do Ansible, os usuários poderão adicionar grupos e variáveis ou incluir hosts com base em critérios complexos e arbitrários.

Os benefícios incluem:

• A capacidade de criar grupos de forma dinâmica e usando várias sources of truth.
• A capacidade de filtrar, analisar e limitar hosts de vários inventários, mas permitir que eles sejam usados para executar automações.
• A capacidade de usar hostvars predefinidos na filtragem.
• Várias equipes podem ter os próprios inventários e metadados associados a seus respectivos hosts. E esses elementos podem ser usados de forma central no Ansible Automation Platform.