ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: failures! (or error handling)

De tempos em tempos, a humanidade é testemunha de um curioso, engraçado e certo tipo de evento: erros que se transformam em felizes acertos! Não faz sentido pra você? Tudo bem, sem problemas! Eu lhe apresento 🥁🥁🥁 a penicilina e a coca-cola 🤭 rsrs! Então, voltando … O mesmo pode acontecer no Ansible. Eventualmente, um código de retorno com valor não-zero (diferente de zero), seja vindo de um comando ou de uma falha em determinado módulo, pode ser exatamente o que você busca no momento e por isso, não vai querer que o Ansible pare a execução naquele host e siga para o próximo. Não, muito pelo contrário. Tal código não-zero indica para você, e sua demanda/tarefa, um verdadeiro baita de um sucesso! Portanto, nada mais lógico do que tratá-lo … Correto? Bom, antes de iniciar os trabalhos, um exemplo básico de situação hipotética para ilustrar melhor: numa bela e ensolarada manhã, seu chefe propõe a você que, caso um host apresente uma falha, o Ansible pare/encerre instantaneamente a execução em todos os outros. Fim!

Agora sim, adiante! Vamos a aula de hoje, com o seu respectivo sumário listado a seguir:

  • Ignorando comandos com falha;
  • Ignorando erros de host inacessíveis;
  • Redefinindo hosts inacessíveis;
  • Manipuladores e falha;
  • Definindo falha;
  • Definindo “alterado”;
  • Garantindo o sucesso para o comando e shell;
  • Abortando uma reprodução em todos os hosts;
  • Controle de erros em blocos;

07-a. Ignorando comandos com falhas

O comportamento padrão, quando uma task qualquer falha num host particular, é puro e simplesmente parar a execução das outras tarefas no mesmo, não importando a quantidade que faltava ou em qual task ele estava (ex: a primeira, a do meio, ou a última). Dessa forma, o Ansible pularia para o próximo host sem piscar duas vezes. Contudo, é totalmente possível continuar naquele host específico apesar dos apesares, ou melhor dizendo, da(s) falha(s). Basta utilizar a palavra-chave ignore_errors:

- name: Do not count this as a failure
  ansible.builtin.command: /bin/false
  ignore_errors: yes

Mas, atenção aqui! Tenha cuidado! Pois essa regra somente funcionará com tarefas capazes de retornar o valor 'failed' (“falhou”). Sendo assim, o Ansible jamais/nunca ignora erros de: variáveis indefinidas, falhas de conexão, problemas de execução, pacotes ausentes ou até mesmo erros de sintaxe.

07-b. Ignorando erros de hosts inacessíveis

Em sua jornada diária, quantas e quantas vezes aquele seu colega sysadmin da infra/operação moveu uma VM de lugar, acrescentou uma nova regra de firewall, ou desligou um grupo de máquinas sem nenhum aviso prévio? Eu sei, talvez sua resposta seja: muitas, várias vezes … Certo? 😥 Mas calma! Por favor, peço que não brigue com ele! Afinal o dia-a-dia de um admin/ops pode ser um pouco cheio e meio estressante, de tanto deveres, rotinas e tarefas. E por isso, eis que trago a solução para os seus problemas (ou erros, neste caso). Se uma task abortar dado ao status do host ser ‘UNREACHABLE’, use ignore_unreachable. Assim o Ansible ignora os erros da tarefa atual, mas permanecendo disponível para executar eventuais futuras tarefas no host que está inacessível no momento 🤩

À nível de task:

- name: This executes, fails, and the failure is ignored
  ansible.builtin.command: /bin/true
  ignore_unreachable: yes

- name: This executes, fails, and ends the play for this host
  ansible.builtin.command: /bin/true

À nível de playbook:

- hosts: all
  ignore_unreachable: yes
  tasks:
  - name: This executes, fails, and the failure is ignored
    ansible.builtin.command: /bin/true

  - name: This executes, fails, and ends the play for this host
    ansible.builtin.command: /bin/true
    ignore_unreachable: no

07-c. Redefinindo hosts inacessíveis

Se o Ansible não puder se conectar a um host, ele marca esse host como ‘UNREACHABLE’ e o remove da lista de hosts ativos para a execução. Você pode usar meta: clear_host_errors para reativar todos os hosts, para que as tarefas subsequentes possam tentar alcançá-los novamente. ( Top demais! 👌💯 )

07-d. Manipuladores e falhas

Ansible executa handlers no final de cada play … Desde a nossa aula passada isso já é fato conhecido! PORÉM, e se uma tarefa notifica um manipulador, mas aí vem uma falha e faz o mesmo, logo em seguida ou posteriormente, na execução do playbook? O que acontece? Bem, o esperado e padrão é o manipulador não ser executado naquele host, o que pode deixar o host em um estado inesperado. Por exemplo, uma tarefa pode atualizar um arquivo de configuração e notificar um manipulador para reiniciar algum serviço. Se uma tarefa posterior na mesma execução falhar, o arquivo de configuração pode ser alterado, mas o serviço não será reiniciado.

Para evitar, reverter ou burlar (nomeie como quiser!) tal comportamento basta usar a opção de linha de comando --force-handlers, incluindo force_handlers: True em uma play, ou adicionando force_handlers = True ao ansible.cfg. Quando os manipuladores são forçados, o Ansible executará todos os manipuladores notificados em todos os hosts, até mesmo hosts com tarefas com falha. (Observe que certos erros ainda podem impedir a execução do handler, como um host inacessível.)

07-e. Definindo uma falha

O Ansible permite definir o que “falha” significa em cada tarefa usando a condição failed_when. Como acontece nas outras condicionais do Ansible, listas com várias condições failed_when são unidas com um and implícito, o que refletindo na tarefa em si, já que a mesma só falha quando todas as condições são atendidas. Caso deseje o oposto disso, que é uma “falha” quando qualquer uma das condições for atendida, você deve definir as condições em uma string com um operador oR explícito.

Você pode verificar se há falhas pesquisando uma palavra ou frase na saída de um comando:

- name: Fail task when the command error output prints FAILED
  ansible.builtin.command: /usr/bin/example-command -x -y -z
  register: command_result
  failed_when: "'FAILED' in command_result.stderr"

Ou baseado no código de retorno:

- name: Fail task when both files are identical
  ansible.builtin.raw: diff foo/file1 bar/file2
  register: diff_cmd
  failed_when: diff_cmd.rc == 0 or diff_cmd.rc >= 2

+ 1 exemplo: combinar múltiplas condições para definir uma “falha”

- name: Check if a file exists in temp and fail task if it does
  ansible.builtin.command: ls /tmp/this_should_not_be_here
  register: result
  failed_when:
    - result.rc == 0
    - '"No such" not in result.stdout'

07-f. Definindo “alterado”

O Ansible permite definir quando uma tarefa específica “mudou” um nó remoto usando a condição changed_when. Isso permite determinar, com base em códigos de retorno ou saída, se uma alteração deve ser relatada nas estatísticas Ansible e se um manipulador deve ser acionado ou não. Como acontece com todas as condicionais em Ansible, listas de várias condições changed_when são unidas com um AND implícito, o que significa que a tarefa só relata uma mudança quando todas as condições são atendidas. Se quiser relatar uma mudança quando qualquer uma das condições for atendida, você deve definir as condições em uma string com um operador OR explícito. Por exemplo:

tasks:

  - name: Report 'changed' when the return code is not equal to 2
    ansible.builtin.shell: /usr/bin/billybass --mode="take me to the river"
    register: bass_result
    changed_when: "bass_result.rc != 2"

  - name: This will never report 'changed' status
    ansible.builtin.shell: wall 'beep'
    changed_when: False

07-g. Garantindo o sucesso para o comando e shell

Os módulos de comando e shell se preocupam com os códigos de retorno, portanto, se você tiver um comando cujo código de saída bem-sucedido não seja zero, você pode fazer o seguinte:

tasks:
  - name: Run this command and ignore the result
    ansible.builtin.shell: /usr/bin/somecommand || /bin/true

07-h. Abortando uma execução em todos os hosts

Às vezes, você deseja que uma falha em um único host, ou falhas em uma certa porcentagem de hosts, aborte a execução inteira em todos os hosts. Você pode interromper a execução da reprodução após a primeira falha acontecer com any_errors_fatal. Para um controle mais refinado, você pode usar max_fail_percentage para abortar a execução após uma determinada porcentagem de hosts falhar.

07-i. Controle de erros em blocos

Veja detalhes e exemplos em https://docs.ansible.com/ansible/latest/user_guide/playbooks_blocks.html#block-error-handling

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_error_handling.html#playbooks-error-handling

ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: handlers

CONT. 🔝

🔙 ANTERIOR: BLOCKS

Visto no final do post passado, numa breve participação coadjuvante, e já tendo aparecido em outras oportunidades aqui no BLOG, chegou a hora de conhecer um pouco mais sobre os handlers (traduzindo para o português: manipuladores). Objetiva e diretamente, são um tipo de tarefa que apenas se auto executa quando recebe uma notificação. Por exemplo, reiniciar determinado serviço (daemon) se, e somente se, alguma task modificou sua configuração. Em oposição, não fazer absolutamente nada enquanto tal permanecer inalterada. Outro fato importante, e assim como as variáveis, cada handler precisa ser nomeado exclusivamente.

  • Exemplo;
  • Controlando a execução de um handler (WHEN);
  • Usando variáveis com handlers;

06-a. Handler Example

A seguir, o playbook verify-apache.yml, apresentando uma play com handler simples:

---
- name: Verify apache installation
  hosts: webservers
  vars:
    http_port: 80
    max_clients: 200
  remote_user: root
  tasks:
  - name: Ensure apache is at the latest version
    ansible.builtin.yum:
      name: httpd
      state: latest

  - name: Write the apache config file
    ansible.builtin.template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf
    notify:
    - Restart apache

  - name: Ensure apache is running
    ansible.builtin.service:
      name: httpd
      state: started

  handlers:
    - name: Restart apache
      ansible.builtin.service:
        name: httpd
        state: restarted

Continuando, mais um playbook. Entretanto, agora é a vez de uma task (anteriormente foi uma play) ser responsável por notificar. Serve para demonstrar que uma única task é capaz de notificar mais de um handler simultaneamente:

- name: Template configuration file
  ansible.builtin.template:
    src: template.j2
    dest: /etc/foo.conf
  notify:
    - Restart memcached
    - Restart apache

  handlers:
    - name: Restart memcached
      ansible.builtin.service:
        name: memcached
        state: restarted

    - name: Restart apache
      ansible.builtin.service:
        name: apache
        state: restarted

06-b. Controlando a execução de um handler (WHEN)

Devido a sua concepção, manipuladores são executados depois que todas as tarefas em uma determinada play foram concluídas. Tal método é eficiente pois o manipulador é executado apenas uma vez, independentemente de quantas tarefas o notificam. Por exemplo, se várias tarefas atualizam um arquivo de configuração e notificam um manipulador para reiniciar o Apache, o Ansible pula o Apache apenas uma vez para evitar reinicializações desnecessárias.

Caso necessite que os handlers sejam executados bem antes do final da execução, basta adicionar uma task que os liberte para tal. Faça uso do ‘meta module’ presente no ansible-base, chamando-o para que o Ansible execute ações:

tasks:
  - name: Some tasks go here
    ansible.builtin.shell: ...

  - name: Flush handlers
    meta:flush_handlers

  - name: Some other tasks
    ansible.builtin.shell: ...

A tarefa meta: flush_handlers aciona todos os manipuladores que foram notificados naquele ponto da play em específico.

06-c. Usando variáveis com handlers

Talvez queira que seus manipuladores usem variáveis. Por exemplo, se o nome de um serviço variar ligeiramente de distro para distro, você espera que sua saída mostre o nome exato do serviço reiniciado para cada máquina de destino. Por isso, evite colocar variáveis no nome do manipulador. Como os nomes do manipulador são modelados desde o início, o Ansible pode não ter um valor disponível para um nome como este aqui:

handlers:
# This handler name may cause your play to fail!
- name: Restart "{{ web_service_name }}"

Se a variável usada no nome do manipulador não estiver disponível, toda a execução falhará. E antes que pense, não! Alterar essa variável “durante” não resultará em um manipulador recém-criado.

Em vez disso, coloque variáveis nos parâmetros de tarefa de seu manipulador. Você pode carregar os valores usando include_vars como este:

tasks:
  - name: Set host variables based on distribution
    include_vars: "{{ ansible_facts.distribution }}.yml"

handlers:
  - name: Restart web service
    ansible.builtin.service:
      name: "{{ web_service_name | default('httpd') }}"
      state: restarted

Os manipuladores também podem “ouvir” tópicos genéricos e as tarefas podem notificar esses tópicos da seguinte maneira:

handlers:
  - name: Restart memcached
    ansible.builtin.service:
      name: memcached
      state: restarted
    listen: "restart web services"

  - name: Restart apache
    ansible.builtin.service:
      name: apache
      state: restarted
    listen: "restart web services"

tasks:
  - name: Restart everything
    ansible.builtin.command: echo "this task will restart the web services"
    notify: "restart web services"

Isso torna muito mais fácil acionar vários manipuladores. Ele também desacopla os manipuladores de seus nomes, facilitando o compartilhamento de manipuladores entre playbooks e roles (especialmente ao usar funções de terceiros de uma fonte compartilhada como o Ansible Galaxy).

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_handlers.html#handlers

ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: blocks

UPDATE! / DISCLAIMER: Depois de muitas idas e vindas ao banco … buscas e mais buscas à procura de documentos pessoais que não via há tanto tempo … cópias, xerox, pdf’s, assinaturas … e por fim, infinitas caixas/pacotes para organizar, mofo/poeira para limpar, caminhão da mudança, lavar o piso novo, desempacotar e remontar 😫😓 (…) Estou vivo, de volta e escrevendo da minha própria casa, cujo foi comprada em JUN/2021, também conhecido como ‘mês passado’. Esse foi o real motivo para o BLOG ter ficado tão parado nessas últimas semanas, caros e estimados leitores. Sendo assim, peço desculpas a todos! Espero que não fiquem chateados comigo 😥 MAS, é como dizem por aí: o show não pode parar! Então, retomando do ponto exato aonde paramos, a seguir, +1 capítulo da série ANSIBLE:

CONT. 🔝

🔙 ANTERIOR: CONDITIONALS

Analogamente (ou equivalente, se preferir) a um grupo de linhas dentro do código-fonte, blocos no contexto ‘ansible’ são formas/maneiras de lidar/tratar dois tipos de elemento básico: (a) tasks e (b) erros! Na prática, blocos acabam criando grupos lógicos, sejam micro tarefas que partilham determinado objetivo maior, sejam erros advindos de uma tarefa mal executada, displicentemente planejada. Em ambos os casos, podemos fazer um paralelo com o tratamento de exceções, observadas em outras linguagens de programação.

  • Agrupando tasks com blocos;
  • Tratando erros com blocos;

05-a. Agrupando tasks com blocos

A herança de dados, diretivas, ocorre e se aplica a todas as tarefas comuns (aninhadas) em um mesmo nível de bloco. Ou seja, a diretiva propriamente dita não afeta o bloco em si, mas sim as tasks delimitadas (contidas) por ele. Para exemplificar: uma vez validada e satisfeita a condição imposta pelo when, aplica-se a mesma numa única tacada para as diversas tarefas presentes no bloco em questão. O que é bem diferente de aplicar a ele mesmo, como pode ser levado a crer, e assim, induzido ao erro. A única exceção aqui são os loops. Esteja sempre atento!

tasks:
   - name: Install, configure, and start Apache
     block:
       - name: Install httpd and memcached
         ansible.builtin.yum:
           name:
           - httpd
           - memcached
           state: present

       - name: Apply the foo config template
         ansible.builtin.template:
           src: templates/src.j2
           dest: /etc/foo.conf

       - name: Start service bar and enable it
         ansible.builtin.service:
           name: bar
           state: started
           enabled: True
     when: ansible_facts['distribution'] == 'CentOS'
     become: true
     become_user: root
     ignore_errors: yes

Resumidamente: a condição é avaliada ANTES e TODA VEZ que “alcançamos” um host diferente. Se passar, aí sim serão executadas as três tarefas informadas no bloco, para aquele node específico (e aprovado). O escalonamento e privilégio de root também são herdados, e por tabela, executados na sequência. Por fim, a última linha ignore_errors: yes serve apenas para que o Ansible dê continuidade ao playbook em casos de falhas nas tasks.

**Names for blocks have been available since Ansible 2.3. We recommend using names in all tasks, within blocks or elsewhere, for better visibility into the tasks being executed when you run the playbook.

05-b. Tratando erros com blocos

Trechos do código identificados como blocos, e marcados com as palavras rescue e always, são chamados (igualmente definidos) de sessões. Elas são peças-chave, fundamentais para controlar as respostas direcionadas a possíveis erros de tarefa.

Blocos rescue ditam novas tasks a serem executadas quando uma task anterior (do mesmo bloco) falhar. Tal abordagem é muito parecida com o tratamento de exceções presente em diversas outras linguagens de programação. É importante frisar aqui a seguinte informação: o Ansible somente executa blocos de resgate após uma tarefa retornar estado de FALHA (failed). Tasks definidas incorretamente ou hosts inacessíveis não irão disparar/acionar nenhum bloco de resgate.

tasks:
 - name: Handle the error
   block:
     - name: Print a message
       ansible.builtin.debug:
         msg: 'I execute normally'

     - name: Force a failure
       ansible.builtin.command: /bin/false

     - name: Never print this
       ansible.builtin.debug:
         msg: 'I never execute, due to the above task failing, :-('
   rescue:
     - name: Print when errors
       ansible.builtin.debug:
         msg: 'I caught an error, can do stuff here to fix it, :-)'

Dentro de um bloco também podem haver sessões always. A partir desse ponto, tarefas serão executadas independentemente do status anterior, ou seja, da task anterior.

- name: Always do X
   block:
     - name: Print a message
       ansible.builtin.debug:
         msg: 'I execute normally'

     - name: Force a failure
       ansible.builtin.command: /bin/false

     - name: Never print this
       ansible.builtin.debug:
         msg: 'I never execute :-('
   always:
     - name: Always do this
       ansible.builtin.debug:
         msg: "This always executes, :-)"

Misturados, esses dois fornecem um belo tratamento para erros um pouco mais complexos.

- name: Attempt and graceful roll back demo
  block:
    - name: Print a message
      ansible.builtin.debug:
        msg: 'I execute normally'

    - name: Force a failure
      ansible.builtin.command: /bin/false

    - name: Never print this
      ansible.builtin.debug:
        msg: 'I never execute, due to the above task failing, :-('
  rescue:
    - name: Print when errors
      ansible.builtin.debug:
        msg: 'I caught an error'

    - name: Force a failure in middle of recovery! >:-)
      ansible.builtin.command: /bin/false

    - name: Never print this
      ansible.builtin.debug:
        msg: 'I also never execute :-('
  always:
    - name: Always do this
      ansible.builtin.debug:
        msg: "This always executes"

As tarefas do bloco são executadas normalmente. Se alguma tarefa no bloco retornar failed, a seção de resgate executa tarefas para se recuperar do erro. A seção always é executada independentemente dos resultados das seções block e rescue.

Se ocorrer um erro no bloco e a tarefa de resgate for bem-sucedida, o Ansible reverterá o status de falha da tarefa original para a execução e continuará a executar a reprodução como se a tarefa original tivesse sido bem-sucedida. A tarefa resgatada é considerada bem-sucedida e não aciona configurações max_fail_percentage ou any_errors_fatal. No entanto, Ansible ainda relata uma falha nas estatísticas do playbook.

Use blocos com flush_handlers em uma tarefa de resgate para garantir que todos os manipuladores sejam executados mesmo se ocorrer um erro:

 tasks:
   - name: Attempt and graceful roll back demo
     block:
       - name: Print a message
         ansible.builtin.debug:
           msg: 'I execute normally'
         changed_when: yes
         notify: run me even after an error

       - name: Force a failure
         ansible.builtin.command: /bin/false
     rescue:
       - name: Make sure all handlers run
         meta: flush_handlers
 handlers:
    - name: Run me even after an error
      ansible.builtin.debug:
        msg: 'This handler runs even on error'

**New in version 2.1

**Ansible provides a couple of variables for tasks in the rescue portion of a block:

ansible_failed_task

The task that returned ‘failed’ and triggered the rescue. For example, to get the name use ansible_failed_task.name.

ansible_failed_result

The captured return result of the failed task that triggered the rescue. This would equate to having used this var in the register keyword.

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_blocks.html#playbooks-blocks

TOPIC: OUT-OF-THE-BOX … coringa, java e encapsulamento ???

O que se pode aprender sobre programação em um filme de héroi com um certo quê policial? (…) Muito, caso preste atenção e observe os detalhes, sutileza e entrelinhas. Falo de Batman: O Cavaleiro das Trevas, de 2008 e dirigido por Christopher Nolan. Sequência direta de Batman Begins (2005), nela acompanhamos os esforços das mais diversas esferas do poder público de Gotham City para encontrar e capturar o criminoso/terrorista de alcunha ‘Coringa’. Tendo a ajuda de um certo “justiceiro mascarado”, a corrida pelo tempo transforma-se em uma verdadeira caçada para dar fim a onda de ataques e assassinatos que ocorrem por toda a cidade, vitimando desde civis desempenhando suas atividades (policiais, enfermeiros, “mafiosos”😁😆😁 ) até autoridades no exercício de suas funções (juízes, comissários, agentes públicos). OK VICTOR, MAS AONDE QUER CHEGAR? QUAL É O SEU PONTO? E O QUE ISSO TEM A VER COM JAVA? Fique comigo para descobrir e compreender tudo 😉

Bem meus amigos, é como diz aquela velha expressão em inglês: first things first … Cito ela pois farei, a seguir, um adendo na forma de parágrafo único. Trata-se de um fato sobre mim que gostaria de esclarecer. Não sou programador, tão pouco especialista na linguagem Java. Minha formação não é de desenvolvedor, mas sim de administrador de sistemas e infraestrutura. Oficialmente sou tecnólogo em redes, e minhas afinidades são Linux, Cloud, Servicedesk, Monitoramento, Devops, e linguagens estruturadas (aquelas que não são orientadas). Deixo bem explicito essa última porque é bem provável, quase certo na verdade, que em algum momento eu fale alguma “besteira”, inverdade, ou dado incongruente acerca do Java. A minha desculpa é, mais uma vez, não ser um profissional dessa área em específico. Mas, por favor, não pare de ler agora, já que acredito ter feito o dever de casa, me esforçando ao máximo para buscar fontes confiáveis e fidedignas ao assunto. Por último, antes de dar início a pauta, um apelo a todos os leitores sêniores e plenos em JAVA: comente abaixo suas ressalvas e eventuais correções, gosto de ouvir pessoas, relatos e experiências.

JAVA E POO: PAI E CONCEITO

Programação Orientada a Objetos, POO para os íntimos, é definido como um paradigma (forma de pensar) para escrever programas de computador baseando-se exclusivamente em “objetos”. Nesses casos, os dados seriam campos ou atributos, e os códigos em si, procedimentos ou métodos. Em pouquíssimas linhas, a lógica aqui é: (a) construir um objeto menor, (b) que será peça de um objeto maior, (c) que será usado por outro objeto, este maior ainda, (d) cuja a junção e interação com outros objetos maiores formaram um sistema, (e) onde finalmente será operado por um objeto chamado cliente. Exemplos de linguagens genuinamente orientadas (ou seja, significativas, que não suportam multiparadigma): o próprio Java, C++, Ruby, Perl.

Antes do surgimento da POO, os softwares eram completamente estáticos. Traduzindo em miúdos, os “objetos” contidos neles eram imutáveis durante todo o tempo de execução. Uma vez iniciado, nada se cria, nada se modifica (…) Tudo é o que é, e ponto final. Basicamente, essa era a lei vigente. Somente em meados da década de 60 para o início dos anos 70, é que ocorreria a virada de maré, tendo o nome de Simula67. Uma linguagem de programação concebida em Oslo, na Noruega, pelos pesquisadores Kristen Nygaard e Ole-Johan Dahl. Aqui foram apresentados os conceitos de classe e herança, duas características dentre um conjunto fundamental, utilizado para definir a orientação a objeto.

Sua popularização (não da Simula67, e sim da POO), ou BOOM! … aconteceria um pouco mais tarde. Foi na década de 90, com a criação do Java por James Gosling, e também, é claro, graças a outras linguagens com igual premissa. Mas sendo a citada anteriormente uma das mais populares, permanecendo até os dias de hoje.

1 2 3 Appeared in 1995 Java

THE DARK KNIGHT: “BUS DRIVER? WHAT BUS DRIVER?”

Hipoteticamente falando, imagine a seguinte situação: você foi contratado para ser o arquiteto de um assalto a banco (…) Não, não, melhor ainda 💡 Você foi contratado para escrever um programa que simula um assalto a determinado banco. Evidentemente, o êxito de tal código apenas será considerado se duas condições forem satisfeitas: (A) pelo menos um dos participantes deverá sair vivo e (B) todo o dinheiro que está na sala-cofre precisa ser retirado, movido e transportado junto. E então? Como você faria? 🤔 Difícil não? Possibilidades: (1) armamento pesado e explosivos? (2) captura de reféns para distração e negociação? (3) escavar um túnel subterrâneo até o cofre principal? (4) ataque hacker para causar um apagão interno ou roubo da grana virtualmente? (5) dispersar várias equipes, em pequenos grupos, para realizar ocorrências e delitos por toda a cidade, com o intuito de consumir os recursos locais das autoridades (viaturas, policiais, comunicação, bombeiros, etc)? Pelos parágrafos sucessores ao corrente, deixarei a minha sugestão de plano/script para tamanho objetivo.

Primeiro, divida o seu time de integrantes em dois. Um será incumbido da abordagem tradicional, velha guarda e ortodoxa da coisa, ou seja, basicamente entrar pela porta da frente anunciando o assalto, atirando para o alto e neutralizando pessoal da segurança. Em contrapartida, o outro grupo será a força técnica e especializada, responsável por desativar alarmes, burlar portas e fechaduras eletrônicas, transpor barreiras físicas como paredes e afins, e finalmente descobrir o segredo e ter acessar ao cofre aonde está todo o dinheiro. Muito óbvio, trivial e simples para o leitor? Pois aqui vai o meu pulo do gato 🐱 Se o trabalho de mentoria foi única e exclusivamente seu, por que não ficar com louros da sua conquista apenas para si? Afinal você é o cérebro da operação, não é mesmo?! Portanto, sendo assim, escreva o seguinte em seu pseudo código-fonte …

< BEGIN_OF_CODE >

Fazer reuniões de planejamento, ação, sincronismo e ajustes, que visam definir cada etapa do processo, somente com um (no máximo dois capangas) por vez. A intenção aqui é não deixar que ninguém conheça completamente como é feita a tarefa do outro, e muito menos ter ciência do panorama geral com riqueza de detalhes.

Além de dividi-los em dois grandes times, conforme mencionado no início, divida-os ainda mais em subgrupos (duplas ou trios) para evitar desentendimentos, brigas ou contratempos ocasionados pelas emoções/sentimentos da natureza humana. Esse é um fator impossível de eliminar já que é algo intrínseco e inerente ao homem. Por isso, o mesmo precisa ser mitigado ao máximo possível, para conter eventuais danos.

Escolha a dedo um indivíduo de cada subgrupo para eliminar o seu parceiro, uma vez que o segundo tenha concluído seu trabalho. Mas antes da execução sumária, oriente para que o primeiro deve aguardar um pouco e confirmar, tanto verbalmente quanto visualmente, o sucesso do seu companheiro. Isso despertará sua ambição interna e ganância por dinheiro, pois dessa forma será uma parte a menos para dividir no final, instigando assim dez vezes mais a desempenhar seu papel com perfeição.

Não fique apenas sentando atrás de uma mesa … Coordenando a ação por telefone ou computador … Não, não. Levanta-se! Vá a campo e infiltre-se na sua própria operação! Reforce a importância de todos usarem mascará (o que inclui você) para não serem rastreados depois, e também para que seus “subordinados” não saibam que o chefe está bem ao lado, supervisionando.

Finalmente, e caso tudo ocorra bem, no hall de entrada do banco, ponto de encontro e extração, sobrará apenas você e um capanga (talvez dois). Terminado de arrastar as malas de dinheiro, o(s) capanga(s) restante(s) será(ão) um daquele(s) instruído(s) a eliminar os eventuais remanescentes da equipe. Então, esteja preparado! Verá a si mesmo tornar-se um alvo ambulante. Será indagado e acusado pela suspeita de que o chefe da operação lhe disse a mesma coisa que ordenou para os outros: elimine as partes. Ganhe tempo, movimente-se devagar, posicione-se para longe da porta e confunda-o falando que está errado, pois você está encarregado de matar o motorista do ônibus (…)

– Aposto que o chefe te disse para me matar quando terminássemos.

– Não, não, não. Eu mato o motorista do ônibus!

– Que motorista? De que ônibus? AAARRGGHHHH

– ( Veículo entra de ré e atropela o dito comparsa )

– Esse aí não levanta mais … Levanta?

– ( Gesto negativo com a cabeça )

– O que houve com o resto dos caras?

– ( Disparo de tiros da sua submetralhadora apontada para o peito do motorista )

Pronto! Está feito! Sucesso absoluto!!! Carregue o ônibus com as sacolas, entre e dirija. Saia para a rua no momento em que um comboio de ônibus escolares está passando e se camufle enquanto as viaturas policiais vão no sentido contrário em direção ao banco.

Daily Heath Ledger — daily-joker: THE DARK KNIGHT 2008 |...
Figura 01. Você ☝
Daily Heath Ledger — daily-joker: THE DARK KNIGHT 2008 |...
Figura 02. O comparsa ☝

< END_OF_CODE />

ENCAPSULAMENTO: LEITURA RECOMENDADA

https://dzone.com/articles/why-encapsulation-matters

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36.8552&rep=rep1&type=pdf

REFERÊNCIAS NERD: BATMAN O CAVALEIRO DAS TREVAS

https://www.youtube.com/watch?v=8VEGGgp-M2w

https://www.youtube.com/watch?v=vetKTtM7YyU

VICRLDA: 24 de maio de 2012

Aonde você estava na presente data logo acima? O que estava fazendo naquele dia? Sozinho ou com alguém? … Não, não … Me antecipando, e antes que me perguntem: não, eu não migrei de área, tampouco virei detetive particular ou perito forense. Talvez a minha resposta fosse igual a sua, que acredito ter sido SEI LÁ VICTOR ! NÃO ME LEMBRO !

Pois é, nove anos atrás é tempo demais para recordar eventos tão precisamente assim. No meu caso, somente sou capaz de afirmar com tanta certeza graças ao YouTube. HÃ? COMO É? Mas foi isso mesmo que acabou de ouvir! Senão fosse os três vídeos que estavam privados na minha conta eu também não saberia dizer.

Tudo aconteceu graças ao professor Thiago Gouveia, responsável pela disciplina de Administração de Sistemas Abertos, e docente no Instituto Federal de Educação, Ciência e Tecnologia da Paraíba (IFPB). Estávamos na metade do semestre letivo e como segunda nota ficou definido um seminário online por aluno, que deveria ser disponibilizado na forma de vídeo na plataforma Youtube. Sorteados tais temas, na verdade ferramentas, acabei pegando o Webmin. Ele existe até hoje, e você pode conferir em https://www.webmin.com/

Sendo considerado uma interface para gestão de servidores linux, ou melhor, uma web console para administrar sistemas Unix, o mesmo mostra-se uma excelente ferramenta para aprender e praticar conceitos básicos. Kernel, pacotes, estrutura e organização de diretórios, são alguns deles. Altamente recomendado para iniciantes mas também igualmente aos usuários de longa data, tendo em vista que os objetivos são os mesmos: facilitar a administração centralizando-a em um único ponto, e melhorar a interação tornando-a o mais gráfica possível.

Voltando ao seminário … Decidi transformar minha conta pessoal em um canal público no YouTube. Essa será outra forma de transmitir conteúdo para vocês, além de socializar. Trocaremos ideias, sugestão de novas pautas, tirar dúvidas através dos comentários, e afins. Por enquanto, e como podem imaginar, não há tanto conteúdo nele. Apenas três vídeos que compõem as partes da minha apresentação sobre o Webmin. São elas: 1) introdução e teoria; 2) instalação e configuração no Debian; 3) módulos e exercícios práticos.

Caso possa e tenha interesse, por favor, peço que se inscreva, favorite e compartilhe os vídeos com mais pessoas. Dessa maneira você dará relevância ao conteúdo, ajudará no crescimento da nossa comunidade e no alcance ao compartilhar assuntos opensource internet afora.

Espero que gostem e se divirtam! Câmbio e desligo!

https://www.youtube.com/channel/UCeY2sSz4ueavFyN0rSTgBog

BLOG SERIES: uma pausa nos estudos, lição de casa, +1 categoria, revisões periódicas e próximos posts

Olá querido leitor! E bem-vindo de volta! O sentimento que espero sempre despertar ao cumprimentá-lo, é basicamente: empatia e companheirismo. Acredito que não exista nada mais humano, nobre e belo (em uma palavra: gratificante) do que se colocar no lugar do outro, compreendê-lo, e ajudá-lo a evoluir/crescer, ensinando como você chegou ao ponto em que está hoje. Digo isso pois já fui um calouro na universidade, como sabem em um curso de tecnologia. Por vezes ao mesmo tempo que estava maravilhado com as linguagens, ide’s, sistemas operacionais, laborátorios de rede, etc, me peguei diversas outras assustado com algumas disciplinas e conteúdos específicos (alô Cálculo I, Física I, Java 😅). É claro que ao longo desse tempo tive ajuda de colegas, professores, veteranos, e amigos da área. A mesma coisa seguiu quando conclui, sai e entrei no mercado de trabalho … Foram meus pares (técnicos, analistas) e superiores (gerentes, diretores) que me auxiliaram na minha jornada profissional. Na verdade isso acontece até o presente momento, tendo em vista que a minha carreira ainda não terminou 👨‍💻

Pois muito bem, contada tal minibiografia, gostaria de resgatar brevemente (prometo!) a ideia por trás desse BLOG e sua disposição de conteúdos. DE NOVO VICTOR?! Calma, calma … Eu sei, eu sei … Somente faço isso pensando em um recém-chegado que caiu de paraquedas nessa postagem. Será rápido e indolor, palavra de escoteiro:

SERIES: Toda vez que um(a) ferramenta/tema/tópico for abordado(a) e identificado(a) por esse termo, saibam que trata-se do início de uma série de postagens ou faz parte de um mesmo conjunto prévio anteriormente criado. PLUS+: Aqui os posts darão continuidade a série “finalizada” da ferramenta presente no título. São uma espécie de extra, dica ou macete que aprendi no dia-a-dia. Algumas vezes tive que correr atrás, pesquisando, testando e documentando. Foi aí que me ocorreu a ideia de compartilhá-las separando-as em um contexto à parte. NEWS: Sugestivo e como a própria tradução do inglês para o português – serão notícias, novidades, atualizações e divulgação de eventos mundo afora. Minhas fontes? Canais oficiais das empresas/organizações responsáveis pelas ferramentas (websites, twitter, contas youtube, newsletter, RSS, etc.)

https://machinesbecomeservices.com/2020/11/04/vicrlda-im-alive-voltei-retorno-notas-e-avisos/

Igualmente importante, e sobre a categoria BLOG do site, segue:

A cada vez, quando quiser interagir, visando definir ou informar algo para o futuro (anúncios, enquetes, consultas, questionários) colocarei no início do título BLOG Series, categorizando o artigo como Blog, e marcando o texto com TAG “blog “.

https://machinesbecomeservices.com/2021/03/22/vicrlda-1-ano-25-posts-3-178-views-803-visitas-7-seguidores-no-wordpress-com/

Acerca da alternância e ordem dos posts, essas são as minhas diretrizes:

1º mandamento: Sempre que começar uma SÉRIE, terminar o mais breve possível (em um futuro próximo). Nunca, jamais deixá-la no limbo e retomar depois. O raciocínio se perde e a lógica se esvai. 2º mandamento: Manter no ar (online/disponível) no máximo duas ou três SÉRIES simultâneas. Mais que isso, corre o risco de comandos, códigos e conceitos serem trocados, gerando dessa forma uma baita confusão. 3º mandamento: Entre uma SÉRIE e outra, durante seus intervalos, fazer pequenas pausas trazendo conteúdo menos denso. Por exemplo, notícias (NEWS) e extras (PLUS+). A justificativa é dar tempo para efeitos de laboração e assimilação da(s) SÉRIE(s) principal(is).

https://machinesbecomeservices.com/2021/02/09/zabbix-series-teoria-monitoramento-e-os-3-qs-o-que-por-que-para-que/

Em suma, foi baseado nessas três colunas (ou como as chamo: pilares de argumento) que tomei algumas decisões, e portanto faço aqui anúncios relativos aos próximos eventos do BLOG.

  • Pequena pausa nas séries, incluindo (e principalmente) o Ansible … A ideia é dar tempo para laborar, praticar e buscar novos materiais. Quero dizer, por conta própria, sozinhos é claro. SUGESTÃO: referências/bibliografia que julguem interessantes, por favor, peço que compartilhem abaixo nos comentários. Tenho curiosidade, e seria bom também para os demais leitores, na minha opinião.
  • Os próximos dois posts serão, respectivamente:
    • um artigo pessoal, divulgando outro meio de interagir e revisar assuntos com vocês. Aguardem!
    • um texto inaugural, apresentando uma nova categoria. Tomara que gostem da proposta!

No mais, se cuidem, usem máscara, fiquem em casa, vacina sim, e esperança sempre!

Até logo!

ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: conditionals

CONT.

👈 ANTERIOR: WHERE TASKS RUN ?

Condicionais, em bom português, são aquelas famosas palavrinhas que aprendemos (lógica da programação) com o intuito de:

  • parar momentaneamente o fluxo do programa;
  • desviar a sequência ou conteúdo de variável para um bloco de código que faz checagem;
  • chamar uma função ou sub-rotina;
  • capturar exceções e tratá-las;
  • exibir informações ou mensagens ao usuário;
  • dentre outras tarefas.

Pois bem, alguns exemplos dessas palavras que normalmente usamos para tais propósitos: SE, SENÃO, ENTÃO, ENQUANTO, PARA, E, OU, NÃO (!not) …

No casos dos playbooks, nossos objetivos vão desde: (a) executar diferentes tasks que dependem do valor de um fato (dado de um host remoto), variável ou resultado anterior (b) atribuir valor a uma variável baseando-se em outra variável precedente (c) definir e criar novos grupos de hosts em cima de alguns critérios de correspondência.

Uma pequena ressalva da documentação oficial:

Ansible usa testes e filtros Jinja2 em condicionais. O Ansible oferece suporte a todos os testes e filtros padrão e também adiciona alguns exclusivos

https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#playbooks-conditionals

E uma pequena nota de rodapé:

Existem muitas opções para controlar o fluxo de execução no Ansible. Você pode encontrar mais exemplos de condicionais com suporte em https://jinja.palletsprojects.com/en/master/templates/#comparisons

https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#playbooks-conditionals

Devido ao sumário de tamanho “razoável” que esta seção apresenta na wiki oficial, tentarei ao máximo fazer breves explanações dos códigos e talvez pule algumas delas, seja porque são muito raras de utilizar ou porque fogem muito dos nossos objetivos, ok?

Figura 01. Sumário da seção (docs.ansible.com)

04-a. Condicionais básicas com WHEN

A unidade mais básica para uma condicional, chamada por alguns de “declaração mais simples”, é essencialmente aplicada a uma única tarefa por vez. Na prática, isso quer dizer que, quando se cria uma tarefa, seguida de uma declaração when, um teste será executado. Essa cláusula when na verdade é uma expressão Jinja2 bruta e sem chaves duplas. Quando se roda uma task ou playbook o que acontece é que o Ansible valida esse teste para todos os hosts remotos. Se qualquer um deles “passar na prova”, o valor retornado é true, e então a task é executada. Para ilustrar, um exemplo:

tasks:
  - name: Configure SELinux to start mysql on any port
    ansible.posix.seboolean:
      name: mysql_connect_any
      state: true
      persistent: yes
    when: ansible_selinux.status == "enabled"
    # all variables can be used directly in conditionals without double curly braces

! ! ! BASEADAS EM ANSIBLE_FACTS ! ! !

Às vezes, ao invés de executar tarefas, simplesmente queremos o oposto. Em outras palavras, desejamos pulá-las e passar adiante. Isso pode ser feito através dos fatos, ou melhor, por meio dos atributos (dados) de um node específico. IP, SO, filesystem, status, são apenas alguns para citar.

Com as condicionais baseadas em fatos, é possível:

  • instalar pacotes somente para determinadas versões ou famílias de um sistema operacional
  • pular configurações de firewall para hosts internos à rede
  • fazer uma limpeza em sistemas de arquivos muito cheios

Veja quais fatos estão disponíveis em cada host, acrescentando uma simples tarefa do tipo debug:

- name: Show facts available on the system
  ansible.builtin.debug:
    var: ansible_facts

Exemplo 1 x 1: uma condicional para um fato

tasks:
  - name: Shut down Debian flavored systems
    ansible.builtin.command: /sbin/shutdown -t now
    when: ansible_facts['os_family'] == "Debian"

Exemplo N x N: múltiplas condicionais para múltiplos fatos

tasks:
  - name: Shut down CentOS 6 and Debian 7 systems
    ansible.builtin.command: /sbin/shutdown -t now
    when: (ansible_facts['distribution'] == "CentOS" and ansible_facts['distribution_major_version'] == "6") or
          (ansible_facts['distribution'] == "Debian" and ansible_facts['distribution_major_version'] == "7")

Outra forma, um pouco mais abreviada:

tasks:
  - name: Shut down CentOS 6 systems
    ansible.builtin.command: /sbin/shutdown -t now
    when:
      - ansible_facts['distribution'] == "CentOS"
      - ansible_facts['distribution_major_version'] == "6"

https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#commonly-used-facts

! ! ! BASEADAS EM VARIÁVEIS ! ! !

Você também pode criar condicionais com base em variáveis definidas nos playbooks ou inventários. Como as condicionais requerem entrada booleana (um teste deve ser avaliado como True para acionar a condição), você deve aplicar o | Filtro booleano para variáveis não booleanas, como variáveis de string com conteúdo como ‘sim’, ‘ativado’, ‘1’ ou ‘verdadeiro’.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#conditionals-based-on-variables

Defina suas variáveis exatamente assim:

vars:
  epic: true
  monumental: "yes"

Agora execute o código a seguir:

tasks:
    - name: Run the command if "epic" or "monumental" is true
      ansible.builtin.shell: echo "This certainly is epic!"
      when: epic or monumental | bool

    - name: Run the command if "epic" is false
      ansible.builtin.shell: echo "This certainly isn't epic!"
      when: not epic

Verá que o Ansible roda uma delas e pula a outra!

! ! ! BASEADAS EM LOOPS ! ! !

Processa a condição separadamente para cada item presente no laço. Isso ocorre para que você possa executar a tarefa em alguns elementos e ignorá-la em outros. Por exemplo:

tasks:
    - name: Run with items greater than 5
      ansible.builtin.command: echo {{ item }}
      loop: [ 0, 2, 4, 6, 8, 10 ]
      when: item > 5

Sobre uma lista:

- name: Skip the whole task when a loop variable is undefined
  ansible.builtin.command: echo {{ item }}
  loop: "{{ mylist|default([]) }}"
  when: item > 5

Sobre um dicionário:

- name: The same as above using a dict
  ansible.builtin.command: echo {{ item.key }}
  loop: "{{ query('dict', mydict|default({})) }}"
  when: item.value > 5

CONTINUA (…)

Próximo post >>> Blocks

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#playbooks-conditionals

ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: where tasks run ???

CONT.

👈 ANTERIOR: LOOPS

Ao executar um playbook, o comportamento que se espera do Ansible é:

  1. antes, reunir todos os fatos referentes aos nodes ( gather_facts )
  2. depois, rodar as tarefas especificadas ( playbook ) somente nas máquinas-alvo que estão expressas ou de acordo com a linha “hosts” , presente no próprio main.yml, test.yml por exemplo.

Dito isso, quatro caminhos estão abertos ao admin responsável (você, eu). São eles:

  • delegar tarefas a uma máquina em particular
  • delegar tarefas a um grupo específico
  • delegar fatos a uma série de hosts ou grupos
  • executar um playbook inteiro localmente

03-a. Tasks que NÃO podem ser delegadas !!!

A execução de algumas pouquíssimas tarefas está restrita apenas ao controlador, e essas sempre serão rodadas única e exclusivamente nele, não importando o que você faça. include , add_hosts , e debug integram essa lista, não podendo de forma nenhuma serem delegadas a terceiros.

03-b. Delegando tasks . . .

Agora sim meus caros colegas 😉, tarefas que podem ser delegadas para nodes remotos. Trecho a seguir retirado da documentação oficial:

Se você deseja executar uma tarefa em um host com referência a outros hosts, use a palavra-chave delegate_to em uma tarefa. Isso é ideal para gerenciar nós em um pool com carga balanceada ou para controlar janelas de interrupção. Você pode usar a delegação com a palavra-chave serial para controlar o número de hosts em execução ao mesmo tempo

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegating-tasks
---
- hosts: webservers
  serial: 5

  tasks:
    - name: Take out of load balancer pool
      ansible.builtin.command: /usr/bin/take_out_of_pool {{ inventory_hostname }}
      delegate_to: 127.0.0.1

    - name: Actual steps would go here
      ansible.builtin.yum:
        name: acme-web-stack
        state: latest

    - name: Add back to load balancer pool
      ansible.builtin.command: /usr/bin/add_back_to_pool {{ inventory_hostname }}
      delegate_to: 127.0.0.1

** 127.0.0.1 : significa que será rodado na máquina corrente, ou seja, localmente naquela que executa o Ansible!

03-c. Delegando fatos . . .

Delegar tarefas do Ansible é como delegar tarefas no mundo real – seus mantimentos pertencem a você, mesmo que outra pessoa os entregue em sua casa. Da mesma forma, quaisquer fatos reunidos por uma tarefa delegada são atribuídos por padrão ao inventory_hostname (o host atual), não ao host que produziu os fatos (o delegado ao host). Para atribuir fatos coletados ao host delegado em vez do host atual, defina delegate_facts como true.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegating-facts
---
- hosts: app_servers

  tasks:
    - name: Gather facts from db servers
      ansible.builtin.setup:
      delegate_to: "{{ item }}"
      delegate_facts: true
      loop: "{{ groups['dbservers'] }}"

Esta tarefa reúne fatos para as máquinas no grupo dbservers e atribui os fatos a essas máquinas, mesmo que a play seja direcionado ao grupo app_servers. Desta forma, você pode pesquisar hostvars [‘dbhost1’] [‘ansible_default_ipv4’] [‘endereço’], mesmo que dbservers não tenham feito parte da peça ou deixados de fora usando –limit.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegating-facts

03-d. Playbooks locais . . .

Pode ser útil usar um playbook localmente em um host remoto, ao invés de conectar por SSH. Isso pode ser usado para garantir a configuração de um sistema, colocando um playbook em um crontab.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#local-playbooks
ansible-playbook playbook.yml --connection=local
---
- hosts: 127.0.0.1
  connection: local

CONTINUA (…)

Próximo post >>> Conditionals

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#playbooks-delegation

ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: building loops

CONT.

👈 ANTERIOR: BECOME

O que fazer quando é necessário repetir determinada ação mais de uma vez ??? Automatizar, é claro, você diria … Tudo bem, já entendi que pegou o espírito da coisa 🙃 E fico deveras feliz por isso, diga-se de passagem! Mas, o que eu quis dizer é como fazê-lo em pormenores? Como executar valendo-se da lógica da programação? Há duas respostas válidas, contudo uma é mais inteligente e menos trabalhosa, e a outra é mais lenta (para não desmerecê-la 😬 haha) e braçal. A primeira delas seria utilizar um monte de IF’s e ELSE’s para cada entrada, interação ou condição. Em contrapartida, a segunda seria criar um laço (daí seu nome loop, em inglês) com uma variável “contador” interna. Essa controlaria a execução do mesmo em N vezes, e até que a condição X fosse satisfeita. Resultado? Um código mais bonito, limpo, enxuto, com menos linhas, e mais otimizado.

No contexto do Ansible, ou de qualquer outra ferramenta de automação, tais ações “repetitivas” abrangeriam desde adicionar vários usuários, replicar uma configuração em um pool de máquinas, até mudar a propriedade/permissão (ou dono) de uma série de arquivos e pastas, por exemplo. Para tal o ansible nos fornece duas palavras-chave: loop e with_<lookup> (lookup em português pode ser traduzido como busca, pesquisa, chave ou valor).

Antes de expor e debater os tópicos a seguir, cabe aqui, e quero destacar algumas notas acerca do recurso loop :

  • Foi introduzido a partir do Ansible 2.5
  • Está presente em todas as versões sucessoras (2.5+)
  • Ainda não substitui completamente o with_<lookup>, embora a ideia seja exatamente essa no futuro.
  • Na maioria dos casos recomenda-se, e satisfaz muito bem, o uso do loop . Somente em situações extremamente específicas o with_<lookup> dá pleno suporte, o que acaba “vencendo” seu concorrente amigo, e portanto o uso dele é o único meio viável para solucionar.
  • Não está obsoleta ou tão pouco depreciada a sintaxe do with_lookup, continuando assim totalmente válida, embora isso possa mudar no médio-longo prazo.
  • O loop encontra-se em constante mudança visando principalmente seu aperfeiçoamento. Para atualizações e alterações do mesmo, por favor consultar o CHANGELOG https://github.com/ansible/ansible/tree/devel/changelogs

02-a. Comparativo entre loop e with_*

As únicas palavras-chave capazes de complementar o with_ são aquelas que estão disponíveis em https://docs.ansible.com/ansible/latest/plugins/lookup.html#lookup-plugins Ou seja, na prática, qualquer uma delas quando utilizadas correspondem ao asterisco (presente no título desta sessão). Para refrescar a memória, * é conhecido também como o caractere-curinga na computação, especificamente quando falamos em interpretadores de comandos nos sistemas operacionais.

A palavra loop é o mesmo que usar a expressão with_list, sendo a primeira uma melhor escolha para loops que não possuem tanta complexidade. Porém, o loop não aceita como entrada nenhuma ‘string’. Veja mais em https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html#query-vs-lookup

Genericamente, e simplificando bastante, qualquer with_* pode facilmente ser trocado por loop. Claro que salva as devidas proporções e ressalvas, todas essas descritas aqui https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html#migrating-to-loop

02-b. Loops Tradicionais (ou padrão/modelos)

! ! ! Interagindo sobre uma lista simples ! ! !

Se uma task precisa ser executada mais de uma vez em determinado host, recomenda-se usar como padrão o próprio loop, assim este agiria de acordo e sobre uma lista de strings, por exemplo. Em outras palavras, defina a lista diretamente, de uma vez só e já estando dentro da task em questão:

- name: Add users and give them root powers
  ansible.builtin.user:
    name: "{{ item }}"
    state: present
    group: "wheel"
  loop:
     - victor
     - viktor
     - vitor
     - vicrlda

O código acima ☝ seria equivalente ao de baixo 👇 (só que mais elegante! e com menos tec-tec-tec-tec 🔉💻💬)

- name: Add user vitor
  ansible.builtin.user:
    name: "vitor"
    state: present
    groups: "wheel"

- name: Add user vicrlda
  ansible.builtin.user:
    name: "vicrlda"
    state: present
    groups: "wheel"

.
.

.
.

! ! ! Interagindo sobre uma lista de hashes ! ! !

Caso tenha uma lista de hashes para trabalhar, utilize referências no formato de chave:subchave dentro do loop.

- name: Add multiple users
  ansible.builtin.user:
    name: "{{ item.name }}"
    state: present
    groups: "{{ item.groups }}"
  loop:
    - { name: 'victor', groups: 'wheel' }
    - { name: 'viktor', groups: 'root' }

! ! ! Interagindo sobre um dictionary ! ! !

Neste caso, simplesmente use o dict2items https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#dict-filter :

- name: Using dict2items
  ansible.builtin.debug:
    msg: "{{ item.key }} - {{ item.value }}"
  loop: "{{ tag_data | dict2items }}"
  vars:
    tag_data:
      Environment: dev
      Application: payment

02-c. Registrando variáveis com um loop

Esse artifício é comumente usado na lógica da programação, em termos genéricos, e desde sempre, remontando ao seu início e concepção. Naturalmente, por tabela, também é observado nas linguagens. Em outras palavras, o que temos é, basicamente um evento partilhado ocorrendo tanto no macro quanto no micro ecossistema. Respeitando, é claro, as particularidades de cada um (limitações, capacidades e sintaxe).

E com os playbooks não poderia ser diferente. Somos capazes de armazenar a saída de um loop dentro de uma variável. Por exemplo,

- name: Register loop output as a variable
  ansible.builtin.shell: "echo {{ item }}"
  loop:
    - "apple"
    - "banana"
  register: echo

Loops que vem logo após a variável registrada, com o intuito de inspecionar eventuais resultados, talvez se assemelhem ao trecho a seguir:

- name: Fail if return code is not 0
  ansible.builtin.fail:
    msg: "The command ({{ item.cmd }}) did not have a 0 return code"
  when: item.rc != 0
  loop: "{{ echo.results }}"

Por padrão, o comportamento da variável durante a execução/interação do loop é sempre armazenar o valor do item atual, indiferente se são números, strings ou caracteres.

- name: Place the result of the current item in the variable
  ansible.builtin.shell: echo "{{ item }}"
  loop:
    - one
    - two
  register: echo
  changed_when: echo.stdout != "one"

02-d. Loops Complexos

! ! ! LISTAS ANINHADAS ! ! !

Aninhado(a), conceitualmente restrito ao universo da programação, implica dizer que um dado elemento está contido em outro elemento. Se preferir mais sinônimos, seria o mesmo que alojado, hospedado, instalado. Isso compreende desde funções, sub-rotinas, até vetores e matrizes. Exemplo: um vetor de tamanho três [0, 1, 2] cujas posições na memória são na verdade ponteiros para outros três vetores distintos. Talvez o mais importante aqui, e que vale destacar, é o tamanho da jurisprudência do primeiro ou o limite imposto ao segundo … ❓❓❓ Certo, certo, eu explico. Vamos imaginar que os sujeitos (elementos) em questão sejam rotinas e sub-rotinas. Então, partindo do pressuposto que apresentei, uma sub-rotina “filha” somente poderia ser chamada para rodar durante o programa única e exclusivamente por sua rotina “mãe”. Caso uma rotina “madrasta”, por exemplo, tentasse invocar essa mesma sub-rotina “filha”, não haveria êxito algum. Isso porque, de antemão, a primeira (madrasta) nunca iria enxergar a segunda (filha) pois ela apenas fica visível para a terceira (mãe). Isso é o que determinados autores chamam de “fazer sentido localmente”, e que é considerada uma forma de encapsulamento.

Ufa! 🥴 Agora sim, voltando ao contexto dos playbooks, e finalizando esse tópico antes de passar para o próximo (…)

Em situações de listas aninhadas recomenda-se o uso de expressões Jinja2 para melhor tratá-las. Como segue abaixo, um loop que combina várias listas:

- name: Give users access to multiple databases
  community.mysql.mysql_user:
    name: "{{ item[0] }}"
    priv: "{{ item[1] }}.*:ALL"
    append_privs: yes
    password: "foo"
  loop: "{{ ['alice', 'bob'] |product(['clientdb', 'employeedb', 'providerdb'])|list }}"

! ! ! INVENTÁRIOS ! ! !

Mais uma opção para uso dos loops no Ansible ocorre quando se trata de arquivos de inventário. Isso nos possibilita varrê-los ou construí-los sem sair do laço. E melhor, não é obrigatório usar todo o arquivo e sim apenas uma parte dele, caso prefira assim. Para tal, basta informar a palavra-chave loop com a variável ansible_play_batch ou a variável groups

- name: Show all the hosts in the inventory
  ansible.builtin.debug:
    msg: "{{ item }}"
  loop: "{{ groups['all'] }}"

- name: Show all the hosts in the current play
  ansible.builtin.debug:
    msg: "{{ item }}"
  loop: "{{ ansible_play_batch }}"

02-e. Adicionando controles aos loops

(A partir da versão 2.1+)

(Palavra-chave: loop_control)

! ! ! LIMITANDO A TELA/SAÍDA DO LOOP ! ! !

Para estruturas de dados muito complexas, executar um laço pode ser algo extenso, e consequentemente, a saída gerada (console) se torna igualmente enorme. Evite dores de cabeça e olhos cansados utilizando a diretriz label com loop_control :

- name: Create servers
  digital_ocean:
    name: "{{ item.name }}"
    state: present
  loop:
    - name: server1
      disks: 3gb
      ram: 15Gb
      network:
        nic01: 100Gb
        nic02: 10Gb
        ...
  loop_control:
    label: "{{ item.name }}"

! ! ! Pausa dentro de um loop ! ! !

Controle o tempo, aqui medido em segundos, entre a execução de cada item dentro de uma loop task (tarefa repetitiva). Use a diretriz pause com a palavra loop_control

# main.yml
- name: Create servers, pause 3s before creating next
  community.digitalocean.digital_ocean:
    name: "{{ item }}"
    state: present
  loop:
    - server1
    - server2
  loop_control:
    pause: 3

! ! ! Definindo nomes internos e externos ao loop com loop_var ! ! !

Você pode aninhar duas tarefas de loop usando include_tasks. No entanto, por padrão, Ansible define o item de variável de loop para cada loop. Isso significa que o loop interno aninhado sobrescreverá o valor do item do loop externo. Você pode especificar o nome da variável para cada loop usando loop_var com loop_control:

# main.yml
- include_tasks: inner.yml
  loop:
    - 1
     - 2
     - 3
  loop_control:
    loop_var: outer_item

# inner.yml
- name: Print outer and inner items
  ansible.builtin.debug:
    msg: "outer item={{ outer_item }} inner item={{ item }}"
  loop:
    - a
     - b
     - c

CONTINUA (…)

Próximo post >>> WHERE TASKS RUN?

REFERÊNCIAS:

https://docs.ansible.com/core.html

https://docs.ansible.com/ansible/latest/user_guide/index.html

https://docs.ansible.com/ansible/latest/user_guide/index.html#writing-tasks-plays-and-playbooks

https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html#playbooks-loops

ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: como escrevê-los?

* Sigla para: < How To Write >

Recapitulando o que vimos até o momento acerca do Ansible:

  • Teoria
    • DevOps: conceito, história, curiosidades ✅
    • Por que automatizar com ansible? ✅
    • 5 conceitos fundamentais ✅
  • Prática
    • Linha de comando, hello.YML e Ad-Hoc ✅
    • Web console: AWX/TOWER ✅
    • Como executar um JOB graficamente em tempo real ✅

Poxa vida! 😲 Eu diria um bocado não é mesmo? Sendo ou não, o que importa é que a estrada ainda se encontra a nossa frente e aos poucos, devagar, mas com passos firmes vamos progredindo no ROADMAP de um DEVOPS. Portanto, e acho que todos já estão acostumados com as minhas deixas (ou chamados) para iniciar um POST do blog … Hey Ho! Let’s go!

Muito bem jovens, ao que interessa então. Se você já buscou material, ou até mesmo cursou algum tipo de preparatório para o Ansible, as chances do professor ter abordado logo no começo (imediatamente após o briefing/overview) esses itens que vou mostrar é muito grande. Em outras palavras, e simplificando, acredito que tenha sido dessa forma: 1. o que é ansible? / 2. definições e termos / 3. prompt, módulos e comandos ad-hoc / para finalmente chegar em 4. como escrever playbooks. Por último é que eles mostram o AWX, boas práticas, roles, hosts windows, network e paramiko, etc. Mas e daí Victor? Eu sei, não há nada de errado com isso. Cada um ministra e monta seu plano de aulas da maneira que achar melhor aos estudantes. E tudo bem, ok. Mas no nosso caso, vocês e eu, quis inverter um pouco as coisas e adiantar logo a parte gráfica do ansible, ou seja, o tower/awx. Na verdade o meu intuito era “cativar” a todos apresentando de cara as duas faces do mesmo: linha de comando e interface web. Assim cada pessoa poderia escolher a melhor forma de trabalhar, de acordo com seu gosto e afinidade. Gosta de terminal? Ótimo, vá de CLI e seja feliz! Não, prefiro botões, gráficos e menus. Maravilha, pegue a GUI e curta a vida! O que quero dizer aqui é não existe método certo ou errado, melhor ou pior. Não, pelo contrário, há vantagens e desvantagens em cada um deles. Cabe tão somente a você pesar os prós e contras e escolher sua forma de operar. Lembrando sempre que é possível combiná-las tá? Por exemplo, tal tarefa é mais rápido e comodo se fizer via bash, já aquela outra é necessário maior controle de usuários e permissões, então farei por meio da web. Entenderam? Ou enrolei demais? 🤔

POOL DE INFORMAÇÕES

https://docs.ansible.com/

Desde sempre admirei empresas de tecnologia, bem antes de entrar na faculdade. Talvez por isso que enveredei para este ramo. Google, Microsoft, IBM, Facebook, e tantas outras (ora gigantes, ora um pouco mais modestas) foram alguns exemplos de modelo a perseguir, almejar e quem sabe um dia entrar no time… Uma vez imerso nesse grande oceano, chamado TI, passei a ter bastante contato com Linux e suas distros. Além de ter curtido, comecei a ficar de olho, meio que acompanhar notícias e bastidores das empresas idealizadoras/responsáveis. Foi assim que fiquei maravilhado com todo o trabalho por trás de cada uma dessas distribuições. Digo, não apenas o resultado final: o lançamento periódico de novas versões. Mas sim o suporte, divulgação, comunidades, fóruns oficiais, documentação, e afins. Também vale um destaque especial, o principal “cartão de visita” dessas empresas: os websites. Falo sério, você já acessou a Canonical, Red Hat, Suse e System76 ?? É verdadeiro deleite, e de encher os olhos, devido a tanto primor e cuidado com o design e layout. São muito bonitos, sem exceção!!!

E como prova disso, trago a seguir uma captura de tela da página INDEX da documentação do ansible. Podemos dizer que ela é uma espécie de hub central, uma vitrine, para orientar sobre tudo que o mesmo é capaz, e como fazer. Confiram:

Figura 01. Docs INDEX page

Acima devidamente circulado está o nosso foco: a documentação base, ou seja, relacionada ao núcleo, chamado de ansible-core. Pelas próximas semanas vamos nos debruçar sobre a sintaxe, lógica, melhores práticas, organização de pastas e arquivos, reuso de código, otimização, e muito mais. Para isso, irei sempre pontuar já no título do POST em questão, o que vamos aprender nele. Ex: loops, variáveis, templates, roles, e assim por diante.

Qualquer dúvida ou lacuna que porventura tenha deixado, acessem o link e vão direto na fonte para saná-las. Até porque não pretendo abordar absolutamente tudo que está lá, ok? Senão o que estaria fazendo é um simples CTRL-C + CTRL-V do referido conteúdo. E isso não quero, e tão é algo ético. Resumindo: antes de ler aqui, recomendo dar uma estudada pela oficial, por favor. Embora prometo fazer o meu melhor para se aproximar ao máximo dos mestres da Red Hat 🎩

01-a. BECOME: acesso, usuários e permissões

Ansible utiliza meios de escalonamento de privilégios pré-existentes na máquina remota. Isso é o que eles chamam de become. Ele seria o equivalente ao su, sudo, runas e similares. O objetivo é tanto permitir quanto executar tarefas locais nos alvos (nodes), usando privilégios de root ou qualquer outra permissão já criada dentro do nó. O efeito prático disso é torna-se outro usuário¹ dentro do host² em questão, sendo o primeiro completamente diferente daquele que usou para entrar no segundo.

i ) Usando o become

É possível controlá-lo através de tasks, plays, variáveis de conexão ou linha de comando. Em caso de duas ou mais ao mesmo tempo (sim, isso é válido e às vezes comum) consulte atentamente as regras de precedência para as mesmas. Leia mais aqui: https://docs.ansible.com/ansible/latest/reference_appendices/general_precedence.html#general-precedence-rules

! ! ! Diretivas do become ! ! !

Estabeleça como definir o become, controlando o mesmo à nível de task ou play. Variáveis e diretivas são independentes entre si. Por exemplo, definir become_user não é a mesma coisa que “só” become.

become: defina para 'yes' e ative o escalonamento de privilégios
become_user : defina o usuário com os privilégios desejados. ou seja, a credencial que você pretende se tornar e não o usuário que fez login.
become_method : (à nível de play ou task) sobrescreve o método padrão definido em ansible.cfg
become_flags :(à nível de play ou task) permite o uso de flags específicas para uma tarefa ou play. bastante comum quando se quer mudar o usuário para 'nobody' em casos de 'shell' setado para 'nologin'

Por exemplo,

Gerenciar um serviço (daemon) que requer privilégios de root … Em um cenário onde o usuário conectado não é root … Neste caso, utilizamos o valor padrão de become_user, que é justamente ‘root’

- name: Ensure the httpd service is running
  service:
    name: httpd
    state: started
  become: yes

Executar algo como ‘nobody’ quando o shell (terminal) está configurado para ‘nologin’

- name: Run a command as nobody
  command: somecommand
  become: yes
  become_method: su
  become_user: nobody
  become_flags: '-s /bin/sh'

To specify a password for sudo, run ansible-playbook with --ask-become-pass (-K for short). If you run a playbook utilizing become and the playbook seems to hang, most likely it is stuck at the privilege escalation prompt. Stop it with CTRL-c, then execute the playbook with -K and the appropriate password.

! ! ! Variáveis de conexão ! ! !

Nós e grupos suportam diversas, e distintas, opções ‘become’. Em cada gerenciável existe a possibilidade de defini-las em um arquivo inventário, ou usá-las como se fossem variáveis comuns.

São elas,

ansible_become: em termos de finalidade, praticamente uma cópia da diretiva become. ou seja, define se o escalonamento de privilégio será utilizado ou não.
ansible_become_method: escolhe qual forma de privilégio será usada.
ansible_become_user: dita qual usuário você irá se tornar via método de escalonamento. não é a mesma coisa que ansible_become: yes
ansible_become_password: senha do usuário citado anteriormente. é possível, mas não aconselhável, passar segredos em texto plano. aprenda formas mais seguras em https://docs.ansible.com/ansible/latest/user_guide/vault.html#playbooks-vault
! ! ! Opções na linha de comando ! ! !
--ask-become-pass OU -K
Solicita a senha "privilegiada" ... É usada para todos os hosts
--become OU -b
Executa as instruções com o become ... Não necessariamente haverá sempre uma senha
--become-method=BECOME_METHOD
Método utilizado ... Padrão = SUDO ... Outros [su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl]
--become-user=BECOME_USER
Rode os comandos como este 'usuário' ... Padrão = ROOT ... Não é o mesmo que --become ou -b

ii ) RISCOS E LIMITAÇÕES DO BECOME

Intuitivo mas não perfeito, o become apresenta certas limitações em sua capacidade. O que gera algumas questões “interessantes” a serem avaliadas, para que não se transformem em “desagradáveis”. Todas elas podem ser estudadas no link a seguir:

https://docs.ansible.com/ansible/latest/user_guide/become.html#risks-and-limitations-of-become

  • Riscos de se tornar um usuário sem privilégios
  • Não compatível com todos os plug-ins de conexão
  • Apenas um método pode ser habilitado por host
  • O escalonamento de privilégios deve ser generalista
  • Talvez não seja possível acessar variáveis de ambiente preenchidas por pamd_systemd

CONTINUA (…)

Próximo post >>> LOOPS

REFERÊNCIAS:

https://docs.ansible.com/

https://docs.ansible.com/core.html

https://docs.ansible.com/ansible/latest/

https://docs.ansible.com/ansible/latest/user_guide/index.html

https://docs.ansible.com/ansible/latest/user_guide/index.html#writing-tasks-plays-and-playbooks

https://docs.ansible.com/ansible/latest/user_guide/become.html#become