Você pode integrar o Ansible Automation Platform e o antigo Ansible Tower com o Automation Assembler para oferecer suporte ao gerenciamento da configuração de recursos implantados. Depois de configurar a integração, será possível adicionar componentes virtuais do Ansible Automation Platform a implantações novas ou existentes a partir do editor de modelo de nuvem.

Pré-requisitos

  • Conceda aos usuários não administradores as permissões apropriadas para acessar o Ansible Automation Platform. Há duas opções que funcionam para a maioria das configurações. Escolha uma que seja a mais apropriada para a sua configuração.
    • Conceda aos usuários as funções Administrador de Inventário e Administrador de Modelos de Trabalho no nível da organização.
    • Conceda aos usuários permissão de Administrador para um inventário específico e a função Executar para todos os modelos de trabalho usados para provisionamento.

  • Você deve configurar as credenciais e os modelos apropriados no Ansible Automation Platform para uso com as suas implantações. Modelos podem ser modelos de trabalho ou modelos de fluxo de trabalho. Modelos de trabalho definem o inventário e o playbook para uso com uma implantação. Há um mapeamento de 1:1 entre um modelo de trabalho e um playbook. Playbooks usam uma sintaxe semelhante à do YAML para definir tarefas que estão associadas ao modelo. Para a maioria das implantações típicas, use credenciais de máquina para autenticação.

    Modelos de fluxo de trabalho permitem que os usuários criem sequências que consistem em qualquer combinação de modelos de trabalho, sincronizações de projeto e sincronizações de inventário vinculadas, para que você possa executá-las como uma única unidade. O Ansible Automation Platform Workflow Visualizer ajuda os usuários a criar modelos de fluxo de trabalho. Para a maioria das implantações típicas, você pode usar credenciais de máquina para autenticação.

    Se você estiver trabalhando com o Ansible Automation Platform, deverá definir um ambiente de execução no Ansible Controller para satisfazer as dependências do ansible-runner. Consulte a documentação do Ansible para obter mais informações sobre ambientes de execução e imagens de contêiner. Em particular, consulte https://docs.ansible.com/automation-controller/4.2.0/html/userguide/execution_environments.html.

    1. Faça login no Ansible Automation Platform e navegue até a seção Modelos.
    2. Selecione a opção para adicionar um novo modelo de trabalho.
      • Selecione as credenciais que você já criou. Estas são as credenciais da máquina a ser gerenciada pelo Ansible Automation Platform. Para cada modelo de trabalho, pode haver um objeto de credencial.
      • Para a seleção do limite, selecione a opção para avisar ao iniciar. Isso garante que o modelo de trabalho seja executado em relação ao nó que está sendo provisionado ou desprovisionado no Automation Assembler. Se essa opção não for selecionada, um erro de limite não definido será exibido quando o blueprint que contém o modelo de trabalho for implantado.
    3. Selecione Adicionando um novo modelo de fluxo de trabalho.
      • Selecione as credenciais que você já criou e defina o inventário. Usando o Workflow Visualizer, projete o modelo de fluxo de trabalho.

      Para a caixa Limite de modelos de fluxo de trabalho ou trabalho, geralmente você pode selecionar Avisar ao Iniciar. Essa seleção garante que o modelo de trabalho ou fluxo de trabalho seja executado no nó que está sendo provisionado ou desprovisionado do Automation Assembler.

  • Você pode visualizar a execução dos modelos de trabalho ou fluxo de trabalho chamados do Automation Assembler na guia Trabalhos do Ansible Tower.

Procedimento

  1. Selecione Infraestrutura > Conexões > Integrações e clique em Adicionar Integração.
  2. Clique em Ansible Automation Platform.
    A página de configuração do Ansible é exibida.
  3. Insira o Nome do Host, que pode ser um endereço IP, e outras informações necessárias para a instância do Ansible Automation Platform.
  4. Insira o Nome de Usuário e a Senha de autenticação com base em UI para a instância aplicável do Ansible Automation Platform.
  5. Clique em Validar para verificar a integração.
  6. Digite um Nome e uma Descrição apropriados para a integração.
  7. Clique em Adicionar.

Resultados

O Ansible Tower está disponível para uso em modelos de nuvem.

O que Fazer Depois

Adicione componentes do Ansible Automation Platform aos modelos de nuvem desejados. Você deve especificar o modelo de trabalho aplicável com permissão de execução para o usuário especificado na conta de integração.

  1. Na página da tela do modelo de nuvem, selecione Ansible sob o título Gerenciamento de Configuração no menu de opções do blueprint e arraste o componente Ansible Automation Platform até a tela.
  2. Use o painel à direita para configurar as propriedades apropriadas do Ansible Automation Platform, como modelos de trabalho.

Quando você adiciona um bloco Ansible Automation Platform a um modelo de nuvem, o VMware Aria Automation cria a entrada de host para a máquina virtual conectada no Ansible Automation Platform. Por padrão, o VMware Aria Automation usará o nome do recurso da máquina virtual para criar a entrada do host, mas pode especificar qualquer nome usando a propriedade hostName no YAML do blueprint. Para se comunicar com a máquina, o VMware Aria Automation criará a variável de host ansible_host: IP Address para a entrada do host. Você pode substituir o comportamento padrão para configurar a comunicação usando FQDN, especificando a palavra-chave ansible_host sob hostVariables e fornecendo o FQDN como seu valor. O seguinte snippet de código YAML mostra um exemplo de como o nome do host e a comunicação FQDN podem ser configurados:

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

Neste exemplo, você substitui o valor ansible_host padrão fornecendo o FQDN. Isso pode ser útil para usuários que desejam que o Ansible Tower se conecte à máquina host usando o FQDN.

O valor padrão de hostVariables no YAML será ansible_host:IP_address, e o endereço IP é usado para comunicação com o servidor.

Se a propriedade YAML "count" for maior que 1 para o Ansible Automation Platform, o nome do host poderá ser mapeado para qualquer uma das propriedades da respectiva máquina virtual. O exemplo a seguir mostrará o mapeamento de um recurso de máquina virtual chamado Ubuntu-VM se quisermos que sua propriedade "address" seja mapeada para o nome do host.

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

Ao adicionar um componente Ansible Automation Platform a um modelo de nuvem, você pode especificar o modelo de trabalho para chamar no YAML do modelo de nuvem. Você também pode especificar modelos de fluxo de trabalho ou uma combinação de modelos de trabalho e modelos de fluxo de trabalho. Se o tipo de modelo não for especificado, por padrão, o VMware Aria Automation assumirá que você está chamando um modelo de trabalho.

O seguinte snippet YAML mostra um exemplo de como uma combinação de modelos de trabalho e fluxo de trabalho pode ser chamada em um modelo de nuvem do 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

Adicionamos o maxConnectionsRetries e o maxJobRetries para lidar com falhas relacionadas ao Ansible. Os modelos de nuvem aceitam o valor personalizado e, caso nenhum valor seja fornecido, o valor padrão será usado. Para o maxConnectionRetries, o valor padrão é 10 e, para o maxJobRetries, o valor padrão é 3.

Observação: Versões anteriores do VMware Aria Automation ofereciam suporte à execução de modelos de trabalho apenas usando o esquema jobTemplate no modelo de nuvem. Agora, jobTemplate está obsoleto e talvez seja removido em releases futuros. Por enquanto, o uso da propriedade jobTemplate continuará funcionando conforme esperado. Para executar modelos de fluxo de trabalho e usar recursos adicionais, é recomendável usar o esquema de modelos.

Modelos de nuvem do Cloud Assembly para integrações com o Ansible Automation Platform incluem a propriedade useDefaultLimit com um valor "true" ou "false" para definir onde os modelos do Ansible são executados. Os modelos do Ansible podem ser modelos de trabalho ou modelos de fluxo de trabalho. Se esse valor for definido como true, os modelos especificados serão executados na máquina especificada na caixa Limite da página Modelos Ansible. Se o valor for definido como "false", os modelos serão executados na máquina provisionada, mas os usuários deverão marcar a caixa de seleção Avisar ao Iniciar na página Modelos do Ansible Automation Platform. Por padrão, o valor dessa propriedade é false. O exemplo YAML a seguir mostra como a propriedade useDefaultLimit aparece em modelos de nuvem.

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

Além disso, como mostra o exemplo anterior, você pode usar a propriedade extraVars para especificar variáveis extras ou variáveis de pesquisa. Esse recurso pode ser útil para executar modelos que requerem entrada. Se um usuário manteve a variável de pesquisa, você deve transmitir essa variável na seção extraVars do modelo de nuvem para evitar erros.

Os usuários com privilégios de administrador de nuvem podem alterar o projeto de uma implantação que contém recursos do Ansible Open Source e do Ansible Automation Platform. A funcionalidade está disponível como uma ação de dia 2 no nível da implantação.

Para alterar o projeto para uma implantação do Ansible, selecione a opção Alterar Projeto no menu Ações da implantação, conforme mostrado na página Implantações do Cloud Assembly, escolha o projeto de destino e clique em Enviar na caixa de diálogo exibida.

Embora a integração com o Ansible Tower não ofereça suporte à propriedade de grupos, há uma alternativa para os clientes implementarem uma funcionalidade equivalente usando as tags de VM e o plug-in de inventário da VMware, conforme descrito no seguinte artigo: https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_vm_inventory_inventory.html

Os usuários devem fazer duas alterações para que isso funcione:
  • Use ansible_host (por exemplo, FQDN) e hostName no modelo de nuvem.
  • No AWX, ative o sinalizador de atualização na inicialização, ou seja, sincronize com o vCenter para detectar novos hosts antes de executar o playbook. A sincronização mesclará as entradas do host FQDN adicionadas pelo VMware Aria Automation e importadas pelo plug-in de inventário da VMware e atribuirá hosts a grupos. Grupos de inventário são criados a partir de valores de tag de VM usando as variáveis de origem de sincronização acima.
Observação: Embora a VMware não ofereça suporte formal ao uso do AWX, ele funcionará no caso descrito aqui.

Consulte o modelo de nuvem a seguir para obter um exemplo de implementação.

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