Dado o necessário para criar infraestruturas em vários ambientes enquanto garante padronização e monitoramento eficaz, torna-se crucial provisionar estes ambientes de forma segura. Para alcançar isso, adotar uma abordagem de infraestrutura imutável, na qual os ambientes são provisionados como código, é essencial.
O objetivo deste artigo é demonstrar uma abordagem possível para alcançar isso usando as estruturas do GitLab para enforcar modelos e padrões, Terraform para aplicar e manter padrões em servidores, e Ansible para aprovisionamento de software e configuração, utilizando um modelo de papéis compartilhados em repositórios. Para gerenciar o estado das máquinas com Terraform, usamos MinIO, já que ele permite essa implementação em local.
Projeto de Arquitetura
Passo 1
O processo sempre começa com a submissão de um issue padrão, especificando o modelo de pilha a ser usado, se as permissões de firewall são necessárias e se é uma configuração nova ou apenas um upgrade de recurso.
Passo 2
O operador revisa o issue e inicia o processo. Todas as conversas e tempo gasto são registrados dentro do issue.
Passo 3
Um novo projeto é iniciado no GitLab, baseado no modelo de infraestrutura que será criado. Este projeto é colocado dentro do grupo correspondente no GitLab, onde herda as variáveis de ambiente necessárias para a criação padronizada da infraestrutura.
Etapa 4
Quando o projeto é criado, você só precisa especificar os IPs para a infraestrutura ser provisionada no ambiente especificado na issue (KVM, VMware). Após o planejamento com o Terraform, os recursos necessários são criados, incluindo a adição de rótulos, se necessário, para que o Veeam realize backups com base nas políticas de rótulos. Ao final, o estado da infraestrutura criada é armazenado em um bucket.
Etapa 5
A próxima etapa envolve a execução de tarefas padrão para todos os servidores, como identificá-los, atualizar pacotes, instalar utilitários necessários e registrar o host no Zabbix para monitoramento básico do sistema operacional e do stack. Dependendo do grupo de recursos, as chaves de acesso apropriadas são atribuídas às equipes responsáveis. Por exemplo, os DBAs recebem chaves de acesso para servidores de banco de dados.
Etapa 6
Com base no modelo escolhido, é realizado o processo de instalação e configuração de todo o stack. Da mesma forma, os usuários são criados e as credenciais são registradas no Vault, quando necessário.
Etapa 7
Com a aplicação agora rodando na nova ambientação, pode-se executar monitoramento específico para cada stack, registrando o novo servidor no Consul. O Prometheus, por sua vez, identifica onde precisa coletar informações. Cada stack tem seu painel de monitoramento já configurado, variando apenas pelo nome do projeto que foi criado.
Passo 8
A nova infraestrutura é entregue ao solicitante. No caso de bancos de dados, as credenciais são fornecidas diretamente no Vault.
Estrutura do Projeto
A estrutura da pasta no GitLab está organizada da seguinte forma:
- /infrastructure/: O grupo principal, onde as variáveis de ambiente globais e valores padrão devem ser armazenadas
- /infrastructure/gitlab-models: Modelos de pipeline, onde temos dois projetos principais
- ansible-pipelines: Um projeto dedicado à manutenção dos stacks e à composição de papéis.
Na imagem acima, vemos um exemplo de tarefas comuns. Na estrutura, está localizada na pasta:/infrastructure/gitlab-models/ansible-pipelines/common-task/provision.yml
- terraform-pipelines: Pipelines para os modelos de infraestrutura disponíveis, como vSphere, KVM, AWS, etc.
Na imagem acima, temos um exemplo de uma pipeline que reside dentro do grupo terraform-pipelines, como kvm-terraform-pipeline.yml. Como podemos ver, é um modelo GitLab CI que visa ser extendido em um pipeline de stack.
- /infrastructure/templates: Neste grupo, temos os projetos debootstrap, que serão usados para criar os modelos de stack.
- /infrastructure/provision/ansible/roles: Neste projeto, temos somente as roles do Ansible, permitindo que nós centralizemos e atualizemos as roles de uma maneira isolada.
- /infrastructure/dependencies-iac: Este repositório contém as dependências do ambiente de plataforma, como Dockerfiles para Terraform e Ansible, garantindo que as versões das ferramentas e bibliotecas necessárias não sejam alteradas.
- /infrastructure/modules/: Os módulos criados para o Terraform são armazenados neste repositório, com cada projeto tendo sua respectiva pasta.
- /infrastructure/on-premise/: Este grupo é onde as infraestruturas criadas serão mantidas, e divididas por ambiente, centro de dados, stack e projeto. Na imagem, podemos ver a hierarquia de grupos e subgrupos até o projeto final. Em cada um destes níveis, podemos sobrescrever os valores das variáveis associadas com os grupos.
Como Usar uma Plataforma
Para simplificar o uso da plataforma, criamos um repositório chamado issues-ops, onde fornecemos um modelo de issue que pode ser selecionado com base em necessidades específicas. Desta forma, a solicitação de infraestrutura é registrada desde o início.
Uma vez criado o issue, a equipe DevSecOps pode começar a configurar o ambiente. Para isso, eles precisam apenas navegar até o grupo apropriado, neste caso, infrastructure/on-premise/staging/dc1/loadbalancer/nginx, e criar um novo projeto com base em um modelo. Depois, eles devem fornecer o nome do projeto a ser criado e atribuir as variáveis necessárias.
Dentro de cada modelo, o arquivo .gitlab-ci.yml necessário para a criação do ambiente já está configurado. No caso do NGINX, está definido neste formato.
Nesta configuração, ambos os modelos de criação de infraestrutura e os modelos do Ansible estão incluídos, garantindo que os papéis padrão já estão integrados a esses projetos. Além disso, fornecemos passos para extendermos o modelo. Se papéis adicionais precisarem ser instalados, você pode simplesmente adicionar o bloco correspondente, permitindo uma abordagem modular e de blocos de construção para a configuração.
Na imagem abaixo, vemos o pipeline que executou a criação do ambiente solicitado. Note que authorized_keys e common foram executados, mesmo que não fossem declarados explicitamente no .gitlab-ci.yml. Isso ocorre porque temos papéis padrão vindos do modelo Ansible importado, garantindo que os papéis padrão sejam aplicados em todos os projetos.
Conclusão
A plataforma de infraestrutura contribui consideravelmente para manter e aplicar padrões, pois exige que um modelo predefinido seja planejado, testado, implementado e tornado disponível como uma template antes que qualquer nova infraestrutura possa ser criada. Este processo garante que sempre que precisarmos de provisionar recursos em um ambiente, estamos estabelecendo padrões consistentes, versionalizando esses ambientes e garantindo que eles possam ser reconstruídos com confiança, se necessário.
Um dos principais desafios é manter os modelos atualizados e validados, especialmente à medida que as aplicações evoluem e as versões do sistema operacional mudam. É crítico lembrar que quando se usa infraestrutura como código, todas as mudanças devem ser feitas através dele, garantindo a versionalização de configurações e imutabilidade de ambientes. Não fazendo isso pode causar a reversão do ambiente para seu estado definido, potencialmente sobrescrevendo mudanças manuais.
O modelo proposto neste artigo é versátil e aplicável a ambientes tanto próprios quanto multi-nuvem, tornando-se uma solução eficaz para infraestruturas híbridas.
Source:
https://dzone.com/articles/implement-an-iac-platform-with-terraform-ansible-gitlab