ZABBIX Series: How to … install Zbx-Srv_5.0 on CentOS_7

Dando prosseguimento ao Zabbix, hoje vamos aprender como instalar a versão LTS (Long Term support) mais recente do mesmo. Pelo site oficial ainda é possível baixar a família anterior, representada pelo 4.0, bem como a versão não-LTS mais nova que é a 5.2 … Outras opções correlatas, à exemplo de DISTRO, DATABASE, WEB SERVER, também estão presentes na página.

Escolhi a 5.0 LTS, ao invés da 5.2, simplesmente por ser mais estável e amplamente depurada (sem bugs) tendo em vista que o intervalo de lançamento entre as duas foram alguns bons meses. Outro fator é o próprio suporte de vida prolongado, garantido assim patches de correção e segurança pelos anos conseguintes, mesmo após o seu encerramento.

Papel, caneta e lápis na mão para os requerimentos de instalação 👨🏻‍🏫

Hardware

A quantidade de memória e o tamanho do espaço em disco depende muito do número de hosts a serem monitorados. Para 500 hosts o mínimo recomendado é 2GB de RAM e 2 GB de HD. De acordo com a documentação oficial este pode ser considerado um ambiente mediano, portanto 2 núcleos de CPU e 2 GB de RAM são mais do que suficientes.

Para nossos laboratórios e exercícios futuros, no VirtualBox:

uma VM com 1 núcleo, 2GB ram, e 5GB ou >/+ hd

( Isso mais do que satisfaz nossos objetivos muito bem! )

Para outros cenários, configurações, ambientes … Maiores informações em 👇🏻👇🏻👇🏻

https://www.zabbix.com/documentation/5.0/pt/manual/installation/requirements

SOFTWARE

Apache: 1.3.12 ou superior
MySQL: 5.5 ou 8.0.x / MariaDB: 10.0.3 ou superior
PHP: 7.2.0 ou superior

Abra o virtualbox, inicie a VM, aguarde pelo CentOS e entre no terminal 👨🏻‍💻

01. REPOSITORIO

Ativar a ‘coleção de softwares’ (scl) via repositório:

yum install -y centos-release-scl

Baixar o repositório zabbix para obter depois os pacotes servidor, agente e frontend:

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

02. PKG ‘ ZABBIX-SERVER ‘

Instalar o servidor zabbix com suporte ao banco de dados MySQL/MariaDB:

yum install -y zabbix-web-mysql-scl zabbix-apache-conf-scl zabbix-server-mysql zabbix-agent --enablerepo=zabbix-frontend

03. TIMEZONE

Para usar o apache com o zabbix, atualize o arquivo de configuração do mesmo:

vi /etc/opt/rh/rh-php72/php-fpm.d/zabbix.conf
php_value[date.timezone] = America/Recife

Encontre a sua zona em:

https://www.php.net/manual/en/timezones.php

04. BANCO DE DADOS (DB)

Instalar o MariaDB listado nos repositórios do sistema:

yum install -y mariadb-server mariadb

Criar a base de dados:

systemctl start mariadb
mysql -u root -p
create database zabbixdb character set utf8 collate utf8_bin;

grant all privileges on zabbixdb.* to zabbixuser@localhost identified by 'password';

quit;

Importar os dados e esquema inicial para a recém-criada database:

cd /usr/share/doc/zabbix-server-mysql*/
zcat create.sql.gz | mysql -u zabbixuser -p zabbixdb

Apontar configuração da base, informando os detalhes no zabbix:

vi /etc/zabbix/zabbix_server.conf
DBHost=localhost
DBName=zabbixdb
DBUser=zabbixuser
DBPassword=password

Reiniciar todos os serviços:

systemctl restart zabbix-server zabbix-agent httpd rh-php72-php-fpm

Ativá-los para subirem automaticamente no reboot do sistema:

systemctl enable zabbix-server zabbix-agent httpd rh-php72-php-fpm

05. SELINUX

Caso você goste, conheça ou utilize em seus servidores de produção, execute esses comandos:

yum install -y policycoreutils-python
setsebool -P httpd_can_connect_zabbix on

Se preferir, também adicione algumas regras personalizadas executando os seguintes comandos:

curl https://support.zabbix.com/secure/attachment/53320/zabbix_server_add.te > zabbix_server_add.te
checkmodule -M -m -o zabbix_server_add.mod zabbix_server_add.te
semodule_package -m zabbix_server_add.mod -o zabbix_server_add.pp
semodule -i zabbix_server_add.pp

Caso contrário… Siga em frente e pule esta etapa 😬

Fonte : https://catonrug.blogspot.com/2018/04/set-up-zabbix-server-on-centos-6.html

06. FIREWALL

Configurar regras que permitam o agente zabbix alcançar o servidor zabbix:

firewall-cmd --permanent --add-port=10050/tcp
firewall-cmd --permanent --add-port=10051/tcp
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --reload

07. WEB INSTALADOR

Abrir o navegador (firefox, chrome, edge) e informar a URL:

http://ip_da_maquina/zabbix/

Pronto! Agora siga os passos e complete a instalação.

(a) Na página de boas-vindas clique em Next

(b) Verifique se todos os pré-requisitos estão OK. Em seguida, Next

(c) Digitar nome, usuário e senha da base de dados ‘zabbix’. Next

(d) Defina alguns detalhes do servidor, como porta e nome da instalação. Next

(e) Quase lá! Revise todas as informações presentes no sumário descrito na tela. Next

(f) Parabéns!!! Você conclui a instalação do Zabbix. Clique em Finish

Uma vez feito, você será redirecionado para a web console, mais precisamente na página de login …

08. ZABBIX DASHBOARD

=== Ou Painel em pt-BR ===

Faça logon com as credenciais padrão:

Username: Admin
Password: zabbix

Feito! Está pronto para uso!

Dark mode is the law … Law is the dark mode 🤣 lol

Agradeço imensamente sua paciência nesse começo “triplo” de mais uma série. Os capítulos subsequentes veremos como instalar o zabbix-agent e também acrescentar nós clientes no zabbix-server para monitoramento.

É isso pessoal. Por hoje é só. Nos vemos na próxima! 👋🏻

REFERÊNCIAS:

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

https://technologyrss.com/how-to-install-zabbix-5-0-on-centos-7/

https://www.itzgeek.com/how-tos/mini-howtos/securing-mysql-server-with-mysql_secure_installation.html

https://catonrug.blogspot.com/2018/04/set-up-zabbix-server-on-centos-6.html

ZABBIX Series: Teoria … Convenções = Palavras + Significados

No episodio anterior de MachinesBecomeServices (…) 👀 Vimos basicamente três coisas: o que é Zabbix? qual sua função? aonde utilizá-lo? Além disso, fui um pouco “categórico demais” ao afirmar que a teoria do mesmo se comparado a do Ansible é mais suave e tranquila. Bem, para me redimir e se por acaso ofendi alguém, segue a minha defesa. Ops! Quis dizer, desculpas (rsrs): Teoricamente falando, Ansible > Zabbix !!! Mas relaxem, não precisamos brigar 😅 Esse é tão somente o meu ponto de vista, opinião pessoal, e até mesmo o sentimento que aflora quando comparo um com o outro. (Use os comentários para expressar a sua: Ansible > Zabbix? Ou Zabbix > Ansible?)

Pedido de desculpas feito, papo introdutório terminado. Passemos agora ao contexto desse post ( e antes de tratarmos/abordarmos seu conteúdo na sequência).

CONTEXTUALIZANDO:

Uma vez instalado, nos deparamos com a interface do Zabbix acessível via browser. Primeiro é necessário finalizar algumas etapas de configuração, que na prática são páginas com perguntas e parâmetros a serem respondidos. Depois criar o próprio usuário para não utilizar mais o root/admin. Finalmente, entrar e conferir a página inicial do Zabbix. Nela, é possível exibir gráficos (simples e composto), mapas, telas, dentre outros elementos. E mais, tanto na barra superior (v_4.0) quanto na barra lateral esquerda (v_5.0), estão localizados todos os menus, sub-menus e opções relativas ao Zabbix e ao monitoramento como um todo.

Agradável visualmente e ao mesmo tempo “complexo” à primeira vista, foi pensando nisso, em facilitar as coisas, que a equipe do Zabbix propôs uma convenção entre palavras-termos-significados. O intuito é unir o útil ao agradável. Ou melhor, em outras palavras, auxiliar não apenas o uso, mas também o entendimento acerca do funcionamento da ferramenta por parte dos administradores e analistas.

Veremos que certas palavras/termos, trazem consigo um mero significado para determinado componente (“peça”) do sistema (zabbix). Ex: “isso é aquilo e ponto final”. E outras vezes significam uma ação para determinada tarefa em um local especificado. Ex: “fulano” é “beltrano” que “faz” tal coisa em “sicrano”.

CONVENÇÕES DO ZABBIX:

=== OU MELHOR, COMO SÃO AS COISAS? OU AINDA, COMO A BANDA TOCA? ===

Um brevíssimo crédito ao autor original e sua obra consultada para esta seção…

Nome: Werneck Bezerra Costa

Perfil técnico: https://br.linkedin.com/public-profile/in/werneckcosta?challengeId=AQENq7hye0XNQgAAAXe1oEyTMh3grPgdcN9gQk2A1SNB5KaM0_yJ-Y5t893eNYfqr9Rm_IyXD52hDmmbCeWQ1gHqKs8p6ifQZA&submissionId=ad992420-25df-6416-9570-61eb71224718

Artigo: http://www.revistas.unirn.edu.br/index.php/revistaunirn/article/view/415/358

Meio publicado: http://www.revistas.unirn.edu.br/index.php/revistaunirn/issue/view/27

Quero deixar claro que apenas sintetizei os principais conceitos baseado na leitura desta como também de outras fontes igualmente analisadas e referendadas por entidades, pares e empresas. Reconhecidas tanto na academia quanto no mercado. Todos os links para consulta estão presentes no final deste texto!

1. Host

Dispositivo de rede que possa ser monitorado por IP ou DNS. Ex: servidores, roteadores, desktops, impressoras.

2. Grupo

Conjunto lógico de hosts usando critérios de tipo, função ou localidade. Ex: Grupo Linux, Grupo Windows, Grupo Firewall, Grupo WEB, Grupo E-mail, etc.

3. Item

Dado, peça ou componente (físico/lógico) de determinado host monitorado. Na prática também pode ser chamado de métrica de dados. Ex: disco, memória, serviço (HTTP, NTP), porta, ping.

4. Template

Conjunto de elementos ou “agrupador” de elementos. É um tipo de “container”, um modelo para entidades (itens, triggers, gráficos, telas, aplicações) iguais e comuns entre ativos de rede, por exemplo, servidores virtuais. Ex: Template_Linux_RedHat, Template_Linux_Debian, Template_Web_Apache, Template_Web_NGINX

5. Triggers

Espécie de “supervisor” para itens. Usualmente monitora valores. Apresenta a capacidade de disparo e aviso por meio de e-mails, ou visualmente altera a cor de um item. Ex: Saída para internet inoperante, ou seja, de verde para vermelho.

6. Eventos

Ocorrência gerada pós-ativação de uma trigger. Normalmente algo que merece atenção. Lista dos últimos eventos está presente na interface inicial do usuário no Zabbix.

7. Actions

Resposta pré-definida à determinado evento. Uma ação é formada por condicionantes + operações a serem executadas. Ex: envia mensagem e depois executa um comando remotamente no servidor.

8. Gráfico simples

Criado automático após a adição de um item. O mesmo não permite mudanças estéticas.

9. Gráfico composto

Oposto do simples. Manualmente ou via template para relacionar itens.

10. Mapas

Conjunto de hosts aglutinados visualmente para melhor identificação de eventos e conexões.

11. Telas

Elemento visual composto. É um “aninhador” de informações. Gráficos, mapas e texto em um só local.

12. Aplicação

Grupo/conjunto lógico de itens.

13. API Zabbix

Possibilita o uso do protocolo RPC Json para criar, atualizar e receber objetos Zabbix (como hosts, itens, gráficos, dentre outros) ou executar qualquer tarefa personalizada.

https://www.zabbix.com/documentation/current/pt/manual/concepts/definitions

http://zabbixbrasil.org/files/Network_Conference.pdf

ZABBIX Series: Teoria … Monitoramento e os 3 “Q”s (O que? Por que? Para que?)

A ideia que tenho (e sustento até o momento) para reger a linha temporal, bem como a sequência entre as ferramentas abordadas aqui no BLOG, é a seguinte:

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

Pois bem, cientes disso agora, e sem floreios ou enrolação, podemos começar 👍 Avante!

Conceitualmente falando, o Zabbix difere muito se comparado ao Ansible. Principal motivo/razão? O primeiro apresenta uma teoria simples, enxuta, fácil e até mesmo, de tamanho reduzido. Já o último possui uma vasta (pra não dizer enorme) “galáxia” de termos e definições. Metaforicamente, cada um desses seria uma “estrela” atraindo gravitacionalmente “planetas” e suas “luas” (itens e subitens, respectivamente) compondo assim, isoladamente, um “sistema solar”. Porém, uma vez somados, estes próprios formam um grande “sistema” de “sistemas”. Daí a escolha da palavra galáxia. E o que seríamos nesse contexto? Pequenos astronautas, é claro! 👨🏻‍🚀 🚀 Desbravando e contemplando todo o seu esplendor.

Se no passado precisamos de pelo menos três partes (links abaixo), deveras longas, para nos situar diante da teoria do Ansible… Veremos que no presente, e com o Zabbix, é necessário apenas duas postagens, curtas por sinal (diga-se de passagem), para expor todos os elementos que servem de fundamentos teóricos.

ANSIBLE Series: Teoria … Um papo sobre DevOps

https://machinesbecomeservices.com/2020/11/12/ansible-series-intro-parte01-um-papo-sobre-devops/

ANSIBLE Series: Teoria … Dicionário Ansible

https://machinesbecomeservices.com/2020/11/16/ansible-series-introducao-parte02-dicionario-ansible-e-a-importancia-da-automacao/

ANSIBLE Series: Teoria … 5-V Conceitos Fundamentais

https://machinesbecomeservices.com/2021/01/22/ansible-series-teoria-5-v-conceitos-fundamentais/

O QUE É ZABBIX?

É um sistema open source robusto e altamente confiável que estende suas funcionalidades desde o monitoramento de componentes em infraestrutura de TI até processos/análise de indicadores críticos de desempenho para negócios, com monitoramento de dados em tempo real.

Complemento Tecnologia (https://complemento.net.br/zabbix/)

É uma ferramenta que oferece um serviço distribuído de monitoramento, possibilitando o acompanhamento e a geração de alertas e relatórios para auxiliá-lo na gestão e a fazer intervenções em sua infraestrutura de TI.

Mário Neto (https://www.devmedia.com.br/zabbix-monitoramento-de-infraestrutura-revista-infra-magazine-5/24089)

Acima estão dois conceitos, duas fontes, e duas palavras-chave a destacar (uma em cada citação)… ¹ Indicadores e ² Alertas… Simplificando ao máximo: 1) É a interpretação, ou contexto, dos resultados advindos de uma medição realizada em determinado componente de um sistema. 2) Refere-se a uma mensagem cujo objetivo é avisar que algo aconteceu (evento) fora do comportamento esperado, o que pode indicar na maioria das vezes uma possível anomalia.

Pontuados e esclarecidos tais termos, e antes de passar para a próxima seção, deixo a seguir a minha definição para o Zabbix. Não que a mesma vá de encontro, bata de frente com outros conceitos. Não. O intuito é apenas registrar com palavras próprias o meu entendimento.

Trata-se de uma solução aberta, gratuita, acessível via WEB, para monitorar toda sorte de itens, sejam eles: (a) componentes e sistemas, (b) hardware e software, (c) aplicações e serviços, (d) métricas e parâmetros, entre muitos outros. Ex: utilização da rede, carga de CPU, espaço em disco, integridade de peças e equipamentos, etc.

POR QUE MONITORAR?

Qualquer ambiente/infraestrutura/rede de uma empresa (pequena, média ou grande), atualmente apresenta uma natureza heterogênea. Servidores Linux, Estações Windows, Macbooks/iMacs, Blades HP, Roteadores Cisco… Esses são só alguns para exemplificar. Na prática, gerenciar e concatenar diversos softwares, equipamentos distintos, fornecedores com marcas diferentes, e afins, é um desafio a ser superado todos os dias pelas equipes de TI. Então, saber o que está acontecendo e ao mesmo tempo ser proativo (não reativo!), deixa de ser um mero detalhe e passa ao status de primordial. Somente assim é possível alcançar uma boa gestão, fazendo intervenções precisas (quase cirúrgicas) no datacenter e seus elementos, lógicos ou físicos. Portanto, a resposta para: por que monitorar? é a seguinte… Evitar, mitigar ou até mesmo eliminar sinistros, bugs, anomalias, sintomas adversos, enfim, todo tipo de problema (maior ou menor).

Em sua maior parte, o Zabbix desempenha e opera funções de forma visual. Opções como gráficos, mapas, tabelas de histórico, alertas interativos, notificações via email – jabber/xmpp – SMS, estão presentes e inteiramente disponíveis ao administrador, analista, ou equipe responsável.

PARA QUE?

Sem rodeios, direto ao ponto, o Zabbix serve para garantir:

  • Qualidade de links e conectividade de redes;
  • Utilização justa e igualitária de banda;
  • Saúde dos ativos de rede (roteadores , switches, access points, etc);
  • Serviços em perfeita execução;
  • Descoberta de novos servidores e dispositivos na rede.
** Lista completa **

https://www.zabbix.com/features

https://www.zabbix.com/br/solutions

(+) Bonus: Scenarios designed by Zabbix LLC

Figura 01. Coleta de métricas
Figura 02. Detecção de problemas
Figura 03. Painel único e customizável
Figura 04. Notificações
Figura 05. Facilidade nos Deploys
Figura 06. Autodescoberta

REFERÊNCIAS:

https://www.zabbix.com/

https://complemento.net.br/zabbix/

https://www.devmedia.com.br/zabbix-monitoramento-de-infraestrutura-revista-infra-magazine-5/24089

TO BE CONTINUED …

( Continua no próximo episódio … )

👀👀👀

ANSIBLE Series: Teoria … 5-V Conceitos Fundamentais

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

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

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

RECAPITULANDO

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

RED HAT BLOG … TAG #RedHatShares

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

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

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

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

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

I) Provisionamento

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

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

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

De servidor…

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

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

De usuário…

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

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

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

De rede…

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

De serviço…

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

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

II) Gerenciamento de Configuração

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

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

Por que gerenciar configurações?

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

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

III) Orquestração

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

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

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

AUTOMAÇÃO

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

Candidatos: processos automatizados para orquestrar

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

Ferramentas de orquestração

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

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

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

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

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

IV) Implantação de Aplicação

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

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

V) Segurança e Conformidade

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

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

OTRS Plus+: OTRS 8 Trial

Bem vindos ao ano de 2021 queridos machiners!!! Meus votos para que o mesmo seja repleto de esperança, retomada, alegrias, e boas surpresas para todos. Devo admitir que estava na dúvida sobre qual assunto abordar no primeiro post do ano. São tantos, além daqueles que já mencionei no artigo passado, que acabei optando por um velho conhecido, o OTRS. Lembram dele? Aposto que sim. Encerramos a sua série em novembro, exatamente no dia 06. E se você acompanha o BLOG há algum tempo, sabe muito bem que ele iria voltar cedo ou tarde. Aliás, é válido lembrar que qualquer tópico/ferramenta abordado aqui, sempre terá conteúdos extras após o término da SERIES principal correspondente. Seja no formato de PLUS+ ou NEWS, eles regressão com toda certeza ao machinesbecomeservices.com 😎 Tendo em mente isso, e sem mais delongas, vamos direto ao assunto de hoje…

Quando você leu o título dessa postagem, estou quase 100% convencido de que duas perguntas vieram imediatamente em sua cabeça:

A) Victor, salvo engano, durante a série o OTRS estava na versão 6.0.18 não? Como ele pulou para a 8?

B) E por que em seu nome não é visto mais o ‘Community Edition’? Ou ‘Business Solution’? Afinal, agora ele é totalmente free ou totalmente pago?

Pois bem, vamos nos debruçar sobre as respostas para tais perguntas a seguir.

UMA BREVE LINHA DO TEMPO …

OTRS (( Software )) :

2001 OTRS é lançado como um gerenciador gratuito de tickets para helpdesk

2003 A OTRS GmbH é formada. A companhia entra na zona EMEA (Europa, Oriente Médio, e África)

2006 Operações iniciadas no mercado norte-americano

2007 Renomeada para OTRS AG para torna-se pública via IPO

2009 Entrada bem-sucedida e oficialmente no mercado de ações (bolsa de valores)

2011 Começo na zona APAC (Ásia e Pacífico)

2015 Nova versão é lançada e intitulada ‘OTRS Business Solution’. Voltada para uso corporativo e comercial. Suporte, configuração e recursos adicionais. Todos esses de natureza exclusiva e totalmente paga

2018 Ambas versões sofrem modificações em seus nomes. A solução de código aberto é chamada de ((OTRS)) Community Edition. Já a paga passa a ser simplesmente OTRS (+ numeral da versão)

UMA BREVE HISTÓRIA …

OTRS (( Group )) :

  • Originalmente era OTRS GmbH
  • Fundada em 2003
  • André Minderman e Burchard Steinbild
  • Mudança para OTRS Group em 2007. Também conhecida como OTRS AG
  • Proprietária e detentora de todo o código fonte do OTRS.
  • Sede na Alemanha
  • 6 afiliadas ao redor do globo
  • EUA, México, Cingapura, Hong Kong, Brasil e Hungria
  • Listada na bolsa de Frankfurt – Alemanha (GER)

MINHA ESTRANHEZA, “APARENTE ABANDONO” DO OTRS FREE, COMO DESCOBRI, E SITES PARA SEGUIR / SE INFORMAR

Na época em que meu chefe escolheu o OTRS como sistema de tickets e chamados (meados de 2018, início de 2019), fiquei incumbido de estudá-lo, gerenciá-lo e configurá-lo o mais rápido possível. As coisas tinham que acontecer na empresa, o pessoal deveria ser treinado e toda a parte de administração precisava ser documentada (em PDF e Wiki). Devido a tamanha urgência, falta de tempo, outras incumbências correlatas, e demais responsabilidades de um sysadmin (eu), não tive oportunidade de pesquisar mais a fundo ou acompanhar as notícias que saiam acerca do OTRS e seu futuro.

Um pequeno parênteses que abro aqui, pois o considero relevante e digno, para não dizer importante… O que fiz foi cometer um erro. Sim, um grande ERRO!!! Fato que não deve acontecer de novo, já que não pretendo repeti-lo e se tornou uma lição para mim. Portanto, deixo a seguinte dica: NUNCA, JAMAIS deixe de acompanhar as novidades e notícias da ferramenta que está usando. Seja por canais oficias, mídias sociais, ou blogs especializados, sempre preste atenção no que está ocorrendo dentro da empresa responsável. Sem isso, possa ser que você enfrente a mesma sensação que tive, de abandono, de algo errado, de “será que é o fim?”, etc, etc.

No meu caso, com o OTRS, somente descobri o que estava acontecendo graças ao site, na verdade fórum, Otterhub.org, especialista em ((OTRS)) Community Edition e Znuny LTS (um fork do OTRS). Gravem este nome e salvem nos favoritos do browser! Falo sério, este website é demasiadamente bom. Me ajudou em diversas dúvidas e questões sobre o que é possível fazer ou não no OTRS Free (community). Usuários amigáveis, pessoas solícitas e moderadores com autoridade e conhecimento no assunto, é basicamente o que irá encontrar.

O link com a discussão acerca do OTRS 7, 8 e Community Edition é o https://forums.otterhub.org/viewtopic.php?f=53&t=41628 sendo que o mesmo nos leva a outro link, uma fonte alemã, a revista Enterprise Application Software Magazine (EAS-Mag) https://de.eas-mag.digital/interview-mit-otrs-zur-neuen-produktstrategie-und-die-bedeutung-fuer-die-free-user/

Apesar de estar em alemão, basta traduzi-lo para o inglês com o recurso translator do Google Chrome. Não vou detalhar toda a discussão e notícia elencadas. Recomendo altamente a leitura de ambos. Até porque esta última é na prática uma entrevista com o próprio CEO e co-fundador da OTRS AG. Muito interessante por sinal, e a discussão entre os usuários do fórum é bastante enriquecedora, com variados pontos de vista, o que é legal demais. Sintetizando, e adiantando aos curiosos e apressados de plantão (rsrs!), o resumo é que:

Novos recursos e novidades presentes no 7 e 8, apenas chegarão no ((OTRS)) Community Edition dois anos após seu lançamento, na forma de updates e mantendo o nome atual e vigente (community)

PRINCIPAIS CARACTERÍSTICAS: RÁPIDO, MODERNO E SEGURO

Figura 01. (Fonte: https://otrs.com/otrs-8/)

+ Extras

  1. Autenticação dois fatores – SMS, App, Email
  2. Comunicação, Páginas, Modificações e Ações em TEMPO REAL
  3. Layout totalmente flexível e customizável
  4. Telas, ícones e disposição de elementos podem ser reorganizadas livremente

GOSTEI… E AGORA? COMO FAÇO PARA TESTAR/COMPRAR O OTRS 8?

Path:

otrs.com > solutions > it service management > start now > contact email form > your company data

Figura 02. Formulário de Contato via Email

** Only business email address !!!

** NO gmail.com OR outlook.com OR yahoo.com !!!!

** EX: first_name_last_name@yourcompany.com
johndoe@notexist.com
peterpan@neverland.com
vicrlda@machiner.com.br

NOW JUST RELAX AND WAIT FOR RESPONSE 😉

See you in the next post. Bye!

Vicrlda: Feliz Ano Novo !!! Cronograma 2021, Férias, Janeiro e Msg ao Leitor :D

Quando você estiver lendo este texto, provavelmente já estarei com o pé na estrada… E de férias do meu trabalho. Mas isso não implica em outro hiato, ou pausa. Não. Muito pelo contrário. Pela primeira vez na vida estou realmente entusiasmado por criar e tocar um projeto pessoal tão singelo, tão reconfortante, quanto gratificante. Tudo isso é fruto, claro, do seu objetivo majoritário: ajudar outras pessoas (profissionais, colegas, pares da área de TI) compartilhando conhecimento e experiências. Mas antes de continuar, o mais importante primeiro:

FELIZ 2021 GALERA !!!! Que este ano que chega nos traga muitas alegrias, conquistas, realizações de sonhos e metas, sejam elas particulares ou comunitárias, pessoais ou profissionais. Além de muita paz interior e saúde, que não podem faltar.

Agora sim, vamos ao restante que quero abordar. Só que por partes 😇 hehehe

. . . Quando afirmei que estava empolgado (aqui e em outras ocasiões passadas), disse isso pois às vezes me pegava divagando e questionando a mim mesmo — “Como pode um simples blog/site causar tamanha euforia e energia dentro de um ser humano?” — (Neste caso, eu) E a resposta, acredito fortemente que seja: a atitude tomada, o passo dado, a ação feita, e não o objeto em si (página web). — “Como assim Victor? Não entendi” — Pois muito bem, eu explico. No dia 31 de março de 2020, data em que criei este blog, uma série de eventos ocorria em minha vida. Fui acometido por uma doença que me fragilizou por oito longos meses; houveram mudanças estruturais e organizacionais no meu trabalho; teletrabalho, remoto ou homeoffice (chame como quiser!) devido a pandemia; questões internas, íntimas e muito pessoais (que não cabem neste post); e a lista segue… Então, foi somente a partir daí que me veio um lampejo, uma faísca, um estalo, para fazer algo, mudar o meu presente, e por tabela mirar o meu futuro — Por que não contribuir com a comunidade que tanto me ajudou ao longo dos anos? — Além disso — Por que não unir o útil ao agradável e desempenhar algo que gosto (desde sempre!) e uma habilidade que desenvolvi graças a minha formação e carreira? — Isso mesmo, acertou 🙂 Escrever e documentar coisas. Essa é a história, foi assim que nasceu o machinesbecomeservices.com 😉 Voltando a resposta para a minha pergunta inicial, se pudesse resumi-la em três palavras, elas seriam: <<< Quebra da inércia >>> Exatamente o que leu. Um dos conselhos que posso lhe dar é: Quebre a sua inércia meu caro. Acabe com o marasmo em sua vida. Espante para longe toda a negatividade que porventura o cerca. Estabeleça pequenas metas, faça pequenos gestos para atingir seu objetivo maior lá na frente. A internet está aí para isso! Nela existem diversas formas de você começar. Seja gratuita ou de forma paga. Busque ajuda com outras pessoas para colocar o seu projeto em prática (caso precise, posso dar uma força 😀) e seja feliz!!!

. . . Janeiro para muitos é sinônimo de férias. E férias é sinônimo de descanso. Sim, essa lógica está correta. Mas, para mim, neste ano, ela termina por aí. — Como assim Victor? — Acontece que minha cabeça está fervilhando de ideias para novos, melhor dizendo, para os próximos posts do blog. Sendo assim, não posso deixar a oportunidade passar e correr o risco de perder/esquecer o fio da meada, a linha de raciocínio. Para ajudar em tal tarefa, e se você está preocupado com o meu bem-estar e descanso mental 😁, farei tudo isso de um local inspirador, de muita paz, e com bastante natureza (detalhe que amo e sempre acalma o meu espírito). Então, fiquem antenados no mês de janeiro, pois haverá muito conteúdo. Só para pontuar os assuntos que aparecerão no cronograma de 2021, aqui vão alguns deles: Zabbix, Universo ‘Docker‘ (Containers, Kuberbentes, Podman, Buildah, Openshift), Cloud e CloudNative, OTRS News e Plus+, dentre outros.

. . . Por último, mas não menos importante, gostaria de sugerir uma dica para o seu 2021. Inspire-se em outros indivíduos que assim como você e eu tiveram que começar de algum lugar, de algum ponto de partida. Se me permite posso dizer os meus:

(A lista acima não apresenta necessariamente uma ordem cronológica, ou de qualquer outra natureza. São apenas sites/blogs que tomei ciência ao longo do tempo, e que de alguma maneira me auxiliaram bem como me inspiraram a contribuir e compartilhar conhecimento)

Um feliz ano novo a todos vocês!!! E nos reencontraremos em breve… Em 2021.

Boas festas!

CENTOS/RHEL News: CentOS Stream? É o 9? Não. De uma distro base para uma distro rolling release…

Olá de novo! Como estão? Quase Natal e gostaria de presenteá-los. Por isso escolhi essa notícia… (Calma! Ao final tudo fará sentido 😉 ) Para aqueles que ainda não estão familiarizados com a classificação das postagens ou perderam como o conteúdo do BLOG é categorizado, nada temam. Basta uma lida rápida em https://machinesbecomeservices.com/2020/11/04/vicrlda-im-alive-voltei-retorno-notas-e-avisos/. Atentos também para o fato de que estarem testando um novo formato de post, um pouco diferente dos outros que escrevi até agora. Visualmente ele será um fluxo de ideias. Apenas frases que simbolizam tópicos, ora curtos, ora longos. Já vi tal recurso literário presente em outros blogs/sites. Alguns gostam de chamá-lo ‘resumo do texto’. Destaco pois este é comumente posicionado ANTES ou DEPOIS do artigo, variando de site para site.

Muito bem meus caros, devidamente explanados e conscientes tais detalhes, só posso desejar… Boa leitura!!!

No início de dezembro, mais precisamente no dia 08, a Red Hat pegou todos de surpresa quando fez o anúncio de que o CentOS Base(ou)Downstream(ou)Versionado (escolha o seu nome preferido!), deixaria de ser alinhado ao calendário de lançamento do Red Hat Enterprise Linux. Traduzindo, e trocando em miúdos, isso significa que o CentOS não possuirá mais números em seu nome e nenhuma relação, pelo menos não diretamente, com os pacotes e versões do RHEL. Vamos então agora aos pormenores dessa notícia:

  • Historicamente falando, o CentOS sempre foi um clone do Red Hat Enterprise Linux (RHEL).
  • Dentre um intervalo de poucos dias, no pós-lançamento do RHEL, saia o CentOS correspondente. EX: RHEL 5 -> CentOS 5 / RHEL 6 -> CentOS 6
  • O projeto CentOS era livre, independente e código aberto.
  • Totalmente voltado para a comunidade.
  • Em janeiro de 2014, a Red Hat adquire os direitos do projeto.
  • Futuramente, via comunicado oficial da Red Hat, o CentOS não será mais uma distro linux downstream e sim uma upstream. Ou seja, agora serão lançados novos pacotes primeiramente no CentOS/Fedora para só depois saírem versões estáveis no RHEL vigente (9, 10, 11, e diante).
  • Na prática isso o torna um ambiente de testes, uma espécie de desenvolvimento para o RHEL.
  • Para ilustrar melhor, no passado, a ordem de lançamento era precisamente essa:
    • 1º) Fedora
    • 2º) RHEL
    • 3º) CentOS
  • Quando foi lançado, ano passado (setembro/2019), o CentOS Stream a principio seria o “man-in-the-middle” entre o Fedora e o RHEL, preservando assim o CentOS Base/Tradicional.
    • Era mais ou menos assim:
    • Fedora > CentOS Stream > RHEL > CentOS Base/Tradicional
  • Lado negativo? A alteração da data final do suporte.
    • CentOS 8: previsto para até 2029, foi encurtado para 2021
    • CentOS 7: planejamento não mudou, continua até 2024
  • Mudança significativa para sysadmins, devops e programadores que utilizam versões anteriores. Tornou-se assim um fator importante a ser considerado a curto prazo.
  • Lado positivo? No mundo open source dificilmente projetos morrem. Quando são ‘descontinuados’ por seus criadores/empresas, como num passe de mágica, são ‘continuados’ por entusiatas, desenvolvedores e usuários órfãos daquele projeto. O apreço e carinho falam mais alto e assim surge um fork do sistema/ferramenta.
  • E o que eu ganho com isso?” ; O que fazer?”. Se você é da área de infra, seja analista, técnico, ou devops, fique atento pois nos próximos meses, diria até anos, haverá uma demanda muito grande por consultoria em migração de servidores CentOS 7 e 8 para o Stream ou para prováveis novos forks feitos pela comunidade.
  • Sabendo disso, fica aqui o meu compromisso (podem me cobrar depois 😅) de trazer em primeiro mão um artigo tutorial, classificado como CENTOS/RHEL PLUS+, de como fazê-lo. Muito em breve!

É isso pessoal. Basicamente o que queria compartilhar com todos. Esse é o meu presente de Natal!!! Uma notícia simples mas importante, que virou uma promessa de mim para vocês, e no final torço que se transforme em oportunidades, colocação no mercado de trabalho, para os todos os machiners desse nosso querido BLOG.

Feliz Natal ! Ho Ho Ho Ho Ho

RECOMENDADOS:

LINUXTips

https://www.youtube.com/watch?v=hJ-wZ0GjAu8

Blog Diolinux

https://diolinux.com.br/editorial/mudancas-no-centos.html

YouTube do CentOS Project

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

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.
%d blogueiros gostam disto: