Get best of the week

Integração via satélite e torre Ansible

Usando o Red Hat Satellite e a Plataforma de Automação Ansible da Red Hat? A partir do Satellite 6.3, eles podem ser integrados entre si para que o Inventário Dinâmico no Ansible Tower obtenha listas de hosts do Satellite. Além disso, se os hosts RHEL forem inicializados usando o Satellite (ou seja, provisionamento), o Ansible Tower poderá ser incorporado nesse processo para executar automaticamente scripts de configuração nos novos hosts.



Neste post, veremos como configurar o Inventário Dinâmico na Torre Ansible para que ele puxe os hosts do Satellite, e mostraremos como usá-lo com exemplos. Além disso, mostraremos como organizar uma chamada automática para a Ansible Tower após a inicialização de um novo host do Satellite.

1. Inventory. Satellite, Dynamic Inventory Ansible Tower


Para que o Ansible Tower tenha acesso à lista de hosts, grupos de hosts e outras informações relacionadas, ele precisa de uma conta no Satellite. Essa entrada possui permissões mínimas suficientes, portanto, criaremos uma nova função no Satellite, forneceremos apenas as permissões necessárias para o Ansible Tower e, em seguida, criaremos uma nova conta e atribuiremos a ela essa função.

O Satellite 6.6 e posterior já tem uma função de Leitor de Inventário da Torre Ansible pronta para isso, para que você possa pular as etapas abaixo para criar uma função.

No Satellite 6.3-6.5, a função terá que ser criada manualmente. Para fazer isso, vá para a interface da web do Satellite, vá para a tela Administer, selecione Roles e clique em Create Role. Nomeamos

essa função ansible_tower_integration_role e definimos Locais e Organizações para ela :



Clique em Enviar para criar a função. Depois disso, clique no nome dela e vá para a guia Filtros. Clique no botão verde Novo filtro e adicione os seguintes filtros, um de cada vez:

Tipo de recurso: Host , Permissão: view_hosts
Tipo de recurso: Grupo de hosts , Permissão: view_hostgroups
Tipo de recurso: Valor de fato , Permissão: view_facts

Como resultado, os seguintes filtros devem ter uma função:



Então, nós criamos um papel. Agora, iniciaremos um novo usuário no Satellite, para o qual vamos ao menu Administer , selecione Users e clique em Create User . Nomeamos esse usuário ansible_integration , altere o parâmetro Authorized by para INTERNAL e defina a senha. Em seguida, nas guias Locais e Organizações , selecione os locais / organizações apropriados. Por fim, vá para a guia Funções e atribua a esse usuário a função ansible_tower_integration_role recém-criada (se você tiver o Satellite 6.3 - 6.5) ou a função Ansible Tower Inventory Reader integrada(Satélite 6.6 e superior). Por fim, clique em Enviar para criar uma conta para este usuário.

Personalize a torre Ansible


Agora vá para a interface da web Ansible Tower e vá para a tela Credenciais . Clique no botão verde + (Adicionar) para criar uma nova entrada de credencial. Nós o chamamos de satellite_integration e, no Tipo de credencial, especificamos o Red Hat Satellite 6 . Em seguida, inserimos a URL (no nosso caso, Satellite 6), bem como o nome de usuário (no nosso caso, ansible_integration ), e a senha é a que definimos no Satellite acima:



Depois clique em Salvar .

Agora vá para a tela Inventários , clique no botão verde + (Adicionar) e selecione Inventário . Especifique satellite_inventory como o nome e clique em Salvar para criar um inventário. Depois disso, vá para a guia Origens do inventário recém-criado e clique no botão verde + (Adicionar) . Usamos satélite como o nome da fonte e especificamos o tipo de fonte como Red Hat Satellite 6 . No campo Credencial, especifique satellite_integration , que foi criado na etapa anterior. Ative a caixa de seleção Substituir ,Substituir variáveis e atualizar ao iniciar no grupo de controle Opções de atualização (você pode aprender mais sobre essas opções usando os pontos de interrogação à direita). Além disso, no campo Tempo limite do cache (segundos) , insira 90 e clique em Salvar .



Agora, sem sair da guia Fontes , clique no ícone Iniciar processo de sincronização :



Esperamos até o ícone ficar verde - isso indica uma conclusão bem-sucedida da sincronização.

Agora você pode ir para a guia Hosts e ver os dados que foram extraídos do Satellite:



Você também pode olhar para a guia Grupos:



Como você pode ver, a sincronização não apenas puxou as listas de hosts do Satellite, mas também as dividiu em grupos de acordo com as visualizações de conteúdo correspondentes no Satellite, grupos de hosts, ambientes de ciclo de vida, locais e organizações. Esse agrupamento pode ser usado para direcionar scripts Ansible nos hosts de destino, e isso é algo muito poderoso.

Se você selecionar um host na guia Hosts, veremos que entre o Satellite e a Ansible Tower muitas informações auxiliares sobre o host são sincronizadas, as quais são apresentadas na forma de variáveis. Essas variáveis ​​podem ser usadas nos scripts Ansible:



Usando inventário dinâmico vinculado ao satélite


Então, sincronizamos o Satellite e o Ansible Tower. Agora vamos considerar como usá-lo na prática.

A maneira mais fácil é usar satellite_inventory como a fonte de inventário no modelo de torre Ansible. Se a opção hosts: all estiver especificada no script , o script será executado em todos os hosts Satellite.

Uma opção mais avançada é usar grupos de inventário criados automaticamente em scripts (como eles são criados - veja acima), ou seja, especificar o grupo de hosts desejado na linha de hosts . Por exemplo, como neste cenário em que o pacote de tela está instalado:

---
- name: Install screen package
  hosts: "foreman_hostgroup_rhel6"
  tasks:
  - yum:
      name: screen
      state: installed

Aqui, registramos os hosts: foreman_hostgroup_rhel6 , indicando a lista de hosts que formam o grupo de hosts rhel6 no Satellite. Assim, o script será executado apenas nesses hosts.

Além disso, no script, você pode especificar na linha de hosts as variáveis ​​que o Ansible Tower recebe durante a sincronização com o Satellite. Por exemplo, você pode fazer isso:

---
- name: Install screen package
  hosts: "{{ hosts_var }}"
  tasks:
  - yum:
      name: screen
      state: installed

Como resultado, poderemos alterar o modelo de trabalho na torre Ansible rapidamente, indicando um dos grupos de inventário por meio de uma variável externa.



Neste exemplo, o modelo será executado apenas em hosts que são membros do grupo rhel7 no Satellite.

Além disso, o modelo de trabalho pode ser configurado para que, na inicialização, o usuário solicite o valor da variável hosts_var (e ao mesmo tempo exiba os grupos de inventário disponíveis na forma de comentários):



A tela acima ilustra a situação em que, ao iniciar o modelo, o usuário é solicitado a inserir o nome do grupo de inventário do Satellite em cujos hosts você deseja executar o script.

Além disso, você pode usar as variáveis ​​de host extraídas do Satellite durante a sincronização. Por exemplo, veja como um script mostra como fazer referência a essas variáveis:

---
- name: Show Satellite variables
  hosts: all
  tasks:
  - name: Show subscription_status
    debug:
      msg: >
        Subscription Status: {{ foreman.subscription_status_label }}
  - name: Show Errata Counts
    debug:
      msg: >
        Bug fixes: {{ foreman.content_facet_attributes.errata_counts.bugfix }},
        Security: {{ foreman.content_facet_attributes.errata_counts.security }},
        Enhancement: {{ foreman.content_facet_attributes.errata_counts.enhancement }},
        Total: {{ foreman.content_facet_attributes.errata_counts.total }}

Se você executar este script no Ansible Tower, ele mostrará os valores das variáveis:



E, é claro, essas variáveis ​​podem ser usadas em construções condicionais quando, para que as tarefas sejam iniciadas apenas sob determinadas condições. Por exemplo, se o host não tiver patches de segurança ou quando a assinatura do host for inválida.

Resumir


O Red Hat Satellite e o Red Hat Ansible são ferramentas muito poderosas e sua integração fornece sinergia tangível. Acima, mostramos como tornar o Satellite uma fonte de dados para o Inventário Dinâmico no Ansible e usá-lo na prática.
 

Parte 2. Ajustando automaticamente novos hosts por meio de provisionamento de retorno de chamada


Além de muitos outros recursos, o Satellite também pode inicializar hosts, ou seja, executar o provisionamento. A torre Ansible, por sua vez, foi projetada para configurar hosts. A integração permite garantir que, após a inicialização de um novo host RHEL por meio do Satellite, o Ansible Tower se conecte automaticamente a esse host e execute o script de configuração correspondente. Obviamente, esse esquema economiza muito tempo para os administradores de sistema, ajudando-os a responder mais rapidamente às necessidades da organização.

Note-se que este esquema só funciona se várias condições forem atendidas. Primeiro, o Satellite deve ser usado como fonte de dados do Inventário Dinâmico na Ansible Tower (abordamos esse problema na parte anterior). Em segundo lugar, a inicialização do host não deve ser feita apenas pelo Satellite, mas também pelo mecanismo do grupo de hosts (para obter mais detalhes, consulte o Guia de Aprovisionamento ).

Abaixo, mostramos como configurar o Satellite e o Ansible Tower para que, após a inicialização do host, o script de configuração do Ansible seja executado automaticamente.

Visão geral


As ferramentas de automação de TI, como a Ansible Tower, geralmente se enquadram em uma de duas categorias: algumas funcionam pelo método push, outras pelo método pull. Nos sistemas push aos quais a Ansible Tower pertence, o servidor de automação inicia uma conexão com o host. Nos sistemas pull, o iniciador é o host, que se comunica com o servidor de automação.

No nosso caso, com scripts automáticos em novos hosts, um esquema misto é usado. O host recém-inicializado entra em contato com o servidor de automação com uma solicitação para "ligar de volta" e configurar. Depois disso, o servidor de automação se conecta a esse host e executa o script de configuração solicitado pelo host. Portanto, no Ansible Tower, esse mecanismo é chamado de retorno de chamada de provisionamento, que pode ser traduzido como "retorno de chamada de inicialização".

Para mostrar por que o provisionamento de retorno de chamada é necessário, considere a seguinte situação: temos um certo script de configuração de host que é executado diariamente à meia-noite. Digamos que às 8 da manhã estamos inicializando vários novos servidores de uma só vez através do Satellite. Ao mesmo tempo, o Satellite é usado como uma fonte de dados do Inventário dinâmico na Ansible Tower, para que os hosts criados caiam automaticamente no Ansible. No entanto, o próximo lançamento do script de automação ocorrerá apenas à meia-noite, ou seja, após 16 horas. Obviamente, isso está longe de ser ideal e eu gostaria que o script fosse executado imediatamente após a inicialização do novo host. Para esse fim, o retorno de chamada de provisionamento também é pensado.

Em geral, o provisionamento de retorno de chamada é configurado e funciona da seguinte maneira:

  1. Ansible Tower credential root, Satellite . Tower , .
  2. Job Template Ansible Tower provisioning callback. URL Host Config Key, Ansible.
  3. Satellite , provisioning callback Ansible Tower, : URL- Ansible Tower, Host Config Key Ansible.
  4. Satellite /etc/systemd/system/ansible-callback.service ( RHEL 7 8; RHEL 6 ). provisioning callback Ansible Tower, , (URL-, Host Config Key ).
  5. Ansible Tower Host Config Key. , Tower , root, Job Template. , .

Ansible Tower Provisioning Callback


Vamos começar criando um script de configuração no servidor Ansible Tower que altera o conteúdo de / etc / motd, cria algum tipo de usuário e instala um pacote específico. Em seguida, usaremos esse script para configurar novos hosts imediatamente após serem inicializados.

Na vida real, os scripts de automação provavelmente são armazenados em algum sistema de controle de versão, mas, por simplicidade, assumimos que eles estão diretamente no servidor Ansible Tower. Portanto, entramos no servidor Ansible Tower via SSH e criamos o diretório / var / lib / awx / projects / provisioning para eles, executando o seguinte comando:

# mkdir /var/lib/awx/projects/provision

Em seguida, criamos nosso script nesse diretório, chamamos provision.yaml e escrevemos o seguinte conteúdo nele:

---

- name: Provision new host

  hosts: all

  tasks:

  - name: Set content in /etc/motd 

    copy:

      content: Authorized use only!

      dest: /etc/motd

      mode: 644

      owner: root

      group: root


  - name: Create brian user account

    user:

      name: brian

      uid: 10000

      state: present


  - name: Install tmux package

    yum:

      name: tmux

      state: present

Agora vá para a interface da web da Tower e vá para a tela Credenciais. Clique no botão verde de sinal de adição para criar uma nova entrada de credencial, atribua o nome provisioning_root e defina o Tipo de credencial como Máquina. No campo Nome de usuário, escreva root e, no campo Senha, especifique a senha especificada no Satellite para uso nos novos hosts do grupo de hosts correspondente no Satellite (seu nome pode ser encontrado na interface da web do Satellite na guia Sistema operacional). Usando esta entrada, o Ansible Tower poderá efetuar login nos novos hosts criados durante a inicialização via Satellite.



Depois disso, na interface Ansible Tower, vá para a tela Projetos e clique no sinal de mais verde para criar um novo projeto. Chame isso de provisão, altere Tipo de SCM para Manual e especifique a provisão como o Diretório do Playbook:



Em seguida, na interface Ansible Tower, vá para a tela Modelos, clique no sinal de adição verde para criar um novo Modelo de trabalho. Vamos chamá-lo de provisão; no campo Inventário, escreveremos Satellite, no campo Projeto - provisão, no campo Playbook - provision.yaml e no campo Credencial - provisioning_root. Além disso, você precisa habilitar a caixa de seleção Allow Provisioning Callbacks e clicar no ícone da varinha mágica à direita do campo Chave de configuração do host para gerar uma chave secreta. Essa chave é necessária para solicitar um retorno de chamada de provisionamento não poderia ser ninguém, mas apenas alguém que conhece a Chave de configuração do host. Sem a chave correta, o servidor da Ansible Tower simplesmente não responderá à solicitação.



Agora precisamos lembrar para o futuro o valor da Chave de configuração do host, bem como o ID do modelo, que pode ser encontrado na URL deste modelo de trabalho:

https://tower.example.com/#/templates/job_template/11

Neste exemplo, o ID é 11.

Configurando o Satellite para provisionar retorno de chamada


Agora vá para a interface da Web via satélite, vá para a tela Configure e clique em Host Groups. Selecionamos o grupo de hosts existente, que é usado ao inicializar novos hosts, em nosso exemplo, este é o RHEL 8.

Na tela de edição do grupo de hosts, vá para a guia Parameters e crie 4 novos parâmetros:

ansible_host_config_key - aqui inserimos a chave de configuração do host em nosso modelo de torre Ansible.
ansible_job_template_id - aqui escrevemos o ID do modelo, que descobrimos anteriormente no URL do modelo.
ansible_tower_fqdn é o nome de domínio totalmente qualificado do servidor Ansible Tower.
ansible_tower_provisioning - definido como verdadeiro.



Veja como tudo funciona


Agora, inicialize o novo host do Satellite e verifique se o retorno de chamada de provisionamento funciona e executa automaticamente nosso script nesse host.

Na interface da web do Satellite, vá para a tela Hosts, clique em Create Host e verifique se o grupo para o qual acabamos de criar 4 novos parâmetros é usado, ou seja, o grupo RHEL 8.



Após a inicialização do host, precisamos garantir que o modelo foi iniciado com sucesso. Para fazer isso, vá para a tela Modelos na interface da web do Ansible Tower, procure nosso modelo na lista e veja se o quadrado mais à esquerda do indicador ficou verde:



Clicamos nessa caixa verde para ver os detalhes do lançamento, que no nosso caso foram bem-sucedidos. Observe que esta tarefa tem um limite (Limit) - o lançamento de apenas novos hosts criados durante a inicialização. Bem, isso não é surpreendente, já que o mecanismo de retorno de chamada de provisionamento executa apenas o modelo nos hosts que o solicitam.



Agora vamos ao host recém-criado e verificamos se ele corresponde ao que está escrito no script:

[root@provision-test-rhel8 ~]# rpm -qa | grep tmux
tmux-2.7-1.el8.x86_64

[root@provision-test-rhel8 ~]# id brian
uid=10000(brian) gid=10000(brian) groups=10000(brian)

[root@provision-test-rhel8 ~]# cat /etc/motd
Authorized use only!

Solução de problemas


Se o modelo da torre Ansible não iniciar automaticamente em um novo host inicializado via satélite, há algumas coisas a serem verificadas.

A primeira etapa é descobrir se a Ansible Tower recebeu uma solicitação de retorno de chamada de provisionamento, como foi o script e se foi iniciado. Para fazer isso, na interface da Torre, vá para a tela Modelos e observe a cor do indicador ao lado do nome do modelo: verde - o lançamento foi bem-sucedido, vermelho - o lançamento falhou.



Se a caixa estiver vermelha, clicamos nela e procuramos informações adicionais para entender por que a inicialização falhou (podem ser erros de sintaxe no script e outros problemas).

Se o quadrado estiver verde, clicamos e olhamos de qualquer maneira, pois a tarefa pode relatar uma execução bem-sucedida, mas na verdade não foi iniciada em nosso host. Por exemplo, se a linha de hosts no script indicar hosts e grupos específicos, mas não incluir os hosts criados durante a inicialização, a tarefa relatará êxito, mas as informações adicionais dirão "ignorando: nenhum host corresponde".

Se o quadrado do indicador não for verde nem vermelho, será necessário começar verificando os parâmetros do grupo de hosts no Satellite. Verifique se o URL do servidor Ansible Tower, a chave de configuração do host e o ID do modelo estão especificados corretamente.

Em seguida, acesse o host recém-inicializado e verifique se há um arquivo /etc/systemd/system/ansible-callback.service (nos sistemas RHEL 7 ou 8) ou um arquivo /root/ansible_provisioning_call.sh (RHEL 6).

Se o arquivo não existir, verifique se o parâmetro ansible_tower_provisioning está definido como true para este grupo de hosts e se os padrões de inicialização no servidor Satellite não foram alterados.
Se o arquivo /etc/systemd/system/ansible-callback.service estiver presente no host, abra-o e procure o URL para o qual a solicitação de retorno de chamada de provisionamento é enviada:

[root@provision-test-rhel8 ~]# cat /etc/systemd/system/ansible-callback.service
[Unit]
Description=Provisioning callback to Ansible Tower
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/curl -k -s --data "host_config_key=aa5ebe82-491c-4fbb-bd36-a6657549451e" https://tower.example.com/api/v2/job_templates/11/callback/
ExecStartPost=/usr/bin/systemctl disable ansible-callback

[Install]
WantedBy=multi-user.target

Você pode executar curl e duplicar manualmente os comandos especificados neste arquivo para iniciar manualmente um retorno de chamada de provisionamento:

[root@provision-test-rhel8 ~]# /usr/bin/curl -k -s --data "host_config_key=aa5ebe82-491c-4fbb-bd36-a6657549451e" https://tower.example.com/api/v2/job_templates/11/callback/

Se uma chave de configuração de host inválida for especificada, receberemos a seguinte mensagem de erro:

[root@provision-test-rhel8 ~]# /usr/bin/curl -k -s --data "host_config_key=wrong-key-here" https://tower.example.com/api/v2/job_templates/11/callback/

{"detail":"You do not have permission to perform this action."}

Se o ID do modelo estiver especificado incorretamente (aqui - 43 em vez de 11), a resposta será a seguinte:

[root@provision-test-rhel8 ~]# /usr/bin/curl -k -s --data "host_config_key=wrong-key-here" https://tower.example.com/api/v2/job_templates/43/callback/

{"detail":"Not found."}

Você também pode desativar o modo silencioso (-s) no comando curl para exibir erros relacionados à resolução do nome do host, como no exemplo abaixo, onde substituímos o nome correto ansible.example.com pelo ansible-tower.example.com incorreto :

[root@provision-test-rhel8 ~]# /usr/bin/curl -k  --data "host_config_key=wrong-key-here" https://ansible-tower.example.com/api/v2/job_templates/11/callback/

curl: (6) Could not resolve host: ansible-tower.example.com

Além disso, ao descobrir a causa do erro, o arquivo /var/log/tower/tower.log no servidor Ansible Tower pode ser útil.
Por exemplo, este arquivo registra o uso de uma chave de configuração de host inválida:

2019-11-19 23:19:17,371 WARNING  awx.api.generics status 403 received by user AnonymousUser attempting to access /api/v2/job_templates/11/callback/ from 192.168.0.138

Isso também corrige o uso de um ID de modelo inválido:

2019-11-19 23:19:49,093 WARNING  awx.api.generics status 404 received by user AnonymousUser attempting to access /api/v2/job_templates/43/callback/ from 192.168.0.138

2019-11-19 23:19:49,095 WARNING  django.request Not Found: /api/v2/job_templates/43/callback/

Resumir


A integração do Satellite e do Ansible Tower pode otimizar muito a inicialização e a configuração de novos hosts, o que economiza muito tempo para os administradores de sistema, ajudando-os a responder mais rapidamente às necessidades da organização.

Em 24 de março, das 11:00 às 12:30, a Red Hat realizará um webinar “O que você precisa saber sobre automação: habilidades básicas possíveis” A

automação é um tópico que se aproxima da popularidade e do número de solicitações de transformação digital. Vamos falar sobre nossa visão da automação - junto com a Ansible e a Ansible Tower - e essas serão as informações básicas que abrirão a porta para o admirável mundo novo das ferramentas de automação declarativas.
Após este webinar, você entenderá as entidades Ansible básicas, como manual, inventário, módulo. Juntamente com você, dominaremos a sintaxe básica do YAML para que você possa escrever seus próprios scripts. Ele também considerará o lançamento de scripts e a escalada de privilégios.

Como resultado, você obterá um conjunto básico de habilidades que lhe permitirá estudar com êxito a documentação e outra literatura sem a sensação constante de que está perdendo alguma coisa. Registre-se e venha!

More articles:


All Articles