Menu Início

ANSIBLE Series: Teoria … Um papo sobre DevOps

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

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

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

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

2008 – Agile Conference – Toronto/Canadá

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

2009 – O’Reilly Velocity Conference – Flickr

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

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

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

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

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

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

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

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

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

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

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

DOIS LADOS, UMA MESMA MOEDA CHAMADA DEVOPS

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

Gerenciamento de configurações

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

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

Orquestração

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

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

E O ANSIBLE? ORQUESTRADOR OU GERENCIADOR?

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

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

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

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

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

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

REFERÊNCIAS:

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

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

Categorias:Ansible

Marcado como:

vicrlda

🐧Linux SysAdmin & OTRS, Zabbix, Ansible
🎴 Paraíba - Brazil
💀 Rock: Garagem, Surf, Punk, 60's, Indie, Folk
😍 @mayararaissa.t
👶 Miguel's Dad

1 resposta

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

%d blogueiros gostam disto: