Cloud Assembly supporta l'integrazione con Puppet Enterprise, Ansible Open Source e Ansible Tower in modo da poter gestire le distribuzioni per la configurazione e la deviazione.

Integrazione di Puppet

Per integrare la gestione della configurazione basata su Puppet, è necessario disporre di un'istanza valida di Puppet Enterprise installata su un cloud pubblico o privato con un carico di lavoro di vSphere. È necessario stabilire una connessione tra questo sistema esterno e l'istanza di Cloud Assembly. È quindi possibile rendere disponibile la gestione della configurazione di Puppet a Cloud Assembly aggiungendola ai blueprint appropriati.

Il fornitore di Puppet del servizio di blueprint di Cloud Assembly installa, configura ed esegue l'agente Puppet su una risorsa di elaborazione distribuita. Il fornitore di Puppet supporta le connessioni SSH e WinRM con i seguenti prerequisiti:

  • Connessioni SSH:
    • Il nome utente deve essere un super utente o un utente con autorizzazioni sudo per eseguire comandi con NOPASSWD.
    • Disattivare requiretty per l'utente specificato.
    • cURL deve essere disponibile nella risorsa di elaborazione della distribuzione.
  • Connessioni WinRM:
    • PowerShell 2.0 deve essere disponibile nella risorsa di elaborazione della distribuzione.
    • Configurare il modello di Windows come descritto nella documentazione di vRealize Orchestrator.

L'amministratore di DevOps è responsabile della gestione delle connessioni a un Puppet Master e dell'applicazione di ruoli di Puppet o delle regole di configurazione a distribuzioni specifiche. Dopo la distribuzione, le macchine virtuali configurate per supportare la gestione della configurazione vengono registrate con il Puppet Master designato.

Quando le macchine virtuali vengono distribuite, gli utenti possono aggiungere o eliminare un Puppet Master come sistema esterno o aggiornare i progetti assegnati al Puppet Master. Infine, gli utenti appropriati possono annullare la registrazione delle macchine virtuali distribuite dal Puppet Master quando le macchine vengono disattivate.

Integrazione di Ansible Open Source

Quando si configura un'integrazione di Ansible, installare Ansible Open Source in conformità alle istruzioni di installazione di Ansible. Per ulteriori informazioni sull'installazione, vedere la documentazione di Ansible.

Ansible attiva per impostazione predefinita il controllo della chiave host. Se un host viene reinstallato con una chiave diversa nel file known_hosts, verrà visualizzato un messaggio di errore. Se un host non è elencato nel file known_hosts, è necessario fornire la chiave all'avvio. È possibile disattivare il controllo della chiave host con le seguenti impostazioni nel file /etc/ansible/ansible.cfg o ~/.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

Per evitare errori di controllo della chiave host, impostare host_key_checking e record_host_keys su False, inclusa l'aggiunta di un'opzione UserKnownHostsFile=/dev/null aggiuntiva impostata in ssh_args. Inoltre, se l'inventario è vuoto inizialmente, Ansible segnala che l'elenco degli host è vuoto. In questo modo, il controllo della sintassi del playbook non riesce.

Ansible Vault consente di archiviare informazioni riservate, ad esempio password o chiavi, in file crittografati anziché come testo normale. Vault è crittografato con una password. In Cloud Assembly, Ansible utilizza Vault per crittografare dati quali le password ssh per le macchine host. Si presuppone che il percorso della password di Vault sia stato impostato.

È possibile modificare il file ansible.cfg per specificare la posizione del file della password utilizzando il formato seguente. 

vault_password_file = /path to/file.txt

È inoltre possibile impostare la variabile di ambiente ANSIBLE_VAULT_PASSWORD_FILE in modo che Ansible cerchi automaticamente la password. Ad esempio, ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt.

Cloud Assembly gestisce il file di inventario Ansible, pertanto è necessario assicurarsi che l'utente di Cloud Assembly disponga dell'accesso rwx nel file di inventario. 

cat ~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ | head -1)/log.txt
Se si desidera utilizzare un utente non root con l'integrazione open source di Cloud Assembly, gli utenti richiedono una serie di autorizzazioni per eseguire i comandi utilizzati dal provider open source di Cloud Assembly. I seguenti comandi devono essere impostati nel file sudoers dell'utente. 
Defaults:myuser !requiretty
Se l'utente non fa parte di un gruppo di amministratori che non dispone di alcuna applicazione askpass specificata, impostare il comando seguente nel file sudoers dell'utente. 
myuser ALL=(ALL) NOPASSWD: ALL

Se si verificano errori o altri problemi durante la configurazione dell'integrazione di Ansible, fare riferimento al file log.txt nel percorso 'cat~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ | head -1)/' in Ansible Control Machine.

Integrazione di Ansible Tower

Tipi di sistemi operativi supportati
  • Red Hat Enterprise Linux 8.0 o versione successiva a 64 bit (x86) supporta solo Ansible Tower 3.5 e versione successiva.
  • Red Hat Enterprise Linux 7.4 o versione successiva a 64 bit (x86).
  • CentOS 7.4 o versione successiva a 64 bit (x86).

Di seguito è riportato un file di inventario di esempio, generato durante un'installazione di Ansible Tower. Potrebbe essere necessario modificarlo per gli utilizzi di integrazione di 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