Olá, seja bem-vindo a unidade três da nossa disciplina de gerenciamento de mudanças, configuração e infraestrutura do nosso curso de especialização em engenharia de vops do IFMT. Eu sou o professor Valdinei Bispo e nesta aula nós vamos tratar de gerenciamento de configuração com ANIB. Nas unidades anteriores, nós construímos uma boa base sobre o gerenciamento de mudanças, configuração e infraestrutura.
falamos de um problema antigo da documentação, dos frameworks e falamos também dessa nova visão a respeito, desse novo paradigma a respeito do DevOps, que é a infraestrutura gerenciada ou IAC o infraestrutura como código. Na unidade dois, nós colocamos a mão na massa e com o Terraform nós aprendemos a provisionar a nossa infraestrutura como código. Agora na unidade três, o nosso foco se volta para o Anball, uma ferramenta que vai configurar aí os servidores, vai dar vida aí aos seus servidores, aos seus ativos.
é uma forma de configurar os seus ativos como código. E na próxima unidade ainda nós vamos tratar de da consolidação dessa coisa toda, do versionamento da da verdadeira fonte da verdade que é o nosso código. Ao final da unidade dois, uma pergunta ficou importante no ar ali.
O Terraform nos entregou uma máquina virtual nova, mas eh ela é apenas uma casca vazia, digamos assim, embora tenha o sistema operacional, eh, e para que ela funcione, mas como que a gente pode transformar essa máquina em algo funcional, um servidor pronto para a produção? Então, nós precisamos instalar aplicações, configurar serviços, aplicar políticas de segurança e garantir que todos os servidores estejam consistentes. E, é claro, fazer tudo isso de forma automatizada.
Bom, é importante a gente considerar que há sim um overlap, uma sobreposição entre o Terraform e o Anible. Sabemos que algumas funcionalidades podem ser executadas tanto por uma ferramenta quanto com a outra. Mas essa sobreposição não é o objeto do nosso estudo nesse momento.
O objetivo de apresentar uma nova ferramenta é demonstrar a amplitude do ecossistema de infraestrutura como código e como elas se especializam. No caso, Terraform no provisionamento e o Anibo. Então, para começar, o que que é Anib?
Então, é uma ferramenta de código aberto mantida pela Redhead, que automatiza o provisionamento de software, o gerenciamento de configuração e a implantação de aplicações. Ela se baseia em três pilares fundamentais: a Gentless, né, que se comunica por SSH sem a necessidade de instalar agentes. Vamos falar um pouco mais ainda sobre isso.
Ela é declarativa, focando no estado final que desejamos e ela é idotente, que significa garantindo que a execução repetida do mesmo código produza sempre o mesmo resultado. Essa abordagem declarativa é uma mudança de paradigma. A abordagem tradicional, a imperativa foca no como fazer com um passo a passo frágil que pode falhar e e se o estado já existir ou se alguma coisa der errada.
Já a abordagem declarativa do ânseb foca no o que queremos. Você simplesmente declara o estado final desejado e o âns se encarrega de verificar eh o sistema e aplicar apenas as mudanças necessárias para atingir aquele objetivo. Essa característica nos leva ao conceito de idem potência que garante consistência.
Executar a mesma operação múltiplas vezes produz exatamente o mesmo resultado. Isso traz segurança, previsibilidade e confiabilidade, sendo ideal para ambientes de produção críticos. Como vemos no no exemplo, na primeira execução, as tarefas são executadas e o estado é alterado.
Na segunda, o ânsbo reconhece que o estado desejado já foi alcançado e não faz nenhuma alteração. E como mencionamos também, já falamos ali atrás, o Bell é a gentless. Eh, ele não exige a instalação de um software cliente em cada servidor.
Toda a comunicação é feita através do protocolo padrão SSRH, o que simplifica enormemente a manutenção e aproveita a infraestrutura infraestrutura de segurança que já existe no seu ambiente. A medida que a automação cresce, a organização é crucial. O padrão Rolles é uma abordagem mais comum para projetos complexos.
Eh, uma RLE é uma estrutura padronizada que encapsula toda a automação eh de uma função específica, eh, como configurar um servidor web, por exemplo. Isso promove a reutilização do código e simplifica a manutenção e permite o o compartilhamento de automações. Para fins didáticos ou para processos mais lineares, nós temos o padrão de tarefas.
tá aqui, a gente organiza tudo. Eh, eh, o fluxo ele é organizado em múltiplos arquivos numerados, eh, podendo ou organizado de uma outra forma, né, onde cada um representa uma etapa sequencial. Essa abordagem oferece uma clareza pedagógica imensa para podermos entender o que está acontecendo, porque permite seguir passo a passo a automação de forma muito evidente.
Mas se nós fizermos uma comparação, então e qual padrão que eu devo usar, né? A a decisão vai depender aí do do contexto, né? Essa tabela que compara os dois, dá pra gente ter uma ideia, roles são excelentes para reutilização e escalabilidade em projetos complexos.
enquanto as tarefas eh são mais simples e intuitivas, ideais para projetos menores ou para o aprendizado mesmo, né? Para o mercado, Roles é o padrão mais realista para o ensino. Tarefas é mais eh eficiente didaticamente, que nós usamos mais para para simplificar o processo de compreensão.
Em nosso primeiro caso prático, né, nós usaremos o padrão Rolles, que para configurar um servidor web completo com o servidor de paja Jinx. O objetivo é gerenciar pacotes, serviços e arquivos de forma modular. O playbook principal é permanece limpo e legível, enquanto toda a complexidade da instalação e configuração do Jinx fica isolada dentro da RUL.
Agora vamos unir as duas unidades. O terraform da unidade do provisiona a infraestrutura, o hardware. O Answidade 3 entra para configurar o software.
Juntos eles formam uma dupla perfeita para automação completa do hardware ao software. Mas fica uma pergunta, né? Como que o Anbo descobre as máquinas que o Terraform acabou de criar?
No exemplo que nós vamos fazer, eh, vamos no nosso teste, eu vou estar informando o IP, eh, que foi atribuído pra máquina, mas na no mundo, num ambiente de produção, as respostas está aí no inventário dinâmico. Em vez de listas estáticas de IPs que são impraticáveis na nuvem, né, usamos scripts que consultam a API do provedor em tempo real. Eh, e o Terraforme etiqueta os recursos que cria e os scripts de inventário usa essas tags para gerar lista de servidores para o Anibaticamente.
No nosso segundo caso prático, nós vamos usar o padrão de tarefas para instalar um servidor Redminer. A abordagem sequencial enumerada nos permitirá acompanhar cada passo do processo, desde a atualização do sistema até a configuração final dos serviços, reforçando os conceitos de forma clara e didática. Aqui nós podemos ver eh esse aqui é o fluxo completo do código a infraestrutura.
Começa com o código Terraform, que é executado para provisionar uma máquina virtual, um AVM. Em seguida, o inventário dinâmico descobre essas novas VMs. O Ans então entra em ação para configurar o software.
O resultado é uma infraestrutura completa, funcional, tudo em questão de minutos. As vantagens dessa automação são imensas: velocidade, consistência, escalabilidade, rastreabilidade, pois tudo é código, recuperação, né? recuperação rápida em caso de desastres e documentação viva.
Estamos transformando a forma como operamos a infraestrutura de um processo artesanal para um processo industrial. com a infraestrutura e a configuração eh agora transformadas em código, você está preparado para o próximo passo. Na unidade 4, nós vamos mergulhar no conceito de GitOps, eh, tratando o código como a única fonte da verdade para o estado do nosso sistema.
Veremos como que o IAC se integra a pipelines de CCD, consolidando definitivamente a cultura de VOPS na infraestrutura. Continue se dedicando aos estudos. Explore a documentação oficial do Ansbo.
Pratique com os exemplos do curso. Olhe o repositório, veja os códigos, execute, participe ativamente dos nossos fóruns de dúvidas, né? Automação é uma habilidade essencial e você está no caminho certo para dominá-lo.
Nos vemos na próxima unidade.