Recentemente eu passei por dois incidentes críticos no meu ambiente de trabalho. Quando digo crítico, é crítico mesmo. Derrubou o ambiente virtual inteiro (90% da operação). Começa que o DNS está lá, e a falta do DNS inutiliza praticamente 100% do ambiente para o usuário final (cerca 600 usuários diretos, sem contar os indiretos).

No primeiro deles, o incidente durou cerca de 16 horas. Iniciou às 11:30 da manhã e finalizou por volta das 03:00am do dia seguinte quando a equipe que tratou o incidente conseguiu levantar as primeiras VMs críticas para o funcionamento do negócio. A sorte desse dia é que era Copa do Mundo e, como regra no Brasil, todos os usuários estavam deixando o trabalho exatamente no início do incidente para assistir o jogo da seleção e iriam voltar somente no dia seguinte. Pouca gente percebeu o problema. Com exceção da equipe que tratou o incidente que sabia muito bem da gravidade dele.

No segundo, o incidente durou menos tempo. Cerca de 3 a 4 horas. E apesar de não ser dia de expediente normal, existia uma grande quantidade de colegas trabalhando, com hora extra autorizada. O incidente foi de menor duração porém o impacto foi maior. Afetou bastante a organização que pagou hora extra para funcionários que não trabalharam porque “os sistemas estavam indisponíveis”.

O que esses dois incidentes têm em comum? Ambos foram causados por mim. Sim. Eu. Com mais de 20 anos de experiência em gestão de infraestrutura de TI. Com bastante conhecimento em redes e configurações de ativos. Enfim, um técnico bastante confiável (modéstia a parte). Porém, num momento de distração causado por cansaço e excesso de confiança, dei conta de errar na configuração de switch, na hora de atribuir VLAN a uma porta. O resultado foi a interrupção de comunicação entre os controladores do cluster, causando queda de do ambiente virtualizado, criando o caos na infraestrutura.

Iniciativa

O livro The Visible Ops Handbook (Spafford, Kim and Behr) me trouxe o conceito de eletrificar a cerca em volta dos seus ativos mais críticos. E isso faz todo sentido. Se eu já tivesse eletrificado a cerca em volta desses switches, esses incidentes dificilmente teriam ocorridos. A organização teria processos mais bem definidos para alterar uma configuração tão crítica como essa.

Para eletrificar a cerca na prática decidimos por usar um conjunto de ferramentas, principalmente Ansible e Git. Os ativos de rede possuem módulos Ansible para a sua configuração. A ideia é que toda a configuração fique em playbooks Ansible e versionados no Git. Os administradores não terão mais credencial de acesso direto a esses ativos de rede, somente ao repositório Git. Farão alterações em uma branch, seguido de um Merge Request. Esse Merge Request será revisado por um par. Somente após a revisão e o aceite do Merge Request é que uma pipe-line de integração contínua vai aplicar, de forma automática, a alteração proposta. Somente o integrador terá acesso de administração ao ativo.

Conclusão

Com a cerca eletrificada a gente evita que um descuido gere um incidente de grandes proporções, principalmente por conta da revisão e por um processo mais bem definido. Além disso, passamos a ter o histórico de alteração da configuração dos ativos, o que ajuda muito na investigação de um incidente, saber o que foi alterado nos últimos tempos. A iniciativa promete deixar o ambiente bem mais estável.

Isso não deixa o processo mais burocrático? Pois é, nem toda burocracia é ruim! Assim que tiver os resultados volto a escrever sobre isso.

O Problema

O WhatsApp tem uma característica irritante que não consigo encontrar justificativa. No iPhone só é possível fazer backup no iCloud. No Android, só é possível fazer backup no Google Drive. Não é possível passar o backup de uma plataforma para a outra. Ou seja... o usuário que quiser migrar de uma plataforma para outra preservando o histórico irá viver um inferno.

Para migrar o WhatsApp do Android para o iPhone já é possível de maneira “oficial” através do aplicativo Migrar para iOS. Existem alguns blogs e vídeos no youtube que mostram como fazer passo-a-passo. Eu indico esse aqui: https://www.youtube.com/watch?v=ivDcM_Kdvz0

O problema é que serve apenas para o Aplicativo WhatsApp e não serve para o WhatsApp Business.

O desafio

Minha esposa usa os dois WhatsApp (normal e business) no mesmo aparelho. Um para assuntos pessoais, outro para assuntos de sua clínica de psicanálise. Após 4 anos tentando se adaptar ao universo Android, ela resolveu migrar de volta para o iOS (o que não julgo).

Tendo o WhatsApp como sua principal plataforma de comunicação, é obvio que ela queria migrar as duas aplicações para o novo smartphone levando junto seu histórico. Não tendo possibilidade de fazer isso de forma simples (ex. WhatsApp no iPhone poderia buscar backup no GoogleDrive), foi necessário uma trabalhosa solução de contorno, conforme abaixo.

Requisitos

• Paciência
• Espaço no iCloud suficiente para fazer backup dos dois WhatsApp
• Espaço no Google drive para fazer backup dos dois WhatsApp (não é realmente necessário, mas é recomendado)
• Tempo (dependendo do históricos a migração pode levar várias horas)

Passo-a-passo

• No Android: Antes de começar qualquer passo, forcei um backup nos dois WhatsApp. Não serão utilizados agora, mas servem como uma segurança a mais para “voltar atrás” caso necessário.
• Com iPhone padrão de fábrica foi feito a transferência do WhatsApp normal do Android para o iPhone, conforme instruções do vídeo https://www.youtube.com/watch?v=ivDcM_Kdvz0. Nesse primeiro passo, foque apenas na transferência do WhatsApp. Nem se preocupe com os demais dados que você queira transferir.
• No iPhone: Ao finalizar a recuperação de dados no iPhone, entrei no WhatsApp e fiz um backup no iCloud. Alguns erros podem ocorrer nesse momento da migração (ocorreram aqui). Dê uma olhada nos comentários do vídeo que tem bastante dica de como resolver. Certifique-se que o backup no iCloud foi feito com sucesso.
• No iPhone: Resetei o iPhone para padrão de fábrica. (Sim, foi necessário fazer tudo novamente).
• No Android. Eu forcei parada do Whatsapp e removi todos os dados (pode ser feito removendo o whatsapp e instalando novamente).
• No Android: Eu entrei no WhtasApp Business e forcei um backup. Sim, fiz isso novamente para ter um backup mais recente.
• No Android: Eu entrei no WhatsApp normal e informei o número vinculado ao WhatsApp Business. Recuperei o backup (nesse passo vem todo o histórico de mensagens e mídias, mas perde-se os dados específicos do WB como resposta automática e catálogos).
• Novamente iniciei o processo de migração de dados do iPhone para transferir o whatsapp novamente. Agora com o histórico do Business. Dessa vez, marque os demais dados que você queira levar do Android para o iOS. Com sorte, não vai precisar fazer isso novamente.
• No iPhone: Abri o WhatsApp (normal) e informei o número do WhatsApp Business para finalizar a migração de histórico.
• No iPhone: Instalei o WhatsApp Business e entrei com o número vinculado ao Business. Foi feita a migração das conversas do Whatsapp normal para o WhatsApp Business.
• No iPhone: Desinstalei o WhatsApp normal.
• No iPhone: Fiz um backup do WhatsApp Business para a iCloud.
• No iPhone: Instalei novamente o WhatsApp normal e entrei com o número original dele. Após registrar, restaurei backup que já tinha feito no iCloud. Pronto os dois WhatsApp foram migrados com todo o histórico de conversas e mídias.

Conclusão

O WhatsApp é péssimo. Inimigo da facilidade.

Nessa migração é perdida todas as funções específicas do WhatsApp Business como respostas automáticas ou catálogo de produtos.

Essa postagem é continuação do texto Ansible – inventario dinâmico VMWare e Ansible – inventario dinâmico VMWare – Alterando padrão de hostnames. Nele mostro como usar categorias e tags do vCenter com inventário dinâmico Ansible. Eu uso essas categorias para agrupar/separar as VMs criadas de acordo com a natureza delas. Uso categorias como Producao, Homologacao, TesteEspecifico, e assim por diante. Dentro dessas categorias eu crio tags padronizadas como basico, zabbix_server, zabbix_agent, upgrade, certificado e assim por diante. Dessa forma eu consigo aplicar meus playbooks em uma categoria de máquinas (ex. Homologacao) sem atingir as máquinas de outra categoria (ex. Producao).

Requisitos

• Possuir conhecimentos básicos de Ansible
• Possuir conhecimentos básicos de vCenter da VMWare

Cenário usado

Para validar essa postagem eu usei o seguinte ambiente:

• vCenter 6.7
• Ubuntu 22.04 minimal
• Ansible 2.14 (ppa)

Instalando

Instalando o Ansible via apt no Ubuntu.

$ sudo apt update
$ sudo apt install software-properties-common
$ sudo add-apt-repository --yes --update ppa:ansible/ansible
$ sudo apt install ansible-core

Essa instalação foi feita em um Ubuntu minimal recém instalado, que não possuía o Ansible instalado. Caso a sua instalação já possua um Ansible instalado, remova com sudo apt remove ansible

Instalando as bibliotecas adicionais para comunicação com vCenter.

$ sudo apt install pip
$ sudo apt install git
$ pip install pyvmomi
$ pip install --upgrade git+https://github.com/vmware/vsphere-automation-sdk-python.git
$ ansible-galaxy collection install community.vmware

O pacote git é instalado apenas para instalar o pacote vsphere-automation-sdk-python. Caso não queira instalar o git, use formas alternativas de instalação encontradas em https://github.com/vmware/vsphere-automation-sdk-python

Configurando

No vCenter

Não é o foco dessa postagem ensinar a gerenciar o vcenter, logo não irei entrar nos detalhes. Para esse exemplo funcionar é necessário criar no vCenter a Categoria Homologacao e as tags zabbix_agent, zabbix_server e basic. Crie as tags com underscore e não com traço. Caso use traço, será convertido para underscore e pode gerar confusão no futuro.

No Ansible

Crie um arquivo inventory.vmware.yml com o seguinte conteúdo

---
plugin: community.vmware.vmware_vm_inventory
strict: false
hostname: <fqdn ou ip do vcenter>
username: <usuario para acesso ao vcenter>
password: <senha do usuario para acesso ao vcenter>
validate_certs: false
with_tags: true
keyed_groups:
- key: "tag_category.Homologacao"
  prefix: ""
  separator: ""
- key: "summary.runtime.powerState"
  separator: ""
  prefix: ""
filters:
- "'Homologacao' in tag_category"

Esse arquivo é usado para agrupar as VMs da categoria “Homologacao”. Importantes diferenças em relação aos artigos anteriores: with_tags: true só funciona se o pacote vsphere-automation-sdk-python estiver instalado. O atributo filters serve para que apenas as VMs que possuem uma tag da categoria Homologacao seja retornada. As demais VMs existentes no ambiente serão ignoradas. Caso não use esse campo, as demais VMs virão no grupo ungrouped O agrupamento ocorre pelo atributo keyed_groups usando a chave tag_category.NomeDaCategoria. Com isso os grupos serão equivalentes as tags da categoria escolhida. É possível criar um arquivo desse para cada “ambiente”. Lembre-se apenas que o arquivo precisa terminar com .vmware.yml ou .vmware.yaml. Exemplo:

• producao.vmware.yml
• homologacao.vmware.yaml
• sandbox.vmware.yml
• novaImagem.vmware.yml

A saída do comando ansible-inventory agora fica assim:

@all:
  |--@ungrouped:
  |--@basic:
  |  |--radius
  |  |--VM-onsa-rlsp
  |--@poweredOn:
  |  |--radius
  |  |--VM-4spa-jh6g
  |  |--zabbix-server
  |  |--VM-2ztj-4ndb
  |  |--dhcp-sandbox
  |  |--VM-onsa-rlsp
  |--@zabbix_agent:
  |  |--VM-k8dn-duzv
  |  |--VM-4spa-jh6g
  |  |--VM-2ztj-4ndb
  |  |--dhcp-sandbox
  |--@poweredOff:
  |  |--VM-k8dn-duzv
  |--@zabbix_server:
  |  |--zabbix-server
  |--@Upgrade:
  |  |--VM-onsa-rlsp

Com essa forma de trabalhar é possível criar playbook de instalação do agente zabbix e colocar como target zabbix_agent. Se uma nova VM precisar do agente zabbix instalado, basta adicionar a tag correspondente à VM no vCenter e rodar novamente o seu playbook. Abaixo tem um exemplo de playbook de instalação do agente zabbix usando essa ideia:

- name: Agente zabbix
  hosts: zabbix_agent
  gather_facts: True
  strategy: free
  become: yes

  pre_tasks:
    - name: Definindo IP do servidor zabbix
      set_fact:
        zabbix_server: "{{ hostvars['zabbix-server'].guest.ipAddress }}"

  roles:
   - zabbix-agent

Note que a pre_task vai atrás de buscar o IP do servidor zabbix. Essa variável será usada pela role para usar na template de configuração do agente zabbix. Logo, se existir mais de um “ambiente” definido por categorias, é admissível ter múltiplos servidores zabbix (um para cada ambiente) e ao rodar seu playbook em um ambiente, os agentes zabbix serão configurados para atender o servidor do ambiente.

Conclusão

Com as categorias e tags do vCenter é possível agrupar as VMs em diferentes ambientes. Alterando os arquivos de configuração os playbooks serão executados apenas para o grupo específico de VM. Permitindo testar playbooks em grupos de máquinas de forma isolada.

Postagens relacionadas

• https://bolha.blog/ulysses-almeida/ansible-inventario-dinamico-vmware
• https://bolha.blog/ulysses-almeida/ansible-inventario-dinamico-vmware-alterando-padrao-de-hostnames

Referências:

https://docs.ansible.com/ansible/latest/collections/community/vmware/docsite/vmware_scenarios/vmware_inventory.html https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_vm_inventory_inventory.html https://www.ansiblepilot.com/articles/how-to-install-ansible-in-ubuntu-22.04-ansible-install/ https://github.com/vmware/vsphere-automation-sdk-python

Essa postagem é continuação do texto Ansible – inventario dinâmico VMWare. A postagem aborda como alterar o padrão de hostnames quando é usado inventário dinâmico VMWare com a ferramenta de automação Ansible.

Motivação

O padrão do inventário dinâmico do VMWare no Ansible é apresentar os hostnames como sendo a nome da vm concatenado com uuid da VM. Essa abordagem é boa para evitar que haja conflitos de nome. Caso tenha VMs com e mesmo nome em pastas separadas, não correrá o risco de ter dois ativos no inventário com o mesmo nome, uma vez que o uuid é único dentro do vcenter.

Por outro lado, essa abordagem é ruim na hora de definir os alvos do seu playbook, uma vez que é necessário saber de antemão qual o uuid da VM para incluir no campo hosts do seu playbook. Isso fica especialmente ruim quando um novo ambiente está sendo criado numa esteira de entrega.

Felizmente o plugin de inventário dinâmico VMWare permite alterar o padrão dos hostnames.

Requisitos

• Possuir conhecimentos básicos de Ansible
• Possuir conhecimentos básicos de vCenter da VMWare

Cenário usado

Para validar essa postagem eu usei o seguinte ambiente:

• vCenter 6.7
• Ubuntu 22.04 minimal
• Ansible 2.14 (ppa)

Instalando

Verifique os passos em Ansible – inventario dinâmico VMWare

Configurando

Usando o nome da VM

No arquivo de configuração do plugin o parâmetro usado para definir o hostname é o hostnames. O hostnames recebe uma lista de templates de nomes. O primeiro template que o plugin conseguir usar para compor o hostname, é o que será usado.

Para alterar o hostname contendo apenas o nome da VM, é necessário criar um arquivo inventory.vmware.yml com o seguinte conteúdo

---
plugin: community.vmware.vmware_vm_inventory
strict: false
hostname: <fqdn ou ip do vcenter>
username: <usuario para acesso ao vcenter>
password: <senha do usuario para acesso ao vcenter>
validate_certs: false
hostnames:
  - config.name

Teste com o comando

$ ansible-inventory -i inventory.vmware.yaml --graph

A saída ficará assim

@all:
  |--@ungrouped:
  |--@ubuntu64Guest:
  |  |--VM-k8dn-duzv
  |  |--VM-4spa-jh6g
  |  |--zabbix-sandbox
  |  |--VM-2ztj-4ndb
  |  |--dhcp-sandbox
  |  |--VM-onsa-rlsp
  |--@poweredOff:
  |  |--VM-k8dn-duzv
  |--@poweredOn:
  |  |--VM-4spa-jh6g
  |  |--zabbix-sandbox
  |  |--VM-2ztj-4ndb
  |  |--dhcp-sandbox
  |  |--VM-onsa-rlsp
  |  |--radius
  |--@windows9Server64Guest:
  |  |--radius

Agora é possível usar o hostname como target do seu playbook

---
- name: Update ubuntu servers
  hosts: zabbix-sandbox
  remote_user: root

  tasks:
...

Cuidado. Alterando o hostname dessa forma, sempre que for manipular o objeto no vcenter com os módulos vmware, não faça referência usando o nome da VM, pois pode haver conflito. Faça sempre usando o uuid ou moid. Dentro de um playbook usando inventário exclusivamente vmware é possível obter o uuid da VM usando {{ config.uuid}}. Essa variável já estará disponível. É adicionada ao hostvars pelo plugin de inventário dinâmico.

Outras composições

É possível compor o nome do host com outras informações da vm, como, por exemplo, usar o endereço IP no nome da VM.

---
plugin: community.vmware.vmware_vm_inventory
strict: false
hostname: <fqdn ou ip do vcenter>
username: <usuario para acesso ao vcenter>
password: <senha do usuario para acesso ao vcenter>
validate_certs: false
hostnames:
  - 'config.name+":"+guest.ipAddress'

produzindo a saída

@all:
  |--@ungrouped:
  |--@ubuntu64Guest:
  |  |--VM-k8dn-duzv
  |  |--VM-4spa-jh6g:172.18.202.26
  |  |--zabbix-sandbox:172.18.202.54
  |  |--VM-2ztj-4ndb:172.18.202.89
  |  |--dhcp-sandbox:172.18.202.10
  |  |--VM-onsa-rlsp:172.18.202.41
  |--@poweredOff:
  |  |--VM-k8dn-duzv
  |--@poweredOn:
  |  |--VM-4spa-jh6g:172.18.202.26
  |  |--zabbix-sandbox:172.18.202.54
  |  |--VM-2ztj-4ndb:172.18.202.89
  |  |--dhcp-sandbox:172.18.202.10
  |  |--VM-onsa-rlsp:172.18.202.41
  |  |--radius:172.18.3.38
  |--@windows9Server64Guest:
  |  |--radius:172.18.3.38

O plugin aceita uma lista de “templates” de informações. Quando o uso de uma template resulta num nome vazio, ele tenta usar a próxima template. Outro ponto importante é que o atributo usado pela template precisar ser carregado pelo campo properties. A documentação informa quais são os atributos padrão, mas é possível carregar qualquer um da lista de atributos vmware. Ao alterar o atributo properties, é necessário lembrar de colocar todos os atributos que você possa usar mais para frente, como, por exemplo, o config.uuid.

No exemplo abaixo criamos três templates, tomando o cuidado de carregar todos os atributos necessários

---
plugin: community.vmware.vmware_vm_inventory
strict: false
hostname: <fqdn ou ip do vcenter>
username: <usuario para acesso ao vcenter>
password: <senha do usuario para acesso ao vcenter>
validate_certs: false
properties:
  - config.name
  - config.guestId
  - config.uuid
  - config.annotation
  - guest.ipAddress
  - summary.runtime.powerState
hostnames:
 - config.annotation
 - guest.ipAddress
  - config.name

Resultando na seguinte saída:

@all:
  |--@ungrouped:
  |--@ubuntu64Guest:
  |  |--VM-k8dn-duzv
  |  |--172.18.202.26
  |  |--Servidor de testes com monitoramento ativo
  |  |--172.18.202.89
  |  |--172.18.202.10
  |  |--172.18.202.41
  |--@poweredOff:
  |  |--VM-k8dn-duzv
  |--@poweredOn:
  |  |--172.18.202.26
  |  |--Servidor de testes com monitoramento ativo
  |  |--172.18.202.89
  |  |--172.18.202.10
  |  |--172.18.202.41
  |  |--172.18.3.38
  |--@windows9Server64Guest:
  |  |--172.18.3.38

Conclusão

Usando o parâmetro hostname do plugin de inventário dinâmico você pode dar mais previsibilidade aos nomes do inventário, facilitando criar playbooks para VMs específicas, sem se preocupar com qual uuid a VM receberá no momento que for criada dentro do vCenter.

Postagens relacionadas

• https://bolha.blog/ulysses-almeida/ansible-inventario-dinamico-vmware
• https://bolha.blog/ulysses-almeida/ansible-inventario-dinamico-vmware-usando-tags

Referências:

• https://docs.ansible.com/ansible/latest/collections/community/vmware/docsite/vmware_scenarios/vmware_inventory.html
• https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_vm_inventory_inventory.html
• https://docs.ansible.com/ansible/latest/collections/community/vmware/docsite/vmware_scenarios/vmware_inventory_vm_attributes.html
• https://www.ansiblepilot.com/articles/how-to-install-ansible-in-ubuntu-22.04-ansible-install/ https://github.com/vmware/vsphere-automation-sdk-python

Certificados SSL estão em nossos cotidianos. A forma mais comum de manipulá-los é com o trio chave privada, certificado assinado, cadeia de certificado da CA. Para simplificar, diversos sistemas preferem trabalhar com arquivos pkcs12 (.p12). Esse artigo mostra como gerar esses arquivos a partir do trio citado.

Requisitos

• Possuir a chave privada do certificado (arquivo .key)
• Possuir o certificado assinado pela Autoridade Certificadora (arquivo .crt ou .pem)
• Possuir a cadeia de certificados das autoridades certificadoras (arquivo .crt ou .pem)

Cenário usado

Para validar esse documento usei

• Ubuntu 22.04
• openssl 3.0.2
• Certificado wildcard Let's Encrypt obtido via certbot

Usando openssl para gerar arquivo .p12

Nesse exemplo usei certificado fornecido pelo Let's Encrypt via certbot. Após uma solicitação bem sucedida do certificado, os arquivos ficam armazenados em /etc/letsencrypt/live/.

Caso use certificado obtido por outra Autoridade Certificadora, a ideia continua a mesma. Basta ter a chave gerada no momento da requisição (privkey.pem), o arquivo com o seu certificado assinado pela CA (cert.pem) e a cadeia de certificados intermediários da CA (chain.pem).

Obs: No diretório letsencrypt existem dois arquivos. chain e fullchain. Necessário usar o primeiro uma vez que o segundo possui, também, o certificado do servidor que está no cert.pem

Para gerar um arquivo p12

$ openssl pkcs12 -export -out certificado.p12 -inkey privkey1.pem -in cert1.pem -certfile chain1.pem

Para gerar um arquivo p12 compatível com openssl 1.1.1

Houve uma atualização no formado do arquivo p12 da versão do openssl 1.1.1 para a versão do openssl 3. Caso use o openssl 3 para gerar o arquivo .p12 para ser usado em ambientes legados que ainda fazem uso do algoritmo antigo (ex. appliance checkpoint em 2023 ou oracle JRE < 8u301), basta adicionar o parâmetro -legacy.

$ openssl pkcs12 -export -out certificado.p12 -inkey privkey1.pem -in cert1.pem -certfile chain1.pem -legacy

Para gerar um arquivo p12 compatível com Windows

Windows definitivamente não é meu forte. Posso estar falando besteira aqui. Mas pelo que entendi o Windows usa um algoritmo de cifragem específico. Para garantir que o openssl não use um algoritmo diferente, temos que foçá-lo a usar o PBE-SHA1-3DES para gerar um p12 compatível com servidores Windows.

$ openssl pkcs12 -export -certpbe PBE-SHA1-3DES -keypbe PBE-SHA1-3DES -nomac -out certificado.p12 -inkey privkey1.pem -in cert1.pem -certfile chain1.pem

Referências

https://www.openssl.org/docs/man1.1.1/man1/pkcs12.html https://www.misterpki.com/openssl-pkcs12-legacy/ https://learn.microsoft.com/en-us/answers/questions/995232/password-incorrect-when-import-certificate-on-serv?orderby=helpful

Automação é extremamente necessário para tornar possível a infraestrutura de TI acompanhar o dinamismo das necessidades de seus usuários. Criar, configurar, alterar e remover novos servidores torna-se parte da rotina diária das operações de TI. Como efeito colateral, é mais fácil perder a rastreabilidade desses servidores. Manter um inventário atualizado começa a se tornar uma tarefa trabalhosa. Para quem usa Ansible e o monitor de máquinas virtuais (hypervisor) da VMWare, é possível manter seu inventário atualizado, de forma automática, através de um plugin de inventário dinâmico. O inventário sempre irá refletir as VMs existentes no vCenter. Nesse post falarei sobre como instalar, configurar e usar essa ferramenta..

Requisitos

• Possuir conhecimentos básicos de Ansible
• Possuir conhecimentos básicos de vCenter da VMWare

Cenário usado

Para validar essa postagem eu usei o seguinte ambiente:

• vCenter 6.7
• Ubuntu 22.04 minimal
• Ansible 2.14 (ppa)

Instalando

Instalando o Ansible via apt no Ubuntu.

$ sudo apt update
$ sudo apt install software-properties-common
$ sudo add-apt-repository --yes --update ppa:ansible/ansible
$ sudo apt install ansible-core

Essa instalação foi feita em um Ubuntu minimal recém instalado, que não possuía o Ansible instalado. Caso a sua instalação já possua um Ansible instalado, remova com sudo apt remove ansible

Instalando as bibliotecas adicionais para comunicação com vCenter.

$ sudo apt install pip
$ pip install pyvmomi
$ ansible-galaxy collection install community.vmware

Configurando

Crie um arquivo inventory.vmware.yml com o seguinte conteúdo. Importante o arquivo finalizar com vmware.yml ou vmware.yaml. Caso não finalize dessa forma o filtro não será carregado.

---
plugin: community.vmware.vmware_vm_inventory
strict: false
hostname: <fqdn ou ip do vcenter>
username: <usuario para acesso ao vcenter>
password: <senha do usuario para acesso ao vcenter>
validate_certs: false

No meu ambiente de testes o vcenter usa um certificado auto-assinado. Se não for o seu caso, recomenda-se a remoção da última linha para que o certificado seja devidamente validado

Testando

Para testar, liste os hosts com o seguinte comando

$ ansible-inventory -i inventory.vmware.yaml --graph

Esse comando irá listar todas as VMs existentes no vcenter.

@all:
  |--@ungrouped:
  |--@ubuntu64Guest:
  |  |--VM-k8dn-duzv_42168141-84d3-4bd6-45c4-3b23bec5d81e
  |  |--VM-4spa-jh6g_42163c5e-7eca-7d91-c740-58b3a2d74b8e
  |  |--zabbix-sandbox_421695c6-a980-09af-d8ca-6a0dc712d9d1
  |  |--VM-2ztj-4ndb_42162ab4-0d78-00e8-fd86-624bcff76392
  |  |--dhcp-sandbox_42163f69-0b69-977c-80d8-0f9bf5437855
  |  |--VM-onsa-rlsp_42168bdc-0096-b4b2-623c-cf6896cea3e8
  |--@poweredOn:
  |  |--VM-k8dn-duzv_42168141-84d3-4bd6-45c4-3b23bec5d81e
  |  |--VM-4spa-jh6g_42163c5e-7eca-7d91-c740-58b3a2d74b8e
  |  |--zabbix-sandbox_421695c6-a980-09af-d8ca-6a0dc712d9d1
  |  |--VM-2ztj-4ndb_42162ab4-0d78-00e8-fd86-624bcff76392
  |  |--dhcp-sandbox_42163f69-0b69-977c-80d8-0f9bf5437855
  |  |--VM-onsa-rlsp_42168bdc-0096-b4b2-623c-cf6896cea3e8
  |  |--radius_4216b4ae-8277-3fd7-9ad2-260a9e83d756
  |--@windows9Server64Guest:
  |  |--radius_4216b4ae-8277-3fd7-9ad2-260a9e83d756

Algumas informações importantes dessa saída, que é a padrão do plugin:

• Os nomes dos ativos listados é uma composição do nome da VM no vcenter concatenado com o uuid da VM, separados por um _.
• As VMs são agrupadas pela família do sistema operacional e pelo estado da vm (Ligada ou desligada).

A inventário listado acima seria o equivalente ao seguinte arquivo .ini

[ungrouped]

[ubuntu64Guest]
VM-k8dn-duzv_42168141-84d3-4bd6-45c4-3b23bec5d81e
VM-4spa-jh6g_42163c5e-7eca-7d91-c740-58b3a2d74b8e
zabbix-sandbox_421695c6-a980-09af-d8ca-6a0dc712d9d1
VM-2ztj-4ndb_42162ab4-0d78-00e8-fd86-624bcff76392
dhcp-sandbox_42163f69-0b69-977c-80d8-0f9bf5437855
VM-onsa-rlsp_42168bdc-0096-b4b2-623c-cf6896cea3e8

[poweredOn]
VM-k8dn-duzv_42168141-84d3-4bd6-45c4-3b23bec5d81e
VM-4spa-jh6g_42163c5e-7eca-7d91-c740-58b3a2d74b8e
zabbix-sandbox_421695c6-a980-09af-d8ca-6a0dc712d9d1
VM-2ztj-4ndb_42162ab4-0d78-00e8-fd86-624bcff76392
dhcp-sandbox_42163f69-0b69-977c-80d8-0f9bf5437855
VM-onsa-rlsp_42168bdc-0096-b4b2-623c-cf6896cea3e8
radius_4216b4ae-8277-3fd7-9ad2-260a9e83d756

[windows9Server64Guest]
radius_4216b4ae-8277-3fd7-9ad2-260a9e83d756

E no campo target do playbook é possível usar poweredOn ou ubuntu64Guest, ou mesmo ubuntu64Guest:&poweredOn

---
- name: Update ubuntu servers
  hosts: ubuntu64Guest
  remote_user: root

  tasks:
...

Conclusão

Esse post mostra apenas como fazer a configuração inicial de um inventário dinâmico baseado no vCenter. Nos próximos posts será visto coisas bem mais divertidas como uso de filtros, tags, customização de informações e assim por diante. Todos os assuntos direcionados para a construção de uma esteira de entrega de máquinas virtuais baseada em configuração declarativa!

Referências:

• https://docs.ansible.com/ansible/latest/collections/community/vmware/docsite/vmware_scenarios/vmware_inventory.html
• https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_vm_inventory_inventory.html
• https://www.ansiblepilot.com/articles/how-to-install-ansible-in-ubuntu-22.04-ansible-install/