Guia completo para implantar Redis com Docker: persistência e autenticação por senha sem perda de dados

Finalmente, o contêiner Redis estava em execução. Testei algumas APIs, e a leitura e a gravação de dados funcionavam normalmente. No dia seguinte, abri o computador para verificar o status do serviço — todos os dados tinham desaparecido. Foi desanimador.

Talvez você já tenha passado por isso: depois de reiniciar o contêiner Docker, é como se os dados no Redis nunca tivessem existido. As sessões dos usuários somem, os carrinhos de compras são esvaziados e os dados em cache desaparecem. O pior é não saber por que isso acontece nem como resolver.

Para ser sincero, também fiquei bastante preocupado na primeira vez que encontrei esse problema. Era um projeto pequeno, e os dados do ambiente de testes desapareceram de repente. Embora isso não tenha afetado a produção, a sensação de impotência foi muito desagradável. Só depois entendi que o contêiner é, por natureza, “temporário”: ao excluí-lo, os dados desaparecem; ao reiniciá-lo sem persistência configurada, os dados também podem ser perdidos.

Neste artigo, você vai aprender passo a passo a:

• Configurar persistência RDB e AOF para impedir que os dados do Redis sejam perdidos quando o contêiner reiniciar
• Definir autenticação por senha para evitar acessos não autorizados ao Redis (há empresas cujos servidores Redis foram invadidos e usados para mineração de criptomoedas por não terem senha)
• Montar o arquivo de configuração para padronizar a implantação do Redis e facilitar a manutenção
• Aplicar boas práticas de produção, incluindo consulta de logs, verificações de integridade e otimização de desempenho

Seja você desenvolvedor backend, profissional de operações ou iniciante em Docker, ao seguir este guia uma vez será capaz de implantar um contêiner Redis pronto para produção.

Por que o contêiner Redis perde dados?

Vamos começar com uma analogia: um contêiner Docker é como um quarto de hotel. Quando você encerra a hospedagem, tudo o que ficou no quarto é removido. Com o contêiner acontece a mesma coisa — ele é temporário por natureza; se você o excluir, os dados que estavam dentro dele desaparecem.

Por padrão, o Redis armazena os dados no sistema de arquivos interno do contêiner. Quando você grava dados, o Redis os salva em caminhos como /data/dump.rdb ou /data/appendonly.aof. O problema é que esses caminhos ficam dentro do contêiner. Assim que o contêiner é excluído ou recriado, os dados desaparecem junto com ele.

Em um caso real, um desenvolvedor de uma startup implantou Redis com Docker no ambiente de testes sem configurar persistência. Depois que o servidor reiniciou, todas as sessões dos usuários foram perdidas, os estados de login foram apagados e os dados dos carrinhos desapareceram. Embora fosse um ambiente de testes, a experiência fez a equipe perceber que uma implantação em contêiner precisa considerar a persistência dos dados.

Segundo dados estatísticos, cerca de 70% dos problemas de perda de dados em contêineres Redis acontecem porque o armazenamento persistente não foi configurado. Em outras palavras, é uma armadilha em que quase todo mundo cai pelo menos uma vez.

Para que serve um Docker Volume

O volume é a chave para resolver esse problema. É como armazenar arquivos importantes na nuvem em vez de deixá-los apenas no disco local do computador.

Quando você usa o parâmetro -v para montar um diretório do host dentro do contêiner, os dados passam a ficar no host. Se o contêiner for excluído, os dados continuam lá; se ele reiniciar, os dados ainda poderão ser lidos. É por isso que, em produção, é obrigatório montar um volume de dados.

Em resumo:

• Sem volume montado = dados dentro do contêiner = os dados desaparecem quando o contêiner é excluído
• Com volume montado = dados em um diretório do host = os dados continuam lá mesmo após a exclusão do contêiner

Implantação rápida de um contêiner Redis básico

Antes de falar sobre persistência, vamos implantar o contêiner Redis mais simples possível. Assim, você poderá perceber na prática o que significa trabalhar “sem persistência”.

Inicie o contêiner básico

Abra o terminal e execute:

docker run -d --name redis-basic -p 6379:6379 redis:latest

Esse comando faz o seguinte:

• -d: executa em segundo plano
• --name redis-basic: define um nome para o contêiner, facilitando o gerenciamento
• -p 6379:6379: mapeia a porta 6379 do contêiner para a porta 6379 do host
• redis:latest: usa a versão mais recente da imagem Redis

Depois da execução, o Docker baixa automaticamente a imagem do Redis, caso ela ainda não exista localmente, e inicia o contêiner.

Verifique se o contêiner está funcionando

Use docker ps para consultar o status do contêiner:

docker ps

Se o status de redis-basic aparecer como Up, o contêiner está funcionando normalmente.

Em seguida, entre no contêiner para testar se o Redis consegue ler e gravar dados:

docker exec -it redis-basic redis-cli

No terminal do Redis, tente armazenar um valor:

set test "hello"
get test

Se o retorno for "hello", o Redis está funcionando corretamente.

Problemas dessa versão básica

Parece bom, certo? Mas essa configuração tem três problemas graves:

1. Os dados não são persistentes: ao reiniciar o contêiner, eles são perdidos
2. Não há proteção por senha: qualquer pessoa pode se conectar ao Redis e ler ou gravar dados
3. A configuração padrão é usada: não é possível personalizar limites de memória, estratégia de persistência e outros parâmetros

Você pode reiniciar o contêiner e verificar se os dados continuam lá:

docker restart redis-basic
docker exec -it redis-basic redis-cli
get test

É muito provável que você descubra que a chave test armazenada anteriormente desapareceu. Esse é o resultado de não configurar a persistência.

Configuração da persistência RDB (snapshots)

O Redis oferece duas formas de persistência: RDB e AOF. Vamos começar pelo RDB, que é mais simples e adequado para quem está começando.

O que é RDB?

RDB é a sigla de Redis Database e pode ser entendido como um “snapshot do banco de dados”. É como tirar uma foto dos dados na memória do Redis: em intervalos definidos, o Redis salva todos os dados atuais em um arquivo dump.rdb.

A vantagem é a recuperação rápida. A desvantagem é a possibilidade de perder os dados gravados depois do último snapshot. Por exemplo, se você configurar um snapshot a cada cinco minutos, uma falha no Redis poderá causar a perda dos dados dos últimos cinco minutos no pior cenário.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Parâmetros de configuração do RDB

A persistência RDB do Redis é controlada pelos parâmetros save. O formato é:

save <segundos> <quantidade de chaves alteradas>

Por exemplo:

• save 900 1: salva um snapshot se pelo menos uma chave for alterada em 900 segundos (15 minutos)
• save 300 10: salva um snapshot se pelo menos dez chaves forem alteradas em 300 segundos (cinco minutos)
• save 60 10000: salva um snapshot se pelo menos 10.000 chaves forem alteradas em 60 segundos

Essas três regras usam uma relação “ou”: basta uma delas ser atendida para disparar o salvamento.

Monte um volume de dados para garantir a persistência

Configurar apenas o RDB não basta. Também é preciso montar o volume de dados no host. Dessa forma, mesmo que o contêiner seja excluído, o arquivo dump.rdb continuará no diretório do host.

Primeiro, crie um diretório para os dados:

mkdir -p ~/redis-data

Depois, inicie um contêiner Redis com volume de dados:

docker run -d \
  --name redis-rdb \
  -p 6379:6379 \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server --save 60 1 --dir /data

Há alguns pontos importantes:

• -v ~/redis-data:/data: monta o diretório ~/redis-data do host no diretório /data do contêiner
• --save 60 1: salva um snapshot quando pelo menos uma chave é alterada em 60 segundos (para testes; em produção, você pode aumentar esse intervalo)
• --dir /data: define o caminho onde o arquivo RDB será salvo

Valide a persistência

Entre no contêiner e armazene alguns dados:

docker exec -it redis-rdb redis-cli
set user:1 "张三"
set user:2 "李四"

Aguarde 60 segundos para que o Redis salve o snapshot. Depois, reinicie o contêiner:

docker restart redis-rdb

Entre novamente no contêiner e verifique se os dados continuam lá:

docker exec -it redis-rdb redis-cli
get user:1

Se o retorno for "张三", parabéns: a persistência foi configurada com sucesso!

Você também pode abrir o diretório ~/redis-data no host. Lá haverá um arquivo dump.rdb, que é o snapshot do Redis.

Configuração da persistência AOF (log somente de acréscimo)

Embora o RDB seja simples, ele tem uma desvantagem: os dados gravados depois do último snapshot podem ser perdidos. Se a sua aplicação exigir maior segurança dos dados, use AOF.

O que é AOF?

AOF significa Append Only File, ou “arquivo somente de acréscimo”. Ele funciona assim: sempre que o Redis executa uma operação de escrita, como set, del ou incr, o comando é adicionado ao arquivo appendonly.aof.

Em uma analogia, o RDB é como tirar fotografias, enquanto o AOF é como gravar um vídeo. O RDB tira uma foto em intervalos definidos, enquanto o AOF registra cada ação em tempo real.

A vantagem é a maior segurança dos dados, com perda máxima de um segundo ao usar a estratégia everysec. A desvantagem é que o arquivo ocupa mais espaço do que o RDB e a recuperação é um pouco mais lenta.

As três estratégias de sincronização do AOF

O AOF oferece três estratégias de sincronização, cada uma com um equilíbrio diferente entre segurança e desempenho:

1. appendfsync always: sincroniza cada operação de escrita imediatamente com o disco

   • É a opção mais segura e praticamente não perde dados
   • Tem o menor desempenho e não é indicada para cenários de alta concorrência

2. appendfsync everysec: sincroniza uma vez por segundo (recomendado)

   • Equilibra desempenho e segurança
   • Pode perder, no máximo, um segundo de dados
   • É a opção recomendada para produção

3. appendfsync no: deixa o sistema operacional decidir quando sincronizar

   • Oferece o maior desempenho
   • Pode perder mais dados e não é recomendada

Inicie o Redis com persistência AOF

Como antes, primeiro garanta que o diretório de dados exista:

mkdir -p ~/redis-data

Inicie o contêiner:

docker run -d \
  --name redis-aof \
  -p 6379:6379 \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server --appendonly yes --appendfsync everysec --dir /data

Parâmetros principais:

• --appendonly yes: habilita a persistência AOF
• --appendfsync everysec: sincroniza uma vez por segundo
• --dir /data: define o diretório de dados

Depois de algum tempo, consulte o diretório de dados. Você encontrará um arquivo appendonly.aof:

ls ~/redis-data/

Persistência híbrida (recomendada no Redis 4.0+)

Desde o Redis 4.0, o modo de persistência híbrida, que combina as vantagens de RDB e AOF, é recomendado oficialmente:

• O RDB permite uma recuperação rápida
• O AOF protege os dados

Para habilitar esse modo, adicione a seguinte linha ao arquivo de configuração:

aof-use-rdb-preamble yes

A vantagem da persistência híbrida é que, ao reiniciar, o Redis primeiro carrega o snapshot RDB, o que é rápido, e depois reproduz os dados incrementais do log AOF gravados após o RDB, garantindo a integridade dos dados.

Sinceramente, se você usa Redis 4.0 ou uma versão mais recente, pode adotar diretamente a persistência híbrida sem ficar em dúvida entre RDB e AOF.

Gerenciamento do Redis por arquivo de configuração (recomendado para produção)

Até agora, configuramos o Redis com parâmetros de linha de comando, como --appendonly yes --appendfsync everysec. O problema dessa abordagem é que, quando há muitos parâmetros, o comando fica longo, pouco legível e difícil de manter.

Em produção, a prática padrão é gerenciar o Redis com um arquivo de configuração.

Por que usar um arquivo de configuração?

O arquivo de configuração oferece várias vantagens:

• Centraliza todas as configurações e facilita a consulta
• Permite controle de versão, por exemplo, armazenando o arquivo no Git
• Permite que a equipe compartilhe a mesma configuração
• Evita redigitar comandos ao alterar parâmetros

Para ser direto: se o seu Redis vai permanecer em execução por muito tempo, não corte caminho; use um arquivo de configuração.

Obtenha o arquivo de configuração padrão

O Redis fornece um arquivo de configuração padrão, que pode ser copiado do contêiner Docker:

mkdir -p ~/redis-config
docker run --rm redis:latest cat /etc/redis/redis.conf > ~/redis-config/redis.conf

Esse comando salva o arquivo de configuração padrão do Redis em ~/redis-config/redis.conf.

Personalize o arquivo de configuração

Abra redis.conf em um editor de texto, localize os itens abaixo e altere-os:

1. Configuração de rede

# Permite conexões de qualquer IP (em produção, prefira um IP da rede interna)
bind 0.0.0.0

# Desabilita o modo protegido (pode ser desabilitado depois que uma senha for configurada)
protected-mode no

2. Autenticação por senha

# Define a senha de acesso
requirepass YourStrongPassword123

3. Configuração de persistência

# Persistência RDB
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb

# Persistência AOF
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

# Persistência híbrida (Redis 4.0+)
aof-use-rdb-preamble yes

# Diretório de dados
dir /data

4. Limite máximo de memória

# Limita a memória máxima a 512 MB
maxmemory 512mb

# Política de remoção da memória: remove as chaves usadas menos recentemente
maxmemory-policy allkeys-lru

5. Configuração de logs

# Níveis de log: debug, verbose, notice, warning
loglevel notice

# Caminho do arquivo de log (uma string vazia envia a saída para a saída padrão)
logfile ""

Inicie o contêiner com o arquivo de configuração

Depois de editar o arquivo, use o parâmetro -v para montá-lo no contêiner:

docker run -d \
  --name redis-prod \
  -p 6379:6379 \
  -v ~/redis-config/redis.conf:/usr/local/etc/redis/redis.conf \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server /usr/local/etc/redis/redis.conf

Observe o trecho final, redis-server /usr/local/etc/redis/redis.conf. Ele informa ao Redis que o contêiner deve iniciar com o arquivo de configuração especificado.

Verifique se a configuração foi aplicada

Entre no contêiner e consulte os parâmetros:

docker exec -it redis-prod redis-cli -a YourStrongPassword123
config get save
config get appendonly
config get maxmemory

Se os valores retornados forem os mesmos definidos no arquivo, a configuração foi aplicada corretamente.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Configuração da autenticação por senha no Redis (três métodos)

Um caso real: o Redis de uma empresa estava sem senha e diretamente exposto à internet. O servidor foi invadido e transformado em uma máquina de mineração de criptomoedas. Não é brincadeira; isso realmente aconteceu.

Por que é obrigatório definir uma senha?

Por padrão, o Redis não tem senha. Qualquer pessoa pode se conectar e ler ou gravar dados. Se a porta do Redis estiver exposta à internet ou se a rede interna da empresa não for confiável, não usar senha equivale a deixar o serviço totalmente desprotegido.

Em produção, definir uma senha é o mínimo necessário.

Método 1: defina a senha por parâmetro de linha de comando

A forma mais simples é adicionar --requirepass ao iniciar o contêiner:

docker run -d \
  --name redis-pwd \
  -p 6379:6379 \
  redis:latest \
  redis-server --requirepass "MyStr0ng#P@ssw0rd"

Esse método serve para testes rápidos, mas não é adequado para produção, pois a senha fica exposta no histórico do terminal.

Método 2: defina a senha no arquivo de configuração (recomendado)

Adicione a seguinte linha ao redis.conf:

requirepass YourStrongPassword123

Depois, monte o arquivo de configuração e inicie o contêiner como explicado anteriormente.

Essa é a prática padrão em produção. A senha fica no arquivo de configuração, não aparece no histórico do terminal e pode ser gerenciada com mais facilidade pela equipe.

Recomendações de complexidade para a senha:

• Pelo menos 16 caracteres
• Letras maiúsculas e minúsculas, números e caracteres especiais
• Não use palavras comuns nem datas de aniversário

Método 3: defina a senha dinamicamente dentro do contêiner

Se o contêiner já estiver em execução e você quiser alterar temporariamente a senha, entre nele e execute:

docker exec -it redis-pwd redis-cli
config set requirepass "NewPassword123"

Observe que essa alteração deixa de valer após a reinicialização. Ela é útil em situações de emergência, mas não para uso permanente.

Conecte-se ao Redis com uma senha

Depois de definir a senha, há duas formas de se conectar ao Redis:

Opção 1: informe a senha diretamente na linha de comando

docker exec -it redis-pwd redis-cli -a "MyStr0ng#P@ssw0rd"

Opção 2: conecte-se primeiro e autentique-se depois

docker exec -it redis-pwd redis-cli
auth MyStr0ng#P@ssw0rd
set test "hello"

Se a senha estiver incorreta, será exibido o erro:

(error) NOAUTH Authentication required.

Nesse caso, basta autenticar novamente com o comando auth.

Configuração da conexão na aplicação

Se a aplicação precisar se conectar ao Redis, lembre-se de incluir a senha na string de conexão:

redis://:YourStrongPassword123@localhost:6379

Ou configure-a no código:

// Exemplo em Node.js
const redis = require('redis');
const client = redis.createClient({
  host: 'localhost',
  port: 6379,
  password: 'YourStrongPassword123'
});

Implantação com Docker Compose (recomendada para equipes)

Até aqui, iniciamos os contêineres com comandos docker run. A desvantagem é que esses comandos são longos e precisam ser digitados novamente a cada execução.

Se você trabalha em equipe ou precisa gerenciar vários contêineres, o Docker Compose é uma opção melhor.

Por que usar Docker Compose?

Vantagens do Docker Compose:

• A configuração fica no arquivo docker-compose.yml, que pode ser versionado
• Inicia tudo com um único comando, sem exigir que você memorize comandos complexos
• Permite que toda a equipe use a mesma configuração e mantenha ambientes consistentes
• Facilita o gerenciamento de vários contêineres, como Redis + MySQL + Nginx

Configuração completa do docker-compose.yml

Crie um arquivo docker-compose.yml:

version: '3.8'

services:
  redis:
    image: redis:7.2-alpine
    container_name: redis-prod
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - ./redis-config/redis.conf:/usr/local/etc/redis/redis.conf
      - ./redis-data:/data
    command: redis-server /usr/local/etc/redis/redis.conf
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

volumes:
  redis-data:
    driver: local

Principais configurações:

• image: redis:7.2-alpine: usa a versão leve baseada em Alpine
• restart: always: reinicia automaticamente o contêiner em caso de falha
• volumes: monta o arquivo de configuração e o diretório de dados
• healthcheck: verifica a integridade do Redis a cada dez segundos

Inicie tudo com um único comando

Depois de preparar o arquivo de configuração, execute no mesmo diretório:

docker-compose up -d

-d indica execução em segundo plano. O Docker Compose cria automaticamente a rede, monta o volume de dados e inicia o contêiner.

Consulte o status

docker-compose ps

Consulte os logs

docker-compose logs -f redis

-f mantém a saída dos logs em tempo real, de forma semelhante a tail -f.

Pare o contêiner

docker-compose down

Esse comando interrompe e exclui o contêiner, mas não remove o volume de dados; os dados continuam lá.

Reinicie o contêiner

docker-compose restart redis

Amplie a configuração

Se o projeto tiver outros serviços, você poderá gerenciá-los no mesmo docker-compose.yml:

version: '3.8'

services:
  redis:
    # Configuração do Redis...

  mysql:
    image: mysql:8.0
    # Configuração do MySQL...

  app:
    build: .
    # Configuração da aplicação...
    depends_on:
      - redis
      - mysql

Dessa forma, ao iniciar o projeto, Redis, MySQL e a aplicação são iniciados juntos, e as dependências também são processadas automaticamente.

Solução de problemas comuns e boas práticas

O contêiner Redis está funcionando, mas você certamente encontrará alguns problemas. Nesta seção, veremos como diagnosticar situações comuns e quais boas práticas aplicar em produção.

Consulte os logs do Redis

Quando houver um problema, a primeira reação deve ser consultar os logs.

Veja as últimas 100 linhas:

docker logs --tail 100 redis-prod

Acompanhe os logs em tempo real, como em tail -f:

docker logs -f redis-prod

Se você usa Docker Compose:

docker-compose logs -f redis

Os logs informam se o contêiner iniciou corretamente, se há erros no arquivo de configuração e se ocorreram conexões anormais.

Verificação de integridade do contêiner

A verificação de integridade permite que o Docker detecte automaticamente se o Redis está funcionando. Em caso de anomalia, o contêiner é reiniciado automaticamente.

Adicione ao docker-compose.yml:

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

healthcheck:
  test: ["CMD", "redis-cli", "ping"]
  interval: 10s
  timeout: 3s
  retries: 3

Isso executa redis-cli ping a cada dez segundos. Se três tentativas consecutivas falharem, o contêiner será marcado como não íntegro.

Se restart: always estiver configurado, um contêiner não íntegro será reiniciado automaticamente.

Recomendações de otimização de desempenho

1. Limite a memória máxima

Por padrão, o Redis usa toda a memória disponível. Em produção, é obrigatório definir um limite:

maxmemory 512mb
maxmemory-policy allkeys-lru

allkeys-lru significa que, quando a memória estiver cheia, as chaves usadas menos recentemente serão removidas.

2. Desabilite comandos perigosos

Alguns comandos são perigosos em produção, por exemplo:

• FLUSHALL: apaga todos os dados
• FLUSHDB: apaga o banco de dados atual
• KEYS *: lista todas as chaves e pode bloquear o Redis

Você pode desabilitá-los no arquivo de configuração:

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command KEYS ""

3. Ajuste a frequência da persistência

Se o volume de gravações for muito alto, você poderá aumentar o intervalo entre snapshots RDB:

save 900 1
save 300 10
save 60 10000

Essa é a configuração padrão e atende à maioria dos cenários. Se o Redis for usado principalmente como cache e a perda de dados não for crítica, você poderá usar intervalos menos frequentes.

Recomendações de segurança

1. Não exponha o Redis à internet

O Redis não deve ficar diretamente exposto à internet. Se o acesso remoto for indispensável, use um túnel SSH ou uma VPN.

No arquivo de configuração, vincule o serviço a IPs da rede interna:

bind 127.0.0.1 192.168.1.100

2. Use uma senha forte

A senha deve ter pelo menos 16 caracteres e incluir letras maiúsculas e minúsculas, números e caracteres especiais:

requirepass Th1s!sA$tr0ngP@ssw0rd2024

3. Faça backups periódicos

Mesmo com a persistência configurada, ainda é preciso fazer backups. Crie um script agendado que copie dump.rdb e appendonly.aof para um diretório de backup todas as madrugadas:

#!/bin/bash
DATE=$(date +%Y%m%d)
cp ~/redis-data/dump.rdb ~/redis-backup/dump-$DATE.rdb
cp ~/redis-data/appendonly.aof ~/redis-backup/appendonly-$DATE.aof

Checklist para produção

Antes de implantar o Redis, confira esta lista:

• ✅ A persistência foi configurada (o modo híbrido RDB + AOF é recomendado)
• ✅ A autenticação por senha foi habilitada
• ✅ O volume de dados foi montado em um diretório do host
• ✅ O arquivo de configuração foi personalizado, sem depender apenas da configuração padrão
• ✅ Os logs podem ser consultados normalmente
• ✅ A verificação de integridade foi configurada
• ✅ A memória máxima foi limitada
• ✅ Os comandos perigosos foram desabilitados ou renomeados
• ✅ Uma estratégia de backup periódico foi definida
• ✅ O Redis não está exposto à internet, ou o acesso usa VPN/túnel SSH

Monitore o desempenho do Redis

Entre no contêiner para consultar o uso de memória:

docker exec -it redis-prod redis-cli -a your_password
info memory

Consulte o status da persistência:

info persistence

Consulte o número de conexões:

info clients

Se você seguiu o artigo até aqui, já deve ter implantado com sucesso um contêiner Redis pronto para produção. Os dados estão persistentes, a autenticação por senha está ativa e a configuração foi padronizada.

Conclusão

Voltando ao cenário inicial: o Redis foi implantado na sexta à noite e, na segunda de manhã, todos os dados tinham desaparecido. Agora você sabe o motivo — a persistência não foi configurada, os dados ficaram dentro do contêiner e desapareceram na reinicialização.

Este artigo apresentou a solução completa:

• Persistência por snapshots RDB: salva os dados periodicamente, oferece recuperação rápida e é adequada para backups
• Persistência por log AOF: registra as operações de escrita em tempo real, oferece maior segurança e perde, no máximo, um segundo de dados
• Persistência híbrida (recomendada): combina as vantagens de RDB e AOF para oferecer recuperação rápida e segurança dos dados
• Autenticação por senha: três formas de configuração, obrigatória em produção
• Gerenciamento por arquivo de configuração: padroniza a implantação e facilita a manutenção e a colaboração da equipe
• Docker Compose: inicia tudo com um comando e transforma a configuração em código

Se você já usa Redis com Docker, verifique agora:

1. O volume de dados foi montado? (-v ~/redis-data:/data)
2. A persistência foi habilitada? (RDB, AOF ou modo híbrido)
3. Uma senha foi definida? (requirepass)
4. O arquivo de configuração foi personalizado? (Não dependa apenas da configuração padrão.)

Esses quatro itens são o mínimo para implantar Redis em produção. Com eles, você evita a perda de dados e acessos não autorizados.

Por fim, salve este artigo para consultar na próxima implantação do Redis. Se sua equipe também usa Docker para implantar Redis, compartilhe o guia para padronizar a configuração e reduzir a chance de repetir esses problemas.

As configurações deste artigo se baseiam no Redis 7.x. Se você usa outra versão, consulte a documentação oficial do Redis para confirmar se houve alterações nos parâmetros.