Configurer l'intégration d'Ansible Automation Platform/Ansible Tower dans Automation Assembler

Vous pouvez intégrer Ansible Automation Platform, anciennement Ansible Tower, à Automation Assembler pour prendre en charge la gestion de la configuration des ressources déployées. Après avoir configuré l'intégration, vous pouvez ajouter des composants virtuels d'Ansible Automation Platform à des déploiements nouveaux ou existants à partir de l'éditeur de modèle de cloud.

Conditions préalables

Accordez aux utilisateurs non-administrateurs les autorisations appropriées pour accéder à Ansible Automation Platform. Deux options fonctionnent pour la plupart des configurations. Choisissez celle qui convient le mieux à votre configuration.
- Accordez les rôles d'administrateur d'inventaire et d'administrateur de modèle de travail au niveau de l'organisation.
- Accordez aux utilisateurs l'autorisation Administrateur pour un inventaire particulier et le rôle Exécuter pour tous les modèles de tâches utilisés pour le provisionnement.
Vous devez configurer les informations d'identification et les modèles appropriés dans Ansible Automation Platform à utiliser avec vos déploiements. Les modèles peuvent être des modèles de tâche ou des modèles de workflow. Les modèles de tâches définissent l'inventaire et la règle à utiliser avec un déploiement. Il existe un mappage 1:1 entre un modèle de tâche et une règle. Les règles utilisent une syntaxe de type YAML pour définir les tâches associées au modèle. Pour la plupart des déploiements typiques, utilisez les informations d'identification de la machine pour l'authentification.
Les modèles de workflow permettent aux utilisateurs de créer des séquences composées de n'importe quelle combinaison de modèles de tâches, de synchronisations de projet et de synchronisations d'inventaire qui sont liés entre eux afin de pouvoir les exécuter en tant qu'unité unique. Le visualiseur de workflow d'Ansible Automation Platform aide les utilisateurs à concevoir des modèles de workflow. Pour la plupart des déploiements classiques, vous pouvez utiliser les informations d'identification de la machine pour l'authentification.
Si vous travaillez avec Ansible Automation Platform, vous devez définir un environnement d'exécution sur le contrôleur Ansible pour satisfaire les dépendances ansible-runner. Pour plus d'informations sur les environnements d'exécution et les images de conteneur, reportez-vous à la documentation Ansible. Reportez-vous plus particulièrement à la section https://docs.ansible.com/automation-controller/4.2.0/html/userguide/execution_environments.html.
1. Connectez-vous à Ansible Automation Platform et accédez à la section Modèles.
2. Sélectionnez Ajout d'un nouveau modèle de tâche.
  - Sélectionnez les informations d'identification que vous avez créées précédemment. Il s'agit des informations d'identification de la machine destinées à être gérées par Ansible Automation Platform. Pour chaque modèle de tâche, il peut y avoir un objet d'informations d'identification.
  - Pour la sélection Limite, sélectionnez Invite au démarrage. Cela garantit que le modèle de tâche s'exécute sur le nœud en cours de provisionnement ou d'annulation de provisionnement depuis Automation Assembler. Si cette option n'est pas sélectionnée, une erreur « Limite non définie » s'affiche lorsque le Blueprint qui contient le modèle de tâche est déployé.
3. Sélectionnez Ajout d'un nouveau modèle de workflow.
  - Sélectionnez les informations d'identification que vous avez déjà créées, puis définissez l'inventaire. À l'aide du visualiseur de workflow, concevez le modèle de workflow.
  Dans la zone Limite des modèles de workflows ou de tâches, vous pouvez généralement sélectionner Invite au démarrage. Cette sélection garantit que le modèle de la tâche ou de workflow s'exécute sur le nœud en cours de provisionnement ou d'annulation de provisionnement depuis Automation Assembler.
Vous pouvez afficher l'exécution des modèles de tâche ou de workflow appelés depuis Automation Assembler dans l'onglet Tâches d'Ansible Tower.

Procédure

Sélectionnez Infrastructure > Connexions > Intégrations et cliquez sur Ajouter une intégration.
Cliquez sur Ansible Tower.
La page de configuration Ansible s'affiche.
Entrez le Nom d'hôte (qui peut être une adresse IP) et les autres informations requises pour l'instance d'Ansible Automation Platform.
Entrez le Nom d'utilisateur et le Mot de passe de l'authentification basée sur l'interface utilisateur pour l'instance d'Ansible Automation Platform.
Cliquez sur Valider pour vérifier l'intégration.
Saisissez un Nom et une Description appropriés pour l'intégration.
Cliquez sur Ajouter.

Résultats

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

Que faire ensuite

Ajoutez des composants d'Ansible Automation Platform aux modèles de cloud souhaités. Vous devez spécifier le modèle de tâche applicable avec l'autorisation d'exécution pour l'utilisateur spécifié dans le compte d'intégration.

Sur la page de canevas de modèle de cloud, sélectionnez Ansible sous l'en-tête Gestion de la configuration du menu Options de Blueprint, et faites glisser le composant Ansible Automation Platform vers le canevas.
Utilisez le panneau de droite pour configurer les propriétés d'Ansible Automation Platform appropriées, telles que les modèles de travail.

Lorsque vous ajoutez une vignette Ansible Automation Platform à un modèle de cloud, VMware Aria Automation crée l'entrée d'hôte pour la machine virtuelle associée dans l'instance d'Ansible Automation Platform. Par défaut, VMware Aria Automation utilise le nom de ressource de la machine virtuelle pour créer l'entrée de l'hôte, mais vous pouvez spécifier n'importe quel nom à l'aide de la propriété hostName dans le YAML du Blueprint. Afin de communiquer avec la machine, VMware Aria Automation crée la variable d'hôte ansible_host: IP Address pour l'entrée de l'hôte. Vous pouvez remplacer le comportement par défaut pour configurer la communication à l'aide du nom de domaine complet (FQDN) en spécifiant le mot clé ansible_host sous hostVariables et en fournissant le nom de domaine complet comme valeur. L'extrait de code YAML suivant montre un exemple de configuration de la communication du nom d'hôte et du nom de domaine complet :

Cloud_Ansible_Tower_1:
	type: Cloud Ansible Tower
	properties:
		host: name of host
		account: name of account
		hostName: resource name
		hostVariables:
			ansible_host:Host FQDN

Dans cet exemple, vous remplacez la valeur ansible_host par défaut en fournissant le nom de domaine complet. Cela peut être utile aux utilisateurs qui souhaitent qu'Ansible Tower se connecte à la machine hôte à l'aide du nom de domaine complet.

La valeur par défaut hostVariables dans le code YAML est ansible_host:IP_address et l'adresse IP est utilisée pour communiquer avec le serveur.

Si la propriété de comptage YAML est supérieure à 1 pour Ansible Automation Platform, le nom d'hôte peut être mappé à l'une des propriétés de la machine virtuelle respective. L'exemple suivant montre le mappage d'une ressource de machine virtuelle nommée Ubuntu-VM si sa propriété d'adresse doit être mappée au nom d'hôte.

 hostname: '${resource.Ubuntu-VM.address[count.index]}'

Lorsque vous ajoutez un composant Ansible Automation Platform à un modèle de cloud, vous pouvez spécifier le modèle de tâche à appeler dans le fichier YAML du modèle de cloud. Vous pouvez également spécifier des modèles de workflow ou une combinaison de modèles de travail et de modèles de workflow. Si vous ne spécifiez pas le type de modèle, VMware Aria Automation considère par défaut que vous appelez un modèle de tâche.

L'extrait de code YAML suivant illustre comment une combinaison de modèles de tâche et de workflow peut être appelée dans un modèle de cloud Ansible Tower.

Cloud_Ansible_1:
type: Cloud.Ansible.Tower
  properties:
    host: ‘${resource.CentOS_Machine.*}’
    account:
    maxConnectionRetries: 2
    maxJobRetries: 2
    templates:
      provision:
        - name: My workflow
          type: workflow
        - name: My job template

Nous avons ajouté maxConnectionsRetries et maxJobRetries pour gérer les pannes liées à Ansible. Les modèles de cloud acceptent la valeur personnalisée et, si aucune valeur n'est fournie, ils utilisent la valeur par défaut. Pour maxConnectionRetries, la valeur par défaut est 10, pour maxJobRetries elle est 3.

Note : Les versions antérieures de VMware Aria Automation prenaient en charge l'exécution des modèles de tâche uniquement en utilisant le schéma jobTemplate dans le modèle de cloud. jobTemplate est devenu obsolète et pourrait être supprimé dans les prochaines versions. Pour le moment, l'utilisation de la propriété jobTemplate continue à fonctionner comme prévu. Pour exécuter des modèles de workflow et utiliser des fonctionnalités supplémentaires, il est recommandé d'utiliser le schéma de modèles.

Les modèles Automation Assembler pour les intégrations d'Ansible Automation Platform incluent la propriété useDefaultLimit avec une valeur true ou false pour définir où les modèles Ansible sont exécutés. Les modèles Ansible peuvent être des modèles de travail ou des modèles de workflow. Si cette valeur est définie sur true, les modèles spécifiés sont exécutés sur la machine spécifiée dans la zone Limite sur la page Modèles Ansible. Si la valeur est définie sur false, les modèles sont exécutés sur la machine provisionnée, mais les utilisateurs doivent cocher la case Invite au démarrage sur la page Modèles Ansible Automation Platform. Par défaut, la valeur de cette propriété est false. L'exemple de YAML suivant montre comment la propriété useDefaultLimit s'affiche dans les modèles de cloud.

templates:
  provision:
    - name: ping aws_credentials
      type: job
      useDefaultLimit: false
      extraVars: '{"rubiconSurveyJob" : "checkSurvey"}'

En outre, comme le montre l'exemple précédent, vous pouvez utiliser la propriété extraVars pour spécifier des variables supplémentaires ou des variables d'enquête. Cette capacité peut être utile pour l'exécution de modèles qui nécessitent une entrée. Si un utilisateur a conservé la variable d'enquête, vous devez la transmettre dans la section extraVars du modèle de cloud pour éviter les erreurs.

Les utilisateurs disposant de privilèges d'administrateur de cloud peuvent modifier le projet d'un déploiement contenant des ressources Ansible Open Source et Ansible Automation Platform. La fonctionnalité est disponible en tant qu'action de jour 2 au niveau du déploiement.

Pour modifier le projet d'un déploiement Ansible, sélectionnez l'option Modifier le projet dans le menu Actions du déploiement comme indiqué sur la page Déploiements de Automation Assembler, puis choisissez le projet cible et cliquez sur Envoyer dans la boîte de dialogue affichée.

Bien que l'intégration d'Ansible Tower ne prenne pas en charge la propriété groupes, les clients peuvent également implémenter des fonctionnalités équivalentes à l'aide des balises de machine virtuelle et du plug-in d'inventaire VMware, comme décrit dans l'article suivant : https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_vm_inventory_inventory.html

Pour en assurer le bon fonctionnement, les utilisateurs doivent apporter deux modifications :

Utilisez ansible_host (par exemple, nom de domaine complet) et hostName dans le modèle de cloud.
Dans AWX, activez la mise à jour sur l'indicateur de lancement, c'est-à-dire la synchronisation avec l'instance de vCenter pour les nouveaux hôtes avant d'exécuter le playbook. La synchronisation fusionnera les entrées d'hôte de nom de domaine complet ajoutées par VMware Aria Automation et importées par le plug-in d'inventaire VMware et attribuera des hôtes à des groupes. Les groupes d'inventaire sont créés à partir des valeurs de balise de machine virtuelle à l'aide des variables sources de synchronisation ci-dessus.

Note : Bien que VMware ne prenne pas formellement en charge l'utilisation d'AWX, cela fonctionnera dans le cas décrit dans le présent document.

Reportez-vous au modèle de cloud suivant pour obtenir un exemple d'implémentation.

# Created by Quickstart wizard.
name: RHEL 8
version: 0.0.1
formatVersion: 1
inputs:
  image:
    type: string
    description: Select an OS Version
    default: RHEL 8 Base
    enum:
      - RHEL 8 Base
      - RHEL 7 Base
  AWX:
    type: string
    description: Choose AWX Environment
    enum:
      - LabAWX
      - FA/CC-AWX
  envrionmnetTag:
    type: string
    description: Choose VM Environment
    enum:
      - cel
      - mag
      - wdr
  purposeTag:
    type: string
    description: Choose Server Purpose
    default: ''
    enum:
      - ''
      - mariadb
      - oracle
  authGroupTag:
    type: string
    description: Choose Authentication Group
    default: ''
    enum:
      - ''
      - dbo_linux
      - oracle
      - postgres
  hostname:
    type: string
    description: Desired hostname
    default: changeme
  cpuCount:
    type: integer
    description: Number of virtual processors
    default: 1
  totalMemoryMB:
    type: integer
    description: Machine virtual memory size in Megabytes
    default: 1024
  disk1Size:
    type: integer
    description: A SIZE of 0 will disable the disk and it will not be provisioned.
    default: 0
  disk2Size:
    type: integer
    description: A SIZE of 0 will disable the disk and it will not be provisioned.
    default: 0
  neededip:
    type: string
    description: Enter an available IP Address
    title: Needed-IP-Address
  vlan:
    type: string
    description: Enter in needed vlan
    title: Enter VLAN ID example "vl500"
resources:
  Cloud_Ansible_Tower_1:
    type: Cloud.Ansible.Tower
    metadata:
      layoutPosition:
        - 0
        - 0
    properties:
      host: ${resource.Cloud_vSphere_Machine_1.*}
      account: ${input.AWX}
      hostName: ${input.hostname}
      hostVariables:
        ansible_host: ${input.hostname}.dcl.wdpr.mycompany.com
      templates:
        provision:
          - name: Linux-Role
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    metadata:
      layoutPosition:
        - 0
        - 1
    properties:
      image: ${input.image}
      Infoblox.IPAM.Network.dnsSuffix: dcl.wdpr.mycompany.com
      Infoblox.IPAM.Network.dnsView: Internal
      customizationSpec: Rhel7Base
      name: ${input.hostname}
      cpuCount: ${input.cpuCount}
      totalMemoryMB: ${input.totalMemoryMB}
      attachedDisks: ${map_to_object(resource.Cloud_Volume_1[*].id + resource.Cloud_Volume_2[*].id, "source")}
      networks:
        - network: ${resource.Cloud_vSphere_Network_1.id}
          assignment: static
          address: ${input.neededip}
      tags:
        - key: Server-Team
          value: ${input.envrionmnetTag}
        - key: Server-Team
          value: ${input.purposeTag}
        - key: Server-Team
          value: ${input.authGroupTag}
  Cloud_Volume_1:
    type: Cloud.Volume
    metadata:
      layoutPosition:
        - 0
        - 2
    properties:
      count: '${input.disk1Size == 0 ? 0 : 1 }'
      capacityGb: ${input.disk1Size}
  Cloud_Volume_2:
    type: Cloud.Volume
    metadata:
      layoutPosition:
        - 0
        - 3
    properties:
      count: '${input.disk2Size == 0 ? 0 : 1}'
      capacityGb: ${input.disk2Size}
  Cloud_vSphere_Network_1:
    type: Cloud.vSphere.Network
    metadata:
      layoutPosition:
        - 1
        - 0
    properties:
      networkType: existing
      constraints:
        - tag: ${input.vlan}