O Cloud Assembly oferece suporte à integração com o Puppet Enterprise, o Ansible Open Source e o Ansible Tower para poder gerenciar configuração e descompasso das implantações.

Integração com o Puppet

Para integrar o gerenciamento de configuração baseado no Puppet, é necessário ter uma instância válida do Puppet Enterprise instalada em uma nuvem pública ou privada com uma carga de trabalho do vSphere. É necessário estabelecer uma conexão entre este sistema externo e sua instância do Cloud Assembly. Em seguida, é possível tornar o gerenciamento de configuração do Puppet disponível para o Cloud Assembly adicionando-o aos blueprints apropriados.

O provedor Puppet do serviço de blueprint do Cloud Assembly instala, configura e executa o agente Puppet em um recurso de processamento implantado. O provedor Puppet oferece suporte a conexões SSH e WinRM com os seguintes pré-requisitos:

  • Conexões SSH:
    • O nome de usuário deve ser um super usuário ou um usuário com permissões sudo para executar comandos com NOPASSWD.
    • Desativar requiretty para o usuário especificado.
    • O cURL deve estar disponível no recurso de processamento na implantação.
  • Conexões WinRM:
    • O PowerShell 2.0 deve estar disponível no recurso de processamento de implantação.
    • Configure o modelo do Windows conforme descrito na documentação do vRealize Orchestrator.

O administrador do DevOps é responsável por gerenciar as conexões a um Puppet mestre e por aplicar funções de Puppets ou regras de configuração a implantações específicas. Após a implantação, as máquinas virtuais configuradas para oferecer suporte ao gerenciamento de configuração são registradas com o Puppet mestre designado.

Quando as máquinas virtuais são implantadas, os usuários podem adicionar ou excluir um Puppet mestre como um sistema externo ou atualizar projetos atribuídos ao Puppet mestre. Por fim, os usuários apropriados podem cancelar o registro de máquinas implantadas do Puppet Master quando essas máquinas são desativadas.

Integração do Ansible Open Source

Ao configurar uma integração do Ansible, instale o Ansible Open Source de acordo com as instruções de instalação do Ansible. Consulte a documentação do Ansible para obter mais informações sobre a instalação.

O Ansible habilita a verificação de chave de host por padrão. Se um host for reinstalado com uma chave diferente no arquivo known_hosts, uma mensagem de erro será exibida. Se um host não estiver listado no arquivo known_hosts, você deverá fornecer a chave na inicialização. É possível desativar a verificação da chave de host com a seguinte configuração no arquivo /etc/ansible/ansible.cfg ou ~/.ansible.cfg:
[defaults]
host_key_checking = False
localhost_warning = False
 
[paramiko_connection]
record_host_keys = False
 
[ssh_connection]
#ssh_args = -C -o ControlMaster=auto -o ControlPersist=60s
ssh_args = -o UserKnownHostsFile=/dev/null

Para evitar os erros de verificação da chave de host, defina host_key_checking e record_host_keys como False, incluindo a adição de uma opção extra UserKnownHostsFile=/dev/null definida no ssh_args. Além disso, se o inventário estiver vazio inicialmente, o Ansible avisará que a lista de hosts está vazia. Isso faz com que a verificação de sintaxe do playbook falhe.

O Ansible Vault permite armazenar informações confidenciais, como senhas ou chaves, em arquivos criptografados ao invés de texto simples. O cofre é criptografado com uma senha. No Cloud Assembly, o Ansible usa o Cofre para criptografar dados, como senhas SSH para máquinas de host. Ele assume que o caminho para a senha do cofre foi definido.

É possível modificar o arquivo ansible.cfg para especificar a localização do arquivo de senha usando o seguinte formato.

vault_password_file = /path to/file.txt

Também é possível definir a variável de ambiente ANSIBLE_VAULT_PASSWORD_FILE para que o Ansible pesquise a senha automaticamente. Por exemplo, ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt

O Cloud Assembly gerencia o arquivo de inventário do Ansible, portanto, é necessário garantir que o usuário o Cloud Assembly tenha acesso ao arquivo de inventário.

cat ~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ | head -1)/log.txt
Se quiser usar um usuário não root com a integração de código-fonte aberto do Cloud Assembly, os usuários precisarão de um conjunto de permissões para executar os comandos usados pelo provedor de código-fonte aberto do Cloud Assembly. Os seguintes comandos devem ser definidos no arquivo sudoers do usuário.
Defaults:myuser !requiretty
Se o usuário não fizer parte de um grupo de administradores que não tenha um aplicativo askpass especificado, defina o seguinte comando no arquivo sudoers do usuário.
myuser ALL=(ALL) NOPASSWD: ALL

Se você encontrar erros ou outros problemas ao configurar a integração com o Ansible, consulte o arquivo log. txt em 'cat~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ | head -1)/' na máquina de controle do Ansible.

Integração com o Ansible Tower

Tipos de sistemas operacionais com suporte
  • O Red Hat Enterprise Linux 8.0 ou posterior de 64 bits (x86) apenas oferece suporte ao Ansible Tower 3.5 e versões superiores.
  • Red Hat Enterprise Linux 7.4 ou posterior de 64-bit (x86).
  • CentOS 7.4 ou posterior de 64 bits (x86).

Esta é uma amostra de arquivo de inventário que é gerada durante uma instalação do Ansible Tower. Talvez seja necessário modificá-la para usos de integração com o Cloud Assembly.

[root@cava-env8-dev-001359 ansible-tower-setup-bundle-3.5.2-1.el8]# pwd
 
/root/ansible-tower-install/ansible-tower-setup-bundle-3.5.2-1.el8
 
[root@cava-env8-dev-001359 ansible-tower-setup-bundle-3.5.2-1.el8]# cat inventory
 
[tower]
 
localhost ansible_connection=local
 
 
 
 
[database]
 
 
 
 
[all:vars]
 
admin_password='VMware1!'
 
 
 
 
pg_host=''
 
pg_port=''
 
 
 
 
pg_database='awx'
 
pg_username='awx'
 
pg_password='VMware1!'
 
 
 
 
rabbitmq_port=5672
 
rabbitmq_vhost=tower
 
rabbitmq_username=tower
 
rabbitmq_password='VMware1!'
 
rabbitmq_cookie=cookiemonster
 
 
 
 
# Needs to be true for fqdns and ip addresses
 
rabbitmq_use_long_name=false
 
 
 
 
# Isolated Tower nodes automatically generate an RSA key for authentication;
 
# To deactivate this behavior, set this value to false
 
# isolated_key_generation=true