ANSIBLE SERIES: YML … add sudo(ers) >> no prompt or ask

Olá! Como vai? Muito prazer, Victor é o meu nome … Ou @vicrlda, se preferir … Navegando pela internet em busca de inspiração, situações, exemplos práticos para exercitar e solucionar via ANSIBLE ??? É um sysadmin ou desenvolvedor que anseia o cargo de Engenheiro Devops / SRE ?? Por favor, peço que me deixe cumprimentá-lo e lhe dar os parabéns, pois o caro leitor (você) veio ao lugar certo! Seja mais do que bem-vindo ao @machinesbecomeservices.com … A partir de hoje, serei o seu humilde anfitrião / companheiro / fiel escudeiro nessa incrível jornada que chamo de “estrada para a automação”

Em contrapartida, se por acaso você é um veterano, não pera (…) Melhor dizendo, se já é um velho conhecido meu e do BLOG, por favor pule para a próxima etapa … Ops! Quero dizer, seção (hahaha)

Ambiente: Máquinas e Pré-requisitos

Para total compreensão e sentido, por favor, peço que…

Recém-chegados, leiam o seguinte post, e partam desse princípio:

https://machinesbecomeservices.com/2021/09/21/vicrlda-dual-boot-pop_os-gnome-boxes-vpn-checkpoint-e-novo-workflow/

Longa datas, revisem esse outro post, e iniciem suas VMs do ponto exato em que paramos:

https://machinesbecomeservices.com/2020/12/01/ansible-series-hands-on-01-modo-cli-e-hello-yml-1st-playbook/

Quem ainda não entendeu nada, acompanhe a śerie ANSIBLE desde o começo 😉

https://machinesbecomeservices.com/?s=ansible

GNOME Boxes, uma solução All-in-One: Download nativo de ISOs + Criação das instâncias + Uso integrado

Com o Boxes, não é mais necessário sair da ferramenta em busca de outros meios/softwares para baixar, instalar, configurar, usar máquinas virtuais. Destaque principalmente, e especialmente, para a primeira etapa que é fazer o download das ISOs, onde normalmente acessaríamos os respectivos sites oficiais de cada uma, e obteríamos via métodos tradicionais como o próprio GET ou até mesmo TORRENT. Bem, dito isso, vamos abri-lo agora para conhecê-lo um pouco melhor e ver como as coisas transcorrem, além de claro, testemunhar toda a sua simplicidade, praticidade e comodidade. Teclado e mouse em mãos, vem comigo!

Uma vez baixado via loja de aplicativos linux favorita (deb, rpm, flatpak, snapp), abra-o pela primeira vez e verá a seguinte tela:

Figura 01: GNOME Boxes v.40.2

Clique no ícone + para iniciar o processo de criação. Observe que a janela aberta traz consigo três opções principais, que são: (a) os sistemas operacionais mais baixados naquele momento, por outros usuários da plataforma; (b) lista de todos os outros SOs que não aparecem pois não figuram no ranking Top 3 anterior; e (c) finalmente instalar a partir de um arquivo .ISO previamente baixado e disponível localmente.

Figura 02. Opções e formas de iniciar o processo

Escolha a segunda opção, “Navegue e pesquise sistemas operacionais para instalar”.

Figura 03. Listagem dos Sistemas Operacionais

Procure por ‘centos’ na barra de pesquisa:

Figura 04. Busca por ‘centos’

Simularemos um ambiente heterogêneo, então isso significa distros variadas, com versões diferentes. Selecione CentOS 7 x86_64 (netinst) :

Figura 05. Download automático da ISO

Aguarde a conclusão do download, iniciado automaticamente, para logo em seguida começar o que o Boxes chama de “instalação expressa”. Informe um nome de usuário, e abaixo clique em adicionar senha, digitando a mesma no campo aberto:

Figura 06. Instalação Expressa / Usuário e senha

Na próxima tela, revisar e criar, defina a quantidade de RAM e tamanho máximo do HD, ambos virtuais. Para efeitos de teste, e considerando que essas máquinas serão sempre “descartáveis”, ou seja, meros templates clonados de um git, GitHub ou GitLAB via Ansible/AWX/Tower … Sinta-se livre para escolher a configuração que mais lhe agrada, e que seu hardware atual permite. Mas, tenha em mente que apenas 512 MB de RAM e 10 GB de HD, são o “mínimo” e mais do que suficientes para rodar um Linux em modo texto. Portanto, esta será a minha escolha de configuração para a maioria dos servidores-alvo (nós) que iremos criar eventualmente, ao longo da série:

Figura 07. Instalação expressa / RAM e HD virtuais

Feito! Agora basta esperar até que o sistema seja criado e pronto! Ressaltando que o ícone da imagem é uma espécie de olho que fica girando (bolinha fazendo círculos) :

Figura 08. Instalação expressa / SO sendo preparado

Caso a instalação demore e comece a achar meio estranho, faça como eu, seja curioso, e dê um simples clique em cima da bolinha. Talvez se depara com isso, um terminal bugado que por algum motivo não conseguiu finalizar o processo sozinho:

Figura 09. Instalação expressa / Kernel panic !!!

Seguindo a própria recomendação exibida em tela, digite journalctl no terminal para depurar o log e reunir mais informações sobre o possível erro.

Buscando a circunstância para tamanha anomalia, ou quem sabe com sorte, pelo menos alguma pista que levasse até o principal suspeito … Encontrei várias linhas no arquivo de log informando que “a partição X não foi montada”; “a partição Y não existe”; “a Z não possui espaço suficiente”; e coisas desse tipo … Meu primeiro palpite foi de que o particionamento automático da instalação expressa está bugando ao dimensionar, formatar e levantar o esqueleto de diretórios necessário ao sistema operacional. Cheguei ao ponto de aumentar o tamanho do disco virtual querendo testar o algoritmo de fracionamento em diferentes quantidades e valores de armazenamento, pois talvez aqueles exatos 10,7 GB iniciais estivessem sendo pulverizados em tantas micro partições, que no final uma ou outra não tivesse espaço disponível para continuar, quebrando assim toda a instalação. Outros testes realizados foram: aumentar memória, reiniciar a máquina, apagar a VM e recomeçar do zero. Nada! Sem êxito nenhum! Quase perdendo as esperanças, resolvi usar outra imagem, o CentOS 8. Além disso, ainda desconfiado de haver algum BUG no meio, desativei o processo de instalação expressa, simplesmente clicando e desmarcando a caixa de seleção. Dedos cruzados, e na torcida!!! Veremos o que nos espera adiante:

Figura 10. Repetindo o processo com CentOS 8
Figura 11. A-ha! Sem erros!!! Conclusão: instalação expressa do Boxes momentaneamente bugada

Siga em frente, definindo seus próprios parâmetros e configurações da VM, contudo sabendo que em muitas das vezes os padrões pré-selecionados de fábrica já satisfazem o nosso objetivo, salvo eventuais exceções a serem modificadas posteriormente, sem dano algum a integridade do sistema. Não explicarei em detalhes pois não cabe aqui, tão pouco é o objetivo desse POST, como instalar e configurar um CentOS. Isso porque no futuro pretendo abordar esse assunto, em particular, trazendo as possibilidades de cenários e suas variantes. Ok?

Pop_OS! : Executando o Ansible

Apostando no conhecimento prévio adquirido nos posts antecessores, vou direto ao ponto e mostro como transformar o seu Pop_OS! em um nó controlador do Ansible. Essa e tantas outras nomenclaturas, podem ser revistas a qualquer momento. Na dúvida sobre determinado termo, busque aqui no BLOG e releia! Pois cada um deles conta e todos são igualmente importantes, sem exceção.

sudo apt update
Figura 12. Atualizando a última versão dos repositórios atuais
sudo apt install software-properties-common
Figura 13. Instalando o pacote de softwares para python
sudo add-apt-repository --yes --update ppa:ansible/ansible
Figura 14. Adicionando o PPA (repo) oficial do Ansible
sudo apt install ansible
Figura 15. Instalando o pacote ‘ansible’ e suas dependências
ansible --version
Figura 16. Verificando qual versão foi instalada
ansible-config init --disabled > ansible.cfg
ansible --version
Figura 17. Criando o arquivo de configuração

LAB : Adicionando usuário e senha pré-definidos

Tarefa recorrente no cotidiano de um administrador de sistemas, informar novos usuários aos servidores linux pode ser divertido ou entediante, dependendo de como enxerga … Se não gosta de aventura, emoção ou coisas novas, então: (a) escreva um shell script, (b) copie-o para todas as máquinas em que o usuário necessita acesso, (c) execute o mesmo localmente, (d) digite o nome/senha, e por fim, repita os passos C e D até o número X de hosts envolvidos. Por outro lado, se busca tempo livre para novas demandas, novos projetos, novas habilidades, ou somente para tomar aquele cafezinho na copa com toda a calma, conversando e saboreando … Então, aprenda YAML, playbooks, Ansible: aqui, agora !!! 😉

Vamos lá! Para começar, armazenar senhas em texto plano é considerado uma falha de segurança. Qualquer atacante (externo ou interno) teria fácil acesso a esse segredo, usando-o a favor dele, e consequentemente, contra você. Por isso, dados críticos ou informações sigilosas devem sempre apresentar certo nível de criptografia, nunca expostos totalmente. Em nosso caso, utilizaremos a biblioteca passlib do python para gerar o hash de uma senha aleatória forte, sendo esse dado a constar no código-fonte, e não a credencial em si. Para tal abra o editor de texto e, sem olhar, digite algumas teclas aleatoriamente. Feito? Ótimo! Agora no terminal execute os seguintes comandos:

pip3 install passlib
python3 -c "from passlib.hash import sha512_crypt; import getpass; print(sha512_crypt.using(rounds=5000).hash(getpass.getpass()))"
CTRL-C (gedit) + CTRL-V (bash) + ENTER (tecla) = HASH (ctrl-c + ctrl-v + ctrl-s)

Salve o resultado (hash) no mesmo bloco de notas, ao lado da senha que criou há pouco. Assim você terá as duas informações, enquanto escreve o playbook, repassando apenas a última.

Com isso, ainda no terminal, monte a estrutura necessária:

mkdir awx
mkdir -p awx/inventories awx/playbooks
ls -lhR awx/
Figura 18.
cd awx/
touch inventories/hosts
touch playbooks/add-sudo-no-prompt-or-ask.yml
Figura 19.
ls -lhR awx/
Figura 20.

Edite o arquivo hosts conforme o conteúdo abaixo:

vim awx/inventories/hosts
##CENTOS-a ansible_host=10.10.2.141
##CENTOS-b ansible_host=10.10.2.143

Depois abra o playbook e cole o seguinte:

vim awx/playbooks/add-sudo-no-prompt-or-ask.yml
---
- hosts: all
  become: yes
    
  tasks:
  - name: Adiciona usuario e entrega poderes de ROOT
    ansible.builtin.user:
        name: "bob"
        state: present
        password: "$6$XxSTRcR6la4KKUl1$R7XqBVSTOTCNq8PeBpPHL5gK9x1xy8D7oICVHgc2StH7/7wuheM2rPdpw9WD4QkM.Sh1BaDaBq70kE8ScY0jd."
        update_password: on_create
        groups: wheel
        append: yes
...

1ª linha: Todo playbook, na prática um arquivo com extensão .yml ou .yaml, deve começar com três hifens (traços) para sinalizar a sintaxe da sua natureza, a linguagem YAML.

2ª linha: YAML suporta vários tipos de estruturas de dados. Quando trabalhamos com ANSIBLE as mais comuns são listas e dicionários. Uma lista pode ser um conjunto de itens, separados por linha e iniciados com hífen + espaço (“- “) cada. Já um dicionário pode ser um grupo de mapas, composto por chave:valor cada linha e nomeado exclusivamente. Também é possível misturá-los, o que acaba resultando em listas de dicionários ou dicionários com listas muitas vezes. Para encurtar, particularmente nesse caso, estamos dizendo ao Ansible que a lista “hosts” é composta por todas as entradas (sem exceção) do inventário padrão, de mesmo nome. Dessa forma, o playbook será executado em TODOS os servidores listados.

3 ª linha: Equivalente ao su/sudo, aqui definimos o método de escalonamento na máquina remota. O valor YES implica que o usuário escolhido foi o root do sistema ( become: yes = become_user: root )

5ª linha: Dicionário que contém todas as tasks daquela play em questão.

6ª linha: String que nomeia a primeira task do playbook, podendo ser uma frase, palavra, ou caractere de escolha livre.

7ª linha: Módulo ansible utilizado para cumprir aquela tarefa.

8ª linha: Parâmetro name do módulo user para informar o login de usuário.

9ª linha: Parâmetro que remove (absent) ou adiciona (present) o login anterior.

10ª linha: Parâmetro que recebe o valor da senha no formato hash, gerado em etapas superiores.

11ª linha: Parâmetro que atualiza para uma nova senha ou mantém a mesma em casos de preexistência.

12ª linha: Parâmetro que dita qual (is) grupo (s) aquela credencial será membro.

13ª linha: Parâmetro que defini se o grupo é só mais um apêndice ou substituto único e exclusivo para aquele usuário.

14ª linha: Fim do playbook (três pontos).

RUN PLAYBOOK , RUN ! ! !

Últimos metros da maratona, faltando apenas uma etapa para que tudo funcione perfeitamente … Bem, conforme dito no passado, Ansible trata-se de uma ferramenta agentless (sem agente) que faz uso do SSH para comunicação entre as partes. E sendo assim, não poderíamos esquecer de gerar o seu par de chaves correspondente. Para isso, logado como usuário SUDO (comum às duas máquinas: local e remota), no controlador execute:

ssh-keygen -t rsa -b 4096
Figura 21.
ssh-copy-id [usuario_remoto]@[ip_ou_hostname_do_alvo]
Figura 22.
ssh user@machine
Figura 23.
[password]
Figura 24.
exit or logout
ansible -i awx/inventories/hosts -m ping all
Figura 25.
ansible-playbook -i awx/inventories/hosts awx/playbooks/add-sudo-no-prompt-or-ask.yml --ask-become-pass
Figura 26.
Figura 27. ANTES e DEPOIS¹
Figura 28. ANTES e DEPOIS²

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html

https://www.redhat.com/en/topics/automation/what-is-yaml

https://www.tutorialspoint.com/yaml/yaml_basics.htm

https://rollout.io/blog/yaml-tutorial-everything-you-need-get-started/

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: 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

ANSIBLE Series: Teoria … 5-V Conceitos Fundamentais

Meados de janeiro (na verdade um pouco além), verão no hemisfério sul, e menos de um mês para o meu aniversário (25 dias precisamente)… Não dá pra reclamar, concordam? 🤔Brincadeiras à parte, e apesar dos pesares que estamos enfrentando localmente e globalmente, só quis encontrar um bom início para nossa conversa de hoje. Algo mais leve. Não é insensibilidade de minha parte, mas sim um artifício para quebrar o gelo, tirar momentaneamente a cabeça dos noticiários e manchetes (segunda onda da Covid-19, aumento de casos e óbitos), e perguntar: o que estão fazendo? como estão?

Pensando na pauta do dia, decidi retomar o Ansible. Não houve motivo específico. Apenas porque gosto, é considerado a ponta do iceberg para vários devops iniciantes, e uma das ferramentas mais legais que conheci nos últimos anos. Sendo assim, o lógico seria continuar de onde paramos, certo? (hands-on, LAB's, aprendizado prático, AWX/Tower) ERRADO! Refleti melhor e achei por bem fazer uma pequena revisão do que já abordei sobre a teoria e reforçar quatro conceitos básicos da automação em TI.

A seguir, faço um compilado bem geral e bastante rápido acerca do que foi discutido em ANSIBLE Series: Teoria … Um papo sobre DevOps

RECAPITULANDO

  • O termo DevOps surge em 2009, na Velocity Conference, um evento da O’Reilly
  • Dois engenheiros da Flickr
  • Palestra “10+ Deploys Per Day: Dev and Ops Cooperation”
  • Em teoria, é uma filosofia, algo maior e mais abrangente
  • Na prática, é a boa e velha empatia, atitude de se colocar no lugar do outro
  • Devs ❤ Sysadmins, e vice-versa
  • Sem muros e barreiras — “já fiz a minha parte”, “o problema não é meu”, “na minha máquina funciona”
  • Gerenciamento de configurações — Escola GCONF, CFEngine, Gerência de Estados
  • Orquestração — Containers, Docker, Kubernetes
  • Ansible — Orquestrador ou Gerenciador?
  • Cartilha GCONF não é totalmente respeitada, ENTÃO
  • Majoritariamente um orquestrador, que eventualmente incorpora e acumula funções de gerenciamento de configuração (opinião deste autor, eu)

RED HAT BLOG … TAG #RedHatShares

https://www.redhat.com/en/blog/tag/red-hat-shares

Newsletter… Ou em bom português: boletim informativo. É exatamente isso que o link acima representa. É o que ele é na verdade, em sua essência mais básica, bem lá no fundo, no seu íntimo. Resumidamente, e conceitualmente, newsletter pode abranger desde uma simples publicação, passando por um editorial, chegando até mesmo em um conteúdo formatado (artigos, notícias, infografias, etc). Para ser chamado assim, ele precisa ter: (a) periocidade; (b) viés / linha / ponto de vista da empresa ou do presente redator/autor; (c) comunicação visual atrativa; e (d) elementos gráficos amigáveis e não exagerados [modelo simples, cores suaves, uso consciente de imagens]. Caso tenha desejo em aprofundar e conhecer um pouco mais, recomendo a seguir dois textos, muito interessantes, que tratam do assunto… Como funciona, como elaborar, dicas e truques, estratégia de marketing/divulgação, entre outros tantos. É rápido e indolor (rsrs!), então confere lá ok? 😉

Muito bem. Voltando. No site oficial da Red Hat, é possível encontrar a parte correspondente ao blog da empresa. São diversos posts categorizados por softwares, produtos e canais. Para buscar, basta acionar os filtros: listando, separando e refinando por tema/tópico/solução/ferramenta.

Cuidado! Alerta de Spoiler!!! Não se assuste com a quantidade de tags e posts no canto lateral esquerdo… Eu sei. Parece uma infinidade. Mas vale a pena cada clique.

Foi assim que descobri uma tag em particular: RED HAT SHARES. Nela foi publicada uma página dedicada exclusivamente sobre ‘automação’ e seus conceitos “satélites”, aqueles que orbitam esse mundo. Daí surgiu o nome do post que escrevo no momento, pois existem 5 conceitos fundamentais para melhor compreensão e prática da automação em TI. Alguns de vocês (inclusive eu) talvez já tenha falado ou escutado tais palavras e ficou na dúvida — “será que estou certo na definição?”, “esqueci alguma coisa?”, ou “simplesmente não sei”. Ressalto que minha intenção não é exaurir o assunto, tão pouco ser perfeccionista ao mínimo dos mínimos detalhes. Não, não se trata disso. Somente quero sintetizar dando uma noção geral de cada um deles, para que não se perca ou passe vergonha numa conversa entre devops, sejam programadores ou sysadmins ou ambos (hahahaha).

I) Provisionamento

Nada mais é do que o processo de configurar a infraestrutura de TI. Sendo este apenas metade do conceito. Explicando melhor, seria uma de duas definições possíveis. Outra abordagem diz que, provisionar é executar as etapas necessárias para: (i) gerenciar o acesso aos dados/recursos, e (ii) torná-los disponíveis para usuários/sistemas.

Independente do significado escolhido, é muito importante não confundir PROVISIONAMENTO com CONFIGURAÇÃO. Eles não são a mesma coisa, e sim etapas no processo de IMPLANTAÇÃO. Para que fique mais claro, uma frase: Depois que algo foi provisionado, a próxima etapa é a configuração.

Quando utilizado o termo “provisionamento”, uma gama de tipos vem à tona: provisionamento de servidor, de rede, de usuário, de serviço e por aí vai.

De servidor…

É o processo de configuração de uma máquina servidora a ser usada dentro de uma rede com base em recursos disponíveis.

Inclui: A – configuração de hardware B – Instalação de software (apps e S.O.) C – Conexão com middleware, outras redes, e armazenamento (bancos de dados).

De usuário…

É um tipo de gerenciamento de identidade que monitora direitos de acesso e privilégios de autorização.

Um usuário é atribuído a um grupo, um grupo é atribuído a funções e uma função é composta de permissões.

Geralmente é acordado entre os setores de TI e recursos humanos.

De rede…

É a configuração de uma rede para ser acessada por usuários, servidores, contêineres, dispositivos IoT, entre outros.

De serviço…

É a configuração de um serviço e o gerenciamento dos dados relacionados a ele.

Para ilustrar, um exemplo. Os usuários obtêm serviços em nuvem por meio de um portal de autoatendimento, sem a necessidade da ajuda da equipe de TI.

II) Gerenciamento de Configuração

Responsável por manter (varredura), e também adequar (correção), sistemas, servidores e softwares em um estado pré-definido. É o processo de garantia para que determinado sistema funcione conforme o esperado, e para que alterações sejam feitas ao longo do tempo, controlando assim todo o planejamento inicial.

Estado desejado, ou estado pré-definido, é uma maneira de fazer referência/alusão à configuração modelo (template) do servidor (ou sistema, ou programa) em questão. Modelo porque se trata do alvo/objetivo/meta a ser perseguido, buscado.

Por que gerenciar configurações?

Evita que pequenas ou grandes modificações sejam executadas erroneamente no ambiente. Uma configuração não documentada, execução manual por alguém desavisado (novato, por exemplo), auto sabotagem, podem ser algumas das circunstâncias que levam a configurações incorretas, e consequentemente, a um desempenho pífio, não satisfatório. Além disso, podem gerar inconsistências que impactam negativamente as operações e a segurança do negócio. Instabilidade e inatividade são alguns do efeitos colaterais sentidos por usuários e clientes.

Do lado técnico, a falta de gerenciamento, documentação, manutenção e controle, acaba levando administradores e desenvolvedores para uma escuridão total, já que os mesmos não são capazes de informar o que há em um servidor específico e qual software nele foi atualizado.

III) Orquestração

Engloba toda a configuração, o gerenciamento e a coordenação de sistemas, aplicativos e serviços. Dentro da TI a mesma auxilia em tarefas e fluxos de trabalho muito complexos, trazendo consigo mais facilidade na gerência.

Sob o guarda-chuva de engenheiros, analistas e programadores, existe um imenso mar de servidores e aplicativos. Gerenciá-los de forma braçal (manual) não é muito inteligente, além de nada escalonável. Maior a complexidade de um ambiente/sistema, maior o esforço para gerenciar as partes envolvidas. Portanto, eis que surge a necessidade de combinar várias tarefas automatizadas e suas configurações dentro de grupos de sistemas ou máquinas. E é exatamente neste ponto que a orquestração entra em cena.

Pausa. Um parênteses importante: automação e orquestração são por definição totalmente diferentes. Ou seja, eles não são o mesmo conceito, tão pouco sinônimos, mas estão sim relacionados. Explicando melhor:

AUTOMAÇÃO

É ponto mais alto do mundo corporativo. Ocorre quando um negócio ou empresa atinge a máxima eficiência e celeridade no processo produtivo, tendo como resultado menor custo e menos erros em sua cadeia de atividades. Geralmente, está ligada à uma única tarefa. Em contraste com a orquestração que lida com um processo ou fluxo de trabalho, mas esse possui várias etapas em vários sistemas distintos. O ideal é criar automação em seus processos para no final orquestrá-los e executá-los automaticamente, com pouca ou nenhuma intervenção humana.

Candidatos: processos automatizados para orquestrar

Provisionamento de servidor , gerenciamento de incidentes, orquestração em nuvem, gerenciamento de banco de dados, orquestração de aplicativos e muitas outras tarefas e fluxos de trabalho.

Ferramentas de orquestração

Os desafios da TI contemporânea são numerosos, difíceis, e distribuídos (guarde bem essa palavra! será relevante no futuro do BLOG). Aplicativos em cluster, múltiplos datacenters, nuvens públicas, privadas e híbridas, softwares com dependências complexas, são apenas alguns exemplos. Ordem correta é a palavra-chave aqui e por isso a importância da ferramenta escolhida.

Atualmente, procurando no mercado, é possível se deparar com inúmeras soluções. Citando três: CHEF, PUPPET e DOCKER. A própria Red Hat oferece duas opções, dependendo da finalidade para uso. Ilustrando melhor, será dito logo abaixo da seguinte maneira:

Cenário/Caso — Plataforma — Tarefas/Ações

Orquestração em nuvem — Ansible — Implantar servidores; Atribuir armazenamento; Criar VMs; Gerência de rede

Orquestração de contêineres — Kubernetes — Dimensionamento de aplicativos; Gerenciar serviços disponibilizados via contêineres

IV) Implantação de Aplicação

Minuciosa demais para ser resumida ou até mesmo cortada. Cada detalhe conta, sua eventual ausência compromete todo o raciocínio e linha de pensamento. Portanto, sendo assim, a teoria completa pode ser lida aqui… É quase meio que obrigatório para uma total compreensão do assunto.

https://www.redhat.com/en/resources/ansible-continuous-integration-delivery-whitepaper

V) Segurança e Conformidade

Ufa! 😓 Eu sei, eu sei… Quase lá. Chegamos no último item (rsrs!) Basicamente é formada por um conjunto de iniciativas. São elas: (A) Definição das políticas de segurança (B) Gerenciamento de risco (C) Identificação e correção de problemas (D) Conversão para etapas totalmente automatizadas (E) Pró-atividade plena, alcançada graças a automação (F) Auditoria e novos requisitos facilmente implementáveis.

Obrigado por sua atenção e companhia ao longo desse post … Mais conceitual do que prático. Forte abraço a todos e até breve 🙂

ANSIBLE Series: Lab … Modo GUI = Web Console = AWX/Tower

Enquete rápida: Você já me segue nas redes sociais? Não?! É bem fácil, basta pesquisar @vicrlda em todas elas…

https://twitter.com/vicrlda
https://www.instagram.com/vicrlda/
https://www.facebook.com/vicrlda/
https://github.com/vicrlda

AWX? TOWER? O QUE SÃO?

A Red Hat, empresa detentora do Ansible, observando a necessidade do mercado e atendendo o desejo de inúmeros usuários entusiastas da ferramenta, criou uma alternativa “mais fácil de usar” em comparação ao Ansible CLI (linha de comando).

Trata-se de uma interface gráfica WEB, desenvolvida em python com o framework Django. Essa mesma foi idealizada com o intuito de centralizar toda a automação em um único lugar: logs, auditoria, segurança, equipes, workflows, surveys, etc.

Essa nova solução, inicialmente batizada de ‘AWX Project’, viu seu código-fonte ser aberto para a comunidade, ao mesmo tempo que foi lançada uma versão proprietária dela, chamada de ‘Ansible Tower’. O AWX está para o Tower assim como o Fedora está para o RHEL.

Ambas possuem o mesmo visual/aparência, menus e botões. Ou seja, de forma sucinta, o que se aprende em uma pode ser facilmente replicado na outra. A lógica por trás é igual. Contudo, existem particularidades que fazem toda a diferença na hora de optar, escolher para o uso e finalidade pretendida. A próxima seção irá ajudar e será um comparativo entre as duas.

TOWER (pago) vs. AWX (free)

Ansible Awx

  • Gratuito e livre para usar
  • Sem limite para a quantidade de nós/hosts presentes
  • Disponível apenas no formato DOCKER (contêiner)
  • Updates frequentes
  • Ausência de HARDENING no código-fonte
  • Não recomendado para fins corporativos/críticos
  • Ciclo de vida muito curto entre as versões lançadas

Ansible Tower

  • Licenciado by Red Hat
  • Custo aprox. de U$ 10.000 a cada 100 hosts
  • Alta disponibilidade
  • Suporte 24×7
  • Pacotes e Novas Versões recebem patches de segurança
  • Updates estáveis
  • Ciclo de vida mais longo que o AWX

WEB > CLI *** (maior e melhor) ***

Alguns dos principais recursos avançados que o TOWER/AWX apresenta, superando assim a linha de comando (ansible-cli):

  • Controle entre equipes e organizações
  • Usuários individuais
  • Auditoria de atividades e gereciamento
  • Controle de acesso
  • LDAP, AD, SAML, e outros
  • Dashboard único com gráficos na tela

ARQUITETURA E COMPONENTES

awx_task

Realiza todas as tasks do AWX. Escrito em Python, ele faz o uso do Ansible para executar todas as tasks que são agendadas e as que são disparadas pelo launch

awx_web

Fornece a interface Web e faz todo o intermédio entre o awx_task e o usuário. Como dito anteriormente, é escrito em Python e usa o framework DJango

awx_memcached

Usado para armazenamento de chave/valor (KV) que o AWX utiliza para armazenar algumas informações e realizar “troca de figurinhas” entre o awx_tasks e o awx_web

awx_rabbitmq

O RabbitMQ é um serviço de mensageria desenvolvido em Erlang, implementado para suportar mensagens em um protocolo denominado Advanced Message Queueing Protocol (AMQP). Na arquitetura do AWX ele é utilizado para realizar o troca de mensagens entre o awx_web e o awx_tasks permitindo o desacoplamento entre esses dois serviços

awx_postgres

Esse é o banco de dados utilizado pelo AWX para armazenar todas as informações criadas pela interface Web. Você pode usar tanto um banco já existente ou subir um container com o banco (o que é default na instalação)

PRE-REQUISITOS

Sistemas Operacionais

  • Red Hat Enterprise Linux 6 64-bit
  • Red Hat Enterprise Linux 7 64-bit
  • CentOS 6 64-bit
  • CentOS 7 64-bit
  • Ubuntu 18.04 LTS 64-bit
  • Ubuntu 20.04 LTS 64-bit

Hardware

  • 2 GB RAM minimum (4+ GB RAM recommended)
  • 2 GB RAM (minimum and recommended for Vagrant trial installations)
  • 4 GB RAM is recommended per 100 forks
  • 20 GB hard disk

INSTALAÇÃO E START *** (simples e rápido) ***

# yum update
# curl -fsSL https://get.docker.com/ | sh
# systemctl start docker
# systemctl status docker
# systemctl enable docker
# curl https://raw.githubusercontent.com/geerlingguy/awx-container/master/docker-compose.yml -o docker-compose.yml
# curl -L "https://github.com/docker/compose/releases/download/1.23.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
# chmod +x /usr/local/bin/docker-compose
# ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
# docker-compose --version
# docker-compose run
ou
# docker-compose up -d
# docker ps
Figura 01. Graças ao docker e docker-compose os 5 containers que formam o AWX estão rodando com suas respectivas imagens: 1) awx_task 2) awx_web 3) postgres_9.6 4) memcached 5) rabbitmq. Explicados devidamente em “arquitetura e componentes”.

+ TUTORIAIS + DETALHES (MAS AINDA DOCKER)

Lintel Technologies Blog (en-US)

https://howto.lintel.in/install-ansible-tower-awx-centos-7/

Git Oficial (en-US)

https://github.com/ansible/awx/blob/devel/INSTALL.md

Sidnei Weber Blog (pt-BR)

http://sidneiweber.com.br/instalar-ansible-awx-com-docker-no-centos-7/

Jeff Geerling Blog (en-US)

https://www.jeffgeerling.com/blog/2017/get-started-using-ansible-awx-open-source-tower-version-one-minute
https://github.com/geerlingguy/ansible-role-awx

USANDO A INTERFACE *** (dicas e truques) ***

Login

Use o ip do servidor e a porta 8052 sempre que quiser conectar.

Ex: http://X.X.X.X:8052

Para o nosso primeiro acesso vamos usar as credenciais padrão…

       username: admin
       password: (*******)password

Assim que entrar é altamente recomendável trocar essa senha por uma mais forte. Para isto clique no avatar localizado no canto superior direito.

Figura 02. Durante o primeiro login o AWX será sempre atualizado. Tal processo varia em tempo e depende muito do hardware da máquina. Quanto mais robusta melhor (RAM, Cores, SSD, etc).

Dashboard

Após o login somos direcionados a página inicial, também conhecida como ‘dashboard’, ou em tradução livre, painel de controle. Nela é possível ver diversos detalhes acerca do nosso servidor AWX bem como seu status geral, o que inclui:

  • Número de hosts que executaram com êxito;
  • Número de hosts que falharam;
  • Número total de inventários;
  • Número de projetos e o status de sincronização;
  • Gráfico de cada playbook executado ao longo do tempo.
Figura 03. O painel é a pagina padrão pós-login e exibe as informações e gráficos dos principais JOBS e HOSTS cadastrados, entre outros.

Organizações

Para adicionar novas organizações dentro do AWX, clique no ícone de mesmo nome que fica do lado esquerdo. Depois no botão ADD, coloque um nome e breve descrição da mesma. Por fim, SAVE para guardar as informações.

Figura 04. Gerenciando organizações.

Usuários

Os passos a seguir se resumem à ações como CLICAR, SELECIONAR, DIGITAR. Dito isto, quem vos lê faz automaticamente a correspondência passo <-> ação, tendo em vista que se trata de um técnico, e não um leigo.

A razão para tal omissão foi apenas visando evitar repetição e redundância de palavras demasiadamente.

a - Lado esquerdo, USERS.
b - Nome e sobrenome do usuário em questão.
c - Organização da sessão anterior.
d - Email corporativo e usuário/senha para logon.
e - Tipo de usuário e direitos de acesso:
       ** Normal - membro da organização que pode criar templates, usá-los e atualizá-los.
       ** Auditor - membro da organização que visualiza inventários, templates, jobs e só... Não modifica nem cria nada no servidor.
       ** Administrador - possui todos os privilégios dentro da máquina (equivalente ao root/admin).
f - Botão SAVE.
Figura 05. Gerenciando usuários.

Inventários

Adicionar inventários é na prática adicionar hosts ao AWX/TOWER e separá-los por arquivo, sendo que cada um é um ambiente diferente. Objetivo: isolar as máquinas-alvo e garantir que a rede/switchs não serão afetados negativamente (ex: lentidão, indisponibilidade).

Tal ocorrência pode vir a acontecer se por acaso, sem querer, um playbook contendo a tarefa de atualizar pacotes linux seja executado ao mesmo tempo em vários servidores. Isso porque “alguém” cadastrou todo o parque, todo o datacenter em um único arquivo de inventário.

Forma textual de passos e ações segue a mesma argumentação do tópico anterior.

a - Lado esquerdo, INVENTORIES.
b - Botão ADD INVENTORY.
c - Nome do arquivo e a organização que o mesmo fará parte.
d - Ao final, SAVE.
Figura 06. Gerenciando inventários.

Hosts

Nomes dos nós/alvos/servidores podem ser IPs, URLs ou FQDNs.

Para criar:

a - Ainda na página INVENTORIES, selecione a aba HOSTS.
b - Clique em ADD HOST.
c - Digite o IP, URL ou FQDN da máquina em questão.
d - Uma breve descrição do que é a mesma.
e - Por fim, botão SAVE. Repita essa ordem quantas vezes for necessário até adicionar todos.
Figura 07. Gerenciando hosts.

Credenciais

São armazenadas separadamente no AWX, tornando-se uma maneira bastante eficiente dentro de um cenário LDAP, onde poderemos usar uma única credencial para N máquinas.

a - Lado esquerdo, CREDENTIALS.
b - Botão ADD, informar um nome e descrição para a nova credencial.
c - Escolha a organização.
d - Selecione o tipo (MACHINE é semelhante à SSH login)
e - Coloque o nome de usuário e senha do host remoto (tal usuário precisa existir do outro lado... senão, ERRO!!!)
f - SAVE para guardar.
Figura 08. Gerenciando credenciais.

Projetos

a - Esquerda, PROJECTS.
b - ADD.
c - Nome e descrição.
d - Organização e o SCM Type**:
       ** Manual - Quando os playbooks estão armazenados dentro do próprio AWX/TOWER. Aqui se passa o caminho do diretório (pasta). Ex:/home/victor/ansible/roles
       ** Git - Situação mais comum. Aqui os arquivos (.yml) estão em um repositório GIT, GitHub, ou similares. Informe a URL do projeto.
e - SAVE.
Figura 09. Gerenciando projetos.

Templates

a - Esquerda, TEMPLATES.
b - Nome e descrição.
c - Job Type: RUN ou CHECK. Mais utilizado (na maioria das situações) é o 'RUN'.
d - INVENTORY e PROJECT (previamente criados) que apontam os playbooks.
e - PLAYBOOK "principal" que referencia e executa as ROLES. Ex: (meio que um padrão/prática entre os programadores ANSIBLE) main.yml, test.yml, playbook.yml, etc...
f - CREDENTIAL para aquele INVENTORY particular.
g - LOG TYPE: verbosity.
h - Por último, SAVE.
Figura 10. Gerenciando templates.

Run the job … *** Ufa! 🙂 ***

a - Continuando na página TEMPLATES, escolha o template desejado para ser "rodado" (executado). Clique no ícone JOB LAUNCHER: o foguete.
b - Redirecionado automaticamente para a página JOBS. Observar a verbose do JOB em execução sendo exibida na tela. Lembrando que essa foi setada em LOG TYPE (7.9 - letra g).
c - Aguardar o fim do JOB...
Verde -> Sucesso -> OK!
Laranja -> Modificações/Alterações!
Vermelho -> Avisos/Falhas -> ERROR!

FIM

That’s all folks 😉 Isso é tudo, pessoal 😀

Até a próxima!!!

REFERÊNCIAS

https://developer.ibm.com/articles/automation-using-ansible-awx-gui/

https://yallalabs.com/devops/how-to-add-new-inventory-create-host-credential-awx-ansible-tower/

ANSIBLE Series: Lab … Modo CLI e Hello.YML (1st Playbook)

Dezembro chegou, e as festas de final de ano já batem a porta. Para celebrar vamos iniciar o lado prático do Ansible. Graças a enorme extensão (falo num bom sentido) dos pontos a serem cobertos, o aprendizado será dividido em várias partes, que quando somadas formarão o conjunto de um todo, fazendo total sentido. Dito isso, essa primeira sessão, podemos chamá-la assim, abordará o contexto não-gráfico do Ansible, ou seja, a sua CLI (Command Line Interface) – modo texto/bash/prompt. Como instalar, como configurar, como testar, como validar, entre outros, foram transformados (convertidos) em tópicos logo adiante. PORÉM, TODAVIA, CONTUDO, bem antes de qualquer passo ou etapa, iremos necessitar de dois sujeitos. São eles: (I) o bom, velho e gratuito VirtualBox; e (II) o poderoso, robusto e estável CentOS. Ambos podem ser baixados respectivamente em https://www.virtualbox.org/ e https://www.centos.org/. Se você é novato, perguntas tais como: O que são? Por que usar? Como utilizar? … Já se encontram respondidas em cada um desses endereços. Embora muito provavelmente por serem figurinhas carimbadas no mundo da TI, eles dispensam maiores apresentações para veteranos e pessoal técnico.

Uma vez instalado o VirtualBox e baixado a ISO do CentOS, é chegada a hora de criar as máquinas virtuais. Pois é. Isso mesmo que acabou de ler… No plural. Tendo em vista que vamos precisar de mais de uma para criar nosso cenário/laboratório de testes, segue abaixo as informações de cada uma.

VM #01

Nome: control-A Usuário: vicrlda SO: CentOS 7 RAM: 512 MB HD: 55 GB Rede: Bridge

VM #02

Nome: node-01 Usuário: vicrlda SO: CentOS 7 RAM: 512 MB HD: 11 GB Rede: Bridge

VM #03

Nome: node-02 Usuário: vicrlda SO: CentOS 7 RAM: 512 MB HD: 11 GB Rede: Bridge

  • Quando formos instalar determinado serviço/ferramenta, utilizaremos a máquina#01 como hospedeira, desempenhando o papel de servidor/controladora. EX: um zabbix-server será a VM control-A; um zabbix-proxy a VM control-B; um zabbix-agent a VM node-01; e assim por diante.
  • Máquinas servidoras/controladoras sempre terão mais espaço em disco do que as máquinas chamadas de nodes (nós). Isso porque elas acumularão sistemas distintos em uma só instância. EX: a VM control-A será o OTRS Server, Zabbix Server, e Ansible Controller.
  • VMs identificadas como node (nó) possuirão a função de host/remoto/cliente/agente para o respectivo serviço/ferramenta em questão. Além de um HD menor pois as considero como “descartáveis”. Por exemplo, se uma máquina ou grupo de X máquinas cair, é possível provisionar novas instâncias rapidamente com qualquer software de automação, criando assim uma espécie de coleção de templates para cada serviço ofertado.
  • Todos os adaptadores de rede estarão em modo bridge para que solicitem a mesma faixa de IPs ao servidor DHCP Local, ao mesmo tempo que são capazes de se comunicar externamente, com a internet. Enxergando uns aos outros e, portanto, na mesma rede, sem barreiras.

Muito bem meus caros… Anotaram tudo? Instalaram? Compreenderam a lógica? Então vamos ao que interessa. Que comece a nossa jornada! 🙃

INSTALAÇÃO E CONFIGURAÇÃO

No sistema operacional CentOS 7, primeiro instale o pacote EPEL “Extra Packages for Enterprise Linux”:

# yum install epel-release

Depois atualize o S.O:

# yum update

Instale o pacote do ansible:

# yum install ansible

Verifque se o ansible foi instalado e qual a versão corrente:

# ansible --version

Configure o arquivo de inventário padrão:

# vi /etc/ansible/hosts
                         FORMATO

[nome_grupo_de_maquinas]
fqdn_do_primeiro_host              ansible_ssh_host=ip_da_maquina1
fqdn_do_segundo_host               ansible_ssh_host=ip_da_maquina2
fqdn_do_terceiro_host              ansible_ssh_host=ip_da_maquina3

(... e assim por diante)

                         EXEMPLO

[pool_prod]
srv01.machiner.com.br               ansible_ssh_host=10.10.0.111
srv02.machiner.com.br               ansible_ssh_host=10.10.0.112
srv03.machiner.com.br               ansible_ssh_host=10.10.0.113

CHAVES SSH

O Ansible faz uso do protocolo SSH para comunicação. Entretanto, existem duas formas de operá-lo.

A primeira delas é, além de colocar no arquivo de inventário o FQDN e IP das máquinas, também é possível colocar o usuário local e senha local dos hosts remotos que irão executar os playbooks. Isso graças aos parâmetros “ansible_user” e “ansible_password”. Todavia, armazenar senhas em texto plano dentro de um arquivo não é nada seguro, tornando-se um ponto de vulnerabilidade.

A segunda, que é a mais recomendada, acontece da seguinte maneira:

  • Gerar um par de chaves com o seu usuário corrente na máquina ansible.
    • $ ssh-keygen -t rsa -b 4096
Quando solicitado "digitar uma senha para a chave SSH", deixar a senha em branco, ou seja, simplesmente apertar "ENTER". Caso contrário, será preciso digitar a senha toda vez que uma máquina é alcançada pelo ansible durante a execução do playbook. Exemplo, imagine digitar a senha 50 vezes para 50 servidores diferentes... Muito trabalho né? 😦
  • Distribuir as chaves com os hosts remotos.
    • $ ssh-copy-id [usuario_remoto]@[ip_ou_hostname_do_alvo]
Na prática você copiará umas das chaves para cada alvo (máquina remota).
EX:

$ ssh-copy-id victor@10.10.0.111
$ ssh-copy-id victor@10.10.0.112
$ ssh-copy-id victor@10.10.0.113
O usuário remoto deve existir localmente na máquina alvo. Se não a execução do ansible irá falhar!
Esteja preparado para digitar "YES" (aceitando a solicitação) para cada troca de chaves para cada host remoto.
TESTAR O SSH

EX: $ ssh victor@10.10.0.111
    $ ssh victor@10.10.0.112
    $ ssh victor@10.10.0.113

COMO VALIDAR? COMO TESTAR? … PING, MÓDULOS, COMANDOS AD-HOC, OUTPUTS

A resposta é simples: basta “pingar” usando um dos inúmeros módulos ansible, neste caso o PING. Com ele é possível dar o comando para: (a) todas as máquinas, (b) um grupo específico, (c) ou ainda um único host. Lembrando que os hosts, grupos e filhos estão presentes ou foram definidos no inventário padrão (/etc/ansible/hosts). Há também a opção de criar seus próprios arquivos e separá-los por ambiente, mas aí você precisa explicitar com o parâmetro -i e argumento nome_inventário. Execute e aguarde a resposta de cada um dos alvos.

# ansible -m ping all
Figura 01. Propositalmente, demonstra a saída do Ansible quando alcança uma máquina com sucesso (verde), e outra não (vermelho)
# ansible -m ping [grupo]
Figura 02. Ansible alcançando máquinas de um grupo chamado ‘web’. Por enquanto, somente a VM #02 (node-01) consta nessa lista
# ansible -m ping [host]
Figura 03. Ansible alcançando a única máquina do nosso LAB chamada ‘node-01′

Dando seguimento aos nossos testes, vamos agora pegar emprestado outros módulos disponíveis no Ansible. Lista completa aqui https://docs.ansible.com/ansible/2.8/modules/modules_by_category.html Bônus¹ – Como trabalhar com módulos – https://docs.ansible.com/ansible/latest/user_guide/modules.html Bônus² – Criando seus próprios módulos – https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html#developing-modules-general

Mesmo procedimento, executar e aguardar a saída (output).

# ansible all -m shell -a 'date'

Buscar a data e hora de todas as máquinas usando o módulo ansible 'shell'
# ansible all -m shell -a 'free -m'

Exibir a quantidade de memória de todas as máquinas usando o módulo 'shell'
# ansible all -m shell -a 'df -h'

Mostrar o espaço em disco e todas as partições de todas as máquinas usando o módulo 'shell'
Figura 04. Ansible mostrando informações de cada partição de cada máquina listada no arquivo inventário. Mais uma vez, de propósito, a VM node-02 está inacessível. O intuito é mostrar a paleta de cores do ansible-cli (command line interface)

Bem legal né? 😎 Concorda?

YAML E O SEU BÁSICO

Breve História e Definição

  • Ano: 2001
  • Criado por: Clark Evans
  • O que é: Um formato de serialização (codificação) de dados legíveis por humanos inspirado em linguagens como XML, C, Python e Perl
  • Sigla: YAML é um acrônimo recursivo que significa “YAML Ain’t Markup Language” (em português, “YAML não é linguagem de marcação”)
  • História: No início do seu desenvolvimento YAML significava “Yet Another Markup Language” (“Mais outra linguagem de marcação”) para distinguir seu propósito centrado em dados no lugar de documentos marcados. Como é usado frequentemente XML para serialização de dados e XML é uma autêntica linguagem de marcação de documentos, é razoável considerar o YAML como uma linguagem de marcação rápida

Por que YAML?

  • Playbooks são escritos e expressos utilizando a sintaxe YAML, que é a linguagem de gerenciamento de configuração do Ansible.
  • É usado YAML porque é mais fácil para humanos lerem e escreverem do que outros formatos de dados comuns, como XML ou JSON. Além disso, existem bibliotecas disponíveis na maioria das linguagens de programação para trabalhar com YAML.

Sintaxe e Visão Geral

  • Para o Ansible, quase todo arquivo YAML começa com uma lista. Cada item da lista é uma lista de pares de chave / valor, comumente chamada de “hash” ou “dicionário”. Portanto, precisamos saber como escrever listas e dicionários em YAML.
  • Há outra pequena peculiaridade no YAML. Todos os arquivos YAML (independentemente de sua associação com Ansible ou não) podem, opcionalmente, começar com — e terminar com … Isso faz parte do formato YAML e indica o início e o fim de um documento.
  • Todos os membros de uma lista são linhas que começam no mesmo nível de recuo começando com um “-” (um travessão e um espaço):
---
# A list of tasty fruits
- Apple
- Orange
- Strawberry
- Mango
...
  • Um dicionário é representado em uma forma simples de chave: valor (os dois pontos devem ser seguidos por um espaço):
---
# An employee record
martin:
    name: Martin D'vloper
    job: Developer
    skill: Elite
...
  • Estruturas de dados mais complicadas são possíveis, como listas de dicionários, dicionários cujos valores são listas ou uma mistura de ambos:
---
# Employee records
- martin:
    name: Martin D'vloper
    job: Developer
    skills:
      	- python
      	- perl
      	- pascal
-  tabitha:
     name: Tabitha Bitumen
     job: Developer
     skills:
      	- lisp
      	- fortran
        - erlang
...
  • Dicionários e listas também podem ser representados de forma abreviada caso prefira:
---
martin: {name: Martin D'vloper, job: Developer, skill: Elite}
['Apple', 'Orange', 'Strawberry', 'Mango']
...
  • Elas são chamadas de “coleções de fluxo” (flow collections).

¹ https://yaml.org/

² https://en.wikipedia.org/wiki/YAML

³ https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html

HELLO.YML, O PRIMEIRO PLAYBOOK … ESCREVENDO E EXECUTANDO

Na verdade, sendo bem sincero, o nome do nosso playbook não será exatamente Hello.YML … E sim, httpd.yml … A razão vocês irão entender logo mais, prometo! O que eu quis foi dar um título que chamasse atenção, e que também remete-se ao mundo da programação. Aquele que nunca nomeou o seu primeiro código-fonte de uma determinada linguagem como hello.c, hello.cpp, hello.sh, hello.py, hello.php, e afins … Que atire a primeira pedra 🤣🤣🤣

Brincadeiras à parte, passemos para nossa real proposta aqui, expressa logo abaixo.

OBJETIVO: Instalar o servidor apache em um grupo de máquinas e configurar uma tela de boas-vindas em HTML.

PS: Elementos que porventura aparecem neste playbook (como template, notify e handlers) serão explicados mais adiante, nos próximos posts.

# cd /etc/ansible/
# mkdir playbooks
# cd playbooks/
# touch httpd.yml
# vi httpd.yml
---
- hosts: webservers
  remote_user: victor
  become: yes
  become_method: su
  tasks:
  - name: Installing Latest Version of Apache
    yum: name=httpd state=latest
  - name: Copying the demo page
    template: src=/etc/ansible/demo/index.html dest=/var/www/html owner=apache group=apache mode=0644
  - name: (Enable it on System Boot)
    service: name=httpd enabled=yes
    notify:
    - start apache
  handlers:
    - name: start apache
      service: name=httpd state=started
...
# cd ..
# mkdir demo
# cd demo/
# touch index.html
# vi index.html
<html>
  <head>
     <title>Apache is installed by Ansible</title>
  </head>
  <body>
     <h1>Apache is installed by Ansible</h1>
     <p>Now, Apache is managed through Ansible</p>
  </body>
</html>
# ansible-playbook httpd.yml

(Quando já se tem a chave SSH no alvo, não precisa de senha!!!)
# ansible-playbook httpd.yml --ask-become-pass

(Caso contrário, é preciso digitar a senha do usuário local ao alvo!!!)

STOP ! ATTENTION! PLAYBOOK RUNNING !!! PLEASE WAIT …

Figura 05. Ansible executando o playbook conforme o esperado, sem nenhum erro. Cor amarela implica que algo (conf., serviço, arquivo, pasta…) foi modificado no host (node) de maneira bem sucedida
Pronto! Feito!

Meus Parabéns 🙂

Me despeço aqui pessoal. Por hoje é tudo. Espero de coração que tenham gostado. Mas calma, nossa caminhada no mundo ansible apenas começou, temos muito chão para cobrir ainda. Forte abraço a todos! Até breve!

ANSIBLE Series: Teoria … Dicionário Ansible e a Importância da Automação

Temos somente mais esta postagem para concluir nossa intro e antes de irmos à pratica. Trarei no decorrer do texto os principais conceitos e termos que orbitam por este universo chamado ansible. Não pretendo me alongar demais aqui por quatro bons motivos: (1) a maior parte da teoria e discussão ficou bem pontuada anteriormente; (2) existe uma infinidade de material online disponível (sites, blogs, vídeos, livros, trabalhos acadêmicos) que tratam com primor e maior detalhamento tal ferramenta; (3) minha intenção é ter um viés hands-on (aprendizado prático em tradução livre) enquanto abordo o ansible; (4) elementos e palavras novas que ocasionalmente irão surgindo explanarei ao longo da série (com definições e exemplos).

Boa leitura e bons estudos machiners!!! 🧐

O QUE É ANSIBLE?

O Ansible é uma ferramenta de código aberto que pode ser usada para: (a) gerenciamento de configuração ou (b) automação de fluxos de trabalho.

De maneira sucinta, gerenciamento de configuração é trazer para o mundo real o conceito de “infraestrutura como código”. Em outras palavras, é colocar tarefas e comandos que são recorrentes do dia-a-dia dentro de um script automatizado, que será escrito uma vez (passível de futura revisão), e executado em várias máquinas ao mesmo tempo.

Já automação de fluxos de trabalho refere-se a qualquer processo ou procedimento da computação cuja complexidade foi reduzida à simplicidade de um script automático bem elaborado. Isso pode ser desde o provisionamento de uma infraestrutura em nuvem até a implantação de um software específico, por exemplo.

O Ansible foi escrito na linguagem de programação Python e utiliza o protocolo SSH para comunicação entre as partes envolvidas. Seu funcionamento será explicado mais adiante.

POR QUE AUTOMATIZAR?

(a) Mitigar o erro humano!

Pessoas digitam errado, interpretam mal, esquecem, colocam na ordem errada, etc. Isso é algo natural do ser humano. Sendo assim, é melhor deixar para as máquinas a execução de tarefas repititivas. Ou seja, o Ansible.

(b) Diminuir o tempo gasto!

Leva muito tempo fazer login em consoles, pesquisar configurações, conectar-se a servidores, escrever comandos. Então mais uma vez, deixe o computador fazer isso. Com o tempo que sobrar você pode focar em escrever novos códigos para automatizar outras coisas.

(c) Auto-documentação!

Você não precisa manter uma biblioteca virtual de blocos de nota (.TXT) com instruções/comandos e listas de verificação. Isso porque esses arquivos podem não ser atualizados, sendo negligenciados e consequentemente tornando-se ultrapassados, o que acaba não refletindo a realidade atual. Na “infraestrutura como código” a automação pode existir em um software de controle de versão, como o Git. Assim ela passa por processos de revisão por pares. E você sempre saberá quais foram as etapas seguidas bem como as decisões tomadas.

(d) Reprodutibilidade!

Reproduzível (nesse contexto específico) significa que a transição de DESENVOLVIMENTO para HOMOLOGAÇÃO para PRODUÇÃO é algo fácil de alcançar, ou seja, a infraestrutura imutável é simples de atingir, além de evitar que componentes falhos apareçam em suas pilhas e ambientes.

CARACTERÍSTICAS DO ANSIBLE

1) Gratuito:

Devido a sua natureza open-source, qualquer pessoa da comunidade pode baixá-lo, usá-lo e até contribuir com o desenvolvimento do seu código-fonte.

2) Simples instalação e uso:

A curva de aprendizagem é muito rápida, fora que também não é necessário altas habilidades em programação para utilizá-lo.

3) Poderoso:

Consegue lidar com modelos de infra/redes desde os pequenos até os mais complexos.

4) Flexível:

O analista responsável é capaz de orquestrar ambientes inteiros e separá-los em vários e por nome (ex: DESENVOLVIMENTO, HOMOLOGAÇÃO, PRODUÇÃO). Tudo isso graças ao recurso de inventários do ansible.

5) Sem agente:

Não é preciso instalar nenhum cliente/programa/daemon para desempenhar o papel de agente nos sistemas alvos (máquinas destino). A diferença é a ausência do pré-requisito de uma estrutura de gerenciamento separada para controle.

6) Idempotente:

Possui inteligência o suficiente para, caso um script seja executado várias vezes numa máquina em particular e a mesma não tenha sofrido nenhuma alteração desde então, o Ansible simplesmente ignora, pulando para a próxima sem refazer nenhuma instrução na vigente.

DO QUE O ANSIBLE É CAPAZ?

  • Gerenciamento de configurações;
  • Implantação de aplicações;
  • Orquestração: Análogo ao maestro musical — Traz diferentes notas (tasks) produzidas por diferentes instrumentos (nodes) dentro de um trabalho artístico coeso (script);
  • Segurança e conformidade;
  • Provisionamento em nuvem

TERMINOLOGIA

  • Tasks: uma tarefa é a menor unidade de trabalho. Pode ser qualquer ação como “criar um banco de dados” ou “remover regra de firewall”.
  • Plays: uma play trata-se de um composto de tarefas. Exemplo, a seguinte play — “Preparar DB para um Nginx” é composto das tarefas:
    • Instalar o pacote de banco de dados;
    • Definir uma senha para o administrador do banco de dados;
    • Criar um banco de dados;
    • Definir o acesso ao banco de dados.
  • Playbooks: um playbook é composto por um conjunto de plays. Um playbook poderia ser: “Preparar meu site com um backend de banco de dados”, e as plays seriam: 1) Configurar o servidor de banco de dados; e 2) Configurar o servidor web.
  • Roles: As funções são usadas para salvar e organizar scripts, além de permitir compartilhar e reutilizar playbooks.
  • Inventory: Por padrão o ansible só vem com um único arquivo de inventário, ele é o /etc/ansible/hosts. Mas é possível criar outros para separar os ambientes e hosts. Nesses arquivos você deve informar todos os parâmetros relacionados a cada máquina, como nome, ip, usuário, senha, etc.
  • Ansible Galaxy: O Ansible Galaxy é um repositório online onde as funções são carregadas para que possam ser compartilhadas com outras pessoas. Está integrado com o GitHub.

ARQUITETURA E FUNCIONAMENTO

O Ansible opera conectando-se e enviando pequenos códigos de programação aos seus nós. Isso é denominado de “módulos”. O Ansible então executa esses miniprogramas (por padrão via SSH) e os remove uma vez concluídos. Essa biblioteca de módulos pode residir em qualquer máquina e não há servidores, daemons ou bancos de dados necessários, caracterizando assim uma arquitetura totalmente descentralizada.

O nó de gerenciamento é o nó de controle (ou máquina de controle) e este controla toda a execução do playbook. É o nó a partir do qual você está “disparando” a instalação. O arquivo de inventário fornece a lista de hosts onde os módulos do Ansible precisam ser executados. O nó de gerenciamento faz uma conexão SSH, executa tais módulos nos hosts, e o resultado é a instalação do produto/software (especificado no playbook) em todas as máquinas destino.

Como dito anteriormente, a beleza do Ansible reside em remover esses pequenos programas, logo após se conectar à máquina host, executar as instruções e, se for instalado com sucesso, o código copiado para o destino é apagado.

BREVE COMPARATIVO COM OUTRAS SOLUÇÕES

Ansible | Chef | Puppet

Chef e Puppet são outras duas ferramentas de automação bem populares. Todos os três podem ser usados para resolver problemas semelhantes e ter conjuntos de recursos semelhantes. Entretanto, existem duas diferenças principais entre Ansible e Chef / Puppet. Tanto o Chef quanto o Puppet são baseados principalmente em agentes. As máquinas gerenciadas pelo Chef / Puppet executam um agente. O agente volta à máquina de controle para ver quais mudanças precisam acontecer. Isso não requer SSH, mas requer infraestrutura para executar o servidor puppet / chef. O modelo sem agente da Ansible significa que é fácil começar e funciona com inventários menores. O Ansible também depende do SSH para se conectar às máquinas, portanto, a distribuição de chaves é outro aspecto a ser considerado.

Outra diferença é que o Chef e o Puppet usam uma linguagem específica de domínio (DSL) customizada para descrever o que fazer. O Chef na verdade usa código Ruby puro. A Puppet criou uma DSL totalmente nova. Contudo, existe um porém, se o indivíduo já conhece YAML, ele está apto para começar a escrever playbooks do Ansible. O que o torna dentre os três o mais amigável para se começar automação.

Ansible: do zero ao Zabbix. Fala pessoal, hoje o artigo é “topzera… | by  Amaury Souza | Medium
DevOps) Gerencia de Configuração, Puppet, Ansible e Chef uma Analise…
DevOps) Gerencia de Configuração, Puppet, Ansible e Chef uma Analise…

Em resumo, temos:

  • * Ansible usa YML para descrever o trabalho;
  • * Chef usa código Ruby para descrever o trabalho;
  • * Puppet usa uma DSL personalizada para descrever o trabalho;
  • * Chef / Puppet são baseados em agentes;
  • * Ansible é baseado em SSH e push.

ANSIBLE Series: Teoria … Um papo sobre DevOps

Bem-vindos de volta queridos machiners! Novo dia, novo post. Encerramos um ciclo, e começamos outro agora. Fico muito feliz em apresentá-lo a todos vocês no formato de série, pois a nossa ferramenta e objeto de estudo para hoje é a minha “menina dos olhos”, particularmente falando. Isso porque desde que a conheci, há um ano, me apaixonei por sua simplicidade, facilidade de START, curva de aprendizado rápida, e sua beleza traduzida em enorme potencial para auxiliar (e muito) a vida de um administrador de sistemas. Falo do incrível Ansible da Red Hat, que desde 2013 vem angariando uma legião de fãs, criando assim uma comunidade bem bacana. Não somente pessoas, mas também vem conquistando empresas entusiasmadas, que querem tirar do papel a automação de servidores, e transformá-la em uma realidade concreta no seu dia a dia.

Mas antes, preciso dar um panorama geral, um tipo de contexto mais amplo sobre DevOps e automação na indústria de Tecnologia da Informação. Por isso, a introdução do Ansible será dividida em duas partes. Esta primeira abordarei o DevOps e sua proposta, e na segunda já passo diretamente para os conceitos e definições do Ansible.

Então, mãos-a-obra. Vem comigo!!! 😉

ORIGEM & CRONOLOGIA … Before ‘DevOps’ There Was ‘Agile’

2008 – Agile Conference – Toronto/Canadá

Durante a conferência o programador Andrew Shafer divulga sua palestra em um anúncio intitulado “Infraestrutura Ágil”. Somente um expectador comparece: Patrick Debois. Belga, consultor, gerente de projetos, e adepto ao Manifesto Agile (2001). Vendo a lista e constatando que haveria uma única pessoa, Shafer não vai a própria sessão que iria ministrar. Achava que não haveria interesse em seu tópico, por isso tal atitude. Mais tarde, naquele mesmo dia, Debois o encontra pelos corredores e iniciam uma vasta conversa. Tempos depois juntos formariam o Agile Systems Administration Group.

2009 – O’Reilly Velocity Conference – Flickr

Passado um ano desde a Agile Conference, ocorre a Velocity Conference da Editora O’Reilly. Nela dois engenheiros da Flickr (John Allspaw e Paul Hammond) dão uma palestra chamada de “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”. Aqui eles explicam os resultados obtidos e desafios enfrentados ao aproximar as equipes de desenvolvimento e operações da própria Flickr. Coincidência ou não, Patrick Debois, o mesmo da Agile Conference, assiste remotamente o seminário e logo depois, lamenta em seu twitter não poder estar presente. Como resposta, ele obtem de um seguidor a sugestão de criar a seu própria “Velocity” na Bélgica, sua terra-natal e residência. Debois aceita mas não antes de escolher um nome para o evento. E assim o faz, juntando as três letras iniciais de ‘development’ e ‘operations’: nomeando-o de DevOpsDay. Tal evento acontece em 30 de outubro de 2009, no mesmo ano, e acaba se espalhando ao redor do globo em vários países. A partir daí, Patrick Debois é creditado como “pai do termo DevOps” e sua disseminação mundo afora.

MAS AFINAL, COMO CLASSIFICAR O DEVOPS? TRATA-SE DO QUE? … Em teoria

Existe um extenso debate acerca do que significaria o termo DevOps. Até hoje não há consenso se tal palavra implica em uma cultura, uma metodologia, uma forma de comunicação entre equipes ou uma simples ideia. É possível encontrar discussões em andamento nos mais diversos meios: fóruns especializados, listas de e-mail, sites, e na própria academia. Sendo assim, ainda não temos uma sentença final e definitiva, por enquanto. Felizmente ou infelizmente, seja isso bom ou ruim.

Todavia, uma corrente** defende classificar o DevOps como uma filosofia. Em outras palavras, seria algo muito maior e bem mais abrangente do que os significados anteriormente citados (cultura, método ou comunicação). Tenho que confessar que sou bastante simpático a esta definição e aceito utilizá-la para conceituar o DevOps. Mas você, querido leitor, não é obrigado a concordar comigo, muito menos ser seguidor desta escola de pensamento. Como indivíduos, somos livres para buscar e formar (por conta própria) a nossa opinião sobre determinado assunto, sem desconsiderar, é claro, os fatos e a realidade observada. Além disso, antes de emitir qualquer opinião de cunho mais técnico, é muito importante pesquisar o “Estado da Arte” do que se está abordando/falando. Somente dessa maneira poderemos embasar nossa hipótese fundamentalmente bem e dar continuidade ao trabalho que outras pessoas no passado iniciaram… Afinal este é o princípio da Ciência moderna.

“Se eu vi mais longe, foi por estar sobre os ombros de gigantes” (Isaac Newton)

QUAL É O PROPÓSITO DE DEVOPS NA PRÁTICA?

Já ouviu falar naquela história de que programadores e sysadmins (de uma mesma empresa) não se dão tão bem assim? Se sim, então provavelmente você é da área de TI. Mas calma, não estou me referindo a brigas de contato físico, intrigas pessoais ou disputas para ver quem é o melhor… Não, não é nada disso! Falo de um conflito de interesses, melhor dizendo, uma espécie de atrito entre os objetivos de cada time: sendo um deles a equipe de operações ou infra (sysadmins) e o outro sendo a equipe de desenvolvimento (programadores). Explicando… Os desenvolvedores são constantemente cobrados pelos seus superiores para que agreguem valor, ou seja, atraiam o capital responsável por gerar receita e lucro, na forma de novas funcionalidades e/ou implementando recursos até então inéditos em suas plataformas/softwares/aplicativos. Em contrapartida, os administradores de sistemas são orientados pelos gerentes e diretores a prezarem sempre pela estabilidade, disponibilidade e continuidade do ambiente computacional (datacenters, parque e servidores). Na prática o que ocorre é a competição entre esses dois grupos para cumprir as etapas e processos alheios de cada um, não importando se o outro teve êxito ou não com os seus. Isso resulta muitas vezes em projetos incompletos, quebrados do ponto de vista do todo. É a famosa visão fragmentada.

Devido a essa problemática (pano de fundo), é bastante comum, até mesmo recorrente durante reuniões de equipes e conversas de trabalho haver questionamentos como:

  • Velocidade ou estabilidade?
  • Recursos ou usabilidade?
  • Acesso ou controle?

Seja qual for seu papel dentro da empresa que trabalha atualmente… Quero dizer, independente se você é um leitor programador ou um leitor admin, deixo aqui um conselho: na próxima reunião que participar, aborde o DevOps como sugestão de pauta ou explique brevemente do que se trata. Pois, caso seus pares bem como seu chefe ainda não o conheçam, será uma oportunidade de ser um protagonista ao propor algo que causará uma mudança de cultura radical e extremamente benéfica a organização vigente.

Lembre-se sempre: a principal meta do DevOps é proporcionar uma melhor integração entre desenvolvedores e sysadmins. De que forma? – Deve estar se perguntando – (a) Facilitando a comunicação entre os mesmos; (b) Eliminando barreiras e muros “invisíveis” quanto a responsabilidade (“já fiz a minha parte”, “o problema não é meu”, “na minha máquina funciona”, “aumenta memória e processamento que resolve”); (c) Recompensando, favorecendo o trabalho em equipe (entre mesmo pessoal) e intersetorial (entre setores diferentes); (d) por último mas não menos importante, tornar mais orgânica e fluida a entrega de valor da tecnologia dentro da empresa.

DOIS LADOS, UMA MESMA MOEDA CHAMADA DEVOPS

Para atingir o status de DevOps podemos optar por dois caminhos distintos. São eles: a gerência de configuração ou a orquestração. Cada uma delas apresenta certas particularidades, assim como prós e contras. Para que fique claro, e não muito cansativo, tentarei resumir ambas em poucas linhas, contudo separadamente.

Gerenciamento de configurações

Tradicionalmente opera em arquiteturas do tipo agente/servidor. Aqui o server memoriza e armazena as informações de todas as configurações desejadas para os nodes (nós). Normalmente são arquivos estáticos que não suportam variáveis ou qualquer coisa de natureza dinâmica. Funciona em intervalos regulares pré-definidos. O agente é executado na ponta do node, que busca pelo servidor central e aplica a última configuração estabelecida, sendo essa uma ação local ao nó em questão. Detalhe para o fato de que o servidor nunca se conecta aos seus alvos, o normal e habitual é justamente o oposto, os alvos se conectarem ao server.

Para aprofundar mais no tema, procure pelas seguintes palavras-chave em sites/indexadores de conteúdo: Escola GCONF, Mark Burgess, CFEngine, Gerência de Estados.

Orquestração

Consiste em executar uma ou mais tarefas de forma paralela e às vezes não em tempo real dentro de um sistema operacional ou em um grupo de máquinas. Sob a ótica da automação de infraestrutura, será sempre quando alguém se conecta em N sistemas e executa algo, pontualmente, sem exigências rígidas ou grandes controles.

Para aprofundar mais no tema, procure pelas seguintes palavras-chave em sites/indexadores de conteúdo: Containers, Docker, Orquestradores, Kubernetes.

E O ANSIBLE? ORQUESTRADOR OU GERENCIADOR?

Responder essa pergunta não é tão fácil. Até porque na internet já faz alguns anos que ocorre um eterno debate, por parte de alguns e um pouco acalorado rsrs, se o Ansible é ou não um orquestrador. Questionam até se ele apresenta características da cartilha do CFEngine, e por tabela, considerado um “discípulo” de Mark Burgess, e sua escola GCONF.

Enfim, debates de lado, e antes de expor o meu entendimento, gostaria de mostrar o que Michael DeHaan, nada menos do que o criador do Ansible, disse em um post no grupo de discussão do Ansible. Na verdade, peguei emprestado um resumo da postagem completa graças ao site ansible-br.org, cujo link segue: http://ansible-br.org/por-que-ansible/faq/. Quanto ao grupo original: https://groups.google.com/g/ansible-project/c/WpRblldA2PQ/m/lYDpFjBXDlsJ

“Esta coisa de estado desejado de vez em quando é escrita de forma errada como ‘Convergência’… Convergência tipicamente significa rodar o processo 4 ou 5 vezes até conseguir chegar no estado desejado. Isso é terrível se você quer dar somente um apenas um salto… A indústria está um pouco atormentada com a ideia de que coisas simples devem ser falada em termos complexos e o Ansible não é bem assim. O nosso objetivo é simples — falado em inglês claro: Get Stuff done (faça acontecer)”.

Lendo todo o texto e a meu ver, Michael não estava preocupado em classificar sua ferramenta entre um dos dois tipos. Tão pouco em usar palavras complexas para explicar coisas simples. Seu intuito foi deixar bem claro que o Ansible é fácil, direto ao ponto e segundo ele mesmo: fazem as coisas acontecerem. O que é verídico baseando na experiência deste autor até aqui.

Sobre o que eu penso que o Ansible é… Bem, se olharmos a cartilha GCONF o Ansible não segue completamente à risca. Pontos a serem destacados: (A) ele não é rígido; (B) não tem controle detalhado; (C) nem tudo é idempotente (algumas coisa sim, outras não); (D) é descentralizado devido a sua arquitetura sem agente; (E) talvez o principal, o sentido da comunicação: a máquina controladora (podemos chamar de servidor) é quem se conecta aos nodes e não o contrário, como acontece no CFEngine. Tendo isso em mente, classifico e defino o Ansible como majoritariamente um orquestrador, que eventualmente incorpora e acumula funções de gerenciamento de configuração.

Mas e você? Qual é a sua concepção a respeito do Ansible? Comentários são para isto 😊

REFERÊNCIAS:

https://blog.newrelic.com/engineering/devops-name/

https://en.wikipedia.org/wiki/DevOps

https://groups.google.com/g/agile-system-administration