AWS SERIES: TEORIA … Nuvem, Cloud Computing ou Internet ?

Sendo ou não de TI, as chances de ter ouvido “esse” ou “aquele” termo, tal “palavrinha” chave, ou todas as alternativas anteriores, é muito, mas muito grande mesmo. E não é exagero dizer que a nuvem já faz parte das nossas vidas, mesmo que às vezes não percebamos ou negligenciamos o seu devido valor. Sim, eu poderia muito bem passar a noite inteira aqui, dando exemplos e situações nas quais você foi salvo pela nuvem, mas vou poupá-lo disso e vamos somente a alguns casos: (a) agenda de contatos restaurada após roubo ou “morte” de um celular; (b) backup das fotos de casamento perdidas durante uma catástrofe natural; (c) carros que enviam dados de GPS uns para os outros sinalizando um eventual congestionamento, e portanto a recomendação de desvio aos demais; (d) download de um bom livro para longas e tediosas viagens.

Todos são a materialização do que ficou conhecido como “Computação em nuvem” (cloud computing, em inglês). Por não ser de hoje, embora soe como algo recente para os mais leigos, a mesma trouxe inúmeras consequências e causou mudanças de paradigma na computação. Ela nos apresentou um novo caminho, quase sem volta, pois os resultados e benefícios são tantos e tão vantajosos, que não faz o menor sentido a ideia de recuo/retrocesso . A Industria 4.0 ou Internet das Coisas (IoT, sigla em inglês) está aí para provar e não me deixa mentir. Somos inteiramente capazes de criar novos dispositivos complexos, a cada dia que passa e a partir de outros menores e mais acessíveis. Por exemplo, somando sensores, leds, circuitos programáveis, baterias, hardware sobressalente (braço, asa, hélice) e um chassi, você é capaz de construir um drone terrestre ou aéreo. Em um segundo momento, inevitavelmente terá que pensar em como interconectá-lo (da melhor maneira possível) a esses outros novos dispositivos ao mesmo tempo que funcione para todo o resto: pré-existente e legado. É justamente nesse intervalo que a nuvem entra em cena para salvar o dia.

E se atualmente testemunhamos esses objetos em todo lugar, coexistindo pacificamente e formando uma grande nuvem de coisas, boa parte do mérito deve ir para as tecnologias sem fio. Wi-Fi, Bluetooth e o 5G, são os vetores que carregam tais mudanças e as possibilita para um incontável número de aparelhos e usuários mundo afora. A cada nova versão lançada destes protocolos sem fio, mais e mais nos libertamos de cabos e tomadas, para uma maior abrangência, eficiência e autonomia, tanto do ponto de vista de alcance quanto do ponto de vista energético.

Porém, mesmo com essa introdução, talvez a pergunta ainda seja … Mas afinal, o que é Cloud Computing (computação em nuvem)? Vamos respondê-la então 🧐

>_ O QUE É?

Com a palavra, alguns dos maiores “players” do mercado no quesito CLOUD, à nível nacional e internacional. É claro que cada um irá expor do seu jeito, mas todos convergem para a mesma ideia por trás do conceito.

De uma forma simples, cloud computing, ou computação na nuvem, é uma tecnologia que permite acesso remoto a softwares, armazenamento de arquivos e processamento de dados por meio da internet. É uma alternativa para você acessar dados importantes de qualquer computador, em qualquer lugar.

SALESFORCE. https://www.salesforce.com/br/cloud-computing/

A computação em nuvem é a entrega de recursos de TI sob demanda por meio da Internet com definição de preço de pagamento conforme o uso. Em vez de comprar, ter e manter datacenters e servidores físicos, você pode acessar serviços de tecnologia, como capacidade computacional, armazenamento e bancos de dados, conforme a necessidade, usando um provedor de nuvem.

AMAZON WEB SERVICES. https://aws.amazon.com/pt/what-is-cloud-computing/

A cloud computing é o acesso sob demanda, via internet, a recursos de computação — aplicativos, servidores (físicos e virtuais), armazenamento de dados, ferramentas de desenvolvimento, recursos de rede e muito mais — hospedados em um data center remoto gerenciado por um provedor de serviços em cloud (ou CSP). O CSP disponibiliza esses recursos por uma assinatura mensal ou por um valor cobrado conforme o uso.

IBM. https://www.ibm.com/br-pt/cloud/learn/cloud-computing

Em suma, o que temos e podemos destacar é:

  • zero investimento (nada de hardware novo ou próprio)
  • onipresente (a qualquer hora, em qualquer lugar, a partir de qualquer plataforma)
  • pagamento == uso (sob-demanda e elástico para mais ou para menos)
  • disponibilidade via internet
  • escolha de um provedor de serviços na nuvem (chamado de CSP)

>_ COMO FUNCIONA?

Existe um velho ditado que afirma ( … ) uma imagem vale mais do que mil palavras. Bom, nesse caso sou obrigado a concordar pois encontrei, talvez a melhor, animação (.GIF) para explicar a nuvem se comportando na pr´atica, em tempo real.

Todos os créditos vão para o blog da MANDIC, uma empresa do Grupo Claranet Brasil. Pioneira com foco na internet desde o embrião, foi fundada em 1990 e especializou-se em prestar serviços on-line disponibilizados na grande rede mundial de computadores (a famosa WWW, ou World Wide Web). Acesse para saber mais em https://www.mandic.com.br/

Quanto ao seu conteúdo, trata-se na prática em reunir todo o processamento e armazenamento contratado pelo indivíduo/empresa em um único, porém amplo, recurso computacional. Em teoria, este seria constituído por uma rede de servidores interligados na nuvem, aonde os mesmos se comportam conforme a necessidade. No fim das contas, eles acabam reagindo dinamicamente as eventuais cargas de trabalho (workloads) provindas de clientes do sistema/aplicação/banco de dados em questão.

Com isso você alcançaria facilmente, e rapidamente:

  • Economia de custose paga apenas pelo que usar
  • Escalabilidade – vantagem da elasticidade
  • Agilidade – diversos servidores no ar em poucos instantes
  • Confiabilidade – suporte 24×7 e 365 dias do ano.
  • Armazenamento ilimitado – aumentar a disponibilidade atual de espaço de armazenamento
  • Backups e restauração – garantidos pelo provedor (CSP)
  • Acesso às informações – dashboards/gráficos/relatórios nativos e integrados

>_ TIPOS E DEFINIÇÕES

Nuvem pública

Toda a infraestrutura, segurança e dados do cliente final estão fisicamente e sob a tutela dos provedores de nuvem. Atualmente, os principais são: Amazon (AWS), Microsoft (Azure), e Google (Cloud Plataform).

Nuvem privada

Um desdobramento da nuvem pública, oferecendo recursos muito semelhantes, mas aonde os dados e serviços do cliente final são totalmente gerenciados pela organização contratada para essa função. É como se essa última fosse uma espécie de intermediário entre você/sua empresa e a AWS, por exemplo.

Nuvem híbrida

Sugestiva e didática, é a junção dos dois tipos de nuvem: pública + privada. Aqui, na maioria das vezes, não é obrigatoriamente necessário ter dois provedores distintos.

>_ MODELOS E SERVIÇOS

IaaS

Infraestrutura como serviço: processamento, armazenamento e conectividade de rede sob demanda. Clientes são capazes de desenvolver seus próprios aplicativos nesses recursos.

EX: Alibaba

PaaS

Plataforma como serviço: serviços, disponibilidade de recursos e backup dos dados são gerenciados pelo provedor mediano, facilitando assim para os clientes finais se concentrarem apenas na funcionalidade de seus próprios aplicativos.

EX: Google App Engine, RedHat OpenShift

SaaS

Software como serviço: terceirizados fornecem aplicativos de usuário final a seus clientes com alguns recursos administrativos no nível do aplicativo, como a capacidade de criar e gerenciar seus usuários.

EX: ERP, CRM, Google Docs

>_ REFERÊNCIAS

https://www.mandic.com.br/cloud/

https://www.salesforce.com/br/cloud-computing/

https://aws.amazon.com/pt/what-is-cloud-computing/

https://www.softwareone.com/pt-br/blog/artigos/2020/01/25/afinal-o-que-e-cloud-computing

https://www.ibm.com/br-pt/cloud/learn/cloud-computing

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.