search

britho / Ansible-HedHat

0 stars 0 forks source link

Aula-9 #6

Open britho opened 3 years ago

britho commented 3 years ago

Solução de problemas de playbooks
Exercício orientado: Solução de problemas de playbooks
Solução de problemas de hosts gerenciados do Ansible
Exercício orientado: Solução de problemas de hosts gerenciados do Ansible
Laboratório Aberto: Solução de problemas do Ansible
Sumário

Meta | Solucionar problemas de playbooks e hosts gerenciados. -- | -- Objetivos | Solucione problemas genéricos com um novo playbook e repare-os. Solucione falhas em hosts gerenciados ao executar um playbook. Seções | Solução de problemas de playbooks (e exercício orientado) Solução de problemas de hosts gerenciados do Ansible (e exercício orientado) Laboratório | Solução de problemas do Ansible

Objetivos

Depois de concluir esta seção, você deverá ser capaz de solucionar problemas genéricos com um novo playbook e repará-los.

Arquivos de log para o Ansible

Por padrão, o RedHat Ansible Engine não está configurado para registrar sua saída em nenhum arquivo de log. Ele fornece uma infraestrutura de registro integrada que pode ser configurada por meio do parâmetro log_path na seção default do arquivo de configuração ansible.cfg ou por meio da variável de ambiente $ANSIBLE_LOG_PATH. Se qualquer um deles ou ambos forem configurados, o Ansible armazena a saída dos comandos ansible e ansible-playbook no arquivo de log configurado, por meio do arquivo de configuração ansible.cfg ou por meio da variável de ambiente $ANSIBLE_LOG_PATH.

Se você configurar o Ansible para gravar arquivos de log em /var/log, a RedHat recomenda que você configure logrotate para gerenciar os arquivos de log do Ansible.

O módulo de depuração

O módulo debug fornece informações sobre o que está acontecendo na ação. Esse módulo pode exibir o valor de uma determinada variável em um determinado ponto da ação. Esse recurso é essencial para depurar tarefas que usam variáveis para se comunicarem (por exemplo, usando a saída de uma tarefa como a entrada de outra).

Os exemplos a seguir usam as configurações msg e var dentro das tarefas debug. O primeiro exemplo exibe o valor no tempo de execução do fato ansible_facts['memfree_mb'] como parte de uma mensagem impressa na saída de ansible-playbook. O segundo exemplo exibe o valor da variável output. 

- name: Display free memory
  debug:
    msg: "Free memory for this system is {{ ansible_facts['memfree_mb'] }}"
- name: Display the "output" variable
  debug:
    var: output
    verbosity: 2

Gerenciamento de erros

Há vários problemas que podem ocorrer durante a execução de um playbook, principalmente relacionados à sintaxe do playbook ou de qualquer um dos modelos que ele usa, ou devido a problemas de conectividade com os hosts gerenciados (por exemplo, um erro no nome do host gerenciado no arquivo de inventário). Esses erros são emitidos pelo comando ansible-playbook no tempo de execução.

Anteriormente, neste curso, você aprendeu sobre a opção --syntax-check, que verifica a sintaxe do YAML para o playbook. É uma boa prática executar uma verificação de sintaxe no seu playbook antes de usá-lo ou caso você venha a ter problemas com ele. 

[student@demo ~]$ ansible-playbook play.yml --syntax-check

Você também pode usar a opção --step para repassar uma tarefa do playbook por vez. O comando ansible-playbook --step solicita interativamente a confirmação de que você deseja que cada tarefa seja executada. 

[student@demo ~]$ ansible-playbook play.yml --step

A opção --start-at-task permite iniciar a execução de um manual de uma tarefa específica. Ela recebe como argumento o nome da tarefa na qual começar. 

[student@demo ~]$ ansible-playbook play.yml --start-at-task="start httpd service"

Depuração

A saída dada pela execução de um playbook com o comando ansible-playbook é um bom ponto de partida para a solução de problemas relacionados a hosts gerenciados pelo Ansible. Considere a seguinte saída de uma execução de playbook: 

PLAY [Service Deployment] ***************************************************
...output omitted...
TASK: [Install a service] ***************************************************
ok: [demoservera]
ok: [demoserverb]
PLAY RECAP ******************************************************************
demoservera                  : ok=2    changed=0    unreachable=0    failed=0
demoserverb                  : ok=2    changed=0    unreachable=0    failed=0

A saída anterior exibe um cabeçalho PLAY com a mesma ação a ser executada, seguida de um ou mais cabeçalhos TASK. Cada um desses cabeçalhos representa sua task associada no playbook e é executado em todos os hosts gerenciados pertencentes ao grupo incluído no playbook no parâmetro hosts.

Como cada host gerenciado executa as tarefas de cada ação, o nome do host gerenciado é exibido no cabeçalho TASK correspondente, juntamente com o estado da tarefa no host gerenciado. Os estados da tarefa podem aparecer como ok, fatal, changed ou skipping.

Na parte inferior do playbook de cada ação, a seção PLAY RECAP exibe o número de tarefas executadas para cada host gerenciado.

Como discutido anteriormente no curso, você pode aumentar o detalhamento da saída de ansible-playbook adicionando uma ou mais opções -v. O comando ansible-playbook -v oferece informações adicionais para depuração, com um total de quatro níveis.

Opção | Descrição -- | -- -v | Os dados da saída são exibidos. -vv | A saída e a entrada são exibidas. -vvv | Inclui informações sobre conexões com hosts gerenciados. -vvvv | Inclui informações adicionais, como scripts executados em cada host remoto, e o usuário que está executando cada script.

Práticas recomendadas para gerenciamento de playbooks

Apesar de as ferramentas discutidas anteriormente ajudarem a identificar e corrigir problemas nos playbooks, ao desenvolver novos playbooks, é importante lembrar-se de algumas práticas recomendadas que podem ajudar a facilitar o processo de solução de problemas. Veja abaixo algumas práticas recomendadas para o desenvolvimento de playbooks:

  • Use uma descrição concisa da finalidade da ação ou da tarefa para nomear as ações e tarefas. O nome da ação ou da tarefa é exibido quando o playbook é executado. Isso também ajuda a documentar o que cada ação ou tarefa deve realizar e, possivelmente, por que ela é necessária.

  • Inclua comentários para adicionar mais documentos em linha sobre as tarefas.

  • Use os espaços em branco verticais de maneira efetiva. Em geral, organize os atributos da tarefa verticalmente para facilitar a leitura.

  • É essencial que o recuo horizontal seja consistente. Use espaços, não a tecla Tab, para evitar erros de recuo. Configure seu editor de texto para inserir espaços ao pressionar a tecla Tab para facilitar.

  • Tente manter o playbook o mais simples possível. Use apenas os recursos necessários.

Configuring Ansible — Ansible Documentation

debug — Print statements during execution — Ansible Documentation

Best Practices — Ansible Documentation

britho commented 3 years ago

Neste exercício, você realizará a solução de problemas de um playbook fornecido que não funciona corretamente.

Resultados

Você deverá ser capaz de solucionar problemas em playbooks.

Faça login na workstation como student usando a senha student.

Na workstation, execute o script lab troubleshoot-playbook start. Ele verifica se o Ansible está instalado na workstation. Ele também cria o diretório /home/student/troubleshoot-playbook/ e faz download ali dos arquivos inventory, samba.yml e samba.conf.j2 a partir de http://materials.example.com/labs/troubleshoot-playbook/.

[student@workstation ~]$ lab troubleshoot-playbook start

Na workstation, acesse o diretório /home/student/troubleshoot-playbook/.

[student@workstation ~]$ cd ~/troubleshoot-playbook/

Crie um arquivo chamado ansible.cfg no diretório atual. Ele deve definir o parâmetro log_path para gravar logs do Ansible para o arquivo /home/student/troubleshoot-playbook/ansible.log. Ele deve definir o parâmetro inventory para usar o arquivo /home/student/troubleshoot-playbook/inventory implantado pelo script de laboratório.

Quando você terminar, ansible.cfg deverá ter os seguintes conteúdos:

[defaults]
log_path = /home/student/troubleshoot-playbook/ansible.log
inventory = /home/student/troubleshoot-playbook/inventory

Execute o playbook. Ele falhará com um erro.

Se tudo estivesse correto, esse playbook configuraria um servidor Samba. No entanto, ocorrerá uma falha na execução devido à falta de aspas na definição de variável random_var. Leia a mensagem de erro para ver como ansible-playbook relata o problema. Um valor com dois-pontos e sem aspas é atribuído à variável random_var.

[student@workstation troubleshoot-playbook]$ ansible-playbook samba.yml
ERROR! Syntax Error while loading YAML.
  mapping values are not allowed in this context

The error appears to have been in '/home/student/troubleshoot-playbook/samba.yml': line 8, column 30, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

    install_state: installed
    random_var: This is colon: test
                             ^ here

Confirme se o erro foi registrado adequadamente no arquivo /home/student/troubleshoot-playbook/ansible.log.

[student@workstation troubleshoot-playbook]$ tail ansible.log
The error appears to have been in '/home/student/troubleshoot-playbook/samba.yml': line 8, column 30, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

    install_state: installed
    random_var: This is colon: test
                             ^ here

Edite o playbook para corrigir o erro adicionando aspas ao valor inteiro sendo atribuído a random_var. A versão corrigida de samba.yml deverá conter o seguinte conteúdo:

...output omitted...
  vars:
    install_state: installed
    random_var: "This is colon: test"
...output omitted...

Verifique o playbook usando a opção --syntax-check. Outro erro ocorrerá devido ao espaço extra no recuo na última tarefa, deliver samba config.

[student@workstation troubleshoot-playbook]$ ansible-playbook --syntax-check \
> samba.yml
ERROR! Syntax Error while loading YAML.
  did not find expected key

The error appears to have been in '/home/student/troubleshoot-playbook/samba.yml': line 44, column 4, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

   - name: deliver samba config
   ^ here

Edite o playbook e remova o espaço extra de todas as linhas na tarefa. O playbook corrigido deve aparecer conforme segue:

...output omitted...
  - name: configure firewall for samba
    firewalld:
      state: enabled
      permanent: true
      immediate: true
      service: samba

  - name: deliver samba config
    template:
      src: templates/samba.conf.j2
      dest: /etc/samba/smb.conf
      owner: root
      group: root
      mode: 0644

Execute o playbook usando a opção --syntax-check. Ocorrerá um erro porque a variável install_state é usada como parâmetro na tarefa install samba. Não tem aspas.

[student@workstation troubleshoot-playbook]$ ansible-playbook --syntax-check \
> samba.yml
ERROR! Syntax Error while loading YAML.
  found unacceptable key (unhashable type: 'AnsibleMapping')

The error appears to have been in '/home/student/troubleshoot-playbook/samba.yml': line 14, column 15, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

      name: samba
      state: {{ install_state }}
              ^ here
We could be wrong, but this one looks like it might be an issue with
missing quotes.  Always quote template expression brackets when they
start a value. For instance:

    with_items:
      - {{ foo }}

Should be written as:

    with_items:
      - "{{ foo }}"

Edite o playbook e corrija a tarefa install samba. A referência à variável install_state deve estar entre aspas. O conteúdo do arquivo resultante deve parecer-se com o seguinte:

...output omitted...
  tasks:
  - name: install samba
    yum:
      name: samba
      state: "{{ install_state }}"
...output omitted...

Execute o playbook usando a opção --syntax-check. Ele não deve exibir erro algum de sintaxe adicional.

[student@workstation troubleshoot-playbook]$ ansible-playbook --syntax-check \
> samba.yml

playbook: samba.yml

Execute o playbook. Um erro, relacionado a SSH, será emitido.

[student@workstation troubleshoot-playbook]$ ansible-playbook samba.yml
PLAY [Install a samba server] **************************************************

TASK [Gathering Facts] *********************************************************
fatal: [servera.lab.exammple.com]: UNREACHABLE! => {"changed": false, "msg":"Failed to connect to the host via ssh: ssh: Could not resolve hostname servera.lab.exammple.com: Name or service not known\r\n", "unreachable": true}

PLAY RECAP *********************************************************************
servera.lab.exammple.com       : ok=0    changed=0    unreachable=1    failed=0

Certifique-se de que o host gerenciado servera.lab.example.com esteja em execução usando o comando ping.

[student@workstation troubleshoot-playbook]$ ping -c3 servera.lab.example.com
PING servera.lab.example.com (172.25.250.10) 56(84) bytes of data.
64 bytes from servera.lab.example.com (172.25.250.10): icmp_seq=1 ttl=64 time=0.247 ms
64 bytes from servera.lab.example.com (172.25.250.10): icmp_seq=2 ttl=64 time=0.329 ms
64 bytes from servera.lab.example.com (172.25.250.10): icmp_seq=3 ttl=64 time=0.320 ms

--- servera.lab.example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.247/0.298/0.329/0.041 ms

Verifique se você consegue se conectar ao host gerenciado servera.lab.example.com como o usuário devops usando SSH e se as chaves SSH corretas estão em funcionamento. Faça logout novamente quando terminar.

[student@workstation troubleshoot-playbook]$ ssh devops@servera.lab.example.com
Warning: Permanently added 'servera.lab.example.com,172.25.250.10' (ECDSA) to the list of known hosts.
...output omitted...
[devops@servera ~]$ exit
Connection to servera.lab.example.com closed.

Execute novamente o playbook com -vvvv para obter mais informações sobre a execução. Ocorrerá um erro porque o host gerenciado servera.lab.example.com não é atingível.

[student@workstation troubleshoot-playbook]$ ansible-playbook -vvvv samba.yml
...output omitted...

PLAYBOOK: samba.yml ******************************************************
1 plays in samba.yml

PLAY [Install a samba server] ********************************************

TASK [Gathering Facts] ***************************************************
task path: /home/student/troubleshoot-playbook/samba.yml:2
<servera.lab.exammple.com> ESTABLISH SSH CONNECTION FOR USER: devops
...output omitted...
fatal: [servera.lab.exammple.com]: UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: OpenSSH_7.8p1, OpenSSL 1.1.1 FIPS  11 Sep 2018\r\ndebug1: Reading configuration data /home/student/.ssh/config\r\ndebug1: /home/student/.ssh/config line 1: Applying options for *\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug3: /etc/ssh/ssh_config line 52: Including file /etc/ssh/ssh_config.d/01-training.conf depth 0\r\ndebug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf\r\ndebug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *\r\ndebug3: /etc/ssh/ssh_config line 52: Including file /etc/ssh/ssh_config.d/05-redhat.conf depth 0\r\ndebug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf\r\ndebug3: /etc/ssh/ssh_config.d/05-redhat.conf line 2: Including file /etc/crypto-policies/back-ends/openssh.config depth 1\r\ndebug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config\r\ndebug3: gss kex names ok: [gss-gex-sha1-,gss-group14-sha1-]\r\ndebug3: kex names ok: [curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1]\r\ndebug1: /etc/ssh/ssh_config.d/05-redhat.conf line 8: Applying options for *\r\ndebug1: auto-mux: Trying existing master\r\ndebug1: Control socket \"/home/student/.ansible/cp/d4775f48c9\" does not exist\r\ndebug2: resolving \"servera.lab.exammple.com\" port 22\r\ndebug2: ssh_connect_direct\r\ndebug1: Connecting to servera.lab.exammple.com [18.211.9.206] port 22.\r\ndebug2: fd 6 setting O_NONBLOCK\r\ndebug1: connect to address 18.211.9.206 port 22: Connection timed out\r\nssh: connect to host servera.lab.exammple.com port 22: Connection timed out",
    "unreachable": true
}

...output omitted...
PLAY RECAP ***************************************************************
servera.lab.exammple.com   : ok=0    changed=0    unreachable=1    failed=0

Quando você usa o nível de detalhes mais alto com o Ansible, o arquivo de log do Ansible é uma opção melhor para verificar a saída do que o console. Revise a saída dos comandos anteriores no arquivo /home/student/troubleshoot-playbook/ansible.log.

[student@workstation troubleshoot-playbook]$ tail ansible.log
2018-12-17 19:22:50,508 p=18287 u=student |  task path: /home/student/troubleshoot-playbook/samba.yml:2
2018-12-17 19:22:50,549 p=18287 u=student |  fatal: [servera.lab.exammple.com]: UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: OpenSSH_7.8p1, OpenSSL 1.1.1 FIPS  11 Sep 2018\r\ndebug1: Reading configuration data /home/student/.ssh/config\r\ndebug1: /home/student/.ssh/config line 1: Applying options for *\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug3: /etc/ssh/ssh_config line 52: Including file /etc/ssh/ssh_config.d/01-training.conf depth 0\r\ndebug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf\r\ndebug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *\r\ndebug3: /etc/ssh/ssh_config line 52: Including file /etc/ssh/ssh_config.d/05-redhat.conf depth 0\r\ndebug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf\r\ndebug3: /etc/ssh/ssh_config.d/05-redhat.conf line 2: Including file /etc/crypto-policies/back-ends/openssh.config depth 1\r\ndebug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config\r\ndebug3: gss kex names ok: [gss-gex-sha1-,gss-group14-sha1-]\r\ndebug3: kex names ok: [curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1]\r\ndebug1: /etc/ssh/ssh_config.d/05-redhat.conf line 8: Applying options for *\r\ndebug1: auto-mux: Trying existing master\r\ndebug1: Control socket \"/home/student/.ansible/cp/d4775f48c9\" does not exist\r\ndebug2: resolving \"servera.lab.exammple.com\" port 22\r\ndebug2: ssh_connect_direct\r\ndebug1: Connecting to servera.lab.exammple.com [18.211.9.206] port 22.\r\ndebug2: fd 6 setting O_NONBLOCK\r\ndebug1: connect to address 18.211.9.206 port 22: Connection timed out\r\nssh: connect to host servera.lab.exammple.com port 22: Connection timed out",
    "unreachable": true
}
2018-12-17 19:22:50,550 p=18287 u=student |     to retry, use: --limit @/home/student/troubleshoot-playbook/samba.retry

2018-12-17 19:22:50,550 p=18287 u=student |  PLAY RECAP ******************
2018-12-17 19:22:50,550 p=18287 u=student |  servera.lab.exammple.com   : ok=0    changed=0    unreachable=1    failed=0

Verifique se há erros no arquivo inventory. O grupo [samba_servers] escreveu o nome de servera.lab.example.com errado. Corrija esse erro conforme mostrado abaixo:

...output omitted...
[samba_servers]
servera.lab.example.com
...output omitted...

Execute o playbook novamente. A tarefa debug install_state variable retorna a mensagem The state for the samba service is installed. Essa tarefa usa o módulo debug e exibe o valor da variável install_state. Um erro também é exibido na tarefa deliver samba config porque não há um arquivo samba.j2 disponível no diretório de trabalho /home/student/troubleshoot-playbook/.

[student@workstation troubleshoot-playbook]$ ansible-playbook samba.yml

PLAY [Install a samba server] **************************************************
...output omitted...
TASK [debug install_state variable] ********************************************
ok: [servera.lab.example.com] => {
    "msg": "The state for the samba service is installed"
}
...output omitted...
TASK [deliver samba config] ****************************************************
fatal: [servera.lab.example.com]: FAILED! => {"changed": false, "msg": "Could not find or access 'samba.j2'\nSearched in:\n\t/home/student/troubleshoot-playbook/templates/samba.j2\n\t/home/student/troubleshoot-playbook/samba.j2\n\t/home/student/troubleshoot-playbook/templates/samba.j2\n\t/home/student/troubleshoot-playbook/samba.j2 on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"}
...output omitted...
PLAY RECAP *********************************************************************
servera.lab.example.com    : ok=7    changed=3    unreachable=0    failed=1

Edite o playbook e corrija o parâmetro src na tarefa deliver samba config para que fique samba.conf.j2. Quando você terminar, ele deverá parecer-se com o seguinte:

...output omitted...
  - name: deliver samba config
    template:
      src: samba.conf.j2
      dest: /etc/samba/smb.conf
      owner: root
...output omitted...

Execute o playbook novamente. Execute o playbook usando a opção --step. Ele deverá funcionar sem erros.

[student@workstation troubleshoot-playbook]$ ansible-playbook samba.yml --step

PLAY [Install a samba server] ************************************************
Perform task: TASK: Gathering Facts (N)o/(y)es/(c)ontinue: y
...output omitted...
Perform task: TASK: install samba (N)o/(y)es/(c)ontinue: y
...output omitted...
Perform task: TASK: install firewalld (N)o/(y)es/(c)ontinue: y
...output omitted...
Perform task: TASK: debug install_state variable (N)o/(y)es/(c)ontinue: y
...output omitted...
Perform task: TASK: start samba (N)o/(y)es/(c)ontinue: y
...output omitted...
Perform task: TASK: start firewalld (N)o/(y)es/(c)ontinue: y
...output omitted...
Perform task: TASK: configure firewall for samba (N)o/(y)es/(c)ontinue: y
...output omitted...
Perform task: TASK: deliver samba config (N)o/(y)es/(c)ontinue: y
...output omitted...
PLAY RECAP *********************************************************************
servera.lab.example.com    : ok=8    changed=1    unreachable=0    failed=0

Encerramento

Na workstation, execute o script lab troubleshoot-playbook finish para limpar este exercício.

[student@workstation ~]$ lab troubleshoot-playbook finish

Isso conclui o exercício orientado.

britho commented 3 years ago

Objetivos

Depois de concluir esta seção, você deverá ser capaz de solucionar falhas em hosts gerenciados ao executar um playbook. Uso do modo de verificação como ferramenta de teste

Você pode usar o comando ansible-playbook --check para executar testes smoke em um playbook. Essa opção executa o playbook sem fazer alterações na configuração dos hosts gerenciados. Se um módulo usado dentro do playbook der suporte ao check mode, as alterações que teriam sido feitas nos hosts gerenciados serão exibidas, mas não realizadas. Se o modo de verificação não for suportado por um módulo, as alterações não serão exibidas, mas o módulo ainda não executará nenhuma ação.

[student@demo ~]$ ansible-playbook --check playbook.yml

O comando ansible-playbook --check poderá não funcionar corretamente se as suas tarefas usarem condicionais.

Você também pode controlar se as tarefas individuais são executadas no modo de verificação com a configuração check_mode. Se uma tarefa tiver check_mode: yes definido, ela sempre será executada no modo de verificação, independentemente de você ter passado a opção --check para ansible-playbook. Da mesma forma, se uma tarefa tiver check_mode: no definido, ela sempre será executada normalmente, mesmo se você passar --check para ansible-playbook.

A tarefa a seguir é sempre executada no modo de verificação e não faz alterações.

tasks:

A tarefa a seguir sempre é executada normalmente, mesmo quando iniciada com ansible-playbook --check.

tasks:

Isso pode ser útil porque você pode executar a maior parte de um playbook normalmente ao testar tarefas individuais com check_mode: yes. Da mesma forma, você pode fazer as execuções de teste no modo de verificação serem mais propensas a fornecer resultados razoáveis executando tarefas selecionadas que coletam fatos ou definem variáveis para condicionais, mas não alteram os hosts gerenciados com check_mode: no.

Uma tarefa pode determinar se o playbook está sendo executado no modo de verificação testando o valor da variável mágica ansible_check_mode. Essa variável booleana é definida como verdadeira se o playbook estiver sendo executado no modo de verificação.

Tarefas que têm check_mode: no definido serão executadas mesmo quando o playbook é executado com ansible-playbook --check. Portanto, você não pode confiar que a opção --check não fará alterações nos hosts gerenciados sem confirmar que esse é o caso inspecionando o playbook e quaisquer funções ou tarefas associadas a ele.

Se você tiver playbooks mais antigos que usam always_run: yes para forçar as tarefas a serem executadas normalmente mesmo no modo de verificação, você precisará substituir esse código com check_mode: no no Ansible2.6 e posteriores.

O comando ansible-playbook também fornece uma opção --diff. Essa opção relata as alterações feitas nos arquivos de modelo em hosts gerenciados. Se forem usadas com a opção --check, essas alterações serão exibidas na saída do comando, mas, na verdade, não serão feitas.

[student@demo ~]$ ansible-playbook --check --diff playbook.yml

Testes com módulos

Alguns módulos podem fornecer informações adicionais sobre qual é o status de um host gerenciado. A lista a seguir inclui alguns dos módulos do Ansible que podem ser usados para problemas de teste e depuração em hosts gerenciados.

O módulo uri fornece um modo de verificar se uma API RESTful está retornando o conteúdo necessário.

  tasks:
    - uri:
        url: http://api.myapp.com
        return_content: yes
      register: apiresponse

    - fail:
        msg: 'version was not provided'
      when: "'version' not in apiresponse.content"

O módulo script dá suporte à execução de um script em hosts gerenciados e apresentará falha se o código de retorno desse script for diferente de zero. O script deve existir no nó de controle e é transferido e executado nos hosts gerenciados.

  tasks:
    - script: check_free_memory

O módulo stat reúne fatos para um arquivo, de forma muito semelhante ao comando stat. Você pode usá-lo para registrar uma variável e, depois, testar para determinar se o arquivo existe ou para obter outras informações sobre o arquivo. Se o arquivo não existir, a tarefa stat não apresentará falha, mas sua variável registrada relatará falso para *.stat.exists.

Neste exemplo, um aplicativo ainda está em execução se /var/run/app.lock existe, caso em que a ação deve ser cancelada.

  tasks:
    - name: Check if /var/run/app.lock exists
      stat:
        path: /var/run/app.lock
      register: lock

    - name: Fail if the application is running
      fail:
      when: lock.stat.exists

O módulo assert é uma alternativa para o módulo failed. O módulo assert é compatível com uma opção that que recebe uma lista de condicionais. Se alguma dessas condicionais for falsa, a tarefa falhará. Você pode usar as opções success_msg e fail_msg para personalizar a mensagem impressa para quando ela reportar sucesso ou falha.

O exemplo a seguir repete o anterior, mas usa assert em vez de fail.

  tasks:
    - name: Check if /var/run/app.lock exists
      stat:
        path: /var/run/app.lock
      register: lock

    - name: Fail if the application is running
      assert:
        that:
          - not lock.stat.exists

Solução de problemas de conexões

Muitos problemas comuns ao usar o Ansible para gerenciar hosts estão associados a conexões com o host e a problemas de configuração em relação ao escalonamento de privilégios e usuários remotos.

Se você estiver enfrentando problemas ao autenticação em um host gerenciado, certifique-se de que definiu remote_user corretamente no arquivo de configuração ou na ação. Você também deve confirmar se tem as chaves SSH corretas configuradas ou se está fornecendo a senha correta para esse usuário.

Certifique-se de que become está definido corretamente e que você está usando o become_user correto (ou seja, root por padrão). Você deve confirmar que está inserindo a senha sudo corretamente e que o sudo no host gerenciado está configurado corretamente.

Há um problema mais sutil relacionado às configurações de inventário. Para um servidor complexo com vários endereços de rede, talvez seja necessário usar um endereço específico ou um nome DNS ao se conectar a esse sistema. Talvez não seja recomendado usar esse endereço como nome de inventário da máquina para melhor legibilidade. Você pode definir uma variável de inventário de host, ansible_host, que substituirá o nome do inventário por um nome ou endereço IP diferente e será usado pelo Ansible para se conectar a esse host. Essa variável pode ser definida no arquivo host_vars ou diretório para esse host, ou pode ser definida no próprio arquivo de inventário.

Por exemplo, a seguinte entrada de inventário configura o Ansible para se conectar a 192.0.2.4 ao processar o host web4.phx.example.com:

web4.phx.example.com ansible_host=192.0.2.4

Essa é uma maneira útil de controlar como o Ansible se conecta a hosts gerenciados. No entanto, ela também pode causar problemas se o valor de ansible_host estiver incorreto. Teste de hosts gerenciados usando comandos ad hoc

Os exemplos a seguir mostram algumas das verificações que podem ser feitas em um host gerenciado pelo uso de comandos ad hoc.

Você usou o módulo ping para testar se você pode se conectar a hosts gerenciados. Dependendo das opções que você passar, você também pode usá-lo para testar se o escalonamento de privilégios e as credenciais estão configurados corretamente.

[student@demo ~]$ ansible demohost -m ping demohost | SUCCESS => { "ansible_facts": { "discovered_interpreter_python": "/usr/libexec/platform-python" }, "changed": false, "ping": "pong" } [student@demo ~]$ ansible demohost -m ping --become demohost | FAILED! => { "ansible_facts": { "discovered_interpreter_python": "/usr/libexec/platform-python" }, "changed": false, "module_stderr": "sudo: a password is required\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1 }

Esse exemplo retorna o espaço atualmente disponível nos discos configurados no host gerenciado demohost. Isso pode ser útil para confirmar que o sistema de arquivos no host gerenciado não está cheio.

[student@demo ~]$ ansible demohost -m command -a 'df'

Esse exemplo retorna a memória livre que está atualmente disponível no host gerenciado demohost.

[student@demo ~]$ ansible demohost -m command -a 'free -m'

O nível correto de teste

O Ansible foi projetado para garantir que a configuração incluída nos playbooks e realizada por seus módulos esteja correta. Ela monitora todos os módulos para falhas relatadas e interrompe o playbook imediatamente se alguma falha é encontrada. Isso ajuda a garantir que qualquer tarefa executada antes da falha não tenha erros.

Por causa disso, geralmente não há necessidade de verificar se o resultado de uma tarefa gerenciada pelo Ansible foi corretamente aplicada aos hosts gerenciados. Uma opção é adicionar algumas verificações de integridade a playbooks ou executá-las diretamente como comandos ad hoc quando uma solução de problemas mais direta é necessária. Mas você deve ter cuidado ao adicionar muita complexidade às suas tarefas e ações a fim de verificar novamente os testes realizados pelos próprios módulos.

Check Mode ("Dry Run") -- Ansible Documentation

Testing Strategies -- Ansible Documentation

britho commented 3 years ago

Neste exercício, você solucionará as falhas de tarefas que estão ocorrendo em um dos seus hosts gerenciados ao executar um playbook.

Resultados

Você deve ser capaz de solucionar problemas de hosts gerenciados.

Faça login na workstation como student usando a senha student.

Na workstation, execute o script lab troubleshoot-host start. Ele garante que o Ansible seja instalado na workstation. Ele também faz o download dos arquivos inventory, mailrelay.yml e postfix-relay-main.conf.j2 do http://materials.example.com/troubleshoot-host/ para o diretório /home/student/troubleshoot-host/.

[student@workstation ~]$ lab troubleshoot-host start

Em workstation, acesse o diretório /home/student/troubleshoot-host/.

[student@workstation ~]$ cd ~/troubleshoot-host/

Execute o playbook mailrelay.yml no modo de verificação.

[student@workstation troubleshoot-host]$ ansible-playbook mailrelay.yml --check
PLAY [create mail relay servers] ***********************************************
...output omitted...
TASK [check main.cf file] ******************************************************
ok: [servera.lab.example.com]

TASK [verify main.cf file exists] **********************************************
ok: [servera.lab.example.com]  => {
    "msg": "The main.cf file exists"
}
...output omitted...
TASK [email notification of always_bcc config] *********************************
fatal: [servera.lab.example.com]: FAILED! => {"msg": "The conditional check 'bcc_state.stdout != 'always_bcc ='' failed. The error was: error while evaluating conditional (bcc_state.stdout != 'always_bcc ='): 'dict object' has no attribute 'stdout'\n\nThe error appears to have been in '/home/student/troubleshoot-host/mailrelay.yml': line 42, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n    - name: email notification of always_bcc config\n      ^ here\n"}
...output omitted...
PLAY RECAP *********************************************************************
servera.lab.example.com    : ok=6    changed=3    unreachable=0    failed=1

A tarefa verify main.cf file exists usa o módulo stat. Ela confirmou que o main.cf existe no servera.lab.example.com.

A tarefa email notification of always_bcc config apresentou falha. Ela não recebeu a saída da tarefa check for always_bcc porque o playbook foi executado com o modo de verificação.

Usando um comando ad hoc, verifique o cabeçalho do arquivo /etc/postfix/main.cf.

[student@workstation troubleshoot-host]$ ansible servera.lab.example.com \
> -u devops -b -a "head /etc/postfix/main.cf"
servera.lab.example.com | FAILED | rc=1 >>
head: cannot open ‘/etc/postfix/main.cf’ for reading: No such file or directorynon-zero return code

Ocorreu falha no comando porque o playbook foi executado usando o modo de verificação. O Postfix não está instalado no servera.lab.example.com

Execute novamente o playbook, mas sem especificar o modo de verificação. O erro na tarefa email notification of always_bcc config deve desaparecer.

[student@workstation troubleshoot-host]$ ansible-playbook mailrelay.yml
PLAY [create mail relay servers] ***********************************************
...output omitted...
TASK [check for always_bcc] ****************************************************
changed: [servera.lab.example.com]

TASK [email notification of always_bcc config] *********************************
skipping: [servera.lab.example.com]

RUNNING HANDLER [restart postfix] **********************************************
changed: [servera.lab.example.com]

PLAY RECAP *********************************************************************
servera.lab.example.com    : ok=8    changed=5    unreachable=0    failed=0    
skipped=1    rescued=0    ignored=0

Usando um comando ad hoc, exiba a parte superior do arquivo /etc/postfix/main.cf.

[student@workstation troubleshoot-host]$ ansible servera.lab.example.com \
> -u devops -b -a "head /etc/postfix/main.cf"
servera.lab.example.com | SUCCESS | rc=0 >>
# Ansible managed
#
# Global Postfix configuration file. This file lists only a subset
# of all parameters. For the syntax, and for a complete parameter
# list, see the postconf(5) manual page (command: "man 5 postconf").
#
# For common configuration examples, see BASIC_CONFIGURATION_README
# and STANDARD_CONFIGURATION_README. To find these documents, use
# the command "postconf html_directory readme_directory", or go to
# http://www.postfix.org/BASIC_CONFIGURATION_README.html etc.

Agora, ele começa com uma linha que contém a string Ansible managed. Esse arquivo foi atualizado e agora é gerenciado pelo Ansible.

Adicione uma tarefa para habilitar o serviço smtp pelo firewall.

[student@workstation troubleshoot-host]$ vim mailrelay.yml
...output omitted...
    - name: postfix firewalld config
      firewalld:
        state: enabled
        permanent: true
        immediate: true
        service: smtp
...output omitted...

Execute o playbook. A tarefa postfix firewalld config deve ser executada sem erros.

[student@workstation troubleshoot-host]$ ansible-playbook mailrelay.yml
PLAY [create mail relay servers] ***********************************************
...output omitted...
TASK [postfix firewalld config] ************************************************
changed: [servera.lab.example.com]

PLAY RECAP *********************************************************************
servera.lab.example.com    : ok=8    changed=2    unreachable=0    failed=0    
skipped=1    rescued=0    ignored=0

Usando um comando ad hoc, verifique se o serviço smtp agora está configurado no firewall no servera.lab.example.com.

[student@workstation troubleshoot-host]$ ansible servera.lab.example.com \
> -u devops -b -a "firewall-cmd --list-services"
servera.lab.example.com | CHANGED | rc=0 >>
cockpit dhcpv6-client samba smtp ssh

Use telnet para testar se o serviço SMTP está ouvindo na porta TCP/25 no servera.lab.example.com. Desconecte-o depois de concluir.

[student@workstation troubleshoot-host]$ telnet servera.lab.example.com 25
Trying 172.25.250.10...
Connected to servera.lab.example.com.
Escape character is '^]'.
220 servera.lab.example.com ESMTP Postfix
quit
221 2.0.0 Bye
Connection closed by foreign host.

Encerramento

Na workstation, execute o script lab troubleshoot-host finish para limpar este exercício.

[student@workstation ~]$ lab troubleshoot-host finish

Isso conclui o exercício orientado.

britho commented 3 years ago

Lista de verificação de desempenho

Neste laboratório, você solucionará problemas que ocorrem ao tentar executar um playbook que foi fornecido a você.

Resultados

Você deverá ser capaz de:

Solucionar problemas de playbooks.

Solucionar problemas de hosts gerenciados.

Faça login na workstation como student usando a senha student. Execute o comando lab troubleshoot-review start.

[student@workstation ~]$ lab troubleshoot-review start

Esse script verifica se o Ansible está instalado na workstation e cria o diretório ~student/troubleshoot-review/html/. Ele faz o download dos arquivos ansible.cfg, inventory-lab, secure-web.yml e vhosts.conf do http://materials.example.com/labs/troubleshoot-review/ para o diretório /home/student/troubleshoot-review/. Ele também faz o download do arquivo index.html para o diretório /home/student/troubleshoot-review/html/.

No diretório ~/troubleshoot-review, verifique a sintaxe do playbook secure-web.yml. Este manual contém uma ação que configura o Apache HTTPD com TLS/SSL para hosts no grupo webservers. Corrija o problema relatado.

    Na workstation, mude para o diretório do projeto /home/student/troubleshoot-review.

    [student@workstation ~]$ cd ~/troubleshoot-review/

    Verifique a sintaxe do playbook secure-web.yml. Este playbook configura o Apache HTTPD com TLS/SSL para hosts no grupo webservers quando tudo está correto.

    [student@workstation troubleshoot-review]$ ansible-playbook --syntax-check \
    > secure-web.yml

    ERROR! Syntax Error while loading YAML.
      mapping values are not allowed in this context

    The error appears to have been in '/home/student/Ansible-course/troubleshoot-review/secure-web.yml': line 7, column 30, but may
    be elsewhere in the file depending on the exact syntax problem.

    The offending line appears to be:

      vars:
        random_var: This is colon: test
                                 ^ here

    Corrija o problema de sintaxe na definição da variável random_var adicionando aspas duplas à string This is colon: test. A alteração resultante deve aparecer da seguinte maneira:

    ...output omitted...
      vars:
        random_var: "This is colon: test"
    ...output omitted...

Verifique a sintaxe do playbook secure-web.yml novamente. Corrija o problema relatado.

Verifique a sintaxe de secure-web.yml usando ansible-playbook --syntax-check novamente.

[student@workstation troubleshoot-review]$ ansible-playbook --syntax-check \
> secure-web.yml

ERROR! Syntax Error while loading YAML.
  did not find expected '-' indicator

The error appears to have been in '/home/student/Ansible-course/troubleshoot-review/secure-web.yml': line 38, column 10, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

         - name: start and enable web services
         ^ here

Corrija todos os problemas de sintaxe no recuo. Remova o espaço adicional no início dos elementos da tarefa start and enable web services. A alteração resultante deve aparecer da seguinte maneira:

...output omitted...
          args:
            creates: /etc/pki/tls/certs/serverb.lab.example.com.crt

        - name: start and enable web services
          service:
            name: httpd
            state: started
            enabled: yes

        - name: deliver content
          copy:
            dest: /var/www/vhosts/serverb-secure
            src: html/
...output omitted...

Verifique a sintaxe do playbook secure-web.yml uma terceira vez. Corrija o problema relatado.

Verifique a sintaxe do playbook secure-web.yml.

[student@workstation troubleshoot-review]$ ansible-playbook --syntax-check \
> secure-web.yml

ERROR! Syntax Error while loading YAML.
  found unacceptable key (unhashable type: 'AnsibleMapping')

The error appears to have been in '/home/student/Ansible-course/troubleshoot-review/secure-web.yml': line 13, column 20, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

          yum:
            name: {{ item }}
                  ^ here
We could be wrong, but this one looks like it might be an issue with
missing quotes.  Always quote template expression brackets when they
start a value. For instance:

    with_items:
      - {{ foo }}

Should be written as:

    with_items:
      - "{{ foo }}"

Corrija a variável item na tarefa install web server packages. Adicione aspas duplas ao {{ item }}. A alteração resultante deve aparecer da seguinte maneira:

...output omitted...
        - name: install web server packages
          yum:
            name: "{{ item }}"
            state: latest
          notify:
            - restart services
          loop:
            - httpd
            - mod_ssl
...output omitted...

Verifique a sintaxe do playbook secure-web.yml uma quarta vez. Ele não deve exibir erro algum de sintaxe.

Verifique a sintaxe do playbook secure-web.yml. Ele não deve exibir erro algum de sintaxe.

[student@workstation troubleshoot-review]$ ansible-playbook --syntax-check \
> secure-web.yml

playbook: secure-web.yml

Execute o playbook secure-web.yml. O Ansible não consegue se conectar a serverb.lab.example.com. Corrija esse problema.

Execute o playbook secure-web.yml. Ele falhará com um erro.

[student@workstation troubleshoot-review]$ ansible-playbook secure-web.yml
PLAY [create secure web service] ***********************************************

TASK [Gathering Facts] *********************************************************
fatal: [serverb.lab.example.com]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: students@serverc.lab.example.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).", "unreachable": true}

PLAY RECAP *********************************************************************
serverb.lab.example.com        : ok=0    changed=0    unreachable=1    failed=0

Execute o playbook secure-web.yml novamente, adicionando o parâmetro -vvvv para aumentar o detalhamento da saída.

Observe que a conexão parece estar estabelecida com serverc.lab.example.com em vez de serverb.lab.example.com.

[student@workstation troubleshoot-review]$ ansible-playbook secure-web.yml -vvvv
...output omitted...
TASK [Gathering Facts] *********************************************************
task path: /home/student/troubleshoot-review/secure-web.yml:3
<serverc.lab.example.com> ESTABLISH SSH CONNECTION FOR USER: students
<serverc.lab.example.com> SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=students -o ConnectTimeout=10 -o ControlPath=/home/student/.ansible/cp/bc0c05136a serverc.lab.example.com '/bin/sh -c '"'"'echo ~students && sleep 0'"'"''
...output omitted...

Corrija a linha no arquivo inventory-lab. Exclua a variável de host ansible_host para que o arquivo apareça conforme mostrado abaixo:

[webservers]
serverb.lab.example.com

Execute o playbook secure-web.yml novamente. O Ansible deve autenticar como usuário remoto devops no host gerenciado. Corrija esse problema.

Execute o playbook secure-web.yml.

[student@workstation troubleshoot-review]$ ansible-playbook secure-web.yml -vvvv
...output omitted...
TASK [Gathering Facts] *********************************************************
task path: /home/student/troubleshoot-review/secure-web.yml:3
<serverb.lab.example.com> ESTABLISH SSH CONNECTION FOR USER: students
<serverb.lab.example.com> EXEC ssh -C -vvv -o ControlMaster=auto
 -o ControlPersist=60s -o Port=22 -o KbdInteractiveAuthentication=no
 -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey
 -o PasswordAuthentication=no -o User=students -o ConnectTimeout=10
 -o ControlPath=/home/student/.ansible/cp/ansible-ssh-%C -tt
 serverb.lab.example.com '/bin/sh -c '"'"'( umask 22 && mkdir -p "`
 echo $HOME/.ansible/tmp/ansible-tmp-1460241127.16-3182613343880 `" &&
 echo "` echo $HOME/.ansible/tmp/ansible-tmp-1460241127.16-3182613343880 `" )'"'"''
...output omitted...
fatal: [serverb.lab.example.com]: UNREACHABLE! => {
...output omitted...

Edite o playbook secure-web.yml para se certificar de que o devops é o remote_user para a ação. As primeiras linhas do playbook deverão ser exibidas como a seguir:

---
# start of secure web server playbook
- name: create secure web service
  hosts: webservers
  remote_user: devops
...output omitted...

Execute o playbook secure-web.yml uma terceira vez. Corrija o problema relatado.

Execute o playbook secure-web.yml.

[student@workstation troubleshoot-review]$ ansible-playbook secure-web.yml -vvvv
...output omitted...
failed: [serverb.lab.example.com] (item=mod_ssl) => {
    "ansible_loop_var": "item",
    "changed": false,
    "invocation": {
        "module_args": {
            "allow_downgrade": false,
            "autoremove": false,
...output omitted...
            "validate_certs": true
        }
    },
    "item": "mod_ssl",
    "msg": "This command has to be run under the root user.",
    "results": []
}
...output omitted...

Edite a ação para se certificar de que ela tem become: true ou become: yes definido. A alteração resultante deve aparecer da seguinte maneira:

---
# start of secure web server playbook
- name: create secure web service
  hosts: webservers
  remote_user: devops
  become: true
...output omitted...

Execute o playbook secure-web.yml mais uma vez. Ele deve ser concluído com êxito. Use um comando ad hoc para verificar se o serviço httpd está em execução.

Execute o playbook secure-web.yml.

[student@workstation troubleshoot-review]$ ansible-playbook secure-web.yml
PLAY [create secure web service] ***********************************************
...output omitted...
TASK [install web server packages] *********************************************
changed: [serverb.lab.example.com] => (item=httpd)
changed: [serverb.lab.example.com] => (item=mod_ssl)
...output omitted...
TASK [httpd_conf_syntax variable] **********************************************
ok: [serverb.lab.example.com] => {
    "msg": "The httpd_conf_syntax variable value is {'stderr_lines': [u'Syntax OK'], u'changed': True, u'end': u'2018-12-17 23:31:53.191871', 'failed': False, u'stdout': u'', u'cmd': [u'/sbin/httpd', u'-t'], u'rc': 0, u'start': u'2018-12-17 23:31:53.149759', u'stderr': u'Syntax OK', u'delta': u'0:00:00.042112', 'stdout_lines': [], 'failed_when_result': False}"
}
...output omitted...
RUNNING HANDLER [restart services] *********************************************
changed: [serverb.lab.example.com]

PLAY RECAP *********************************************************************
serverb.lab.example.com    : ok=10   changed=7    unreachable=0    failed=0

Use um comando ad hoc para determinar o estado do serviço httpd no serverb.lab.example.com. O serviço httpd agora deve estar em execução no serverb.lab.example.com.

[student@workstation troubleshoot-review]$ ansible all -u devops -b \
> -m command -a 'systemctl status httpd'
serverb.lab.example.com | CHANGED | rc=0 >>
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2019-04-11 03:22:34 EDT; 28s ago
...output omitted...

Avaliação

Na workstation, execute o script lab troubleshoot-review grade para confirmar a conclusão com êxito deste exercício.

[student@workstation ~]$ lab troubleshoot-review grade

Encerramento

Na workstation, execute o script lab troubleshoot-review finish para limpar este laboratório.

[student@workstation ~]$ lab troubleshoot-review finish

Isso conclui o laboratório.

britho commented 3 years ago

Lista de verificação de desempenho

Neste laboratório, você solucionará problemas que ocorrem ao tentar executar um playbook que foi fornecido a você.

Resultados

Você deverá ser capaz de:

Solucionar problemas de playbooks.

Solucionar problemas de hosts gerenciados.

Faça login na workstation como student usando a senha student. Execute o comando lab troubleshoot-review start.

[student@workstation ~]$ lab troubleshoot-review start

Esse script verifica se o Ansible está instalado na workstation e cria o diretório ~student/troubleshoot-review/html/. Ele faz o download dos arquivos ansible.cfg, inventory-lab, secure-web.yml e vhosts.conf do http://materials.example.com/labs/troubleshoot-review/ para o diretório /home/student/troubleshoot-review/. Ele também faz o download do arquivo index.html para o diretório /home/student/troubleshoot-review/html/.

No diretório ~/troubleshoot-review, verifique a sintaxe do playbook secure-web.yml. Este manual contém uma ação que configura o Apache HTTPD com TLS/SSL para hosts no grupo webservers. Corrija o problema relatado.

    Na workstation, mude para o diretório do projeto /home/student/troubleshoot-review.

    [student@workstation ~]$ cd ~/troubleshoot-review/

    Verifique a sintaxe do playbook secure-web.yml. Este playbook configura o Apache HTTPD com TLS/SSL para hosts no grupo webservers quando tudo está correto.

    [student@workstation troubleshoot-review]$ ansible-playbook --syntax-check \
    > secure-web.yml

    ERROR! Syntax Error while loading YAML.
      mapping values are not allowed in this context

    The error appears to have been in '/home/student/Ansible-course/troubleshoot-review/secure-web.yml': line 7, column 30, but may
    be elsewhere in the file depending on the exact syntax problem.

    The offending line appears to be:

      vars:
        random_var: This is colon: test
                                 ^ here

    Corrija o problema de sintaxe na definição da variável random_var adicionando aspas duplas à string This is colon: test. A alteração resultante deve aparecer da seguinte maneira:

    ...output omitted...
      vars:
        random_var: "This is colon: test"
    ...output omitted...

Verifique a sintaxe do playbook secure-web.yml novamente. Corrija o problema relatado.

Verifique a sintaxe de secure-web.yml usando ansible-playbook --syntax-check novamente.

[student@workstation troubleshoot-review]$ ansible-playbook --syntax-check \
> secure-web.yml

ERROR! Syntax Error while loading YAML.
  did not find expected '-' indicator

The error appears to have been in '/home/student/Ansible-course/troubleshoot-review/secure-web.yml': line 38, column 10, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

         - name: start and enable web services
         ^ here

Corrija todos os problemas de sintaxe no recuo. Remova o espaço adicional no início dos elementos da tarefa start and enable web services. A alteração resultante deve aparecer da seguinte maneira:

...output omitted...
          args:
            creates: /etc/pki/tls/certs/serverb.lab.example.com.crt

        - name: start and enable web services
          service:
            name: httpd
            state: started
            enabled: yes

        - name: deliver content
          copy:
            dest: /var/www/vhosts/serverb-secure
            src: html/
...output omitted...

Verifique a sintaxe do playbook secure-web.yml uma terceira vez. Corrija o problema relatado.

Verifique a sintaxe do playbook secure-web.yml.

[student@workstation troubleshoot-review]$ ansible-playbook --syntax-check \
> secure-web.yml

ERROR! Syntax Error while loading YAML.
  found unacceptable key (unhashable type: 'AnsibleMapping')

The error appears to have been in '/home/student/Ansible-course/troubleshoot-review/secure-web.yml': line 13, column 20, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

          yum:
            name: {{ item }}
                  ^ here
We could be wrong, but this one looks like it might be an issue with
missing quotes.  Always quote template expression brackets when they
start a value. For instance:

    with_items:
      - {{ foo }}

Should be written as:

    with_items:
      - "{{ foo }}"

Corrija a variável item na tarefa install web server packages. Adicione aspas duplas ao {{ item }}. A alteração resultante deve aparecer da seguinte maneira:

...output omitted...
        - name: install web server packages
          yum:
            name: "{{ item }}"
            state: latest
          notify:
            - restart services
          loop:
            - httpd
            - mod_ssl
...output omitted...

Verifique a sintaxe do playbook secure-web.yml uma quarta vez. Ele não deve exibir erro algum de sintaxe.

Verifique a sintaxe do playbook secure-web.yml. Ele não deve exibir erro algum de sintaxe.

[student@workstation troubleshoot-review]$ ansible-playbook --syntax-check \
> secure-web.yml

playbook: secure-web.yml

Execute o playbook secure-web.yml. O Ansible não consegue se conectar a serverb.lab.example.com. Corrija esse problema.

Execute o playbook secure-web.yml. Ele falhará com um erro.

[student@workstation troubleshoot-review]$ ansible-playbook secure-web.yml
PLAY [create secure web service] ***********************************************

TASK [Gathering Facts] *********************************************************
fatal: [serverb.lab.example.com]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: students@serverc.lab.example.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).", "unreachable": true}

PLAY RECAP *********************************************************************
serverb.lab.example.com        : ok=0    changed=0    unreachable=1    failed=0

Execute o playbook secure-web.yml novamente, adicionando o parâmetro -vvvv para aumentar o detalhamento da saída.

Observe que a conexão parece estar estabelecida com serverc.lab.example.com em vez de serverb.lab.example.com.

[student@workstation troubleshoot-review]$ ansible-playbook secure-web.yml -vvvv
...output omitted...
TASK [Gathering Facts] *********************************************************
task path: /home/student/troubleshoot-review/secure-web.yml:3
<serverc.lab.example.com> ESTABLISH SSH CONNECTION FOR USER: students
<serverc.lab.example.com> SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=students -o ConnectTimeout=10 -o ControlPath=/home/student/.ansible/cp/bc0c05136a serverc.lab.example.com '/bin/sh -c '"'"'echo ~students && sleep 0'"'"''
...output omitted...

Corrija a linha no arquivo inventory-lab. Exclua a variável de host ansible_host para que o arquivo apareça conforme mostrado abaixo:

[webservers]
serverb.lab.example.com

Execute o playbook secure-web.yml novamente. O Ansible deve autenticar como usuário remoto devops no host gerenciado. Corrija esse problema.

Execute o playbook secure-web.yml.

[student@workstation troubleshoot-review]$ ansible-playbook secure-web.yml -vvvv
...output omitted...
TASK [Gathering Facts] *********************************************************
task path: /home/student/troubleshoot-review/secure-web.yml:3
<serverb.lab.example.com> ESTABLISH SSH CONNECTION FOR USER: students
<serverb.lab.example.com> EXEC ssh -C -vvv -o ControlMaster=auto
 -o ControlPersist=60s -o Port=22 -o KbdInteractiveAuthentication=no
 -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey
 -o PasswordAuthentication=no -o User=students -o ConnectTimeout=10
 -o ControlPath=/home/student/.ansible/cp/ansible-ssh-%C -tt
 serverb.lab.example.com '/bin/sh -c '"'"'( umask 22 && mkdir -p "`
 echo $HOME/.ansible/tmp/ansible-tmp-1460241127.16-3182613343880 `" &&
 echo "` echo $HOME/.ansible/tmp/ansible-tmp-1460241127.16-3182613343880 `" )'"'"''
...output omitted...
fatal: [serverb.lab.example.com]: UNREACHABLE! => {
...output omitted...

Edite o playbook secure-web.yml para se certificar de que o devops é o remote_user para a ação. As primeiras linhas do playbook deverão ser exibidas como a seguir:

---
# start of secure web server playbook
- name: create secure web service
  hosts: webservers
  remote_user: devops
...output omitted...

Execute o playbook secure-web.yml uma terceira vez. Corrija o problema relatado.

Execute o playbook secure-web.yml.

[student@workstation troubleshoot-review]$ ansible-playbook secure-web.yml -vvvv
...output omitted...
failed: [serverb.lab.example.com] (item=mod_ssl) => {
    "ansible_loop_var": "item",
    "changed": false,
    "invocation": {
        "module_args": {
            "allow_downgrade": false,
            "autoremove": false,
...output omitted...
            "validate_certs": true
        }
    },
    "item": "mod_ssl",
    "msg": "This command has to be run under the root user.",
    "results": []
}
...output omitted...

Edite a ação para se certificar de que ela tem become: true ou become: yes definido. A alteração resultante deve aparecer da seguinte maneira:

---
# start of secure web server playbook
- name: create secure web service
  hosts: webservers
  remote_user: devops
  become: true
...output omitted...

Execute o playbook secure-web.yml mais uma vez. Ele deve ser concluído com êxito. Use um comando ad hoc para verificar se o serviço httpd está em execução.

Execute o playbook secure-web.yml.

[student@workstation troubleshoot-review]$ ansible-playbook secure-web.yml
PLAY [create secure web service] ***********************************************
...output omitted...
TASK [install web server packages] *********************************************
changed: [serverb.lab.example.com] => (item=httpd)
changed: [serverb.lab.example.com] => (item=mod_ssl)
...output omitted...
TASK [httpd_conf_syntax variable] **********************************************
ok: [serverb.lab.example.com] => {
    "msg": "The httpd_conf_syntax variable value is {'stderr_lines': [u'Syntax OK'], u'changed': True, u'end': u'2018-12-17 23:31:53.191871', 'failed': False, u'stdout': u'', u'cmd': [u'/sbin/httpd', u'-t'], u'rc': 0, u'start': u'2018-12-17 23:31:53.149759', u'stderr': u'Syntax OK', u'delta': u'0:00:00.042112', 'stdout_lines': [], 'failed_when_result': False}"
}
...output omitted...
RUNNING HANDLER [restart services] *********************************************
changed: [serverb.lab.example.com]

PLAY RECAP *********************************************************************
serverb.lab.example.com    : ok=10   changed=7    unreachable=0    failed=0

Use um comando ad hoc para determinar o estado do serviço httpd no serverb.lab.example.com. O serviço httpd agora deve estar em execução no serverb.lab.example.com.

[student@workstation troubleshoot-review]$ ansible all -u devops -b \
> -m command -a 'systemctl status httpd'
serverb.lab.example.com | CHANGED | rc=0 >>
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2019-04-11 03:22:34 EDT; 28s ago
...output omitted...

Avaliação

Na workstation, execute o script lab troubleshoot-review grade para confirmar a conclusão com êxito deste exercício.

[student@workstation ~]$ lab troubleshoot-review grade

Encerramento

Na workstation, execute o script lab troubleshoot-review finish para limpar este laboratório.

[student@workstation ~]$ lab troubleshoot-review finish

Isso conclui o laboratório.

britho commented 3 years ago

Neste capítulo, você aprendeu que:

O Ansible fornece registro integrado. Esse recurso não está habilitado por padrão.

O parâmetro log_path na seção default do arquivo de configuração ansible.cfg especifica o local do arquivo de log para o qual a saída do Ansible é redirecionada.

O módulo debug oferece informações adicionais para depuração ao executar um playbook (por exemplo, valor atual de uma variável).