Você pode integrar o Ansible Tower com o Cloud Assembly 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 Tower 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 Tower. 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 Tower 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 Tower 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.
- Faça login no Ansible Tower 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 Tower. 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 Cloud Assembly. 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 Cloud Assembly.
- Você pode visualizar a execução dos modelos de trabalho ou fluxo de trabalho chamados do Cloud Assembly 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 Tower aos modelo 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 Tower até a tela.
- Use o painel à direita para configurar as propriedades apropriadas do Ansible Tower, como modelos de trabalho.
Quando você adiciona um bloco Ansible Tower a um modelo de nuvem, o vRealize Automation cria a entrada de host para a máquina virtual conectada no Ansible Tower. Por padrão, o vRealize 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 vRealize 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 “count” YAML for maior que 1 para o Ansible Tower, o nome do host poderá ser mapeado para qualquer uma das propriedades da respectiva máquina virtual. O exemplo a seguir mostra o mapeamento de um recurso de máquina virtual chamado Ubuntu-VM quando queremos que sua propriedade “address” seja mapeada para o nome do host.
hostname: '${resource.Ubuntu-VM.address[count.index]}'
Ao adicionar um componente Ansible Tower 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 vRealize 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.
Modelos de nuvem do Cloud Assembly para integrações com o Ansible Tower 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 Tower. 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.