Cloud Assembly prend en charge l'intégration avec Puppet Enterprise, Ansible Open Source et Ansible Tower pour vous permettre de gérer les déploiements de la configuration et le décalage.

Intégration Puppet

Pour intégrer la gestion de la configuration basée sur Puppet, vous devez disposer d'une instance valide de Puppet Enterprise installée sur un cloud privé ou public avec une charge de travail vSphere. Vous devez établir une connexion entre ce système externe et votre instance de Cloud Assembly. Vous pouvez ensuite mettre la gestion de la configuration de Puppet à la disposition de Cloud Assembly en l'ajoutant aux Blueprints appropriés.

Le fournisseur Puppet du service de Blueprint Cloud Assembly installe, configure et exécute l'agent Puppet sur une ressource de calcul déployée. Il prend en charge les connexions SSH et WinRM avec les conditions préalables suivantes :

  • Connexions SSH :
    • Le nom d'utilisateur doit être celui d'un super utilisateur ou d'un utilisateur disposant d'autorisations sudo pour exécuter les commandes avec NOPASSWD.
    • Désactivez requiretty pour l'utilisateur donné.
    • cURL doit être disponible sur la ressource de calcul de déploiement.
  • Connexions WinRM :
    • PowerShell 2.0 doit être disponible sur la ressource de calcul de déploiement.
    • Configurez le modèle Windows comme décrit dans la documentation de vRealize Orchestrator.

L'administrateur DevOps est chargé de la gestion des connexions à un Puppet Master et de l'application des rôles Puppet, ou des règles de configuration, à des déploiements spécifiques. Une fois le déploiement terminé, les machines virtuelles configurées pour la prise en charge de la gestion de la configuration sont enregistrées auprès du Puppet Master désigné.

Lorsque les machines virtuelles sont déployées, les utilisateurs peuvent ajouter ou supprimer un Puppet Master en tant que système externe ou mettre à jour les projets attribués au Puppet Master. Enfin, les utilisateurs appropriés peuvent annuler l'enregistrement des machines virtuelles déployées à partir du Puppet Master lorsqu'elles sont désaffectées.

Intégration de l'open source Ansible

Lors de la configuration d'une intégration Ansible, installez l'open source Ansible conformément aux instructions d'installation d'Ansible. Pour plus d'informations sur l'installation, reportez-vous à la documentation Ansible.

Ansible active par défaut la vérification des clés d'hôte. Si un hôte est réinstallé avec une clé différente dans le fichier known_hosts, un message d'erreur s'affiche. Si un hôte n'est pas répertorié dans le fichier known_hosts, vous devez fournir la clé au démarrage. Pour désactiver la vérification des clés de l'hôte, utilisez le paramètre suivant dans le fichier /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

Pour éviter les erreurs de vérification de la clé d'hôte, définissez host_key_checking et record_host_keys sur False, et ajoutez une option supplémentaire UserKnownHostsFile=/dev/null définie dans ssh_args. En outre, si l'inventaire est initialement vide, Ansible vous avertit que la liste d'hôtes est vide. Cela provoque l'échec de la vérification de la syntaxe du playbook.

Le coffre Ansible vous permet de stocker des informations sensibles, telles que des mots de passe ou des clés, dans des fichiers chiffrés, plutôt que sous forme de texte brut. Le coffre est chiffré avec un mot de passe. Dans Cloud Assembly, Ansible utilise son coffre pour chiffrer des données, telles que les mots de passe SSH des machines hôtes. Cela suppose que le chemin d'accès au mot de passe du coffre a été défini.

Vous pouvez modifier le fichier ansible.cfg pour spécifier l'emplacement du fichier de mot de passe en utilisant le format suivant : 

vault_password_file = /path to/file.txt

Vous pouvez également définir la variable d'environnement ANSIBLE_VAULT_PASSWORD_FILE pour qu'Ansible recherche automatiquement le mot de passe. Par exemple, ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt

Cloud Assembly gère le fichier d'inventaire Ansible, vous devez donc vous assurer que l'utilisateur Cloud Assembly dispose d'un accès rwx sur le fichier d'inventaire. 

cat ~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ | head -1)/log.txt
Si vous souhaitez utiliser un utilisateur non-racine disposant de l'intégration open source Cloud Assembly, les utilisateurs nécessitent un ensemble d'autorisations pour exécuter les commandes utilisées par le fournisseur open source Cloud Assembly. Les commandes suivantes doivent être définies dans le fichier sudoers de l'utilisateur. 
Defaults:myuser !requiretty
Si l'utilisateur ne fait pas partie d'un groupe d'administrateurs pour lequel aucune application askpass n'est spécifiée, exécutez la commande suivante dans le fichier sudoers de l'utilisateur : 
myuser ALL=(ALL) NOPASSWD: ALL

En cas d'erreurs ou d'autres problèmes lors de la configuration de l'intégration Ansible, reportez-vous au fichier log.txt situé dans « cat~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ | head -1)/ » sur la machine de contrôle Ansible.

Intégration d'Ansible Tower

Types de systèmes d'exploitation pris en charge
  • Red Hat Enterprise Linux 8.0 ou version ultérieure 64 bits (x86), prend uniquement en charge Ansible Tower 3.5 et versions ultérieures.
  • Red Hat Enterprise Linux 7.4 ou version ultérieure 64 bits (x86).
  • CentOS 7.4 ou version ultérieure 64 bits (x86).

Voici un exemple de fichier d'inventaire généré lors d'une installation d'Ansible Tower. Vous devrez peut-être le modifier pour les utilisations d'intégration de 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