Tradicionamente, servidores eram instalados um por um nos data centers. Cada servidor precisava de horas (senão dias) pra ficar pronto. O trabalho do sys admin era colocar o casaco de pele, entrar no data center equipado com um caderno e um cd-rom, achar o servidor em questão e instalar o sistema operacional a partir do CD, configurar o básico para ter rede e acesso SSH pra depois poder voltar para sua mesa e terminar a configuração.

Além de consumir muito tempo, essa tarefa era extremamente propensa a falhas. Como o CD-ROM poderia estar arranhado ou pior, sem querer instalar na máquina errada.

Com a virtualização, a vida do sys admin ficou muito mais fácil. Agora bastava instalar o hypervisor (VMware, Xen) na máquina e o resto dos servidores eram todos gerenciados remotamente por uma interface gráfica. Facilmente pode-se detectar problemas de hardware, dimensionar o servidor para o hardware que este precisa, e instalar novos servidores passou a ser feito através de imagens. Mais tarde surgiram ferramentas para gerar imagens já pre-configuradas com os pacotes instalados o que facilitou ainda mais.

A virtualização foi evoluindo e os hypervisors rapidamente viraram plataformas complexas que conseguem simular até topologias complexas de rede. Os hypervisors também passaram a possuir APIs que permitem controlar toda a infraestrutura virtual com programas – scripts interagindo com essa API, abrindo as portas para criar sistemas que podem reagir automaticamente conforme a demanda ou falhas no hardware.

É então que chega a tão famosa “nuvem”. Computação na nuvem é nada menos do que um ambiente virtualizado onde clientes podem alugar máquinas virtuais por hora e interagir com as mesmas através de uma API. Claro que isso foi bem no começo, logo esses serviços de nuvem criaram outros produtos que suprem quase todas as necessidades computacionais de uma empresa, tudo pago por hora (ou por GB) e interagido por APIs.

Finalmente atingimos um ponto onde infraestruturas complexas que antes requeriam centenas de horas-homem para montar, além de comprar hardware caríssimos, espaço em data center, links de fibra ótica, etc, podem ser criadas e gerenciadas com alguns clicks usando provedores como AWS, Rackspace ou Azure.

Mas e o sistema operacional, acompanhou essa mudança?

Desde o início dessa jornada até hoje, o sistema operacional mais utilizado nesses ambientes, o Linux, pouco mudou. Certamente houveram melhorias no kernel para suportar virtualização melhor mas em termos de instalação e configuração, isso ficou na mão das distribuições como Ubuntu e RedHat que pouco fizeram para acompanhar a evolução pra nuvem que tem ocorrido.

Foi então que surgiram ferramentas para gerenciar configuração como Puppet, Chef e Ansible. Essas ferramentas tem como propósito garantir que os servidores estejam em um certo estado de configuração baseado em regras pre-definidas. Em outras palavras, toda a configuração do servidor é reduzida a poucas linhas de código e a ferramenta irá periodicamente checar se a configuração dos servidores está de acordo com esse código, se não estiver, a configuração é alterada para esse estado.

Um exemplo mais prático seria a criação do código que define o estado de um servidor web. O que um servidor web precisa?

  1. Apache precisa estar instalado
  2. A pasta /var/www/htdocs precisa existir e pertencer ao usuário www-data
  3. Apache precisa estar rodando

Essas 3 regras que eu defini arbitrariamente acima descrevem um estado e poderiam ser escritas como código para Ansible utilizar.
Quando Ansible é executado e as regras acima são carregadas, este funciona dessa maneira:

Apache está instalado?
Se sim: Ok, não faz nada.
Se não: Instale apache e marque o estado 1 como alterado.

E por ai vai. Ansible (e outras ferramentas) só alteram o que precisa ser alterado, então mesmo que este seja executado 2 vezes consecutivas, o Apache não será instalado 2 vezes mas só na primeira. Essa propriedade se chama “idempotent” ou idempotência em português (http://pt.wikipedia.org/wiki/Idempot%C3%AAncia)

Voltando ao Linux.

Ferramentas de gerenciar configuração estão uma camada acima do sistema operacional, ao traduzir as regras de configuração para ações a ser executadas, precisam levar em conta fatores como a distribuição Linux que afeta onde os arquivos de configuração se encontram e o gerenciador de pacotes utilizado. Instalar apache no Ubuntu é diferente do RedHat até no nome do pacote. Isso causa problemas e uma complexidade que essas ferramentas até então tem realizado um bom trabalho em abstrair.

Dado a maturidade dessas ferramentas e dos provedores de computação na nuvem atuais, o trabalho do sys admin tem mudado radicamente. Uma analogia com um operário em uma fábrica de carros, antes este instalava as partes manualmente e apertava os parafusos um por um e agora passa o seu tempo escrevendo rotinas para um braço mecanico executar essas tarefas nos carros automaticamente. A configuração inicial leva mais tempo para desenvolver e precisa de ajustes conforme os modelos dos carros são atualizados, mas a automação permite que um operário monte vários carros ao mesmo tempo, limitado apenas pelos recursos da fábrica.

Porém diferente do operário da fábrica de carros que provavelmente vai causar a demissão de seus colegas por conta da automação e ser processado pelo sindicado, o sys admin que sabe automatizar a criação e configuração de servidores consegue gerenciar um número muito maior de servidores e com menos problemas, já que tudo é padronizado e monitorado com as APIs.

Espero que esse artigo tenha ajudado você a entender um pouco da situação atual e como podemos atingir uma eficiência maior utilizando as tecnologias atuais.

Leave a Reply

Your email address will not be published. Required fields are marked *