Configurer l'intégration de Puppet Enterprise dans Automation Assembler

Automation Assembler prend en charge l'intégration avec la gestion de la configuration Puppet Enterprise.

Lorsque vous ajoutez le composant Puppet Enterprise à Automation Assembler en tant que système externe, il est par défaut disponible sur tous les projets. Vous pouvez en limiter l'utilisation à des projets spécifiques.

Pour ajouter une intégration de Puppet Enterprise, vous devez disposer du nom du Puppet Master et du nom d'hôte ou de l'adresse IP du master.

Si vous devez consulter les journaux Puppet pour vérifier des erreurs ou informations, vous les trouverez aux emplacements indiqués ci-dessous.


Description	Emplacement du journal
Journal pour les événements associés à la création et à l'installation	Les journaux se trouvent sur la machine déployée à l'adresse ~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ \| head -1)/. Pour obtenir les journaux complets, reportez-vous au fichier log.txt. Pour obtenir les journaux détaillés de l'agent Puppet, reportez-vous à https://puppet.com/docs/puppet/4.8/services_agent_unix.html#logging.
Journal pour les tâches associées à la suppression et l'exécution de Puppet	Les journaux se trouvent sur le PE à l'adresse ~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ \| head -1)/. Pour obtenir les journaux complets, reportez-vous au fichier log.txt.

Procédure

Sélectionnez Infrastructure > Connexions > Intégrations et cliquez sur Ajouter une intégration.
Sélectionnez Puppet.
Entrez les informations requises sur la page de configuration de Puppet.
Pour que l'intégration Puppet fonctionne correctement, les informations d'identification fournies doivent être valides pour le SSH et le compte de l'API. En outre, les comptes d'utilisateur du système d'exploitation et de l'application spécifiés doivent avoir les mêmes nom d'utilisateur et mot de passe.
Si vous avez besoin d'un proxy cloud, cliquez sur NOUVEAU PROXY CLOUD et entrez les informations requises. En général, un proxy cloud est requis uniquement si vous utilisez vSphere. Reportez-vous à la section Ajouter un proxy cloud à une instance de vCenter dans Automation Assembler.
Cliquez sur Valider pour vérifier l'intégration.
Cliquez sur Ajouter.

Résultats

Puppet est disponible pour une utilisation avec des modèles de cloud.

Que faire ensuite

Ajoutez des composants Puppet aux modèles de cloud souhaités.

Sous l'onglet Conception dans Automation Assembler, sélectionnez Puppet sous l'en-tête Gestion de contenu dans le menu Modèle de cloud et faites glisser le composant Puppet vers le canevas.

Entrez les propriétés de Puppet dans le volet de droite.


Propriété	Description
Master	Entrez le nom de la machine principale Puppet utilisée avec ce modèle de cloud.
Environnement	Sélectionnez l'environnement pour la machine principale Puppet.
Rôle	Sélectionnez le rôle Puppet qui sera utilisé avec ce modèle de cloud.
Intervalle d'exécution de l'agent	Fréquence à laquelle vous souhaitez que l'agent Puppet interroge la machine principale Puppet pour connaître les détails de configuration à appliquer aux machines virtuelles déployées associées à ce modèle de cloud.

Cliquez sur l'onglet Code dans le volet de droite afin d'afficher le code YAML pour les propriétés de configuration de Puppet.

Lorsque vous ajoutez un composant Puppet à un modèle de cloud, vous pouvez ajouter la propriété installMaster au fichier YAML afin de pointer vers un master d'installation Puppet, également appelé master de compilation. La valeur de cette propriété peut être l'adresse IP ou le nom d'hôte du master de compilation Puppet. L'utilisation de cette propriété permet d'accéder à des capacités améliorées pour les machines virtuelles Puppet déployées et également prendre en charge des actions du jour 2 supplémentaires.

  Puppet_Agent:
    type: Cloud.Puppet
    properties:
      account: PEIntegrationAccount
      environment: production
      role: 'role::linux_webserver'
      host: '${CentOS-Puppet.*}'
      username: root
      password: password123!
      installMaster: my-pe-compile-master.example.com
      agentConfiguration:
        certName: '${CentOS-Puppet.address}'
      osType: linux
      count: 1

Note : Bien que l'utilisateur défini ici soit racine, le modèle de cloud peut être configuré avec n'importe quel utilisateur inclus dans la liste sudoers.

Dans certains cas, VMware Aria Automation transmet des informations relatives à la machine aux machines virtuelles Puppet en tant que faits par défaut. Les éléments personnalisés ne sont pas pris en charge pour les machines Windows. Sur les machines Linux, certaines informations sont transmises par défaut et les utilisateurs peuvent transmettre des informations supplémentaires à l'aide de propriétés personnalisées.

Les éléments transmis aux machines Puppet sous Linux font l'objet de certaines limitations. Les propriétés personnalisées sur les ressources de l'hôte et sur l'agent Puppet sont transmises aux machines virtuelles Puppet. Les propriétés personnalisées sur les ressources réseau ne sont pas transmises à la machine virtuelle. Les éléments transmis incluent des propriétés simples, des propriétés booléennes, ainsi que des types personnalisés nommés et complexes, tels que des mappages imbriqués dans des groupes.

L'exemple suivant montre comment diverses ressources personnalisées peuvent être appelées sur des ressources d'hôte :

resources:
  Puppet-Host:
    type: Cloud.AWS.EC2.Instance
    properties:
      customer_specified_property_on_ec2_resource: "property"
      customer_specified_property_on_network_resource_that_should_also_be_a_fact_and_is_boolean: true
      CustomerNameStuff: "zone A"
      try_map:
      key: value
      keytwo: value
      nested_array:
        - one
        - two
        - true
      try_array:
        - one
        - two
        -three:
           inner_key: value

Si une commande de purge Puppet provoque des erreurs, dans la plupart des cas VMware Aria Automation ignorera les erreurs de purge des nœuds et procédera à la suppression du nœud. Même en l'absence d'un certificat pour un nœud spécifique, VMware Aria Automation procédera à la suppression. Si VMware Aria Automation ne peut pas poursuivre la suppression du nœud pour une raison quelconque, vous pouvez cliquer sur Supprimer dans le menu Actions de la page Déploiements pour ouvrir une boîte de dialogue qui vous permettra de poursuivre la suppression du nœud. Un workflow similaire est exécuté lorsque vous supprimez une intégration Puppet d'un modèle de cloud, puis que vous appliquez le modèle au déploiement. Ce workflow déclenche une opération de purge de nœud qui est gérée comme décrit ci-dessus.

L'intégration à Puppet Enterprise nécessite une adresse IP publique. Si aucune adresse IP publique n'est configurée pour la machine Puppet Enterprise, l'adresse IP de la première carte réseau est utilisée.

Si la carte réseau d'une machine Puppet provisionnée s'exécutant sur une machine vSphere dispose de plusieurs adresses IP, vous pouvez utiliser la propriété YAML primaryAddress dans les modèles de cloud pour spécifier l'adresse IP à utiliser pour les connexions. Lorsque la propriété primaryAddress est attribuée à une carte réseau, l'adresse IP de cette carte réseau est utilisée par Puppet. Une seule carte réseau peut être désignée comme principale. Voir l'extrait de code YAML suivant pour un exemple d'utilisation de la propriété primaryAddress.

BaseVM:
  type: Cloud.vSphere.Machine
  properties:
   image: photon
   count: 2
   customizationSpec: Linux
   cpuCount: 1
   totalMemoryMB: 1024
   networks:
    - network: '${resource.dev.id}'
     deviceIndex: 0
     primaryAddress: true
     assignment: static
    - network: '${resource.prod.id}'
     deviceIndex: 1
     assignment: static

Si la propriété primaryAddress n'est définie pour aucune carte réseau de machine virtuelle, la logique de modèle de cloud utilisera par défaut le comportement actuel pour la sélection de l'adresse IP.

Si vous souhaitez configurer l’intégration de Puppet pour un utilisateur non-racine disposant de privilèges Sudo, cet utilisateur doit être autorisé (activé) à exécuter les commandes suivantes.

L’utilisateur doit être autorisé à créer un répertoire et un fichier de facts Puppet :

sudo mkdir -p /etc/puppetlabs/facter/facts.d 
       sudo tee /etc/puppetlabs/facter/facts.d/puppet_cloudassembly_facts.json

L’utilisateur doit être autorisé à exécuter Puppet :

sudo /opt/puppetlabs/bin/puppet resource service puppet ensure=stopped
       sudo /opt/puppetlabs/bin/puppet agent --test --color=false --detailed-exitcode

L’utilisateur doit être autorisé à supprimer les fichiers CSR (Certificate Signing Request), y compris les fichiers csr_attributes.yaml et CSR pem :
```
 sudo rm /etc/puppetlabs/puppet/csr_attributes.yaml
       sudo rm -f /etc/puppetlabs/puppet/ssl/certificate_requests/*
```