È possibile integrare Ansible Automation Platform, precedentemente Ansible Tower, con Automation Assembler per supportare la gestione della configurazione delle risorse distribuite. Dopo aver configurato l'integrazione, è possibile aggiungere i componenti virtuali di Ansible Automation Platform a distribuzioni nuove o esistenti dall'editor di modelli cloud.

Prerequisiti

  • Concedere agli utenti non amministratori le autorizzazioni appropriate per accedere ad Ansible Automation Platform. Sono disponibili due opzioni che sono compatibili con la maggior parte delle configurazioni. Scegliere quella più appropriata per la propria configurazione.
    • Concedere all'amministratore dell'inventario e all'amministratore dei modelli di processo ruoli a livello di organizzazione.
    • Concedere agli utenti l'autorizzazione di amministratore per un particolare inventario e il ruolo Esegui per tutti i modelli di processo utilizzati per il provisioning.

  • È necessario configurare le credenziali e i modelli appropriati in Ansible Automation Platform per l'utilizzo con le distribuzioni. I modelli possono essere modelli di processo o modelli di workflow. I modelli di processo definiscono l'inventario e il playbook da utilizzare con una distribuzione. Esiste una mappatura 1:1 tra un modello di processo e un playbook. I playbook utilizzano una sintassi simile a YAML per definire le attività associate al modello. Per la maggior parte delle distribuzioni tipiche, utilizzare le credenziali della macchina per l'autenticazione.

    I modelli di workflow consentono agli utenti di creare sequenze composte da una combinazione qualsiasi di modelli di processo, sincronizzazioni di progetti e sincronizzazioni di inventario collegate tra loro in modo che sia possibile eseguirle come singola unità. Il visualizzatore di workflow di Ansible Automation Platform consente agli utenti di progettare modelli di workflow. Per la maggior parte delle distribuzioni tipiche, è possibile utilizzare le credenziali della macchina per l'autenticazione.

    Se si utilizza Ansible Automation Platform, è necessario definire un ambiente di esecuzione in Ansible Controller per soddisfare le dipendenze di ansible-runner. Per ulteriori informazioni sugli ambienti di esecuzione e le immagini dei contenitori, vedere la documentazione di Ansible. In particolare, fare riferimento a https://docs.ansible.com/automation-controller/4.2.0/html/userguide/execution_environments.html.

    1. Accedere ad Ansible Automation Platform e passare alla sezione Modelli.
    2. Selezionare Aggiunta di un nuovo modello di processo.
      • Selezionare le credenziali già create. Queste sono le credenziali della macchina che deve essere gestita da Ansible Automation Platform. Per ogni modello di processo, può essere presente un solo oggetto credenziali.
      • Per la selezione del limite, selezionare Richiedi all'avvio. In questo modo, il modello di processo viene eseguito in base al nodo sottoposto a provisioning o a deprovisioning da Automation Assembler. Se questa opzione non è selezionata, viene visualizzato un errore di limite non impostato quando viene distribuito il blueprint che contiene il modello di processo.
    3. Selezionare Aggiunta di un nuovo modello di workflow.
      • Selezionare le credenziali già create e quindi definire l'inventario. Utilizzando il visualizzatore di workflow, progettare il modello di workflow.

      Nella casella Limite dei modelli di processo o workflow è in genere possibile selezionare Richiedi all'avvio. In questo modo, il modello di processo o workflow viene eseguito in base al nodo sottoposto a provisioning o a deprovisioning da Automation Assembler.

  • È possibile visualizzare l'esecuzione dei modelli di processo o dei modelli di workflow richiamati da Automation Assembler nella scheda Processi di Ansible Tower.

Procedura

  1. Selezionare Infrastruttura > Connessioni > Integrazioni e fare clic su Aggiungi integrazione.
  2. Fare clic su Ansible Tower.
    Viene visualizzata la pagina di configurazione di Ansible.
  3. Immettere il nome host, che può essere un indirizzo IP e le altre informazioni necessarie per l'istanza di Ansible Automation Platform.
  4. Immettere il nome utente e la password dell'autenticazione basata sull'interfaccia utente per l'istanza di Ansible Automation Platform applicabile.
  5. Fare clic su Convalida per verificare l'integrazione.
  6. Digitare un nome e una descrizione appropriati per l'integrazione.
  7. Fare clic su Aggiungi.

risultati

Ansible Tower è disponibile per l'uso nei modelli cloud.

Operazioni successive

Aggiungere i componenti di Ansible Automation Platform ai modelli cloud desiderati. È necessario specificare il modello di processo applicabile con l'autorizzazione di esecuzione per l'utente specificato nell'account di integrazione.

  1. Nella pagina della tela del modello cloud, selezionare Ansible sotto l'intestazione Gestione configurazione nel menu delle opzioni del blueprint e trascinare il componente di Ansible Automation Platform nella tela.
  2. Utilizzare il pannello a destra per configurare le proprietà di Ansible Automation Platform appropriate, ad esempio i modelli di processo.

Quando si aggiunge un riquadro Ansible Automation Platform a un modello cloud, VMware Aria Automation crea la voce dell'host per la macchina virtuale collegata in Ansible Automation Platform. Per impostazione predefinita, VMware Aria Automation utilizza il nome della risorsa della macchina virtuale per creare la voce dell'host, ma è possibile specificare qualsiasi nome utilizzando la proprietà hostName nel codice YAML del blueprint. Per comunicare con la macchina, VMware Aria Automation creerà la variabile host ansible_host: IP Address per la voce dell'host. È possibile ignorare il comportamento predefinito per configurare la comunicazione utilizzando il nome di dominio completo, specificando la parola chiave ansible_host in hostVariables e fornendo il nome di dominio completo come valore. Il seguente frammento di codice YAML mostra un esempio di come è possibile configurare la comunicazione del nome host e del nome di dominio completo:

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

In questo esempio si sovrascrive il valore ansible_host predefinito fornendo il nome di dominio completo. Questo può essere utile per gli utenti che desiderano che Ansible Tower si connetta alla macchina host utilizzando il nome di dominio completo.

Il valore predefinito di hostVariables nel codice YAML sarà ansible_host:IP_address e l'indirizzo IP viene utilizzato per comunicare con il server.

Se la proprietà count del codice YAML è maggiore di 1 per Ansible Automation Platform, il nome host può essere mappato a qualsiasi proprietà della rispettiva macchina virtuale. L'esempio seguente mostra la mappatura per una risorsa di una macchina virtuale denominata Ubuntu-VM se si desidera che la relativa proprietà address sia mappata al nome host.

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

Quando si aggiunge un componente Ansible Automation Platform a un modello cloud, è possibile il modello di processo da richiamare nel codice YAML del modello cloud. È inoltre possibile specificare i modelli di workflow o una combinazione di modelli di processo e modelli di workflow. Se non si specifica il tipo di modello, per impostazione predefinita VMware Aria Automation presuppone che venga richiamato un modello di processo.

Il seguente frammento di codice YAML illustra un esempio di come è possibile richiamare una combinazione di modelli di processo e workflow in un modello cloud di 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

Sono stati aggiunti maxConnectionsRetries e maxJobRetries per gestire gli errori relativi ad Ansible. I modelli cloud accettano il valore personalizzato e, nel caso non venga specificato alcun valore, utilizzano il valore predefinito. Per maxConnectionRetries, il valore predefinito è 10, mentre per maxJobRetries è 3.

Nota: Le versioni precedenti di VMware Aria Automation supportavano l'esecuzione dei modelli di processo utilizzando solo lo schema jobTemplate nel modello cloud. jobTemplate è ora obsoleto e potrebbe essere rimosso nelle versioni future. Per il momento, l'utilizzo della proprietà jobTemplate continuerà a funzionare come previsto. Per eseguire modelli di workflow e utilizzare le funzionalità aggiuntive, è consigliabile utilizzare lo schema dei modelli.

I modelli cloud di Cloud Assembly per le integrazioni di Ansible Automation Platform includono la proprietà useDefaultLimit con un valore true o false per definire la posizione di esecuzione dei modelli di Ansible. I modelli di Ansible possono essere modelli di processo o modelli di workflow. Se questo valore è impostato su true, i modelli specificati vengono eseguiti per la macchina specificata nella casella Limite della pagina dei modelli di Ansible. Se il valore è impostato su false, i modelli vengono eseguiti per la macchina sottoposta a provisioning, ma gli utenti devono selezionare la casella di controllo Richiedi all'avvio nella pagina dei modelli di Ansible Automation Platform. Per impostazione predefinita, il valore di questa proprietà è false. Il seguente esempio di codice YAML illustra come viene visualizzata la proprietà useDefaultLimit nei modelli cloud.

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

Inoltre, come illustrato nell'esempio precedente, è possibile utilizzare la proprietà extraVars per specificare variabili aggiuntive o variabili di sondaggio. Questa funzionalità può essere utile per l'esecuzione di modelli che richiedono input. Se un utente mantiene la variabile di sondaggio, è necessario passare la variabile nella sezione extraVars del modello cloud per evitare errori.

Gli utenti con privilegi di amministratore del cloud possono modificare il progetto di una distribuzione contenente le risorse Ansible Open Source e Ansible Automation Platform. La funzionalità è disponibile come azione giorno 2 a livello di distribuzione.

Per modificare il progetto per una distribuzione Ansible, selezionare l'opzione Modifica progetto nel menu Azioni della distribuzione, come mostrato nella pagina Distribuzioni di Cloud Assembly, quindi scegliere il progetto di destinazione e fare clic su Invia nella finestra di dialogo visualizzata.

Anche se l'integrazione di Ansible Tower non supporta la proprietà groups, esiste un'alternativa per i clienti per implementare la funzionalità equivalente utilizzando i tag della macchina virtuale e il plug-in dell'inventario VMware, come descritto nell'articolo seguente: https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_vm_inventory_inventory.html

Per utilizzarlo correttamente, gli utenti devono apportare due modifiche:
  • Utilizzare ansible_host (ad esempio, il nome di dominio completo) e hostName nel modello cloud.
  • In AWX, attivare l'aggiornamento all'avvio, ossia eseguire la sincronizzazione con il vCenter per i nuovi host prima di eseguire il playbook. La sincronizzazione unirà le voci dell'host del nome di dominio completo aggiunte da VMware Aria Automation e importate dal plug-in dell'inventario di VMware e assegnerà host ai gruppi. I gruppi di inventario vengono creati dai valori dei tag VM utilizzando le variabili di origine della sincronizzazione riportate sopra.
Nota: Sebbene VMware non supporti formalmente l'uso di AWX, funzionerà nel caso qui descritto.

Per un'implementazione esemplificativa, vedere il modello cloud seguente.

# 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.disney.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.disney.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}