Para executar os desafios, você deve ter instalados:
- Docker Engine: Versão 20.10.0 ou superior.
- Docker Compose: Versão v2.0.0 ou superior.
- Git: Para clonar o repositório.
-
Clonar o Repositório:
git clone [LINK DO SEU REPOSITÓRIO] cd nome-do-seu-projeto -
Configurar Variáveis de Ambiente (Desafios 2 e 3): Crie o arquivo
.envnas pastasdesafio2/edesafio3/para que os serviços de banco de dados iniciem corretamente.- Importante: O arquivo
.envé ignorado pelo.gitignorepor razões de segurança, mas é necessário para a execução local.
- Importante: O arquivo
-
Executar Individualmente: Navegue até a pasta do desafio desejado (
cd desafioX/) e utilize o comandodocker compose up -d.
Este desafio demonstra o DNS interno provido por uma rede customizada do Docker.
- Rede:
desafio-1(Driverbridge). - Serviço 1 (Servidor):
servidor-web(Imagem Nginx, porta 80 interna). - Serviço 2 (Cliente):
cliente-curl(Imagem Alpine), que executa um scriptcurlem loop apontando para o hostnameservidor-web.
A comunicação é feita diretamente pelo nome do serviço, provando que a rede customizada está funcional.
- Suba os serviços:
cd desafio1 docker compose up -d - Visualize os logs do Nginx, que registrarão as requisições periódicas do
cliente-curl:docker logs servidor-web -f
A persistência de dados é garantida pelo uso de um Volume Nomeado do Docker, a abordagem recomendada para dados de produção.
- Serviço:
postgres-db(PostgreSQL). - Persistência: O volume
desafio2_pgdataé mapeado para o diretório de dados padrão do PostgreSQL:/var/lib/postgresql/data. - Segurança: As credenciais de acesso são fornecidas pelo arquivo
.envlocal, seguindo as boas práticas para o Git.
- Suba o serviço (Certifique-se que o
.envesteja criado):cd desafio2 docker compose up -d - Passo A: Inserção de Dados (Escrita)
- Acesse o terminal do banco:
docker exec -it postgres-db psql -U usuario - Crie e insira dados:
CREATE TABLE teste (id INT); INSERT INTO teste (id) VALUES (42); \q
- Acesse o terminal do banco:
- Passo B: Recriação do Container (Teste de Persistência)
- Remova o container (MANTENDO O VOLUME):
docker compose stop && docker compose rm -f - Suba um NOVO container:
docker compose up -d
- Remova o container (MANTENDO O VOLUME):
- Passo C: Verificação
- Acesse o novo container:
docker exec -it postgres-db psql -U usuario - Verifique os dados:
SELECT * FROM teste;-> O valor42deve persistir.
- Acesse o novo container:
- Limpeza Total (Remove Container e Volume):
docker compose down -v
O docker-compose.yml orquestra uma arquitetura de 3 camadas, utilizando a rede interna desafio3_rede.
- Serviços:
db(PostgreSQL),cache(Redis) eweb(Nginx). - Dependência: O serviço
webutilizadepends_on: [db, cache]para garantir que os serviços de apoio sejam iniciados antes da aplicação principal. - Comunicação: Todos os serviços se comunicam usando seus nomes (ex:
dbecache) na rede.
- Suba os serviços (Certifique-se que o
.envesteja criado):cd desafio3 docker compose up -d - Teste de Comunicação (DNS):
- Execute um container Alpine temporário na mesma rede para pingar os serviços:
docker run --rm --network desafio3_rede alpine ping -c 3 db docker run --rm --network desafio3_rede alpine ping -c 3 cache
- Ambos os comandos devem retornar sucesso, provando que a orquestração de rede e DNS funcionou.
- Execute um container Alpine temporário na mesma rede para pingar os serviços:
Implementação de dois microsserviços Flask com seus respectivos Dockerfiles e comunicação direta via HTTP.
- Serviço A (
data-service): Fornece dados JSON na porta 5000.- Dockerfile: Instala Flask e expõe
app.py.
- Dockerfile: Instala Flask e expõe
- Serviço B (
consumer-api): Microsserviço consumidor (porta 5001).- Comunicação: Usa a biblioteca
requestspara fazerGET http://data-service:5000/usuarios. - Dockerfile: Instala Flask e a biblioteca
requests.
- Comunicação: Usa a biblioteca
- Suba os serviços (o
--buildé necessário para compilar as imagens Flask):cd desafio4 docker compose up --build -d - Teste do Consumidor: Acesse a API do serviço B, que deve retornar o HTML formatado com dados puxados do serviço A:
curl http://localhost:5001/
Implementação de um padrão API Gateway usando Nginx como Proxy Reverso para centralizar o acesso a dois microsserviços internos (Flask).
- Gateway:
api-gateway(Nginx). O arquivogateway-nginx/nginx.confé montado via volume e define as regras de roteamento. - Serviço 1:
user-service(Flask, porta 5000 interna). - Serviço 2:
order-service(Flask, porta 5000 interna). - Roteamento (Nginx):
/users-> Proxy parahttp://user-service:5000/orders-> Proxy parahttp://order-service:5000
- Suba os serviços:
cd desafio5 docker compose up -d - Teste Rota de Usuários (via Gateway):
curl http://localhost/users
- O Gateway roteia a chamada para o
user-service.
- O Gateway roteia a chamada para o
- Teste Rota de Pedidos (via Gateway):
curl http://localhost/orders
- O Gateway roteia a chamada para o
order-service.
- O Gateway roteia a chamada para o