🐳 1. Introdução ao Docker

1.1 O que é Docker e por que usar

Docker é uma plataforma que permite empacotar, distribuir e executar aplicações dentro de containers.

Um container é como uma “caixinha” que contém tudo o que uma aplicação precisa para rodar: código, bibliotecas, dependências e configurações.

Vantagens principais:

Portabilidade: funciona da mesma forma em qualquer ambiente (seja no seu notebook, em um servidor ou na nuvem).
Rapidez: containers são mais leves e iniciam em segundos, diferentemente de máquinas virtuais.
Escalabilidade: fácil criar múltiplas instâncias da mesma aplicação.
Isolamento: cada container roda separado, evitando conflitos de dependências.

1.2 Containers vs Máquinas Virtuais (VMs)

Aspecto	Containers 🐳	VMs 💻
Peso	Leves (compartilham kernel do SO)	Pesadas (SO completo por VM)
Inicialização	Segundos	Minutos
Consumo de Recursos	Baixo	Alto
Portabilidade	Alta (mesma imagem em qualquer host)	Menor (dependente do hypervisor)
Isolamento	Bom (nível de processo)	Forte (nível de hardware)

Resumo: Containers são ideais para desenvolvimento ágil e escalável, enquanto VMs ainda são úteis para cenários que exigem isolamento extremo.

1.3 Conceito de Imagem e Container

Imagem:

Modelo imutável que descreve o ambiente de execução.
Contém o sistema operacional mínimo + bibliotecas + código da aplicação.
Exemplo: node:20-alpine (imagem oficial do Node.js baseada no Alpine Linux).

Container:

Instância em execução de uma imagem.
Você pode criar vários containers a partir da mesma imagem.
Containers são descartáveis: você pode parar, remover e recriar rapidamente.

📝 Analogia:

Imagem = receita de bolo.
Container = o bolo pronto feito a partir da receita.

1.4 Arquitetura do Docker

A arquitetura do Docker é composta por quatro partes principais:

Docker Client

Ferramenta de linha de comando (docker run, docker ps, etc.).
O usuário interage com o Docker por aqui.

Docker Daemon (dockerd)

Processo em background que faz todo o trabalho “pesado”.
Cria, gerencia e executa containers e imagens.

Docker Engine

Conjunto formado pelo Client + Daemon.
É o “motor” do Docker que executa e gerencia containers.

Docker Registry

Local onde imagens são armazenadas e distribuídas.
O Docker Hub é o registro público padrão (como um “GitHub de imagens”).
Também é possível ter registries privados (AWS ECR, GitHub Packages, etc.).

🔗 Fluxo básico de uso:

Você pede ao Client: docker run nginx.
O Daemon busca a imagem no Registry (Docker Hub).
O Daemon cria um container a partir dessa imagem.
O container roda no seu sistema.

🐳 2. Conceitos Fundamentais do Docker

2.1 Imagens

O que são:
Uma imagem é um “pacote” que contém tudo que uma aplicação precisa para rodar (bibliotecas, dependências, binários e arquivos de configuração).

Camadas (Layers):

Cada instrução do Dockerfile (ex.: RUN, COPY, ADD) cria uma camada.
Essas camadas são cacheadas → reaproveitamento em builds futuros.
Camadas imutáveis: apenas a camada final muda ao atualizar.

Reuso:

Imagens podem ser baseadas em outras.
Exemplo: FROM node:20-alpine → reaproveita uma imagem oficial.

Versionamento:

Controlado por tags (ex.: nginx:1.25, nginx:latest).
Tags ajudam a garantir consistência no ambiente (evitar latest em produção).

2.2 Containers

O que são:

São instâncias em execução de uma imagem.
Criados, parados e removidos rapidamente.

Ciclo de vida:

docker run     # cria e inicia um container
docker start   # inicia um container parado
docker stop    # para um container
docker restart # reinicia um container
docker rm      # remove definitivamente um container

📝 Exemplo prático:

docker run -d --name meu_nginx nginx:latest
docker stop meu_nginx
docker start meu_nginx
docker rm -f meu_nginx

2.3 Volumes (Persistência de Dados)

Problema: Containers são efêmeros → ao parar/remover, dados internos são perdidos.
Solução: Volumes.

Tipos de volumes:

Volumes gerenciados (docker volume create): mantidos pelo Docker.
Bind mounts: mapeiam uma pasta do host para dentro do container.

Exemplo prático:

docker run -d -v meu_volume:/var/lib/mysql mysql:8

➡️ Os dados do banco ficam persistentes no volume meu_volume.

2.4 Redes

O Docker cria redes virtuais para comunicação entre containers.

Tipos principais:

Bridge (padrão): containers comunicam-se entre si usando nomes/IPs.
Host: o container compartilha a rede do host (desempenho/necessidades especiais).
Overlay: usada em clusters (ex.: Docker Swarm, Kubernetes).

Comandos úteis:

docker network ls
docker network create minha_rede
docker run --network minha_rede ...

2.5 Docker Hub e Registries Privados

Docker Hub:

Registro público oficial de imagens.
Possui imagens oficiais (ex.: nginx, postgres, node).

Registries privados:

Empresas podem manter repositórios privados para imagens internas.
Exemplos: AWS ECR, Azure ACR, GitHub Packages, GitLab Registry.

Autenticação:

docker login my-registry.com
docker push my-registry.com/minha-imagem:1.0

✅ Resumo visual:

Imagens → base imutável (receita).
Containers → instâncias vivas (o prato pronto).
Volumes → guardam dados mesmo após o container morrer.
Redes → conectam containers entre si.
Registries → bibliotecas de imagens (públicas ou privadas).

🐳 3. Primeiros Comandos do Docker

3.1 `docker run`

Cria e executa um container a partir de uma imagem.

Principais opções:

-d → executa em background (detached).
--name → dá um nome ao container.
-p → mapeia portas (host:container).
-v → monta volumes.

📝 Exemplo:

docker run -d --name meu_nginx -p 8080:80 nginx:latest

➡️ Sobe o Nginx no background, acessível em http://localhost:8080.

3.2 `docker ps`

Lista os containers em execução.
Use -a para ver todos (inclusive parados).

docker ps
docker ps -a

3.3 `docker stop` e `docker rm`

Parar um container ativo:

docker stop meu_nginx

Remover um container (parado ou com -f forçando):

docker rm meu_nginx

3.4 `docker images` e `docker rmi`

Listar imagens disponíveis localmente:

docker images

Remover uma imagem não utilizada:

docker rmi nginx:latest

3.5 `docker exec`

Executa comandos dentro de um container em execução (ex.: abrir um shell).

docker exec -it meu_nginx bash

➡️ Abre um terminal interativo dentro do container meu_nginx.

3.6 `docker logs`

Mostra os logs de um container (útil para depuração).

docker logs meu_nginx
docker logs -f meu_nginx   # segue os logs em tempo real

3.7 `docker pull` e `docker push`

Baixar imagens do Docker Hub ou registry privado:

docker pull postgres:16

Enviar imagens para um registry:

docker tag minha_api:1.0 my-registry.com/minha_api:1.0
docker push my-registry.com/minha_api:1.0

✅ Resumo rápido dos comandos básicos:

Comando	Função
`docker run`	Criar e executar container
`docker ps`	Listar containers
`docker stop`	Parar container
`docker rm`	Remover container
`docker images`	Listar imagens
`docker rmi`	Remover imagem
`docker exec`	Executar comando dentro do container
`docker logs`	Ver logs do container
`docker pull`	Baixar imagem do registry
`docker push`	Enviar imagem para registry

🐳 4. Dockerfile

4.1 O que é um Dockerfile

É um arquivo de texto que contém instruções para construir uma imagem Docker.
Funciona como uma receita: cada linha define uma etapa que será transformada em uma camada da imagem.
Nome padrão: Dockerfile (sem extensão).

4.2 Estrutura Básica de um Dockerfile

Um Dockerfile típico tem a seguinte estrutura:

# Imagem base
FROM node:20-alpine

# Diretório de trabalho
WORKDIR /app

# Copiar arquivos para dentro do container
COPY package*.json ./
RUN npm install
COPY . .

# Porta exposta
EXPOSE 3000

# Comando padrão
CMD ["npm", "start"]

4.3 Principais Instruções

`FROM`

Define a imagem base a ser utilizada.
Exemplo:

FROM python:3.11-slim

`RUN`

Executa comandos durante a construção da imagem.
Exemplo:

RUN apt-get update && apt-get install -y curl

`COPY`

Copia arquivos do host para dentro da imagem.
Exemplo:

COPY . /app

`WORKDIR`

Define o diretório de trabalho dentro da imagem.
Exemplo:

WORKDIR /app

`CMD`

Define o comando padrão a ser executado quando o container iniciar.
Só pode existir um CMD → se tiver vários, apenas o último é usado.
Exemplo:

CMD ["node", "server.js"]

`ENTRYPOINT`

Parecido com CMD, mas torna o comando fixo.
O que for passado no docker run será tratado como argumento.
Exemplo:

ENTRYPOINT ["python", "app.py"]

4.4 Build de Imagens (`docker build`)

Para construir uma imagem a partir de um Dockerfile:

docker build -t minha_api:1.0 .

-t → define nome e tag da imagem.
. → indica o diretório atual (onde está o Dockerfile).

4.5 Boas Práticas para Imagens Menores

Use imagens oficiais leves (ex.: alpine, slim).
- Exemplo: node:20-alpine em vez de node:20.

Combine comandos RUN para reduzir camadas.

RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*

Copie apenas o necessário (use .dockerignore para excluir arquivos).
Multi-stage builds → construa em uma imagem maior e copie o resultado para uma imagem final menor.

# Etapa 1: build
FROM node:20 as builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

# Etapa 2: imagem final
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

➡️ Apenas o resultado final vai para produção.

✅ Resumo

Dockerfile = receita de uma imagem.
Instruções principais: FROM, RUN, COPY, WORKDIR, CMD, ENTRYPOINT.
Build com docker build.
Boas práticas → imagens leves, multi-stage builds, .dockerignore.

🐳 5. Volumes e Persistência

5.1 Por que precisamos de volumes?

Containers são efêmeros → quando param ou são removidos, os dados internos desaparecem.
Para manter dados além do ciclo de vida do container, usamos volumes.
Volumes permitem:
- Persistência de dados.
- Compartilhamento entre múltiplos containers.
- Backup e migração de informações.

5.2 Montagem de Volumes

Existem duas formas comuns de montar volumes em containers:

Usando `-v`

docker run -d -v meu_volume:/var/lib/mysql mysql:8

Cria um volume chamado meu_volume.
Monta-o no caminho /var/lib/mysql dentro do container.

Usando `--mount`

docker run -d --mount source=meu_volume,target=/var/lib/mysql mysql:8

Sintaxe mais explícita e flexível.
Útil para configurações avançadas.

5.3 Bind Mount vs Volumes Gerenciados

Bind Mount

Mapeia um diretório do host para dentro do container.

Exemplo:

docker run -v $(pwd):/app node:20

➡️ O diretório atual do host é acessível dentro do container em /app.

Prós: fácil para desenvolvimento (edição em tempo real).
Contras: depende do host → menos portável.

Volumes Gerenciados

Criados e gerenciados pelo Docker.
Local padrão: /var/lib/docker/volumes/.

Exemplo:

docker volume create dados_db
docker run -d -v dados_db:/var/lib/mysql mysql:8

Prós: mais portáveis, ideais para produção.
Contras: menos transparência (não acessíveis diretamente no host sem comandos Docker).

5.4 Casos de Uso

Bancos de Dados

docker run -d -v db_dados:/var/lib/postgresql/data postgres:16

Arquivos de Configuração

docker run -d -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf nginx:latest

Ambiente de Desenvolvimento

docker run -it -v $(pwd):/app node:20 bash

✅ Resumo

Volumes resolvem o problema da perda de dados quando containers são removidos.
Bind mount: conecta pasta do host → bom para desenvolvimento.
Volumes gerenciados: controlados pelo Docker → melhor para produção.
Principais usos: bancos de dados, configs, desenvolvimento colaborativo.

🐳 6. Redes e Comunicação

6.1 Redes Padrão do Docker

Quando instalamos o Docker, ele cria redes padrão automaticamente:

Bridge (padrão)

Rede privada criada pelo Docker.
Usada quando não especificamos nenhuma rede.
Containers conectados a essa rede podem se comunicar entre si usando IP interno ou nome do container.

Exemplo:

docker run -d --name web1 nginx
docker run -d --name web2 nginx
# web1 pode acessar web2 usando:
# curl http://web2

None

O container não terá rede.
Sem comunicação externa → usado em casos de segurança ou processamento isolado.

docker run -d --network none alpine sleep 3600

Host

O container compartilha a rede do host.
Útil para performance de rede ou serviços que precisam expor portas diretamente.

docker run -d --network host nginx

➡️ O Nginx escutará diretamente nas portas do host.

6.2 Criação de Redes Customizadas

Podemos criar redes personalizadas para organizar melhor os containers.

Criar uma rede

docker network create minha_rede

Rodar containers na rede

docker run -d --name app --network minha_rede nginx
docker run -d --name db --network minha_rede postgres

Inspecionar redes

docker network ls
docker network inspect minha_rede

➡️ Assim, app pode se conectar ao db usando o nome db.

6.3 Comunicação entre Containers

Containers na mesma rede podem se comunicar pelo nome do container.

Exemplo:

db (PostgreSQL) rodando na rede app_net.
api (Node.js) também conectado à app_net.
A api pode acessar o banco usando db:5432 no lugar de localhost.

📝 Exemplo prático:

docker network create app_net

docker run -d --name db --network app_net -e POSTGRES_PASSWORD=123 postgres:16
docker run -d --name api --network app_net meu_api:1.0

✅ Resumo

Redes padrão:
- bridge: comunicação isolada entre containers.
- none: sem rede.
- host: usa a rede do host.
Redes customizadas → maior controle, containers se comunicam pelo nome.
Comunicação entre containers → usar nomes de container ou service name (em Compose/Kubernetes).

🐳 7. Docker Compose

7.1 O que é e quando usar

Docker Compose é uma ferramenta para definir e gerenciar múltiplos containers como um único serviço.
Permite descrever toda a stack da aplicação em um arquivo docker-compose.yml.
Ideal para:
- Projetos com vários serviços (ex.: frontend + backend + banco).
- Facilitar o desenvolvimento local (um único comando sobe tudo).
- Garantir que todos usem a mesma configuração.

7.2 Estrutura de um `docker-compose.yml`

Exemplo básico:

version: "3.9"

services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
  
  api:
    build: ./api
    ports:
      - "3000:3000"
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: mydb
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

7.3 Comandos Principais

Subir serviços:

docker compose up

Subir em segundo plano (detached):

docker compose up -d

Parar e remover serviços:

docker compose down

Ver containers ativos:

docker compose ps

Ver logs dos serviços:

docker compose logs -f

7.4 Exemplos Práticos: Web + API + DB

Stack completa

version: "3.9"

services:
  frontend:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./frontend:/usr/share/nginx/html

  backend:
    build: ./backend
    ports:
      - "3000:3000"
    environment:
      DB_HOST: db
      DB_USER: user
      DB_PASS: pass
    depends_on:
      - db

  db:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: mydb
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

➡️ Neste exemplo:

O frontend (Nginx) serve arquivos estáticos.
O backend (API) se comunica com o banco usando db:5432.
O Postgres mantém dados persistentes em db_data.

✅ Resumo

Docker Compose simplifica o gerenciamento de múltiplos containers.
Arquivo central: docker-compose.yml.
Comandos principais: up, down, ps, logs.
Permite criar stacks completas (web + api + db) com poucas linhas.

🐳 8. Gestão e Monitoramento

8.1 Inspeção de Containers (`docker inspect`)

Mostra detalhes completos de um container ou imagem em formato JSON.

Informações disponíveis:

Configuração (volumes, redes, portas).
Variáveis de ambiente.
Caminhos de montagem.
Status de execução.

Exemplo:

docker inspect meu_container

➡️ Útil para depuração ou checar parâmetros de rede e volumes.

8.2 Logs (`docker logs`)

Mostra a saída padrão (stdout e stderr) de um container.

Usos comuns:

Ver mensagens de erro.
Acompanhar execução em tempo real.

Exemplo:

docker logs meu_api
docker logs -f meu_api   # segue logs em tempo real

8.3 Métricas Básicas (`docker stats`)

Exibe uso em tempo real de recursos de cada container:

CPU (%)
Memória usada
I/O de disco
Tráfego de rede

Exemplo:

docker stats

➡️ Semelhante ao top do Linux, mas para containers.

8.4 Healthchecks

Verificam se o container está saudável.
Podem ser configurados no Dockerfile ou no Compose.
Permitem que orquestradores (Compose, Swarm, Kubernetes) saibam se o container precisa ser reiniciado.

Healthcheck no Dockerfile

HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

➡️ Verifica a cada 30s se a rota /health responde.

Healthcheck no Docker Compose

version: "3.9"

services:
  api:
    build: ./api
    ports:
      - "3000:3000"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

✅ Resumo

docker inspect → informações detalhadas do container.
docker logs → análise de execução e erros.
docker stats → monitoramento de consumo de recursos.
Healthchecks → garantem que o container esteja realmente funcionando.

🐳 9. Segurança Básica

9.1 Usuários Não-root em Containers

Por padrão, muitos containers rodam como usuário root → aumenta o risco de segurança se alguém explorar vulnerabilidades.
Boa prática: criar e usar usuários não-root.

Exemplo em Dockerfile:

FROM node:20-alpine

# Cria um usuário
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

WORKDIR /app
COPY . .

# Define o usuário para execução
USER appuser

CMD ["node", "server.js"]

➡️ Assim, mesmo que o container seja comprometido, o invasor terá privilégios limitados.

9.2 Imagens Oficiais vs Imagens Desconhecidas

Imagens oficiais (ex.: nginx, postgres, node) são mantidas pela comunidade/empresa responsável → mais confiáveis.
Imagens desconhecidas podem conter backdoors ou software desatualizado.

Sempre verifique:

Fonte da imagem.
Quantidade de downloads e estrelas.
Atualizações recentes.

Exemplo seguro:

docker pull postgres:16

Exemplo de risco:

docker pull usuario123/postgres-modificado

9.3 Atualização de Imagens (`docker pull`)

Manter imagens sempre atualizadas é fundamental para corrigir falhas de segurança.

Exemplo:

docker pull nginx:latest
docker pull node:20-alpine

Após atualizar, reconstrua containers:

docker compose up -d --build

9.4 Scanners de Vulnerabilidades

Ferramentas que analisam imagens em busca de falhas conhecidas (CVEs).
Exemplo: Trivy.

Instalação (Ubuntu/Debian):

sudo apt install trivy

Escaneando imagens:

trivy image nginx:latest
trivy image postgres:16

➡️ Resultado mostra vulnerabilidades e recomendações de atualização.

✅ Resumo

Nunca rode containers como root → use usuários dedicados.
Prefira imagens oficiais e mantenha-as atualizadas (docker pull).
Evite imagens de fontes duvidosas.
Use scanners como Trivy para verificar vulnerabilidades.

🐳 10. Casos de Uso Práticos

10.1 Containerizando uma API Node.js

Objetivo: empacotar uma aplicação Node.js em um container.

Estrutura de projeto:

api/
├── package.json
├── package-lock.json
├── server.js
└── Dockerfile

Exemplo de Dockerfile:

FROM node:20-alpine

WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .

EXPOSE 3000
CMD ["node", "server.js"]

Build e execução:

docker build -t minha_api:1.0 ./api
docker run -d --name api -p 3000:3000 minha_api:1.0

➡️ A API agora roda em http://localhost:3000.

10.2 Executando PostgreSQL/MySQL em Container

Objetivo: subir um banco de dados rapidamente sem instalar localmente.

PostgreSQL

docker run -d --name meu_postgres \
  -e POSTGRES_USER=user \
  -e POSTGRES_PASSWORD=pass \
  -e POSTGRES_DB=meubanco \
  -v pg_data:/var/lib/postgresql/data \
  -p 5432:5432 postgres:16

MySQL

docker run -d --name meu_mysql \
  -e MYSQL_ROOT_PASSWORD=root \
  -e MYSQL_DATABASE=meubanco \
  -v mysql_data:/var/lib/mysql \
  -p 3306:3306 mysql:8

➡️ Ambos criam volumes (pg_data, mysql_data) para persistência.

10.3 Subindo Stack Web Completa (Nginx + API + DB)

Objetivo: rodar um ambiente com frontend, backend e banco.
Usaremos Docker Compose para orquestrar os serviços.

Estrutura:

project/
├── api/
│   ├── Dockerfile
│   └── server.js
├── frontend/
│   └── index.html
└── docker-compose.yml

Exemplo de docker-compose.yml:

version: "3.9"

services:
  frontend:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./frontend:/usr/share/nginx/html

  backend:
    build: ./backend
    ports:
      - "3000:3000"
    environment:
      DB_HOST: db
      DB_USER: user
      DB_PASS: pass
    depends_on:
      - db

  db:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: mydb
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

Subindo a stack:

docker compose up -d

➡️ Serviços disponíveis:

Frontend → http://localhost:8080
API → http://localhost:3000
Postgres → localhost:5432

✅ Resumo

API Node.js → containerizada em imagem leve e reutilizável.
PostgreSQL/MySQL → fácil de rodar e persistir dados com volumes.
Stack completa (Nginx + API + DB) → substitui ambientes complexos com um único comando.

🐳 11. Boas Práticas

11.1 Minimizar Tamanho de Imagens

Imagens menores = menos tempo de build, menos uso de rede e mais segurança.
Use imagens leves (ex.: alpine, slim) e remova dependências desnecessárias após uso.

Multi-stage builds (ex.: Node.js):

# Etapa 1: build
FROM node:20 as builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

# Etapa 2: imagem final leve
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY package*.json ./
RUN npm install --only=production
CMD ["node", "dist/server.js"]

➡️ A imagem final contém apenas os arquivos essenciais.

11.2 Organizar Volumes e Redes

Nomeie volumes e redes para facilitar manutenção; evite deixar tudo no bridge.

Exemplo:

services:
  api:
    networks:
      - backend
    volumes:
      - api_data:/app/data

  db:
    networks:
      - backend
    volumes:
      - db_data:/var/lib/postgresql/data

networks:
  backend:

volumes:
  api_data:
  db_data:

11.3 Versionamento de `docker-compose.yml`

Use Git e separe arquivos por ambiente:

docker-compose.dev.yml
docker-compose.prod.yml

Exemplo (produção):

docker compose -f docker-compose.prod.yml up -d

11.4 Limpeza de Recursos

Com o tempo, o Docker acumula containers parados, imagens antigas e volumes não utilizados.

Comandos úteis:

docker container prune   # remove containers parados
docker image prune       # remove imagens não usadas
docker volume prune      # remove volumes órfãos
docker system prune -a   # remove TUDO não utilizado (atenção!)

✅ Resumo

Imagens menores → mais rápidas e seguras (use multi-stage).
Volumes/redes organizados → melhor manutenção e isolamento.
Versione Compose → ambientes consistentes (dev/prod).
Limpeza periódica → evita desperdício de espaço.

🐳 12. Próximos Passos (Intermediário+)

12.1 Introdução à Orquestração

Problema: gerenciar containers manualmente funciona em projetos pequenos, mas em ambientes maiores é necessário automatizar.

Soluções:

Docker Swarm
- Orquestrador nativo do Docker.
- Fácil de configurar, bom para ambientes menores.
- Suporta clustering, balanceamento de carga e replicação.
- Exemplo:
```
docker swarm init
docker service create --replicas 3 nginx
```
Kubernetes (K8s)
- Orquestrador mais usado em produção.
- Suporta autoescalonamento, alta disponibilidade, secrets e volumes avançados.
- Mais complexo, mas padrão de mercado.

12.2 CI/CD com Docker

CI/CD (Integração Contínua e Entrega Contínua) automatiza build, testes e deploy.

Docker no CI/CD:

Criar imagens da aplicação em pipelines.
Rodar testes dentro de containers.
Publicar imagens em registries (Docker Hub, GitHub Packages, AWS ECR).

Ferramentas: GitHub Actions, GitLab CI/CD, Jenkins.

Exemplo (GitHub Actions):

name: CI/CD

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build image
        run: docker build -t minha_api:latest .
      - name: Push image
        run: docker push usuario/minha_api:latest

12.3 Deploy em Nuvem

Containers podem ser implantados em diversos provedores:

AWS
- ECS (Elastic Container Service): gerencia containers com ou sem Kubernetes.
- EKS (Elastic Kubernetes Service): Kubernetes gerenciado.
Azure
- AKS (Azure Kubernetes Service): Kubernetes como serviço.
- Azure Container Instances (ACI): containers simples sem orquestrador.
GCP
- GKE (Google Kubernetes Engine): Kubernetes gerenciado.
- Cloud Run: roda containers serverless.

➡️ A nuvem elimina a necessidade de manter servidores próprios.

12.4 Observabilidade (Grafana + Prometheus com Docker)

Monitoramento é essencial para aplicações em containers.

Prometheus
- Coleta métricas (CPU, memória, I/O, rede).
- Usa exporters para integrar com serviços (ex.: cAdvisor para containers).
Grafana
- Interface para visualizar métricas e criar dashboards.

Exemplo básico (Docker Compose):

version: "3.9"

services:
  prometheus:
    image: prom/prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml

  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"

➡️ Resultado:

Prometheus coleta métricas em http://localhost:9090.
Grafana exibe dashboards em http://localhost:3000.

✅ Resumo

Orquestração: Swarm (simples) e Kubernetes (padrão de mercado).
CI/CD com Docker: pipelines automatizados para build, teste e deploy.
Deploy em nuvem: AWS, Azure e GCP oferecem soluções prontas.
Observabilidade: Prometheus + Grafana para métricas e dashboards.

nunesfb/docker.md

🐳 1. Introdução ao Docker

1.1 O que é Docker e por que usar

1.2 Containers vs Máquinas Virtuais (VMs)

1.3 Conceito de Imagem e Container

1.4 Arquitetura do Docker

Docker Client

Docker Daemon (dockerd)

Docker Engine

Docker Registry

🐳 2. Conceitos Fundamentais do Docker

2.1 Imagens

2.2 Containers

2.3 Volumes (Persistência de Dados)

2.4 Redes

2.5 Docker Hub e Registries Privados

🐳 3. Primeiros Comandos do Docker

3.1 docker run

3.2 docker ps

3.3 docker stop e docker rm

3.4 docker images e docker rmi

3.5 docker exec

3.6 docker logs

3.7 docker pull e docker push

🐳 4. Dockerfile

4.1 O que é um Dockerfile

4.2 Estrutura Básica de um Dockerfile

4.3 Principais Instruções

FROM

RUN

COPY

WORKDIR

CMD

ENTRYPOINT

4.4 Build de Imagens (docker build)

4.5 Boas Práticas para Imagens Menores

🐳 5. Volumes e Persistência

5.1 Por que precisamos de volumes?

5.2 Montagem de Volumes

Usando -v

Usando --mount

5.3 Bind Mount vs Volumes Gerenciados

Bind Mount

Volumes Gerenciados

5.4 Casos de Uso

🐳 6. Redes e Comunicação

6.1 Redes Padrão do Docker

Bridge (padrão)

None

Host

6.2 Criação de Redes Customizadas

6.3 Comunicação entre Containers

🐳 7. Docker Compose

7.1 O que é e quando usar

7.2 Estrutura de um docker-compose.yml

7.3 Comandos Principais

7.4 Exemplos Práticos: Web + API + DB

🐳 8. Gestão e Monitoramento

8.1 Inspeção de Containers (docker inspect)

8.2 Logs (docker logs)

8.3 Métricas Básicas (docker stats)

8.4 Healthchecks

🐳 9. Segurança Básica

9.1 Usuários Não-root em Containers

9.2 Imagens Oficiais vs Imagens Desconhecidas

9.3 Atualização de Imagens (docker pull)

9.4 Scanners de Vulnerabilidades

🐳 10. Casos de Uso Práticos

10.1 Containerizando uma API Node.js

10.2 Executando PostgreSQL/MySQL em Container

10.3 Subindo Stack Web Completa (Nginx + API + DB)

🐳 11. Boas Práticas

11.1 Minimizar Tamanho de Imagens

11.2 Organizar Volumes e Redes

11.3 Versionamento de docker-compose.yml

11.4 Limpeza de Recursos

🐳 12. Próximos Passos (Intermediário+)

12.1 Introdução à Orquestração

12.2 CI/CD com Docker

12.3 Deploy em Nuvem

3.1 `docker run`

3.2 `docker ps`

3.3 `docker stop` e `docker rm`

3.4 `docker images` e `docker rmi`

3.5 `docker exec`

3.6 `docker logs`

3.7 `docker pull` e `docker push`

`FROM`

`RUN`

`COPY`

`WORKDIR`

`CMD`

`ENTRYPOINT`

4.4 Build de Imagens (`docker build`)

Usando `-v`

Usando `--mount`

7.2 Estrutura de um `docker-compose.yml`

8.1 Inspeção de Containers (`docker inspect`)

8.2 Logs (`docker logs`)

8.3 Métricas Básicas (`docker stats`)

9.3 Atualização de Imagens (`docker pull`)

11.3 Versionamento de `docker-compose.yml`