Orquestração, DevOps e o Puppet

Fui demitido! Infelizmente a empresa que atuei nos últimos 7 anos esta em meio a uma crise financeira e dispensou diversos funcionários de todos os níveis hierárquicos e dentre os cortes necessários para garantir a sobrevida da empresa, fui atingido. Reconheço com amargura os efeitos do LuloPetismo que está levando o nosso país  ao fundo do poço.

Passei por esta experiência amarga com um saldo final positivo, pois levo comigo excelentes recordações dos amigos e das realizações conquistadas.

Durante o período em que fiquei desempregado fui chamado para algumas entrevistas e uma delas motivou este post, a entrevista era para uma vaga para DevOps Manager. Um belo cargo não é mesmo? Já até imaginei o cartão profissional com este cargo, coisa de Nerd.

Confesso que não sou especialista no assunto, o conhecimento que tenho advém de estudos teóricos do assunto e da minha participação em projetos onde o conceito DevOps foi implementado (desenvolvimento web) e em outros onde não obtivemos sucesso.

Além da área de desenvolvimento web vivenciei uma implementação deste conceito numa área de desenvolvimento de sistemas transacionais, corporativa, e encontramos uma série de barreiras que durante o tempo em que fui responsável pela iniciativa não conseguimos transpor.

Conceitualmente o DevOps tem por objetivo unir as etapas de desenvolvimento de sistemas com a fase de disponibilização da infraestrutura tecnológica, os objetivos são; acelerar o ciclo de desenvolvimento, reduzir custos, melhorar o time to market de aplicativos e fazer chover no reservatório da Cantareira. Brincadeira a parte, notei durante a entrevista de emprego que os executivos que me entrevistaram mal sabiam o que buscar em termos de conhecimentos e experiência para a vaga em questão.

Quando comecei a explicar o que eu entendia por DevOps notei o semblante de espanto no gestor de desenvolvimento, realmente ele não tinha ideia alguma do que precisava avaliar como requerimentos para potenciais candidatos, o dono da cadeira de infraestrutura estava coma impressão que bastaria ter a oferta de serviços IaaS sobre sua responsabilidade.

Para ajudar pessoas como estes gestores decidi escrever este post com os alguns componentes que podem ser considerados para viabilizar a implementação do conceito de DevOps.

Pessoas, Ferramentas e Processos

Enquanto na teoria o DevOps pretende unir as áreas e profissionais (de infraestrutura e desenvolvimento) de fato o que eu vivenciei não foi isso, quando tentamos elevar a maturidade do time de desenvolvimento para ser o time responsável por realizar os scripts e deploys automatizados não obtivemos sucesso. E tampouco tivemos sucesso quando tentamos a responsabilizar os times de infraestrutura.

No fundo ninguém está disposto a fazer mais do que o combinado, é cultural. No caso onde evidenciei o sucesso do conceito havia uma diferença fundamental,  a realização do ciclo total DevOps era realizada por um único time, no caso o time de desenvolvimento, pois esta equipe foi contratada já com um job description muito parecido das inteligências necessárias para utilizar o DevOps.

Isso ficou evidente quando os times de desenvolvimento abraçaram atividades outrora realizadas pelo time de infraestrutura (sem reclamar) e as realizaram através de scripts automatizados nas ferramenta de orquestração.

Parece-me que o caminho natural é mesmo o time de desenvolvimento ser o responsável pelo ambiente de orquestração uma vez que os scripts necessários lhes são muito mais peculiares do que aos times de infraestrutura. É claro que toda a regra pode haver exceções, no caso por exemplo de administradores de Unix/like é possível que se encontre gente com conhecimento na escrita dos scripts.

A melhor (em minha opinião) e mais utilizada (fato) ferramenta para orquestrar as configurações e deploys automatizados é o Puppet – ferramenta de Orquestração e Gestão da Configuração. Vale ressaltar que o escopo da Gestão da configuração é em parte o que a ITIL contempla.

O Puppet foi desenvolvido pela Puppet Labs, e dentre as ferramentas que analisei  possui o maior número de funcionalidades e tem o maior marketshare. Ela é capaz de orquestrar vários sistemas operacionais e independente de ser físicos, virtuais, Cloud Pública, privada etc. Vale a pena entrar no site da empresa e dar uma boa navegada pelo conteúdo disponível e baixar a versão trial do Enterprise com a console gráfica.

Os requisitos de hardware não são empecilho para o Puppet Master.  Este serviço é o responsável por executar o enforce de políticas, deploy de imagens etc. A configuração inicial é simples, depois de realizar o setup no servidor do Puppet Master é necessário instalar os Agentes nos servidores que serão gerenciados.  O Puppet tem uma arquitetura muito similar a de sistemas de monitoração, composta do servidor principal e agentes, com uma pequena diferença, os scripts de configuração/Manifestos que podem ser escritos em linguagem própria do Puppet ou eu Ruby. Normalmente esta decisão será direcionada pelo nível de complexidade dos manifestos.

O produto está disponível em 2 versões: uma corporativa chamada Puppet Enterprise e uma de uso livre chamada Puppet OpenSource. A versão corporativa possui alguns recursos adicionais e uma excelente interface gráfica para o Puppet Master, a versão Open não fica perde muito em termos de funcionalidades, embora muitos dos recursos não sejam nativos, os mesmos podem ser encontrados em versões alternativas que podem ser configuradas. Pessoalmente pelo baixo valor do produto acredito que vale mais a pena adquirir a versão Enterprise.

Além do serviço que “empurra” as configurações é necessário ter um tipo de infraestrutura como serviço, pode ser tanto uma nuvem IaaS como a AWS quanto algo similar on premises rodando Vmware ou Open Stack. É necessário é conseguir criar a máquina virtual a partir de uma console ou de um scripts para preencher todo o processo de criação do ambiente.

Imagine a criação de um pequeno ambiente composto de web Server, app Server e DB server. Seria necessário rodar algum wizard que faça o deploy da imagem simples do SO com o agente do Puppet na imagem, para assim que o servidor estiver up and running sincronizar com os manifestos desejados e assim receber as imagens e configurações desejadas (Apache, Joboss, Jetty, Tomcat etc) após estas etapas também é possível sincronizar os containers com versionadores (GIT/SVN) para também efetuar o deploy dos últimos pacotes das aplicações.

Além das ferramentas é necessário definir claramente quais serão os entregáveis da orquestração, é comum incorrer no erro de achar que somente o componente sistêmico irá atender plenamente o DevOps. É necessário planejar detalhadamente com os times de arquitetura, segurança, desenvolvimento e infraestrutura e juntos criar um catálogo do serviço. Vou deixar alguns exemplos possíveis da orquestração.

Recriação de ambientes – Refreshs

  • Garantir que os manifestos ou receitas geradas, mantidas e administradas realizem e apoiem as verticalizações por torres, sistemas ou tecnologia de cada ambiente participante do hardening.
  • Em caso de comprometimento de ambiente por invasão e a integridade do ambiente produtivo esteja em cheque, um novo ambiente pode ser recriado a partir de uma versão viva do ambiente anterior a contaminação.

 Auditoria e gestão da configuração

  • Garantir repositório e continuum da gestão da configuração contida nos manifestos.
  • É fundamental que o operador do hardening mantenha e esteja apto a manter documentações “vivas” – válidas e dinâmicas de cada nicho, bem como, aspectos de receitas complementares nominadas e válidas para sistemas ou negócios com peculiaridades.
  • Considerar o hardening nas receitas com atualizações de patches. Ganhos operacionais e redução do tempo de planejamento e execução.
  • Ter disponíveis os logs de operações técnicas de hardening, colaborando com alarmes de domínio Active Directory, permitindo a visão de controle das alterações.

Hardening e compliance dos ambientes em operação

  • Mesmo para ambientes específicos é recomendado que ainda assim, ajustes específicos e pontuais não sejam feitos manualmente e sim resolvidos sempre que possível por receitas.
  • Gestão de acessos em compliance com a política de segurança e respectivos padrões.
  • Trabalhar com períodos definidos de refresh, por exemplo, a cada 1 hora para o audit e para realizar o enforce de configurações de conformidade.

 Integridade e padronização dos novos ambientes

  • Garantir que sistemas e servidores que forem hardenizados, estejam de acordo com o portfólio de produtos e marcas padrões presentes nos padrões tecnológicos, operacionais e arquitetônicos.
  • Camadas de produtos e softwares embarcados em servidores orquestrados em compliance com arquitetura de camadas, integrações e processos que a governança de TI previamente homologou.
  • Garantir que ganhos de produtividade e assertividade técnicas sejam alcançados, perante tal investimento (DevOps). Considerar ainda e com maior ênfase, ganhos de ordem econômica (ROI/TCO) advindo da redução de pessoas e controles operacionais.

Resposta a incidentes de segurança

  • Garantir a ciência e atuação nos eventos de segurança no ambiente hardenizado e monitorado pelo Puppet Master.
  • Remover acessos privilegiados e desnecessários de forma contínua em servidores participantes das receitas válidas no ambiente.
  • Em caso de vulnerabilidades 0 day, o controle centralizado dos manifestos poderá agilizar o tempo de correção ou mitigação.

É isso, acho que este post é um bom começo para quem procura desenvolver o conceito do DevOps dentro da TI corporativa. Tenha em mente que além do Puppet também existem outras ferramentas de orquestração e que cada companhia tem as suas próprias necessidades.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Você pode gostar...

2 Resultados

  1. Colega, quando esse tipo de tecnologia pegar de fato, os fornecedores de serviços convencionais de outsourcing vão falir, pois vai ser impossível cobrar o que eles cobram hoje de DPP output/input com este tipo de automatização. Será o momento de reinventar a HP, IBM e outros…..

    • Isso mesmo Carlos, você entendeu muito bem o sentido e a natureza da mudança no dia a dia da operação de infraestrutura de TI. O impacto na forma de se fazer as coisas é grande, não será mais necessário fazer o deploy de ambientes etapa por etapa de forma manual, complicada e cara como fazemos atualmente.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *