This project has been created as part of the 42 curriculum by wil.

Inception

Description

Inception é um projeto de administração de sistemas que consiste em montar, do zero, uma pequena infraestrutura web usando Docker e Docker Compose. O objetivo é entender como containers funcionam por baixo dos panos (isolamento via namespaces do kernel, gerenciamento de processos, redes virtuais) e aplicar boas práticas de configuração, segurança e persistência de dados.

A infraestrutura final é composta por três serviços, cada um rodando em seu próprio container, construído a partir de um Dockerfile escrito à mão (nenhuma imagem pronta foi utilizada, exceto a imagem base do sistema operacional):

• NGINX — único ponto de entrada da infraestrutura, servindo HTTPS (TLSv1.2/1.3) na porta 443.
• WordPress + php-fpm — aplicação web, sem servidor HTTP embutido (o NGINX faz proxy reverso via FastCGI na porta 9000).
• MariaDB — banco de dados relacional usado pelo WordPress.

Os dados do banco e os arquivos do site são persistidos em volumes Docker, montados via bind mount em /home/wil/data/ no host.

Escolhas de design e comparações

Máquina Virtual vs Docker Uma VM virtualiza hardware inteiro (kernel próprio, boot completo), o que é mais pesado e mais lento para subir. Docker usa isolamento em nível de processo via namespaces e cgroups do kernel Linux, compartilhando o mesmo kernel do host — por isso containers sobem em segundos e consomem muito menos recursos. A troca é isolamento: uma VM isola até o kernel; um container isola processos, mas todos compartilham o kernel do host.

Secrets vs Variáveis de Ambiente Variáveis de ambiente (.env) ficam visíveis em texto claro para qualquer processo que inspecione o container (docker inspect, /proc/1/environ) e podem vazar em logs. Docker secrets são montados como arquivos somente leitura em /run/secrets/, fora do docker inspect, e nunca ficam gravados na definição do container. Por isso, neste projeto, apenas configurações não sensíveis (domínio, nomes de usuário, título do site) vão no .env; senhas e credenciais vão exclusivamente em secrets.

Docker Network vs Host Network network: host faz o container compartilhar o namespace de rede do host inteiro — sem isolamento nenhum, e com risco de conflito de portas. Uma rede Docker dedicada (bridge) cria um namespace de rede isolado por container, com resolução de DNS interna pelo nome do serviço (ex: o NGINX fala com wordpress:9000 sem precisar saber IPs). Este projeto usa uma rede bridge customizada (inception), nunca host.

Docker Volumes vs Bind Mounts Nesse projeto usamos volumes Docker configurados com driver: local e driver_opts apontando para um bind mount específico (/home/wil/data/...), unindo as vantagens de ambos: o Docker gerencia o ciclo de vida do volume, mas os dados ficam visíveis e acessíveis diretamente no filesystem do host, como o enunciado exige.

Instructions

Ver DEV_DOC.md para o passo a passo completo de configuração e build, e USER_DOC.md para como acessar e usar o site depois de rodando.

Resumo rápido:

Copiado
git clone <repo>
cd inception
# preencher srcs/.env e secrets/*.txt (nao versionados)
make

Resources

• Documentação oficial do Docker: https://docs.docker.com
• Documentação oficial do Docker Compose: https://docs.docker.com/compose
• WP-CLI Handbook: https://make.wordpress.org/cli/handbook
• man pages: docker(1), docker-compose(1), nginx(8), mysqld(8)
• man 7 namespaces, man 2 unshare, man 2 clone — para entender o isolamento por baixo dos containers (PID, mount, UTS, net namespaces)

Uso de IA neste projeto

Utilizei um assistente de IA (Claude) principalmente para:

• Entender conceitualmente como namespaces do Linux funcionam por baixo do Docker (PID, mount, UTS, net), incluindo experimentação prática com unshare/chroot num ambiente de testes, para consolidar o entendimento antes de aplicar no projeto.
• Estruturar um roadmap de implementação por serviço (MariaDB, WordPress+php-fpm, NGINX), incluindo esqueletos de entrypoint scripts.
• Gerar scripts de teste de conformidade (test-mariadb.sh, test-wordpress.sh, test-nginx.sh) para verificar regras objetivas do enunciado (PID 1, ausência de hacks como tail -f, versões de TLS aceitas/rejeitadas, persistência de volumes).
• Montar o esqueleto do docker-compose.yml, Makefile e arquivos de configuração (.env, secrets) como ponto de partida.

Todo o código gerado foi revisado, testado e adaptado manualmente antes de ser incorporado ao projeto. Nenhum trecho foi copiado sem entendimento do que faz.