
Em sua forma mais simples, um inventário é um arquivo estático. Isso é ideal quando você começa a usar o Ansible, mas conforme a automação se expande, torna-se insuficiente.
E é por causa disso:
- Como atualizar e manter atualizada uma lista completa de nós monitorados, quando algo está mudando constantemente, quando as cargas de trabalho - e depois delas os nós em que são executados - aparecem e desaparecem?
- -, ?
As respostas a ambas as questões fornecem um inventor dinâmico ( o inventário dinâmico a ) - o script ou plugin que parece ser as unidades de automação, referindo-se à fonte da verdade (fonte da verdade). Além disso, o inventário dinâmico categoriza automaticamente os nós em grupos para que você possa selecionar com mais precisão os sistemas de destino para executar uma automação Ansible.
Os plug-ins de inventário fornecem ao usuário Ansible a capacidade de acessar plataformas externas para localizar nós de destino dinamicamente e usar essas plataformas como uma fonte de verdade ao formar inventários. A lista de fontes Ansible padrão inclui plataformas em nuvem AWS EC2, Google GCP e Microsoft Azure, e há muitos outros plug-ins de inventário para Ansible.
O Ansible Tower vem com vários plug-ins de inventário que funcionam imediatamente e, além das plataformas em nuvem acima, fornecem integração com VMware vCenter, Red Hat OpenStack Platform e Red Hat Satellite. Para esses plug-ins, é suficiente fornecer credenciais para se conectar à plataforma de destino, após o que eles podem ser usados como uma fonte de dados de inventário no Ansible Tower.
Além dos plug-ins padrão fornecidos com o Ansible Tower, existem outros plug-ins de inventário suportados pela comunidade Ansible. Com a mudança para as Coleções de conteúdo Ansible da Red Hat, esses plug-ins foram incluídos em suas respectivas coleções.
Neste post, vamos dar um exemplo de trabalho com um plugin de inventário para ServiceNow, uma plataforma de gerenciamento de serviço de TI popular, na qual os clientes geralmente armazenam informações sobre todos os seus dispositivos no CMDB. Além disso, o CMDB pode conter contexto que é útil para automação, como informações sobre proprietários de servidores, níveis de serviço (produção / não produção), atualizações instaladas e janelas de manutenção. O plug-in de inventário Ansible pode funcionar com o CMDB ServiceNow e faz parte da coleção servicenow em galaxy.ansible.com .
Repositório Git
Para usar um plugin de inventário da coleção no Ansible Tower, ele deve ser definido como a fonte do projeto. No Ansible Tower, um projeto é uma integração com algum tipo de sistema de controle de versão, como um repositório git, que pode ser usado para sincronizar não apenas manuais de automação, mas também variáveis e listas de inventário.
Nosso repositório é realmente muito simples:
├── collections
│ └── requirements.yml
└── servicenow.yml
O arquivo servicenow.yml contém os detalhes do inventário do plug-in. Em nosso caso, simplesmente especificamos a tabela no CMDB ServiceNow que desejamos usar. E também definimos os campos que serão adicionados como variáveis de nó, além de certas informações sobre os grupos que queremos criar.
$ cat servicenow.yml
plugin: servicenow.servicenow.now
table: cmdb_ci_linux_server
fields: [ip_address,fqdn,host_name,sys_class_name,name,os]
keyed_groups:
- key: sn_sys_class_name | lower
prefix: ''
separator: ''
- key: sn_os | lower
prefix: ''
separator: ''
Observe que isso não especifica a instância do ServiceNow à qual nos conectaremos de forma alguma e não especifica nenhuma credencial para conexão. Vamos configurar tudo isso mais tarde na Torre Ansible.
O arquivo Collections / requirements.yml é necessário para que o Ansible Tower possa baixar a coleção necessária e, assim, obter o plugin de inventário necessário. Caso contrário, teríamos que instalar e manter manualmente essa coleção em todos os nós do Ansible Tower.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Depois de enviar essa configuração para o controle de origem, podemos criar um projeto no Ansible Tower vinculado ao repositório correspondente. O exemplo abaixo vincula a Torre Ansible ao nosso repositório github. Preste atenção ao URL do SCM: ele permite que você registre uma conta para se conectar a um repositório privado, bem como especificar um branch específico, tag ou commit para checkout.

Crie credenciais para ServiceNow
Conforme declarado, a configuração em nosso repositório não contém credenciais para se conectar ao ServiceNow e não completa a instância do ServiceNow com a qual nos comunicaremos. Portanto, para definir esses dados, vamos criar credenciais na Torre Ansible. De acordo com a documentação do plug-in de inventário ServiceNow , há uma série de variáveis de ambiente com as quais definiremos os parâmetros de conexão, por exemplo:
= username
The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by SN_TABLE
set_via:
env:
- name: SN_USERNAME
Nesse caso, se a variável de ambiente SN_USERNAME for definida, o plug-in de inventário irá usá-lo como uma conta para se conectar ao ServiceNow.
Também precisamos definir as variáveis SN_INSTANCE e SN_PASSWORD.
No entanto, o Ansible Tower não possui esse tipo de credencial onde se possa especificar esses dados para o ServiceNow. Mas o Ansible Tower nos permite definir tipos de credenciais personalizadas . Você pode ler mais sobre isso no artigo "Destaque do recurso do Ansible Tower: Credenciais personalizadas" .
Em nosso caso, a configuração de entrada para credenciais personalizadas para ServiceNow se parece com isto:
fields:
- id: SN_USERNAME
type: string
label: Username
- id: SN_PASSWORD
type: string
label: Password
secret: true
- id: SN_INSTANCE
type: string
label: Snow Instance
required:
- SN_USERNAME
- SN_PASSWORD
- SN_INSTANCE
Essas credenciais serão expostas como variáveis de ambiente com o mesmo nome. Isso é descrito na configuração do injetor:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Portanto, definimos o tipo de credencial de que precisamos, agora você pode adicionar a conta ServiceNow e definir a instância, nome de usuário e senha, assim:

Nós criamos inventário
Portanto, agora estamos prontos para criar um inventário na Torre Ansible. Vamos chamá-lo de ServiceNow:

Depois de criar o inventário, podemos anexar uma fonte de dados a ele. Aqui, apontamos para o projeto que criamos anteriormente e inserimos o caminho para o nosso arquivo YAML de inventário no repositório de controle de origem, em nosso caso é servicenow.yml na raiz do projeto. Além disso, a conta ServiceNow deve ser vinculada.

Para verificar como tudo funciona, vamos tentar sincronizar com a fonte de dados clicando no botão “Sincronizar tudo”. Se tudo estiver configurado corretamente, os nós devem ser importados para nosso inventário:

Observe que os grupos de que precisamos também foram criados.
Conclusão
Nesta postagem, vimos como usar plug-ins de inventário de coleções no Ansible Tower usando o plug-in ServiceNow como exemplo. Também protegemos as credenciais para se conectar à nossa instância ServiceNow. Vincular um plug-in de inventário de um projeto funciona não apenas com plug-ins de terceiros ou customizados, mas também pode ser usado para modificar o trabalho de alguns inventários regulares. Isso permite que a plataforma de automação Ansible se integre de forma contínua e contínua com as ferramentas existentes para automatizar ambientes de TI cada vez mais complexos.
Encontre mais informações sobre os tópicos abordados nesta postagem, bem como outros aspectos do uso do Ansible, aqui:
- Blog para automação usando ServiceNow Ansible .
- .
- Red Hat Automation Hub (cloud.redhat.com).
- Ansible Automation Platform.
*Red Hat . , .