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.
- Faça login no Ansible Automation Platform e navegue até a seção Modelos.
- 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.
- 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
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.
- 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.
- 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.
Os modelos do Automation Assembler para integrações da 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 Automation Assembler, 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
- Use
ansible_host
(por exemplo, FQDN) ehostName
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.
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}