Infraestrutura como código (IaC) é uma prática de desenvolvimento de software que se enquadra na abordagem DevOps. Ela envolve a automação e gerenciamento da infraestrutura de um sistema de computador usando código, assim, as tecnologias empregadas neste tutorial, em conjunto o Vagrant, o Ansible e o Docker fornecem uma poderosa combinação de ferramentas para a criação, provisionamento e implantação de infraestrutura e aplicativos como código. Eles permitem definir, compartilhar e gerenciar toda a pilha de infraestrutura, desde a configuração do sistema até a execução de aplicativos, de forma automatizada e escalável.
A base deste tutorial consiste basicamente no provisionamento de servidores Linux bem como algumas configurações de gerenciamento de disco, hardening Linux, BIND9, Nginx e Apache. A seguir, temos uma imagem que ilustra a arquitetura do cenário proposto.
Comentando com mais detalhes, temos:
- Instalação e configuração realizadas no Virtual Box, utilização do sistema Debian versão 11 bullseye64, adição de 3 HDs de 10GB para o gerenciamento de disco no Server-Veridis, adição de 2 interfaces de rede para o Server-Veridis e Server-Statusquo.
- O gerenciamento de disco compreendeu o uso de 3 discos para redundância completa dos dados, onde no Server-Veridis foram criadas as seguintes partições: /dados/www (Tipo ext4, 2 Gbits) /dados/jornal (Tipo ext4, 3 Gbits) Em seguida, foram criados RAID para cada partição. Por fim, foi criado um LVM para cada RAID, sendo para /dados/www e /dados/jornal.
- Com relação aos Requisitos de Rede foi feita a configuração dos 3 primeiros endereços IPs da 2ª subrede de 8 IPs da faixa 200.200.200.32/27 para a inteface WAN. Para a interface LAN foi utilizada a rede 10.0.128.0/23.
- No Server-Veridis, para a segurança de Acesso ao Sistema foram implementados os procedimentos de: Acesso remoto permitido somente por meio de chaves de criptografia assimétrica, Restrição de acesso local para o usuário root, Acesso local permitido apenas para o usuário suporte, Configuração do tempo de inatividade para realizar logout automático após 5 minutos de inatividade, Acesso de super usuário deve ser realizado com o comando sudo.
- Para o Serviço DNS foi configurado o serviço de DNS primário para responder pelo domínio abranteme.com.br. Foram definidos os seguintes requisitos: TTL máximo padrão dos registros: 24h, fácil identificação da última alteração no arquivo de zona, verificação de alterações no servidor primário a cada 1 hora pelo servidor secundário (slave), configuração de 2 views: View Externa: Atendimento de requisições de DNS apenas da interface WAN, registros: DNS Primário (ns01.abranteme.com.br), DNS Secundário (ns02.abranteme.com.br), Portal WEB (www.abranteme.com.br), Aplicação 01 (app01.abranteme.com.br) e Aplicação 02 (app02.abranteme.com.br). Na View Interna: Atendimento de requisições apenas da LAN, permitir uso como servidor recursivo, registros: DNS Primário (ns01.abranteme.com.br), Portal WEB (www.abranteme.com.br), Aplicação 01 (app01.abranteme.com.br) e Aplicação 02 (app02.abranteme.com.br).
- Para o Serviço WEB foi utilizado no Server-Veridis o Nginx como Proxy WEB e Load Balancer para os serviços. A comunicação entre cliente e Nginx (Internet - Interface WAN) obrigatoriamente via HTTPS, e entre Nginx e Apache apenas HTTP. A configuração do Apache (Server-Statusquo) foi realizada com os seguintes requisitos: Atendimento de requisições na porta 8000, Impedimento de listagem de conteúdo de diretórios pelo acesso WEB, Não permitir criação de links simbólicos, Configuração de 2 virtual hosts: app01.abranteme.com.br: Diretório do site: /dados/www/app01, Adição de arquivo index.html para testes do "App01", app02.abranteme.com.br: Diretório do site: /dados/www/app02, Adição de arquivo index.html para testes do "App02", Acesso com autenticação do usuário "jornalista" ao diretório para obtenção dos arquivos postados, Leitura do conteúdo do diretório do serviço SFTP (/dados/jornal) pelo Apache.
- Ao acessar app02.abranteme.com.br/jornal, com usuário e senha "abranteme" é possível ter acesso aos arquivos de log de teste da autenticação do usuário. Esse diretório está localizado no container statusquo-apache em /dados/www/app02/jornal, enquanto que os arquivos de logs estão sendo compartilhados a partir de um volume criado via docker-compose na VM Server-statusquo no diretórior /home/vagrant/reports
- Para o Serviço SFTP foi configurado o servidor OpenSSH para atender requisições SFTP na porta 22, com os seguintes requisitos: Criação de usuário "jornalista" com acesso ao diretório /dados/jornal.
A estrutura do tutorial envolvendo o Vagrant e o Ansible e o Docker está ilustrada na imagem abaixo. Foram configurados três máquinas virtuais a partir do arquivo vagrantfile, sendo elas: Server-Veridis, Server-Statusquo e Client-Host. Em seguida, para cada uma das máquinas virtuais o ansible é inicializado a partir dos arquivos de configuração playbook.yml, que por sua vez envia o arquivo docker-compose.yml para dentro de cada uma das VMs. Por fim, para as VMs Server-Veridis e Server-Statusquo o docker é utilizado para a criação de containers dos serviços de DNS, Nginx e Apache a partir das imagens que foram anteriormente criadas mediante modificação de acordo com as necessidades para atender os requisitos do tutorial. A VM do Cliente-Host é utilizada para testar a parte do acesso remoto ao servidor Veridis, bem como o serviço de SFTP.
Para a criação do pipeline CI/CD foi utilizado o GitHub Actions, que é uma ferramenta de integração e entrega contínua incorporado ao GitHub. A branch "dev" foi configurada para ser a branch de teste, onde a build das imagens Docker (CI) são realizadas e encaminhadas ao registry (CD). A pipeline foi configurada para executar as seguintes etapas:
-
Build das imagens Docker: É responsável por construir a imagem docker do servodpr DNS Primário e Secundário, do servidor proxy Nginx para requisições LAN e WAN e por fim do servidor web Apache que contém os virtual hosts para os serviços app01 e app02.
-
Testes dos Serviços: São realizados com o auxílio de scripts que verificam se os serviços do BIND9, Nginx e Apache estão ativos e respondendo corretamente através dos containers criados a partir das imagens Docker da etapa anterior.
-
Vulnerabilidades: Após os testes é iniciado a análise de vulnerabilidades com o auxílio da ferramenta Trivy, que é um scanner de código aberto para imagens e artefatos de contêiner.
-
Push: Após a conclusão das etapas anteriores, as imagens são encaminhadas ao registry Dockerhub para que possam ser baixadas e utilizadas no tutorial.
Após o push das imagens para o registry, é necessário de um processo para automatizar as atualizações dos containers que estão em execução nas VMs. Para isso, foi utilizado o serviço Watch Tower, que irá baixar a nova imagem, remover o container antigo e iniciar um novo container com as mesmas opções que foram usadas inicialmente. O Watch Tower é executado a partir dos arquivos docker-compose, que estão configurados para monitorar em um intervalo de 5 minutos, caso seja identificado uma nova versão o Watch Tower irá baixar a nova imagem e reiniciar o container. Com isso, finalizamos o pipeline de CI/CD com integração, entrega e deploy contínuo. A imagem abaixo ilustra todo esse processo.
-
É necessário que o provider de virtualização, o Vagrant e o Ansible estejam instalados na máquina real. Para isso siga as instruções de instalação, que pode ser encontrado aqui: VirtualBox, Vagrant, Ansible
-
O ambiente foi provisionado e testado a partir das seguintes versões: Sistema operacional Ubuntu 20.04.6 LTS (Focal Fossa), VirtualBox 6.1.26, Vagrant 2.3.4 e Ansible 2.12.10.
Importante: Caso opte por usar outra distribuição Linux, esteja seguro que conhece bem o gerenciador de pacotes, sistema de arquivos e comandos que sejam necessários para resolver eventuais imprevistos que possam ocorrer na sua opção GNU/Linux, você será responsável pelo troubleshooting da distribuição que escolher. Se você não está totalmente seguro, sinta-se a vontade para baixar e utilizar a VM já configurada e testadas acessando aqui: VM DevOps
- Antes de começar, certifique-se de adicionar no arquivo hosts da máquina real a seguinte linha de configuração:
192.168.57.7 www.abranteme.com.br www.app01.abranteme.com.br app01.abranteme.com.br www.app02.abranteme.com.br app02.abranteme.com.br- Os serviços podem ser inicializados a partir do comando abaixo:
# Clone este repositório
$ git clone https://github.com/abrantedevops/Network-Services-Structure.git
# Acesse a pasta no terminal/cmd em que está o arquivo Vagrantfile
$ cd detools
# Para criar todas as máquinas virtuais e executar o tutorial
$ vagrant up
# Após a finalização do processo, basta acessar os endereços abaixo com http ou https para testar os serviços:
www.abranteme.com.br
app01.abranteme.com.br
app02.abranteme.com.br
app02.abranteme.com.br/jornal
# Para acessar o servidor Veridis, Statusquo ou Client-Host a partir da máquina real, utilize os seguintes comandos:
$ vagrant ssh veridis
$ vagrant ssh statusquo
$ vagrant ssh client
# Para o acesso remoto ao servidor Veridis foi criado um par de chaves de criptografia assimétrica, logo de dentro da VM Client-Host alterne para o usuário suporte e acesse o servidor Veridis com o comando abaixo:
$ su suporte
$ passord: 1234
$ ssh suporte@10.0.128.1
# Do mesmo modo, para testar o serviço SFTP, pode ser utilizado o comando abaixo a partir da VM Client-Host:
$ su jornalista
$ password: 1234
$ sftp jornalista@10.0.128.1
# Caso queira criar apenas uma das máquinas virtuais:
$ vagrant up veridis
$ vagrant up statusquo
$ vagrant up client
# Atenção: Como em toda execução do Vagrantfile são criados discos rígidos virtuais (destinados ao gerenciamento de disco) na VM Veridis, caso queira levantar novamente as VMs, é necessário executar o comando abaixo para não dar erro de disco já existente:
$ vagrant destroy -f- VirtualBox
- Vagrant
- Ansible
- Docker
- Docker Compose
- Repositório Docker Hub
- Nginx
- Apache
- Bind9
- Visão Geral das Imagens
- Trivy
- GitHub Actions
- Robot Framework
- Watchtower
MIT License
Copyright (c) 2012-2024 Thiago Abrante de Souza
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.