Uma volta rápida ao passado

No meu tempo de estagiário eu lembro que os meus orientadores me ensinaram a administrar os serviços e os servidores que tínhamos, tudo muito cauteloso pois os recursos além de não serem nossos, eram recursos escassos e precisam atender aos alunos então cuidávamos como se fosse o nosso PET querido.

Uma das coisas curiosas daquele tempo era o processo para dar nomes às novas máquinas que chegavam ao laboratório, frases que eu lembro até hoje “Esse LAB aqui vai ter o nome dos personagens do Hantaro”, em um outro momento “Essas máquinas aqui vamos dar os nomes dos Animaniacs”, na época era um servidor do proxy, web e um servidor de e-mail, trabalhei em um lugar que os nomes seguiam a temática dos Cavaleiros do Zodíaco, chamávamos os servidores de “Pégasus, Athena, Ares, Fênix , Shiryu, etc …”. Esses são só alguns exemplos dos lugares por onde eu passei, mas conheço muitas outras histórias do tempo que as salas dos servidores eram chamadas centro de processamento de dados (CPD).

Esses modelos de nomenclaturas funcionavam e podem funcionar até hoje por causa da finalidade dos ambientes que em geral eram laboratórios pequenos, a quantidade de servidores e equipamentos eram limitados e tinham objetivos muito específicos.

Um tempo intermediário

Com o passar do tempo deixei de ser estagiário e segui a vida profissional, fui trabalhar como analista de redes e data center num provedor de serviços com presença em muitos países, alguns dos data centers possuíam mais de cinco mil hosts físicos. Diante dessa quantidade de equipamentos surge um problema, como fazer para dar nomes a todos esses servidores? Qual história ou desenho animado tem mais de cinco mil personagens?? (Nesse momento grita a voz interna do espírito de porco “Os Cavaleiros do Zodíaco: Saga de Hades!!!” :) ), mesmo esse não iria dar conta de tantos nomes para tantos equipamentos.

Nessa empresa, o modelo de nomenclatura dos servidores seguia um método mais holístico que pode ser decomposto da seguinte forma: Primeira parte, agrupamento por finalidade de atividade que eles desempenhavam, assim, os nomes possuíam a seguinte lógica: web1, db2, cache3; Segunda parte, a qual produto elas pertenciam ex: mail, news, ads. Terceira parte, seguido pela sigla do data center que elas estavam localizados ex: nys2, mia2, bra1; Por último, o domínio da empresa, empresa.com.

Como resultado final, o nome ficava dessa forma web1.mail.bra1.empresa.com ou cache8.ads.mia2.empresa.com, assim, em caso de problemas, era possível saber que a máquina de cache número 8, do serviço de ADS, no data center de Miami 2 estava com problemas, com essa técnica tinha-se um modelo muito mais escalável do que o modelo que utilizávamos nos meus tempos de estagiário.

Nos tempos atuais

Atualmente raramente lidamos com servidores físicos, gera-se instâncias em nuvens públicas ou privadas, pode-se criar e destruir-las em qualquer momento e por isso não faz sentido memorizar os nomes ou IPs das instâncias criadas, todas são iguais e com as características semelhantes como se fossem GADO de uma boiada.

Diante desse cenário, qual é a solução para o gerenciamento desse tipo de infraestrutura? Bem, para esses modelo de infraestrutura deve-se sempre pensar em um grupo de instâncias realizando um trabalho desempenhando o papel de um componente de sua aplicação. A finalidade de um grupo de máquinas é mais importante que o nome das máquinas.

Conhecendo a finalidade de cada grupo pode-se distinguir os hosts por meio de TAG ou LABEL, dessa forma a administração passa ser pensada baseada em grupos de hosts e não em um único host com nome e IP conhecido.

A partir desse modelo de gerenciamento na nuvem foi feita uma alusão ao modelo de tocar uma boiada, e, é nesse momento nasce a expressão tratar suas máquinas como gado (Cattle). Para ilustrar esse conceito veja o código de exemplo a seguir, são criadas cinco máquinas, especificando algumas características e atribuindo TAGs com informações que irão facilitar o gerenciamento e identificação do perfil de cada servidor.

 1#!/usr/bin/python3.6
 2
 3import boto3
 4import time
 5
 6machines_ids=()
 7
 8hosttags = {'fe-infra-as-code-01': 'front-end', 
 9      'fe-infra-as-code-02': 'front-end', 
10      'be-infra-as-code-01': 'back-end', 
11      'be-infra-as-code-02': 'back-end',
12      'db-infra-as-code-01': 'data-base'} 
13
14ec2 = boto3.resource('ec2')
15
16def cria_maquina(hname,htag):
17 new_reservation = ec2.create_instances(
18  ImageId='ami-02c8813f1ea04d4ab',
19  KeyName='lml_boto_aws',
20  InstanceType='t1.micro',
21  MinCount=1, 
22  MaxCount=1)
23 current_instance_id = str(new_reservation)
24 current_instance_id = (current_instance_id.split("'")[1])
25 ec2.create_tags(Resources=[current_instance_id], Tags=[{'Key':'Component_name', 'Value': hname}])
26 ec2.create_tags(Resources=[current_instance_id], Tags=[{'Key':'Component_tag', 'Value': htag}])
27
28for hname,htag in hosttags.items():
29 cria_maquina(hname,htag)

Link: Infra-as-code GitHub / Script create instances

Após a criação das instâncias, é possível verificar que as TAGs definida no script (linha 8), estão atreladas a cada um dos servidores criados. Com o script a seguir, é possível trazer todos os metadados referentes aos hosts criados.

1#!/usr/bin/python3.6
2
3import boto3 
4
5ec2 = boto3.resource('ec2')
6for instance in ec2.instances.all():
7  print (instance.id , instance.state , instance.tags)

Link: Infra-as-code GitHub / Script lista instances

Resposta com todas as TAGs e valores criadas:

i-0f9522d5296485c2d {'Code': 16, 'Name': 'running'} [{'Key': 'Component_tag', 'Value': 'front-end'}, {'Key': 'Component_name', 'Value': 'fe-infra-as-code-01'}]
i-05c3b9c11084aa8ab {'Code': 16, 'Name': 'running'} [{'Key': 'Component_name', 'Value': 'fe-infra-as-code-02'}, {'Key': 'Component_tag', 'Value': 'front-end'}]
i-09e9233befd8885bf {'Code': 16, 'Name': 'running'} [{'Key': 'Component_name', 'Value': 'db-infra-as-code-01'}, {'Key': 'Component_tag', 'Value': 'data-base'}]
i-03f41d6e65083a97f {'Code': 16, 'Name': 'running'} [{'Key': 'Component_tag', 'Value': 'back-end'}, {'Key': 'Component_name', 'Value': 'be-infra-as-code-02'}]
i-07de7b9755b30e33a {'Code': 16, 'Name': 'running'} [{'Key': 'Component_tag', 'Value': 'back-end'}, {'Key': 'Component_name', 'Value': 'be-infra-as-code-01'}]

Link: Infra-as-code GitHub / Saída script lista instances

Conclusão

Respondendo a pergunta inicial você cria GADO ou PET? Ao longo do tempo o modelo de administração de sistemas evoluiu, não só pelo aspecto da definição de nomes dos equipamentos, mas, com a oferta dos recursos de infraestrutura disponíveis para a construção de aplicações. Vou deixar uma sugestão, seja para infraestruturas locais onde todos os serviços são instalados com muito carinho e cuidado para atender finalidades específicas até um modelo de infraestrutura na nuvem onde os recursos são criadas dezenas de instâncias, utilize ferramentas de automação que possibilitem a criação de Profile, TAGs, Roles, etc… você vai estar no caminho das melhores práticas que existem hoje para administração de ambientes.

Abraços!

Vida longa e próspera a todos!!

MENTORIA

Curtiu o blog? Quer trocar uma ideia comigo sobre algum post?

Marca Aqui! É um papo gratuito oferecido para quem é leitor do blog, podemos falar de temas como: DevOps, SRE e carreira em TI.

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- --- As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.