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

Em DevOps, Sistemas operacionais por Jonathan Maia

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).

Infraestrutura que mantem seu parque de servidores manualmente

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 servidores com ferramentas de gerenciamento de configuração

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:

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!

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á):

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.

Comentários

  1. Pingback: Puppet: Subindo seus primeiros serviços e o Docker - DevOps Parte 5 - Eu na TI

  2. Pingback: Vagrant: Crie sua própria box e disponibilize-a na Vagrant Cloud - DevOps Parte 2 - Eu na TI

  3. Pingback: Puppet: Instalação e fundamentos - DevOps Parte 4 - Eu na TI

  4. Pingback: Docker e containers: Fundamentos - DevOps Parte 6 - Eu na TI - Por Jonathan Maia

Deixe uma resposta