Gerenciamento de configuração e automação de servidores – DevOps Parte 3

Quem trabalha com desenvolvimento de software já está bem acostumado com o conceito de gerenciamento de configuração, mas nem todos profissionais conhecem os benefícios do gerenciamento de configuração na infraestrutura. Neste artigo, você conhecerá os principais conceitos e ferramentas para gerenciamento de configuração e automação dos seus servidores.

Nos dois primeiros artigos sobre ferramentas de apoio a times DevOps, Vagrant: Turbine suas VMs e ambientes de desenvolvimento e Vagrant: Crie sua própria box e disponibilize-a na Vagrant Cloud, conhecemos o Vagrant e aprendemos a gerenciar máquinas virtuais de maneira automatizada e como provisioná-las utilizando Shell Script (disponibilizando todos pacotes, arquivos, configurações e serviços necessários).

Com o tempo, verificou-se que manter e aplicar scripts Shell em centenas ou milhares de servidores não era uma tarefa fácil, e começaram a nascer ferramentas específicas (e simples) para gerenciamento de configuração, automação e provisionamento. De acordo com esse excelente artigo da Digital Ocean:

Configuration management (CM) refers to the process of systematically handling changes to a system in a way that it maintains integrity over time. Even though this process was not originated in the IT industry, the term is broadly used to refer to server configuration management

Assim, o gerenciamento de configuração busca garantir que as mudanças na infra mantenham a integridade do ambiente, minimizando a possibilidade de erros em itens de configuração.

Imagine um Analista de Operações de um Google Cloud da vida. Seria completamente inviável (e enlouquecedor) manter milhares de servidores manualmente e ainda garantir que eles possuem uma configuração consistente e íntegra.

Para tanto, as ferramentas de gerenciamento de configuração e automação (também chamadas de ferramentas de orquestração), como o Puppet, Chef, Ansible e Salt, disponibilizam mecanismos para facilitar a configuração individual e coletiva do seu parque de servidores (ainda que ele seja pequeno).

O Analista de Infraestrutura que mantem seu parque de servidores manualmente

Adiante, seguem alguns dos principais conceitos e benefícios relacionados à utilização de ferramentas de gerenciamento de configuração.

Infra como código

A configuração dos seus servidores será mantida como código, podendo ser versionada em ferramentas de SCM (Source Control Management) como Git ou SVN.

Isso te possibilita criar baselines (ex: tags) para a configuração dos seus servidores, acompanhar a evolução da configuração ao longo do tempo, fazer diffs, permitir que times trabalhem paralelamente sobre os mesmos artefatos com estratégias de branches, etc.

Há algum tempo, versionar apenas o código dos sistemas era a realidade. Agora, com os Vagrantfiles, Dockerfiles, Manifests, Recipes e todos outros tipos de arquivos que nos permitem tratar a infra como código, temos a possibilidade de versionar o código da infra estrutura de servidores e dos sistemas. Não é uma maravilha ?

Provisionamento

Ao subir uma nova máquina virtual (como exemplo, com um vagrant up), você pode provisioná-la com sua ferramenta preferida de gerenciamento de configuração ao invés de utilizar Shell Script puro (como fizemos nos artigos anteriores) .

É possível, inclusive, criar camadas de abstração para suas configurações e fazer composições conforme necessário (de acordo com sistema operacional, ambiente, …). Exemplo: todos os servidores Debian possuirão configurações básicas X, enquanto todos servidores Ubuntu possuirão configurações básicas Y.

As ferramentas de gerenciamento de configuração disponibilizam mecanismos que facilitam a manutenção de tais especificidades: variáveis, condicionais, loops, classes, etc.

Escalabilidade é o ponto chave: você pode gerenciar e provisionar centenas de servidores, com suas especificidades, de maneira facilitada (não precisa conhecer os detalhes do Shell) e integrada. Esse é o ganho! Além da recuperação de desastres: o servidor morreu? Provisione outro idêntico em alguns minutos com o código mantido no teu Git. Quer provisionar 100 novos servidores idênticos ? Mamão com açúcar!

Provisionar centenas de servidores com ferramentas de gerenciamento de configuração

Formatos dos scripts/arquivos de configuração

Cada ferramenta utiliza arquivos com formatos e linguagens específicos para determinar a configuração dos servidores.

O Puppet utiliza uma DSL (Domain Specific Language), ou seja, uma linguagem própria baseada em Ruby para criar seus Manifestos ou Módulos (arquivos do Puppet).

Já o Ansible utiliza YAML para seus Playbooks (arquivos do Ansible).

O Chef utiliza Ruby para suas Recipes (arquivos do Chef).

Fique tranquilo, o formato desses arquivos é bem simples.

Idempotência

Um conceito importante é o de Idempotência:

A idempotência é a propriedade que algumas operações têm de poderem ser aplicadas várias vezes sem que o valor do resultado se altere após a aplicação inicial.

Imagine que um dos passos no provisionamento do seu servidor é inserir uma linha no final de um arquivo de configuração. Se o ambiente já estiver devidamente provisionado e o script de provisionamento for executado novamente, como ficará o arquivo de configuração ? Com duas linhas repetidas no final ? Quais serão os impactos disso ?

Mais um exemplo: se no seu script de provisionamento você sobe um serviço que já está rodando no servidor, qual será o comportamento ao tentar subi-lo novamente ? Você consegue garantir que o ambiente permanecerá estável ?

As ferramentas de gerenciamento de configuração buscam garantir a idempotência nas suas mudanças: mesmo que você provisione novamente um servidor já provisionado, o “estado desejado” será mantido. Isso é muito importante quando evoluímos os scripts de provisionamento (adicionando novas diretivas) e queremos provisionar as máquinas com o novo script: aquilo que já estava provisionado não deve ser afetado e as novas mudanças no estado devem ser aplicadas.

Idempotência: tá dominado! Mais fácil que falar a palavra idempotência!

Necessidade de clientes e servidores específicos

Ferramentas como o Puppet e o Chef demandam a existência de servidores específicos (Puppet Master e Chef Server) onde as configurações são mantidas e enviadas ou obtidas pelas máquinas a serem configuradas. Também é necessário instalar clientes (pacotes específicos) nas máquinas a serem configuradas.

Já o Ansible possui uma abordagem diferente: qualquer máquina pode atuar como um Controller pois ele se conecta às outras máquinas por SSH para efetuar as configurações. Também não é necessário instalar clientes específicos para o funcionamento do Ansible (basta que o SSHD esteja rodando na máquina a ser configurada, o que já é o padrão no Gnu/Linux).

Abstração

Claro que não é possível abstrair todos os detalhes do Sistema Operacional, mas dá uma olhada nesse exemplo de um trecho de manifesto do Puppet:

$ssl = $operatingsystem ? {
  solaris => SMCossl,
  default => openssl
}

package { 'openssl':
  ensure => installed,
  name   => $ssl,
}

Especificamos que o pacote $ssl precisa estar instalado (ensure => installed) através do recurso package.

Observe que o nome do pacote ($ssl) é setado condicionalmente de acordo com o sistema operacional (se for Solaris o nome será SMCossl, caso contrário será openssl).

O mais legal: não precisei dizer se o pacote será instalado por apt-get ou por yum. O Puppet vai reconhecer o provider do sistema operacional e fazer a instalação do pacote $ssl de maneira transparente.

Comparação das ferramentas populares

Agora, já dominando os conceitos básicos, dê uma olhada nesse excelente quadro comparativo elaborado pela Digital Ocean (sem jabá):

Fonte: Digital Ocean

No mundo de Docker, quando usar ferramentas de gerenciamento de configuração ?

Uma pergunta que me fizeram recentemente: num mundo de Docker, onde já tenho diversas imagens prontas com os serviços já configurados (o artigo sobre Docker chegará em breve), quando utilizarei uma ferramenta específica de gerenciamento de configuração ?

Se sua empresa ou órgão possui infra estrutura própria, como você vai configurar o Docker Server ? Na mão ? Ou então, se você já utiliza soluções de orquestração de containers, como o Docker Swarm ou Kubernetes, como você vai configurar os nós do seu cluster ? Manualmente ? Utilize ferramentas de gerenciamento de configuração para isso.

Além disso, para replicar teu ambiente de containers nas máquinas dos desenvolvedores, como você fará para mantê-lo o mais próximo possível da sua homologação e produção ? Vai fazer na mão também ?

Minimize os riscos e deixe os ambientes de desenvolvimento idênticos aos ambientes produtivos. Quando abordarmos o Docker em um próximo artigo, utilizaremos uma solução integrada com Vagrant + Puppet + Docker para montar uma máquina de desenvolvedor. Tudo vai se encaixar!

Conclusão

Agora, com os fundamentos já construídos sobre o gerenciamento de configuração de servidores e sobre o gerenciamento de máquinas virtuais com Vagrant, estamos prontos para abordar o Puppet na próxima postagem!

Próximos artigos:

Puppet: Instalação e fundamentos – DevOps Parte 4

Puppet: Subindo seus primeiros serviços e o Docker – DevOps Parte 5

Docker e containers: Fundamentos – DevOps Parte 6

Espero que você tenha gostado! Agradeço se você puder curtir e compartilhar esse artigo em suas redes sociais.

Curta nossas páginas nas redes sociais para acompanhar novas postagens.

Em breve, mais conteúdos de qualidade para você aqui no Blog Eu na TI, o seu Blog sobre Tecnologia da Informação.

Um forte abraço e até mais.

Jonathan Maia

Olá, sou Jonathan Maia, marido, pai, apaixonado por tecnologia, gestão e produtividade. Ocupo o cargo de Secretário de Tecnologia da Informação e Comunicação do Tribunal Regional do Trabalho do Ceará (TRT7) desde 2021, onde ingressei como servidor público federal (analista de TIC) no ano de 2010. Fui diretor da Divisão de Sistemas de TIC do TRT7 entre 2018 e 2020 e também tenho experiência prévia na Dataprev, Serpro e Ponto de Presença da Rede Nacional de Ensino e Pesquisa (RNP) no Ceará.

Graduado em ciências da computação pela Universidade Federal do Ceará e especialista em gerenciamento de projetos de TIC pela Universidade do Sul de Santa Catarina. Detentor das certificações em gestão e inovação: Project Management Professional © (PMP), Professional Scrum Master II © (PSM II), Professional Scrum Master I © (PSM I), Professional Scrum Product Owner I © (PSPO I), Kanban Management Professional © (KMP II), Certified Lean Inception Facilitator® (CLF), ISO 31000:2018 Risk Management Professional © e Project Thinking Essentials.

Desenvolvedor Full Stack, possuo experiência em diversas arquiteturas / plataformas de desenvolvimento. Já tive experiências profissionais em redes metropolitanas de alta velocidade (GigaFOR/RNP), business intelligence, desenvolvimento de sistemas, gestão de projetos e produtos, governança, etc. Experiência em dezenas de projetos com abordagens de gestão ágeis, híbridas e tradicionais, incluindo projeto com menção honrosa no Prêmio de Excelência em Governo Eletrônico (e-Gov).

Com dezenas de turmas de capacitação, oficinas ou palestras ministradas nas temáticas de gestão ágil, gestão de projetos, tecnologia, inovação e produtividade nas seguintes instituições: Conselho Superior da Justiça do Trabalho (CSJT), Tribunal de Justiça do Distrito Federal e Territórios (TJDFT), Tribunais Regionais do Trabalho do Ceará (TRT7), Pará e Amapá (TRT8), Sergipe (TRT20), Rio Grande do Norte (TRT21), Tribunais Regionais Eleitorais do Ceará (TRE-CE), Mato Grosso do Sul (TRE-MS) e da Bahia (TRE-BA), Justiça Federal em Sergipe (JF-SE), Justiça Federal no Ceará (JF-CE), Companhia Siderúrgica do Pecém (CSP), Instituto Federal do Ceará (IF-CE), Instituto Federal do Rio Grande do Norte (IF-RN), Banco do Nordeste do Brasil (BNB), Gagliardi (Mobil), Udemy, Companhia Cearense de Gás (CEGÁS), Agile Trends Gov, Project Management Institute (PMI-CE), Cagece, Faculdade Estácio e Associação de Gerenciamento de Projetos do Mato Grosso do Sul (AGPMS).

www.eunati.com.br