AWS SERIES: DAY … ONE: (conta) FREE TIER, (instância) EC2 e (dois passos) 2FA

Em nosso desembarque na tão famosa e “badalada” nuvem, necessitaremos criar e configurar alguns itens básicos antes de qualquer outra coisa. Primeiramente, é claro, começando pela conta de usuário gratuita na própria AWS … Sem ela? Nada de acesso, simples assim. Curta e grosseiramente (me perdoem, por favor) essa seria a resposta. Então, arregacem as mangas e mãos à obra!

No navegador digite https://aws.amazon.com/ na barra de endereços. Localize o botão ‘criar uma conta gratuita’ e selecione com clique simples.

Figura 01. criar uma conta gratuita

Logo após, o que temos é apenas mais um daqueles formulários de internet para usar determinado serviço. Perguntas triviais como: nome, e-mail, endereço, profissão, login, senha, etc, etc, etc. É bem provável até que o seu browser já tenha algumas dessas respostas e vá auto completando tais informações graças aos cookies e mecanismos de salvamento 🤭

Figura 02. questionário 1 de 5
Figura 03. questionário 2 de 5
Figura 04. fatura e pagamento (3 de 5)

Sim, é obrigatório cadastrar pelo menos um número de cartão de crédito internacional válido e ativo 😨😨😨 Como é? Tô fora Victor … Obrigado, mas essa série vou pular! Nada temam sra.(s) e sr.(s) pois não serão cobrados por isso. Aliás, melhor dizendo, somente em casos de uso acima da quota estabelecida pelos termos de uso gratuito. Chamado de “Nível de uso gratuito da AWS”, o mesmo se encontra disponível em https://aws.amazon.com/pt/free Recomenda-se aqui uma leitura mais pausada e detalhada, para que em seu futuro não haja surpresas desagradáveis ou consequências mais severas na forma de taxas extras.

Por exemplo, quanto custa uma instância EC2 ligada initerruptamente na nuvem AWS? Parênteses: não estamos considerando a parte gratuita já adquirida. Queremos calcular o preço (valor/hora) excedente ao limite gratuito. E a resposta está em https://aws.amazon.com/pt/ec2/pricing/on-demand/

Figura 05. tabela de preços para EC2 sob demanda

>_ AWS CONSOLE: LOGIN E MULTI-FATOR

Principal porta de entrada (na verdade, a única até então) para gerenciar seus serviços e recursos disponibilizados na nuvem, a AWS Console fica acessível por meio do link https://aws.amazon.com/pt/console/ E para tal, resgate o usuário e senha criados hoje mais cedo:

Figura 06. link de acesso
Figura 07. e-mail do proprietário (usuário root)
Figura 08. multi-factor authentication

Pausa para explicar essa opção extra de segurança que impede acessos indevidos e não-autorizados. Uma vez dentro da web console, veremos que o céu é o limite para AWS. Digo isso pois encontraremos uma infinidade de recursos e possibilidades bem ali, ao nosso alcance. Coisas que talvez nunca serão utilizadas mas de todo jeito permanecem lá, esperando, prontos pra uso. Para que fique ainda mais claro o poder que você tem em suas mãos, é como se ela fosse o internet banking da sua conta bancaria. A maioria dos itens presentes não são gratuitos e portanto seu eventual uso será cobrado. Então, exercite sua mente e dimensione o estrago que um atacante causará na fatura do seu cartão … Bem grande não é? 😱😱😱 Sendo assim, não perca mais tempo e ative o código multi-fator na sua conta AWS. Na barra de pesquisa da console, busque pelo termo-chave “iam”(i-a-m):

Figura 09. todos os serviços AWS
Figura 10. painel do IAM
Figura 11. dispositivo MFA

No meu caso, optei por usar meu próprio smartphone Android com o app Google Authenticator. Consulte para saber mais sobre dispositivos, sistemas, aplicativos MFA suportados pela nuvem AWS.

>_ AWS CONSOLE: EC2 – AMAZON LINUX – T2.MICRO

Elastic Computer, ou simplesmente, EC2. Trata-se do nome que é dado a uma máquina virtual (vm) dentro da AWS. Quando começar, é bastante comum não haver a correspondência termo-serviço totalmente formada e definida na mente. Está na dúvida? Use a pesquisa para saber qual é o serviço que aquela sigla/palavra representa.

Figura 12. painel EC2

Localizada internamente, no painel do EC2, a Visão Global traz uma foto de todos os recursos de todas as instâncias sendo usados (ou não) no momento. Disse “ou não” porque você pode ter X instâncias criadas mas nenhuma em execução. Talvez foram desligadas ou nunca foram ligadas ainda. Ou seja, esses recursos “constam”, pois estão sim listados. Mas não “contam” como uso corrente, já que não serão cobrados.

Figura 13. visão global (instâncias)

Se observarem a imagem acima, verão que já tenho uma instância na AWS. Criei essa no início do mês e deixei rodando desde então. Por se tratar de apenas uma, estou seguro e isento de cobranças. Isso porque estou dentro do pacote de 750 horas mensais gratuitas de EC2 (meses pares, 24 x 30 = 720) (meses ímpares, 24 x 31 = 744). Contudo, preste sempre muita atenção! O dashboard da AWS nunca será absoluto e mostrará todas as instâncias em todas as regiões. Regiões? 🤨 Como assim? Acontece que a computação de modo geral funciona em torno dos datacenters: pequenos, modestos ou grandiosos. E com a nuvem não poderia ser diferente. Os centros de dados da AWS estão espalhados por todo o globo, em regiões distintas. Nos últimos anos, o padrão para as novas contas de usuário da Amazon normalmente é: ou Ohio, ou Virgínia do Norte (ambos Estados Unidos). Portanto, caso você crie uma instância em X e depois sem querer acabe esbarrando em Y com o mouse, saiba que a AWS não o notificará sobre tal mudança e você será cobrado de acordo com o preço daquela “nova” região (Y). A lógica é bastante simples: quanto mais próximo do seu local atual for a hospedagem das máquinas, mais caro será o preço por horas excedentes. Por exemplo, no caso de um brasileiro como eu, o valor para ter servidores em São Paulo, que é o datacenter mais perto de mim, será bem maior do que em outras regiões.

Encerrando essa parte de “precificação”, fique atento para essas duas situações:

a) No meio do caminho, durante os estudos, uma troca acidental de região e consequentemente valores um pouco mais “salgados” no fim do mês, na fatura do cartão.

Figura 14. us-east-2 (Ohio)

b) Mais de uma instância rodando ao mesmo tempo durante o mês inteiro, resultando no estouro das horas gratuitas cedidas pela AWS, e por tabela, cobrança sob demanda (ex: U$ 0,22/h) dali em diante até o fechamento do mês corrente.

Agora sim, estamos prontos! Burocracia compreendida, passemos para a parte mais legal: a prática. E antes de criarmos a nossa primeira instância na nuvem, uma ressalva … Eventualmente, se a aplicação/sistema/solução em que está trabalhando foi homologada para “esse” ou “aquele” Linux, se atenha ao script, mantenha o plano. Claro que ninguém irá lhe impedir de testá-lo em outros sistemas, mas para fins de produção é sempre melhor estar no ambiente em que o mesmo foi desenvolvido e tem suporte garantido. Ok?

Siga os passos e dirija-se até a seguinte tela:

página inicial > EC2 > executar instâncias > selecione uma AMI (Amazon Machine Image)

Figura 15. etapa 01: imagem de máquina

O primeiro ponto que vale a pena destacar aqui é a etiqueta “qualificado para o nível gratuito” (em inglês, free tier). Procure por ela quando quiser utilizar esse e os demais serviços da AWS. Do contrário, você já sabe … 💸💸💸 Segundo ponto, é o tipo de imagem para a máquina virtual EC2. Caso a recomendação da aplicação/solução seja Ubuntu, então use o Ubuntu. Caso seja OpenSuSE, use o OpenSuSE. E assim por diante. Quando não, opte pelo Amazon Linux. E quem é esse Victor? Nada mais do que um RedHat compilado para a AWS. Em outras palavras, otimizado para trabalhar na nuvem da Amazon. Ele conta com uma série de ferramentas e integrações que irão facilitar muito o dia-a-dia do administrador (você).

À título de informação, as outras opções que temos (desde o Windows, passando pelo MacOS, e chegando até o Linux) :

Figura 16.

Próxima etapa, tipo da instância a ser implantada. Ou seja, o hardware da máquina. Seguindo a lógica, quanto mais poderosa for, mais caro será o seu valor. Sendo assim, busque pelas instâncias free tier (gratuitas). Normalmente são as de nome T2.MICRO

Figura 17. t2.micro – 1 CPU 2.5GHz – 1 GB ram

No rodapé, aperte o botão PRÓXIMO: detalhes da instância. Nessa página não mexeremos em nada, deixando tudo como está (padrão/default) Voltaremos em breve, no futuro, para maiores detalhes e explicações acerca de cada uma das configurações.

Figura 18. detalhes da instância (default)

NEXT … Adicionar um storage, ou em bom português, armazenamento de dados. Somente aqui haverá uma segmentação por parte da AWS, pois a mesma trata a máquina virtual e o armazenamento como serviços diferentes. A máquina virtual diz respeito as questões de processamento, memória, etc. Já o armazenamento diz respeito ao disco, ou seja, até onde vai a capacidade de gravar informações. Um fato positivo é que todos são SSD, melhorando significativamente o desempenho e velocidade. Mas, novamente cuidado! Limite-se apenas a quantidade máxima para o nível gratuito.

Figura 19. storage

NEXT … Tags? Não, por enquanto não queremos nenhuma.

NEXT … Security Group, ou Grupo de Segurança. Equivalente a um firewall para essa vm EC2. Devido ao fato de estar na nuvem, aberta a toda e qualquer pessoa, quem realmente pode/deve acessá-la via SSH e afins? Todos, apenas um grupo seleto, somente você? Para isso, uma boa recomendação é deixar ativa a opção meu IP e só.

Figura 20. meu ip

NEXT … Review e launch (revisão e lançamento). Verifique se está tudo OK e conforme desejado. Se sim, mande em frente e espere a conclusão!

Figura 21. executar (launch)

É obrigatório gerar um novo par de chaves SSH ou selecionar algum já pré-existente salvo localmente no seu computador. Como já possuo um devido a primeira instância, sendo esta a minha segunda, então vou apenas apontar o par que tenho na minha máquina.

Figura 22.

Running … Please wait …

Figura 23.

Ao final, edite, dê um nome e salve!

Figura 24.

Dia 01 de trabalho concluído 🙃 Te aguardo no próximo !!!

>_ REFERÊNCIAS:

https://explore.skillbuilder.aws/learn/course/external/view/elearning/134/aws-cloud-practitioner-essentials?dt=tile&tile=fdt

https://explore.skillbuilder.aws/learn/course/external/view/elearning/1851/aws-technical-essentials?dt=tile&tile=fdt

VICRLDA: GNOME BOXES … cadê o modo bridge ???

Certa vez, lendo as discussões num fórum sobre Linux, me deparei com a declaração de um usuário que afirmava o seguinte: “Em grande parte, os desenvolvedores do projeto GNOME encaram a própria bandeira à níveis extremos – simples e fácil de usar (…) E como consequência, suas aplicações carregam esse DNA intrinsecamente”. Na época, honestamente não fez muito sentido para mim. Além disso, um questionamento aflorou particularmente: E o que há de errado? Isso é bom, não? Bem, e a resposta é SIM e NÃO. Continue lendo para entender melhor!

Se você, caro leitor, ficou empolgado com o Ansible mas não teve êxito no último laboratório, peço desculpas pois sim, foi minha culpa 😦 Para o sucesso deste é necessário fazer um pequeno workaround, gambiarra, ou melhor, uma solução alternativa, para soar mais bonito (rsrs) Em minha defesa, e fazendo o papel de advogado do diabo, o que aconteceu foi que travei em determinado ponto da prática, enquanto escrevia a teoria (o POST em si) ao mesmo tempo. Dessa maneira, pesquisei sobre o erro no Google, encontrei, corrigi e voltei a escrever como se nada tivesse acontecido, como se o BUG não existisse (quase que cantarolando de tanta felicidade, haha)

Eu sei que o título já entrega muita coisa, quando exponhe logo de cara sobre o que abordará, indo até o cerne e apontando o problema … Mas, mesmo assim, peço um pouco de paciência para os fatos, capturas de tela e explicações a seguir:

Acredito que o primeiro impulso de todo administrador/engenheiro de sistemas quando loga em uma máquina é verificar qual IP ela pegou. Portanto, vamos abrir o boxes e iniciar a VM. Feito isso, execute o comando que lista tais informações:

Figura 01. ip addr show

Observe atentamente para a faixa de rede atribuída (/24), neste caso sendo 10.0.2.X, e o endereço 10.0.2.15 … Guarde-a bem pois utilizaremos em um dos testes mais básicos para validar a comunicação entre máquinas: o ping.

Deixando aberto o terminal convidado, e liberando o teclado (CTRL+ALT da esquerda), dirija-se até o terminal hospedeiro, no meu caso o Pop_Shell, e digite ping -c 5 10.0.2.15

Figura 02. Pingando do HOST para o GUEST

Exatamente! Não conseguimos enxergar o CentOS 8, porque a interface é automaticamente configurada no modo NAT, processo esse considerado interno, do próprio GNOME Boxes. O porém aqui reside no fato de que não há outra opção de rede para a interface dessa ou qualquer outra máquina que esteja rodando sob o boxes. Isso porque o ecossistema GNOME Shell (interface gŕafica + aplicativos) tentam manter sempre tudo o mais simples possível. Recordam do lema deles?? Pois é, isso mesmo! Resultado: não sobra muito espaço para customizações e afins, já que a margem é quase inexistente, ínfima na maioria das aplicações 😦

Caso sirva de consolo, e graças a lógica de funcionamento do NAT, você não fica completamente isolado uma vez dentro da VM, pois a máquina visualiza sua rede doméstica/corporativa além de sair para internet sem nenhum problema.

Figura 03. Ping para a rede local e saída pela internet

Localize a pasta onde fica armazenada o disco virtual do CentOS, e copie o seu caminho completo:

Figura 04. /home/user/.var/app/org.gnome.Boxes/data/gnome-boxes/images

Instale o virt-manager no sistema hospedeiro. Disponível na Pop_Shop! ou visitando o site oficial (https://virt-manager.org/) e baixando.

Quando concluído, abrir e ir na opção Arquivo > Nova Máquina Virtual > Importar imagem de disco existente

Figura 05. QEMU/KVM

Botão “Avançar”, forneça o caminho navegando até ele ou cole aquele copiado mais cedo:

Figura 06.

Defina quanto de memória e CPU:

Figura 07.

Revise as configurações e por fim, botão “concluir”:

Figura 08.

Listada como ‘centos8’, clique com botão direito e escolha ‘executar’

Figura 09.

Em seguida, botão “abrir” para visualizar a console:

Figura 10.

Menu superior, aba “Ver”, opção “Detalhes”

Figura 11.

Um clique simples sobre o ícone ” NIC :b3:de:40 ” e copie exatamente de acordo com a captura abaixo:

Figura 12.

Aplique as alterações antes de fechar, retorne a console da máquina, e verifique o IP da interface:

Figura 13.

Finalmente, repita o teste do ping em ambos os sentidos da comunicação (HOST > GUEST e GUEST > HOST)

Figura 14. VM alcançando o hospedeiro tanto via IP quanto hostname
Figura 15. Sucesso total !!! Pop_OS enxergando a VM

Conclusão: a partir de hoje use sempre o virt-manager para executar a máquina devido a possibilidade de mais modos de rede para a interface!

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

ZABBIX Series: how to … adicionar um host linux ao monitoramento zabbix

Olá, aqui e de volta outra vez ( J. R. R. Tolkien feelings 😊 ) A série não pode parar e por isso, vamos nessa!!!!

Neste episódio veremos como adicionar um servidor linux ao nosso monitoramento. Ué Victor, e por acaso não já o fizemos no POST anterior? E a reposta é: não meus caros, ainda não. Ou melhor, eu diria quase. Não basta apenas instalar o agente zabbix e esperar que ele faça o restante do trabalho, não é bem assim. Mesmo apresentando o recurso de autodescoberta (que vale um artigo num futuro próximo), é bom, e por que não saudável também, aprender a configurar sozinho um host linux na interface web do zabbix.

ADD HOST

Uma vez logado na web console, vá para Configuration >> Hosts >> Create Host

** http://192.168.1.10/zabbix/

username: Admin

password: zabbix

Figura 01

Agora, informe os detalhes para os seguintes parâmetros:

Hostname: Nome do host remoto/cliente/alvo (nó)
Visible nameNome do host, algumas vezes chamado de nó
GroupSelecionar o(s) grupo(s) de hosts ao(s) qual(is) o nó pertence
Agent Interface: Digitar o endereço IP ou o nome DNS (IP recomendado)
Connect toEscolher entre IP / DNS (Forma de comunicação: IP recomendado)

Figura 02

NÃO clique em Add, por favor … O próximo passo são os templates, a setinha amarela (canto superior)

TEMPLATE

Um template é um conjunto de entidades que reduz seu esforço manual na configuração de gatilhos, itens, gráficos, aplicativos, etc. para cada host.

Templates podem ser aplicados a vários hosts ao mesmo tempo. E para diminuir ainda mais o trabalho, o próprio Zabbix já vem com alguns pré-definidos por padrão.

Vá para Templates >> Link new templates. Aqui é possível tanto digitar para pesquisar um modelo quanto clicar em Selecionar para escolher dentre uma lista (Marque o modelo que deseja vincular ao novo host)

Figura 03
Figura 04
Figura 05

Feito isso, redirecionado automaticamente (e de volta) para Configuration >> Hosts

Observe a mensagem (tarja verde) dizendo que o novo host que foi adicionado com sucesso:

Figura 06

MONITOR

Qualquer problema é sempre listado em Monitoring >> Dashboard Então, dirija-se até lá:

Figura 07

Para dados, valores, estatísticas e informações mais detalhadas acerca dos recursos coletados, vá para Monitoring >> Graphs

Escolha um host, procure pelo parâmetro do recurso desejado (CPU, RAM, HD, etc) e finalmente clique em GRAPH, sendo esta a última coluna no canto direito.

Figura 08

Aos mais atentos, percebam que a categoria Monitoring >> (lado esquerdo) possui muitas outras opções, como OVERVIEW, LATEST DATA, MAPS, DISCOVERY, SERVICES … Mas não se preocupem, pois todas elas serão cobertas e tratadas em artigos futuros da série

Bom galera, esse foi o conteúdo que quis trazer para vocês. Como disse no início, o BLOG não pode parar e tenho planejado algumas outras séries ainda este ano. Acredito que vão gostar bastante 😋 Mas primeiro, preciso concluir essas duas em aberto: o Zabbix e o Ansible. Então, já sabem: favorite no seu browser, seja um seguidor por e-mail ou redes sociais, e volte sempre pra checar se não saiu texto novo por aqui.

Grande abraço a todos! Um ótimo fim de semana

REFERÊNCIAS:

https://www.itzgeek.com/how-tos/linux/how-to-add-a-node-to-zabbix-server-for-monitoring.html

https://blog.zabbix.com/zabbix-agent-active-vs-passive/9207/

https://www.zabbix.com/auto_discovery

ZABBIX SERIES: how to … install zbx-agent on centos_7

Saudações 🖖 Agora que a páscoa ficou para trás, e esse é oficialmente o início do 2º ano do BLOG, nada melhor que começar com o pé direito e resgatar a série “pausada” do nosso querido Zabbix … Para tal vamos aprender hoje como instalar os agentes que monitoram toda a atividade no outro lado, nas pontas, ou melhor, nas máquinas alvo (nodes).

O mais legal é: trata-se de um tutorial bem curtinho e fácil de reproduzir. Quando piscarem os olhos verão que já terá acabado. Sendo assim, terminais abertos, usuários logados, e atenção aos comandos necessários. Vem comigo! 🚶‍♂️🚴‍♂

01. REPOSITORIO

Entre como root ou mude para o mesmo:

sudo su -

ou

su -

Devido ao pacote zabbix-agent não estar listado nos repositórios base do CentOS, adicione o endereço correspondente para configurá-lo em sistemas clientes (somente aqueles que deseja monitorar, é claro)

rpm -ivh https://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/zabbix-release-4.0-1.el7.noarch.rpm

02. PACOTE

Use o comando a seguir para instalar o agente propriamente dito:

yum install -y zabbix-agent

03. ARQUIVO

Modifique o arquivo do cliente para expressividades referentes ao servidor mãe/central:

vi /etc/zabbix/zabbix_agentd.conf

Atualize as seguintes informações no arquivo de configurações:

### Zabbix Server IP Address or Hostname ###

Server=192.168.1.10

### Client Hostname ###

Hostname=control-A

04. CONTROLE

Reinicie o agente zabbix:

systemctl restart zabbix-agent

Ative o zabbix-agent para um start automático no boot:

systemctl enable zabbix-agent

Fim

Eu avisei (…) O tempo passou e você nem viu 😄 hahaha

Vejo todos na próxima !!!

Tchau 👋

Referências:

https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/how-to-install-zabbix-agent-on-centos-7-ubuntu-16-04-debian-8.html

BLOG Series: C:\ >_ echo “Hello?” ; nmap -sP (network).(ip).(range).1-254 ; whoami ; printf “Leave a comment below… \n”

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed vitae odio ac risus iaculis tempor. Donec at magna orci. Pellentesque malesuada maximus fringilla. Donec at nunc at tortor dictum dapibus eu vulputate sapien. Cras faucibus quam enim, eu congue libero vulputate non. Cras a orci quis est dapibus eleifend eu ut quam. Curabitur posuere justo ex. Nulla a blandit lorem. Aenean vitae fringilla felis, et varius nunc. Nulla faucibus massa ac lacus ultrices, condimentum tincidunt ex accumsan. Fusce vulputate quam ipsum, non interdum ligula mattis sit amet.

In nec sem gravida, rhoncus sem et, vulputate libero. Integer nec elit ipsum. Fusce a suscipit velit. In in laoreet mauris, eget condimentum turpis. Mauris faucibus ligula ante, nec dignissim lorem fringilla in. Aenean vel lectus a sapien cursus iaculis. Proin ut lectus in enim ornare interdum nec commodo ex. In hac habitasse platea dictumst. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur id pharetra sem. Aliquam erat volutpat. Proin placerat lobortis ipsum, tincidunt tempus urna dictum a. In sollicitudin justo enim, sed dignissim nisi varius at. Nam tortor diam, interdum pretium semper id, posuere eleifend elit. In ut tortor in ipsum egestas porttitor. Morbi dictum orci eget ante porta bibendum.

Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Praesent interdum massa in congue blandit. Etiam non ultrices libero. Vestibulum ut posuere sem. Nullam sed nulla a lorem sagittis porta eu ut erat. Donec at malesuada urna. Nulla eu nulla nulla. Nulla tincidunt pulvinar ligula, ac suscipit orci condimentum non. Phasellus placerat nisi quis faucibus finibus. Donec dictum, diam quis volutpat iaculis, eros ante suscipit tellus, vitae eleifend orci mi in mi. Sed tempus, ex id elementum auctor, diam ante facilisis est, at maximus diam ante vitae tellus. Curabitur finibus odio quis libero lobortis interdum. Ut a commodo mauris, nec molestie lacus. Ut posuere, lorem ut elementum tempus, ipsum arcu egestas velit, id sagittis nisl dolor sed enim. Maecenas tempus, mauris sit amet lobortis tristique, justo turpis rutrum mauris, a consectetur ligula nisl non turpis. Maecenas hendrerit felis quam, a mattis mauris commodo placerat.

ANSIBLE Series: Web … Observando a execução de um JOB em tempo real

<head>
       Dedico esse post às mulheres 🌷 Especialmente para todas as  devs,
       sysadmins, engenheiras, pesquisadoras e cientistas 👩🏻‍🔬👩🏻‍💻👩🏻‍🏫👩🏻‍🎓 da computação
       ao redor do globo
</head>

E estamos aqui novamente, de volta ao Ansible. Mais precisamente continuando a parte gráfica, batizada de AWX/Tower. Preciso que resgatem na memória o que vimos no post ANSIBLE Series: Lab … Modo GUI = Web Console

Um resumo rápido e para ajudá-los…

1ª parte – Teoria: o que é AWX, por que foi criado, funções principais, e explicação sobre cada componente integrante da arquitetura.

2ª parte – HOW TO: como instalá-lo usando o método docker-compose.

3ª parte – Mão na massa: adicionar usuários, inventários, hosts, criar projetos e templates na interface web.

Portanto, sendo assim, não pretendo repetir ou me alongar demais nas explicações de cada coisa, seja item ou subitem, seja menu ou submenu, seja aba ou opção. Para que isso ocorra e todos compreendam recomendo a leitura do já citado ANSIBLE Series: Lab … Modo GUI = Web Console … Basta pesquisar no blog ou retroceder alguns artigos, ok? 😏

O que verão a seguir serão apenas telas já com os campos preenchidos por mim, de acordo com as minhas definições e configurações, ou seja, hosts, iventário, chave SSH, repositório GIT, etc. Se por acaso os nomes que você utilizou no laboratório diferem dos meus (o que é bem provável e possível), preste atenção e preencha os campos de acordo com eles.

Ultima chamada e reforço antes da prática de hoje: Caso queira saber/localizar aonde deve clicar selecionar ou digitar em cada passo/etapa no AWX, pare agora, leia e só retorne após o ANSIBLE Series: Lab … Modo GUI… Aaaaahhhhh, vocês já sabem muito bem o quê 😂😂😂😂 Chega de enrolar!!! rsrs

IF (TIMEOUT=TRUE) OR (ERROR=TRUE) THEN:

Control-A

# firewall-cmd --zone=public --add-masquerade --permanent
# firewall-cmd --permanent --add-service=http
# firewall-cmd --permanent --add-service=https
# firewall-cmd --reload

Node-01, Node-02

# systemctl status firewalld
# systemctl stop firewalld
# iptables -L

CRIANDO UMA ORGANIZAÇÃO (…)

Figura 01

ADICIONANDO UM USUÁRIO (…)

Figura 02

DEFININDO INVETÁRIO (…)

Figura 03

ACRESCENTANDO HOSTS (…)

Figura 04

ESTABELENCENDO CREDENCIAL (…)

Figura 05

INICIANDO UM PROJETO (…)

Figura 06

CRIANDO TEMPLATE (…)

Figura 07

RUNNING A JOB (!!!)

Figura 08

(**) Legendas:

Verde -> Sucesso -> OK!
Laranja -> Modificações/Alterações!
Vermelho -> Avisos/Falhas -> ERROR!

https://www.linuxtechi.com/install-ansible-awx-docker-compose-centos-8/

https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_engineer)

https://pt.wikipedia.org/wiki/Margaret_Hamilton_(cientista_da_computa%C3%A7%C3%A3o)

Margareth Hamilton & Apollo 11

Happy women’s day 🙂