Docker secrets e volumes resolvem dois problemas que aparecem em todo projeto: passar dados sensiveis para dentro do container sem deixar no codigo fonte, e manter dados persistentes mesmo depois que o container reinicia.
Vou mostrar os dois na pratica com exemplos funcionais.
Primeiro, um docker-compose.yml que usa um secret para a senha do banco:
version: '3.8'
services:
app:
image: alpine:latest
secrets:
- db_password
command: cat /run/secrets/db_password
secrets:
db_password:
file: ./db_password.txt
Crie o arquivo db_password.txt com a senha:
echo "SuperS3nh4Segura!" > db_password.txt
Depois suba o container:
docker compose up
O Docker monta o arquivo dentro do container em /run/secrets/db_password. O segredo nunca aparece no Dockerfile nem no repositorio.
Agora volumes. Volumes sao a forma certa de persistir dados. Eles sobrevivem a remocao do container e sao mais rapidos que bind mounts.
Exemplo com PostgreSQL persistindo os dados:
version: '3.8'
services:
db:
image: postgres:16
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
secrets:
- db_password
volumes:
- pgdata:/var/lib/postgresql/data
secrets:
db_password:
file: ./db_password.txt
volumes:
pgdata:
Execute com:
docker compose up -d
docker compose stop
docker compose rm -f
docker compose up -d
Os dados continuam la porque o volume pgdata persiste mesmo com o container removido. Para ver os volumes:
docker volume ls
docker volume inspect myproject_pgdata
Para limpar volumes nao usados:
docker volume prune
Secrets tambem funcionam em servicos Swarm. O Docker mantem o segredo criptografado em transito e em repouso:
echo "minha-chave-api" | docker secret create api_key -
docker service create --name app --secret api_key alpine cat /run/secrets/api_key
Uma dica: nunca use variaveis de ambiente para dados sensiveis. O ENV de um container pode ser lido com docker inspect e vaza em logs. Secrets resolvem isso de verdade.
That's all for now.
Thanks for reading!
Top comments (0)