Os ambientes de TI estão se tornando cada vez mais complexos. Nestas condições, é fundamental que o sistema de automação informática tenha informação atualizada sobre os nós que estão presentes na rede e sujeitos a processamento. No Red Hat Ansible Automation Platform, esse problema é resolvido por meio do chamado inventário () – listas de nós gerenciados.
Na sua forma mais simples, o inventário é um arquivo estático. Isso é ideal quando você começa a trabalhar com Ansible, mas à medida que a automação aumenta, ela se torna insuficiente.
E aqui está o porquê:
- Como você atualiza e mantém uma lista completa de nós monitorados quando as coisas estão mudando constantemente, quando as cargas de trabalho (e subsequentemente os nós em que elas são executadas) vêm e vão?
- Como classificar os componentes da infraestrutura de TI para selecionar especificamente os nós para aplicação de uma determinada automação?
O inventário dinâmico fornece respostas para essas duas perguntas () – um script ou plugin que busca nós a serem automatizados, referindo-se à fonte da verdade. Além disso, o inventário dinâmico classifica automaticamente os nós em grupos para que você possa selecionar com mais precisão os sistemas de destino para executar a automação específica do Ansible.
dê ao usuário Ansible a capacidade de acessar plataformas externas para pesquisar dinamicamente nós de destino e usar essas plataformas como fonte de verdade ao criar um inventário. A lista padrão de fontes no Ansible inclui plataformas em nuvem AWS EC2, Google GCP e Microsoft Azure, e também existem muitos outros plug-ins de inventário para Ansible.
Ansible Tower vem com vários , que funcionam imediatamente e, além das plataformas de nuvem listadas acima, fornecem integração com VMware vCenter, Red Hat OpenStack Platform e Red Hat Satellite. Para esses plug-ins, você só precisa fornecer credenciais para se conectar à plataforma de destino, após o que eles podem ser usados como fonte de dados de inventário no Ansible Tower.
Além dos plug-ins padrão incluídos no Ansible Tower, existem outros plug-ins de inventário suportados pela comunidade Ansible. Com a transição para esses plugins começaram a ser incluídos nas coleções correspondentes.
Nesta postagem, daremos um exemplo de trabalho com o plugin de inventário para ServiceNow, uma plataforma popular de gerenciamento de serviços de TI na qual os clientes geralmente armazenam informações sobre todos os seus dispositivos no CMDB. Além disso, o CMDB pode conter contexto ú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 plugin de inventário Ansible pode funcionar com ServiceNow CMDB e faz parte da coleção no portal .
Repositório Git
Para usar um plugin de inventário de uma coleção no Ansible Tower, ele deve ser definido como a origem 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 detalhes do inventário do plugin. No nosso caso, simplesmente especificamos a tabela no ServiceNow CMDB que queremos usar. Também definimos os campos que serão adicionados como variáveis de nó, além de algumas 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 alguma forma e não especifica nenhuma credencial para conexão. Configuraremos tudo isso mais tarde no Ansible Tower.
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 esta coleção em todos os nossos nós do Ansible Tower.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Depois de enviarmos essa configuração para o controle de versão, podemos criar um projeto no Ansible Tower que faça referência ao repositório correspondente. O exemplo abaixo vincula o Ansible Tower ao nosso repositório github. Preste atenção na URL do SCM: ela permite registrar uma conta para se conectar a um repositório privado, bem como especificar um branch, tag ou commit específico para check-out.
Criando credenciais para ServiceNow
Conforme mencionado, a configuração em nosso repositório não contém credenciais para conexão ao ServiceNow e não especifica a instância do ServiceNow com a qual nos comunicaremos. Portanto, para definir esses dados, criaremos credenciais no Ansible Tower. De acordo com , há uma série de variáveis de ambiente com as quais definiremos os parâmetros de conexão, por exemplo, assim:
= 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 estiver definida, o plugin de inventário a usará como uma conta para se conectar ao ServiceNow.
Também precisamos definir as variáveis SN_INSTANCE e SN_PASSWORD.
No entanto, não há credenciais desse tipo no Ansible Tower onde você possa especificar esses dados para o ServiceNow. Mas o Ansible Tower nos permite definir , você pode ler mais sobre isso no artigo .
No nosso caso, a configuração de entrada para credenciais personalizadas para ServiceNow é assim:
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
Estas credenciais serão expostas como variáveis de ambiente com o mesmo nome. Isto está descrito na configuração do injetor:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Assim, definimos o tipo de credencial que precisamos, agora podemos adicionar uma conta ServiceNow e definir a instância, nome de usuário e senha, assim:
Criamos inventário
Então agora estamos todos prontos para criar um inventário no Ansible Tower. Vamos chamá-lo de ServiceNow:
Depois de criar o inventário, podemos anexar uma fonte de dados a ele. Aqui especificamos o projeto que criamos anteriormente e inserimos o caminho para nosso arquivo de inventário YAML no repositório de controle de origem, no nosso caso é servicenow.yml na raiz do projeto. Além disso, você precisa vincular sua conta ServiceNow.
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 deverão 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 registramos credenciais com segurança para conectar-nos à nossa instância do ServiceNow. Vincular um plug-in de inventário de um projeto funciona não apenas com plug-ins de terceiros ou personalizados, mas também pode ser usado para modificar a operação de alguns inventários padrão. Isso torna a integração do Ansible Automation Platform fácil e contínua com as ferramentas existentes ao automatizar ambientes de TI cada vez mais complexos.
Você pode encontrar mais informações sobre os tópicos discutidos nesta postagem, bem como outros aspectos do uso do Ansible, aqui:
- Blogue por .
- .
- Lista de coleções suportadas pela Red Hat no site do Automation Hub ().
- .
*A Red Hat não garante que o código aqui contido esteja correto. Todos os materiais são fornecidos sem endosso, salvo indicação expressa em contrário.
Fonte: habr.com