Blog do Ulysses Almeida

Postagens aleatórias

Resumo

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

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

Resumo

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

Referências:

Resumo

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

Resumo

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: