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 🙂

um comentário

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