Tecnologia / Artigos / O Guia Definitivo do Salt /
Parte 1

Cléber

![Saltstack](/files/95) *08/11/2018|30/11/2018* # Introdução Aqui na Dronemapp decidimos gerenciar nossa infraestrutura de computação usando uma ferramenta muito poderosa e interessante chamada “Salt”. Além da minha experiência prévia com ela, contou alguns pontos o fato de ser escrita também em Python, que é a nossa “linguagem default”, ser open source, ter uma comunidade bem ativa e possuir documentação razoavelmente boa. Do meu ponto de vista, o Salt vive um momento curioso: é bem poderoso, é conceitualmente [até] simples, é muito facilmente extensível, usa YAML e Python (que é uma das linguagens mais fáceis de se aprender), tem um projeto extremamente ativo (vide https://github.com/saltstack/salt/pulse/monthly) e é usada por empresas grandes, como Booking,com, Ubisoft e LinkedIn. Mas, ao mesmo tempo, pouco se ouve falar dele entre as comunidades de desenvolvedores. Minha impressão é que quase todo mundo já ouviu falar, por exemplo, de Puppet ou Cheff, mas quase ninguém conhece o Salt. Uma pena. Talvez uma dificuldade seja justamente a falta de bons tutoriais. Eu confesso que penei bastante para conseguir gerar uma configuração usável e útil aqui para a DroneMapp e o motivo foi que, no geral, a documentação oficial foca muito mais em informação, e não conhecimento, e os artigos são escritos, geralmente, sob o ponto de vista de pessoas que já tem fluência em sistemas de gerenciamento de configuração ou de infraestrutura. As soluções para casos de uso reais eu acabei encontrando no StackOverflow, não em tutoriais ou guias, o que parece confirmar minha afirmação de que o “ecossistema de conhecimento” em torno do Salt é mais pobre do que poderia ou deveria ser. E é por isso que estou escrevendo este artigo. O público alvo será desenvolvedores que nunca lidaram com gerenciamento de configuração ou de infra antes e que não são especialistas em nenhum provedor de infraestrutura de computação (como AWS). Meu objetivo é que, no final dessa série, você tenha conhecimento suficiente para configurar sua própria solução de gerenciamento de infraestrutura e, a partir disso, correr atrás de adaptar e melhorar isso por conta própria. # 1- O que é um sistema de gerenciamento de configurações Talvez o primeiro conceito importante que você precisa absorver é o seguinte: **Trate seus servidores como gado, não como pets.** Eu tenho um *catioro*. Ele se chama Rufus. E ele é diferente de todos os outros cachorros. Afinal, ele se chama Rufus. E é meu e da minha esposa. E eu tenho uma carteira de vacinação na gaveta da minha escrivaninha e lembro de quando ele chegou em casa, das vacinas que tomou, das “artes” que ele aprontou e sei bem como ele é apegado a nós. Isso é um pet. E um pet é diferente de **gado**. Gado é gado. Gado é 500 quilos de carne sem nome e pronto. Soa sem carinho? Pois é. Para começar a brincar de *devops* de verdade e a gerenciar infraestrutura de computação de verdade você deve despir-se desse carinho todo que você tem pelos seus servidores ou instâncias ou o que for. Quando o Rufus precisa tomar vacina nós colocamos a coleira nele, preparamos o carro (afinal, ele é meio grande…), o levamos até o veterinário e ele toma a dita cuja da vacina. Ele também é pesado (não que ele seja gordo. “Seu peso é aferido”), já aproveitamos e compramos alguma outra coisa que possa ser necessária, como um kit de limpeza do ouvido ou algo assim e voltamos para casa. É uma experiência. Quando é hora do gado tomar vacina, o gestor só supervisiona o processo, mas quem vacina o gado é um bando de terceiros e só o que importa é chegar logo no “100% vacinado”. Não tem “experiência” nenhuma aí. É só mais um dia. Da mesma forma, quando você precisa instalar algum pacote nos seus servidores, a última coisa que você deve pensar é em acessar cada um deles via SSH, instalar o tal pacote, fazer as configurações necessárias e depois ir para o próximo. Isso é enfiar o boi no carro. E não importa se você só tem cinco máquinas. Colocar um boi só no carro já é um problema! Assim, o primeiro sintoma de que você está gerenciando sua infraestrutura da maneira errada é o uso de SSH (ou scripts do Fabric) para logar nas máquinas para executar operações de gerenciamento, como instalar pacotes, alterar configurações, subir ou descer serviços ou mesmo ler logs. # 2- Infraestrutura mutável versus infraestrutura imutável Aqui na DroneMapp nós optamos por usar infraestrutura mutável, já que para nós é algo muito mais simples e exige menos tempo de implantação. Sendo bem generalista e básico, diferenciar infra mutável de imutável é simples: mutável é quando você pega uma imagem genérica (como “Ubuntu 16.04”), instala uns pacotes, altera umas configurações, sobe uns serviços, clona uns repositórios e etc, tudo “ao vivo”. Imutável é quando você transforma todas essas operações em um passo prévio e cria uma imagem ou container específicos para a sua aplicação. Por exemplo: nosso backend, o Ishikawa, é uma aplicação Django (Python) que usa PostGIS. Ele depende da instalação da biblioteca GDAL, já que trabalhamos com informações geoespaciais. O processo para que tenhamos uma máquina com o Ishikawa rodando envolve iniciar uma instância no EC2 rodando Linux, instalar o GDAL, instalar o pip (gerenciador de pacotes do Python), clonar o repositório, instalar as dependências do projeto via pip, executar a migração do banco de dados, se necessário, e rodar o gunicorn para servir a interface web. Numa abordagem de infra imutável, cada nova versão do Ishikawa dispararia a criação de uma nova imagem (uma AMI, no caso da Amazon), provavelmente gerada via Packer, e essa imagem já teria tudo pronto. Havendo uma instância rodando dessa imagem, o Ishikawa estaria rodando. Correndo o risco de ser bem polêmico, na prática eu vejo que a diferença é mínima e a implementação da geração das imagens acaba sendo meramente um passo extra mas sem tantos benefícios assim. # 3- Terminologia Se começarmos a falar sobre gerenciamento de configurações chamando a configuração do próprio Salt de “configuração”, a configuração das máquinas de “configuração” e a configuração que desejamos que as máquinas tenham de “configuração”, logo estaremos completamente perdidos. "*A configuração da configuração que altera a configuração? What?*" Precisamos de uma terminologia adequada para evitarmos confusão, e o Salt provê uma, mesmo que bem “temática”. ## 3.1- Estados e templates de estados Um estado é a descrição da situação de uma máquina. Esse estado inclui o conteúdo de determinados arquivos, quais serviços estão rodando, se um determinado repositório git está clonado localmente, devidamente atualizado e no branch certo, quais pacotes estão ou não instalados, etc. No Salt, definimos os estados via arquivos, geralmente sufixados com “.sls” (salt state) e na maioria da documentação e tutoriais que encontra-se por aí, chamam esses arquivos de “estados” ou, no melhor dos casos, de “arquivos de estados”. O fato é que essa terminologia é fraca, pois não é capaz de transmitir o conceito da melhor maneira possível. Os arquivos “.sls” do Salt são templates de estados, e você entenderá por que os chamo assim quando eu explicar como esses templates de estados são aplicados às máquinas. E por falar em “máquinas”… ## 3.2- Master e minions O termo “máquina” é ruim, pois meio que remete a uma máquina física. No Salt dividimos as máquinas/instâncias/containers em “master” e “minions”. Master ou minion pode ser teu laptop, um mainframe, uma função lambda no AWS, um container ou o que for. O Salt consegue funcionar numa arquitetura “masterless”, na qual não existe uma máquina que seja a “fonte da verdade”. Mas nesse artigo trataremos da arquitetura mais comum, já que primeiro é importante você botar a mão na massa para só depois começar a trabalhar com topologias diferenciadas. O master é a fonte da verdade: é lá que os templates de estados são salvos e é a ele que os minions obedecem e reportam. É a partir do master que você envia comandos como: “todos os minions que tem Ubuntu e são categorizados como webservers, instalem o pacote nginx e depois deixem o serviço nginx rodando” ou “todos os minions que tem Windows, desliguem-se”. O mestre mandando, os servos (minions) obedecem. ## 3.3- Grains Aqui a terminologia temática começa a transparecer. Lembra do que eu disse sobre ficar usando o termo “configuração” para tudo? Os grains ajudam a não confundir as coisas: grains são características dos minions que são coletadas pelo Salt e também definidas por você. Um minion provê grains para praticamente tudo: nome e versão do sistema operacional, hostname, interfaces de rede e seus IPs, versão do Salt, tipos de discos rígidos, flags e modelo da CPU, GPUs, tipo de init (systemd/openrc/etc), locale, et cetera. E você ainda pode definir os seus próprios grains para cada máquina. Assim que implementarmos alguma coisa você poderá ver melhor como funcionam os grains. Por agora basta você saber que eles podem te ajudar a selecionar máquinas para a aplicação de estados ou simplesmente prover informações simples sobre seu rebanho. ## 3.4- Mines, events, etc. Não se importe com isso agora. Sério, estamos para desbravar todo um novo mundo de conceitos, então não vamos tornar a experiência ainda mais complexa… # 4- salt-cloud O Salt não provia uma solução para criação de novas máquinas ou instâncias, mas focava no gerenciamento de um conjunto já existente. Até que chegou o salt-cloud, que te ajuda a gerenciar máquinas/instâncias/containers, suportando AWS, Linode, Azure, Google Compute Engine, HP Cloud, LXC, OpenStack, Rackspace, Parallels, Virtualbox, VMWare e outros. No próximo capítulo criaremos algumas máquinas usando ele. # 5- Amazon Web Services Para esta série, usarei como exemplo instâncias EC2 e configuração de serviços periféricos, como SNS e SQS. Mas, caso você não tenha interesse algum em trabalhar com AWS, não se preocupe: o que importa é você entender os conceitos. # 6- Resumo Para começar a trabalhar com Salt é necessário haver uma mudança de mentalidade: você está prestes a largar essa vida de “meu querido servidorzinho” e começar uma vida de fazendeiro. Neste artigo, começamos a conhecer os conceitos básicos que nos ajudarão a prosseguir para o próximo, no qual criaremos nossso “salt master” e nosso primeiro minion, este último já usando salt-cloud. Até lá!

Curti

56 visitantes curtiram esse Item.

Anterior: Parte 2 | Próximo: Artigos / O Guia Definitivo para construção de APIs REST