在项目里折腾过好几次 Redis 部署之后我现在的习惯基本就是一句话能用 docker 部署 redis 7就绝不在服务器上裸装。原因很简单容器把 Redis 的版本、配置、数据目录全部固化下来换机器、升级、回滚都变成了一条命令的事。这篇博文就围绕“docker 部署 redis7”这条主线把从环境检查、镜像拉取、配置挂载、数据持久化到生产级细节全部梳理一遍。适合第一次在服务器上跑 Redis 的新手也适合已经被“本机好好的一上生产就出问题”这类事折磨过的后端和运维同学。1. 为什么选 Docker 部署 Redis 7而不是直接装1.1 用 Docker 而不是裸装 Redis省下的是什么很多人会问服务器上直接apt install redis-server或者编译安装不也一样吗确实能跑但实际维护起来差别很大。裸装最大的问题是版本锁定在系统源里Ubuntu 20.04 默认源里的 Redis 还停在 5.xCentOS 7 的源更是老到没法看。你本地写代码用的可能是 Redis 7 的语法和特性一部署到服务器发现老版本根本不支持这种问题排查起来非常痛苦。用 Docker 部署之后版本完全由镜像 tag 决定我拉redis:7.2.4就是 7.2.4拉redis:7.0.15就是 7.0.15跟宿主机操作系统没有半点关系。升级的时候改一下 tag 重新起容器回滚就再改回旧 tag整个过程不超过一分钟。另外裸装 Redis 会在系统里留下一堆文件二进制、配置文件、日志、数据快照散落在不同目录卸载时很难清理干净。容器方式下所有东西都在挂载目录里不需要了docker rm -f一条命令宿主机上不会残留任何进程和文件。还有一点是资源控制。裸装的 Redis 默认可以吃满宿主机内存一旦maxmemory没设好OOM 直接拖垮整台服务器上的其他服务。Docker 方式可以用--memory和--cpus把 Redis 限制在一个可控范围内进程崩了也只是容器退出不影响宿主机其他应用。这对线上环境来说是非常重要的安全边界。1.2 Redis 7 里值得看一眼的新变化既然专门用 7自然要知道 7 带来了什么。我日常用到最多的三个变化第一个是 Redis Functions。Redis 7 允许你把 Lua 脚本封装成可管理的函数通过FUNCTION LOAD注册到服务端。相比传统EVAL脚本函数可以统一管理、动态更新在集群模式下不用手动同步到每个节点这对复杂业务逻辑落地很有帮助。第二个是 ACL 的增强。7.x 里 ACL 已经相当成熟可以精确到用户、键空间、命令类别、Pub/Sub 频道来做权限控制。以前只有一把requirepass万能钥匙谁拿到都能执行FLUSHALL现在可以给业务方单独建个只读用户只能访问指定前缀的 key风险隔离做得更细。第三个是 Sharded Pub/Sub。这是集群模式下的大改进旧版 Pub/Sub 在集群中一条消息会广播到所有节点分片 Pub/Sub 会把消息限制在相关分片内网络开销明显下降。除此之外7.x 在性能、内存碎片整理、大 key 删除策略上都有优化。所以新项目我直接上 7没必要再从 6 起步。如果你是从 6.x 升上来配置文件里有些默认值和语义有调整docker 方式方便你同时起一个 6 和 7 的容器对比验证数据迁移时这种“版本并行”能力很实用。2. 部署前的准备环境检查与镜像源加速2.1 先确认 Docker 环境是好的这一步看起来基础但很多问题都出在“以为 Docker 装上就能用”上。先在终端执行docker --version docker info能看到版本信息并且docker info正常输出环境才算基本可用。如果命令报Got permission denied while trying to connect to the Docker daemon socket说明当前用户不在 docker 组里。解决办法是sudo usermod -aG docker $USER执行完退出终端重新登录或者干脆重启一下一般就能解决。如果你在 Windows 上用 Docker Desktop最容易碰到的是启动时提示虚拟化没开启错误信息类似 “virtualization support not detected” 或者 “Docker Desktop failed to start because virtualisation support wasnt detected”。这个问题的根因——注意这个错误提示非常典型——多半是 BIOS 里的 VT-x/AMD-V 没打开或者 WSL2 相关 Windows 功能没有启用。处理顺序一般是重启进 BIOS 开启虚拟化然后在“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”再到 Windows 商店安装 WSL2最后重启 Docker Desktop。我见过不少人在这一步卡住实际上排查顺序对了百分之八九十都能解决。Linux 服务器上还有一种情况是 Docker 服务没起来用systemctl status docker能看到具体状态日志可以去/var/log/messages或者直接journalctl -u docker看。大多数时候是配置写错了导致 dockerd 无法启动把最近改动过的 daemon.json 还原就能定位。2.2 配置镜像源把拉镜像的速度救回来环境确认没问题之后第一件要做的不是急着拉镜像而是先把镜像源配好。默认从 Docker Hub 拉取镜像在国内很多时候慢得让人抓狂几 MB 的镜像等好几分钟都有可能。解决办法是在 Docker 的 daemon.json 里配置 registry-mirrors。Linux 下这个文件路径是/etc/docker/daemon.json如果文件不存在就新建一个{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com, https://docker.mirrors.ustc.edu.cn ] }Windows 的 Docker Desktop 更方便打开 Settings - Docker Engine直接把配置贴进去保存Docker 会自动重启。改完配置重启 Docker 服务sudo systemctl restart docker然后执行docker info在输出里找Registry Mirrors这一段能看到你配置的地址说明生效了。这里多说一句镜像加速源只对拉取 Docker Hub 官方仓库中的镜像起效不影响你 push 到自己私有仓库。另外公共镜像源偶尔会失效如果你发现某个源拉不动了删掉换一个就行多配几个坏的也不影响好的。这个操作的本质是给 Docker 加一层镜像下载的代理缓存和改任何系统网络配置都不沾边纯属 Docker 客户端层面的设置。2.3 拉取 Redis 7 镜像tag 怎么选镜像源配好之后拉取 Redis 7 镜像就很快了docker pull redis:7.2.4这里我不建议直接用redis:latest因为 latest 的指向会变今天部署的 7.2过段时间可能就变成 8.x 了线上环境最忌讳这种不确定性。生产环境一定要固定具体版本号。关于 tag 怎么选我整理了一个简单的对照tag基础镜像特点适用场景redis:7.2.4Debian完整版依赖齐全生产环境首选redis:7.2-alpineAlpine Linux体积小约 30MB测试环境、磁盘敏感场景redis:7Debian跟随 7.x 最新版滚动开发调试redis:latestDebian跟随最新大版本滚动不推荐生产使用如果你不是特别在意镜像体积生产环境我更推荐用不带-alpine的官方版本。Alpine 虽然小但它用的 musl libc 偶尔会跟某些需要编译扩展的场景不兼容Redis 本身没问题但排查问题的时候多一个变量总是不好的。拉完用docker images确认一下看到redis 7.2.4那一行就准备开始部署了。3. 从裸跑命令到带配置启动最基本的部署流程3.1 五分钟跑一个最小实例确认镜像没问题拿到镜像后第一件事我先跑一个最小实例确认这个镜像在环境里能正常工作再往里加配置。最小命令是这样的docker run -d \ --name redis7 \ -p 6379:6379 \ redis:7.2.4-d表示后台运行--name redis7给容器命名-p 6379:6379把宿主机 6379 端口映射到容器的 6379 端口。跑起来之后验证一下docker ps docker logs redis7 docker exec -it redis7 redis-cli ping正常情况下docker logs会输出 Redis 启动成功的日志redis-cli ping返回PONG。这一步确认了镜像本身没问题、端口映射正常、容器能访问。在这个最小配置下Redis 是以默认配置运行的没有密码、没有持久化、没有自定义参数。注意默认配置下 Redis 7 的protected-mode是开启的如果你没有设置密码并且bind的是0.0.0.0外部客户端连接会被拒绝只有本机可以访问。这个机制可以防止你裸奔到公网上但你后面要做本地开发或者在服务器间访问还是得显式配置。3.2 挂载 redis.conf让 Redis 按你的规则运行最小实例验证通过后就该把配置掌握在自己手里了。Redis 官方镜像里其实带了一份默认的 redis.conf 模板最稳妥的做法是先把它导出在此基础上修改mkdir -p /data/redis/conf /data/redis/data docker cp redis7:/usr/local/etc/redis/redis.conf /data/redis/conf/redis.conf docker rm -f redis7然后编辑这份 redis.conf重点改这几个配置项bind 0.0.0.0 protected-mode yes port 6379 daemonize no dir /data appendonly yes appendfilename appendonly.aof逐个解释。bind 0.0.0.0表示监听所有网卡容器网络里必须这么设因为外部访问经过端口映射后源 IP 是 docker 网桥的地址只监听127.0.0.1会导致外部永远连不上。protected-mode yes配合密码使用设置了密码后保护模式会自动放行。daemonize no这条非常关键容器启动时主进程必须在前台运行如果设成 yesRedis 会 fork 出子进程然后主进程退出容器检测不到前台进程会立即停止你看到的症状就是容器刚启动就 Exited。dir /data指定持久化目录appendonly yes开启 AOF 追加写。配置改好后用挂载方式启动docker run -d \ --name redis7 \ -p 6379:6379 \ -v /data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf \ -v /data/redis/data:/data \ redis:7.2.4 \ redis-server /usr/local/etc/redis/redis.conf注意命令末尾的redis-server /usr/local/etc/redis/redis.conf必须写。官方镜像默认的 CMD 是直接用内置配置启动 redis-server但你指定了挂载的配置文件路径后必须显式告诉 Redis 去加载这个文件否则挂载了也等于没挂载。3.3 数据持久化容器删了数据不能丢Redis 默认是纯内存数据库数据要持久化只能靠 RDB 快照或者 AOF 日志。RDB 是定时把全量数据 dump 到磁盘恢复快但可能丢最近几分钟的数据AOF 是追加每一条写命令最多丢 1 秒的数据我推荐至少开 AOF。配置里已经开启了appendonly yes现在把/data目录挂载出来数据就能保留在宿主机上。验证一下docker exec -it redis7 redis-cli set test 1 docker stop redis7 docker rm redis7 docker run -d \ --name redis7 \ -p 6379:6379 \ -v /data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf \ -v /data/redis/data:/data \ redis:7.2.4 \ redis-server /usr/local/etc/redis/redis.conf docker exec -it redis7 redis-cli get test执行完最后一步如果返回1说明数据在容器删除重建后依然存在。这个验证非常值得做很多人以为容器重启数据还在是理所应当的实际上不挂载数据目录的话容器一旦删除里面的数据就跟着没了。这里有个隐蔽的坑如果你用docker rm -v删除容器它会连匿名卷一起删掉。虽然我们这里用的是显式路径挂载-v /data/redis/data:/data不算是匿名卷但你要清楚这个行为差异。另外挂载目录的宿主机权限要注意容器内 Redis 进程是以 redis 用户运行的如果/data/redis/data的属主不对可能出现写入失败。稳妥的做法是chown -R 999:999 /data/redis/data999 是容器内 redis 用户的 uid。4. 生产环境更值得关注的四个细节4.1 密码与 ACL别只用一把万能钥匙生产环境不设密码等于把数据裸奔在网络上。最简单的配置是在 redis.conf 里加一行requirepass YourStrongPassword客户端连接时用redis-cli -a YourStrongPassword或者认证命令。但是requirepass本质上是一把万能钥匙所有操作权限都一样一旦泄露别人可以执行任意命令包括FLUSHALL、DEBUG这种危险指令。Redis 7 里 ACL 已经很好用了建议按业务划分用户。比如在 redis.conf 里这样配user default on nopass ~* * all user appuser on app123456 ~app:* get set ping这两行的含义是default用户保留全部权限但不给远程访问appuser用户密码是app123456只能操作app:前缀的 key只能执行GET、SET、PING三条命令。业务方即使拿到这个账号也无法读写其他 key更不可能执行危险的管理命令。在 Docker 容器里使用 ACL 文件需要注意一点aclfile配置项指定一个独立文件存放 ACL 规则Redis 运行期间通过 ACL 命令做的修改会写回这个文件。如果这个文件挂载自宿主机要确保容器内 redis 用户有写权限否则会出现运行时修改 ACL 报错的情况。另一个细节是密码不要直接写进docker run的命令行里因为命令会记录在 shell 历史中docker inspect也可以看到环境变量建议全部写在 redis.conf 文件中并把这个文件的权限改成 600。4.2 时区、日志和内核参数容器里容易被忽略的三件事容器内的默认时区是 UTC如果你直接把日志写到容器文件里时间会跟北京时间差 8 个小时排查问题时非常误导人。解决方案有两个启动时加环境变量-e TZAsia/Shanghai或者挂载宿主机时区文件docker run -d \ ... \ -e TZAsia/Shanghai \ -v /etc/localtime:/etc/localtime:ro \ ...日志方面如果 redis.conf 里logfile设为空字符串Redis 会把日志输出到 stdout这样可以直接用docker logs redis7查看非常方便。如果设成/data/redis.log日志会落盘在挂载目录里适合要长期留存日志的场景。我个人的偏好是开发环境用 stdout生产环境落盘方便日志采集。内核参数方面容易被忽略的是tcp-backlog。Redis 默认值 511但系统默认的net.core.somaxconn一般是 128高并发下连接排队会被截断。容器里调整系统参数需要在启动时加--sysctldocker run -d \ ... \ --sysctl net.core.somaxconn1024 \ ...另外maxmemory必须设置这是防止 Redis 吃光内存的最后防线。假设你打算限制容器内存 512MRedis 的maxmemory建议设置 350M 左右因为除了存储数据本身Redis 还要留出一部分内存给复制积压缓冲区、客户端输出缓冲区、AOF 重写临时内存等。具体计算方式可以按容器内存的 70%-80% 来预估网上有太多 OOM 事故是因为以为设置了maxmemory就能高枕无忧实际上没算这部分开销。4.3 容器资源限制与监控生产环境用 docker 部署 Redis我是强烈建议加资源限制的。启动命令里加上docker run -d \ --name redis7 \ --memory512m \ --cpus1 \ -p 6379:6379 \ -v /data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf \ -v /data/redis/data:/data \ redis:7.2.4 \ redis-server /usr/local/etc/redis/redis.conf--memory512m限制容器最多使用 512M 内存--cpus1限制最多使用 1 个 CPU 核心。有了这层限制即使 Redis 配置出了问题也不会拖垮整个宿主机。运行时的监控我常用这几个命令docker stats redis7 docker exec -it redis7 redis-cli info memory docker exec -it redis7 redis-cli --statdocker stats看容器整体资源占用redis-cli info memory看 Redis 内部的内存细分redis-cli --stat能实时滚动输出连接数、内存、命中率等关键指标。我一般关注used_memory占maxmemory的比例超过 80% 就要开始评估是否需要扩容或者调整淘汰策略。结合外部监控系统的话每隔几十秒执行一次redis-cli info把数据抓出来打点上报Redis 本身也会在日志里输出慢查询信息排查性能问题的时候都能用上。4.4 主从复制部署示例一个可以照抄的方案如果只有一台机器但你又想体验 Redis 7 的主从复制用 Docker 可以快速搭起来。关键是不要用--link这种老掉牙的方式直接用自建网络加容器名解析这是当前主流做法。先建网络docker network create redis-net准备一个 master 的配置文件主要开启 AOF 并设置密码然后启动 masterdocker run -d \ --name redis-master \ --network redis-net \ -p 6379:6379 \ -v /data/redis/master:/data \ -e TZAsia/Shanghai \ redis:7.2.4 \ redis-server /usr/local/etc/redis/redis.conf从节点的启动命令稍微加两个参数docker run -d \ --name redis-slave \ --network redis-net \ -p 6380:6379 \ -v /data/redis/slave:/data \ -e TZAsia/Shanghai \ redis:7.2.4 \ redis-server /usr/local/etc/redis/redis.conf \ --replicaof redis-master 6379 \ --masterauth YourStrongPassword这里--replicaof后面跟的是容器名而不是 IP这样容器重启后 IP 变了也能通过 Docker 内置 DNS 自动找到主节点避免了想用 IP 结果重启就失联的问题。验证复制是否生效redis-cli -p 6380 info replication输出里role:slave、master_link_status:up就说明成功了。在主库写入数据从库能查到就是正常的异步复制。需要注意的是 Redis 主从复制是异步的从库数据有短暂延迟不要在主库写入后立刻要求从库强一致返回。如果要搞读写分离业务上要能容忍这种秒级甚至毫秒级的延迟。5. 常见报错与排查思路5.1 Docker Desktop 起不来多半是虚拟化问题Windows 上 Docker Desktop 启动失败最常见的就是文章开头提到的虚拟化检测问题报错通常包含 “Virtualization support not detected”或者更详细的 “Docker Desktop failed to start because virtualisation support wasnt detected”。这类问题大概率是以下三种情况之一BIOS 里 CPU 虚拟化没开启VT-x/AMD-V 被禁用Windows 功能里“虚拟机平台”或“适用于 Linux 的 Windows 子系统”没打开WSL2 没有安装或者版本太老按顺序检查重启电脑进入 BIOS 开启虚拟化在“启用或关闭 Windows 功能”里勾选三项“虚拟机平台”、“适用 于 Linux 的 Windows 子系统”、“Hyper-V”部分版本需要然后以管理员身份运行命令wsl --update更新 WSL2 内核最后重启 Docker Desktop。我自己遇到过一次很诡异的情况BIOS 里虚拟化明明是开的但装完安全软件后虚拟化被禁用了查到最后才发现是安全软件的隔离功能动了设置。遇到这种报错可以先在任务管理器-性能-CPU 里看“虚拟化”状态是不是“已启用”有效快速定位。5.2 容器启动后秒退先看日志再动手容器启动后马上退出几乎每个人都会遇到。先执行docker ps -a找到那个 Exited 状态的容器然后看日志docker logs redis7日志一般会直接告诉你原因。最常见的几种配置文件里daemonize yes导致 Redis 进程在后台运行容器主进程退出容器跟着退出。解决改成daemonize no。配置文件某行语法错误日志里会显示类似Bad directive or wrong number of arguments的内容它会精确指出第几行找到这行检查即可。端口被占用日志会提示bind: address already in use因为宿主机 6379 端口已经被另一个进程占了可以用ss -lntp | grep 6379查看是谁然后换端口或者停掉占用进程。挂载的 redis.conf 路径不对容器启动时找不到文件直接报错检查挂载路径和启动命令里的配置路径是否一致。遇到秒退的时候我有一个高效调试方法不用-d后台跑改成前台运行docker run --rm -it \ -v /data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf \ redis:7.2.4 \ redis-server /usr/local/etc/redis/redis.conf这样所有报错会直接打在终端上比翻日志直观得多。5.3 外部连不上 Redis网络问题排查顺序容器在服务器上跑起来了本机docker exec执行redis-cli ping也通但外部客户端就是连不上。我一般按这个顺序排查第一步检查端口映射是否正常。docker ps看PORTS列有没有0.0.0.0:6379-6379/tcp如果没有对外映射外部自然访问不到。第二步检查 Redis 监听地址。登录容器执行docker exec -it redis7 redis-cli config get bind如果返回127.0.0.1改为0.0.0.0并重启容器。这一步非常常见因为 Redis 默认只监听回环地址。第三步看保护模式是否拦住了你。Redis 7 的protected-mode默认开启没有设密码时只允许回环地址访问外部连接会被拒绝。要么设一个强密码要么显式设置protected-mode no但我强烈建议设密码而不是关保护模式。第四步检查宿主机防火墙。Ubuntu 上可能是 ufw 拦了端口CentOS 上可能是 firewalld 拦了端口执行ufw status或firewall-cmd --list-all确认 6379 是否放行。还有云服务器的安全组这个是很多人忽略的安全组没放行端口本地防火墙放行也没用。如果是容器间互相访问不通大概率是网络没组对。两个容器必须在同一个 Docker 网络里才能通过容器名互相访问docker network ls查看网络列表docker inspect 容器名查看它属于哪个网络。跨容器访问不要用127.0.0.1去连另一个容器要用服务名因为每个容器有自己独立的网络命名空间。5.4 数据目录和权限类问题挂载数据目录后出现写入失败日志里显示Permission denied这种情况在 Linux 上很常见。原因多半是宿主机目录的属主和容器内进程的用户不一致。容器内 redis 用户 uid 通常是 999所以执行chown -R 999:999 /data/redis/data如果系统启用了 SELinux即使权限正确也可能被拦截此时挂载时加:z后缀即可-v /data/redis/data:/data:zz是让 Docker 自动给挂载目录设置正确的 SELinux 标签只对单容器访问安全如果多个容器共享这个目录可以用:Z。还有一类问题是 AOF 文件异常Redis 启动时可能会拒绝加载损坏的 AOF 文件报错Bad file format reading the append only file。通常是突然断电或磁盘空间不足导致的可以先用redis-check-aof --fix appendonly.aof修复修复前记得备份原文件。我把常见的权限和目录问题整理成了个速查表现象可能原因解决方式容器启动后落盘失败挂载目录属主不是 999chown -R 999:999容器被 SELinux 拦截SELinux 标签未设置挂载加:z或:ZAOF 文件损坏、启动失败断电、磁盘不足用redis-check-aof --fix修复配置文件只读导致运行时 ACL 写入失败宿主机文件权限过紧调整容器内 redis 用户写权限6. 一些实际踩坑后的经验补充前面把主流程和常见问题都写完了最后分享几个我实际踩过、特别想提醒你的细节。第一个是固定版本号。我见过太多人图省事直接docker run redis默认拉 latest结果某天重新部署发现 Redis 版本变了配置文件里某个参数过期不生效整个业务告警。线上环境一定要用带小版本的 tag比如redis:7.2.4升级时主动换 tag而不是被动被 latest 牵着走。第二个是配置文件统一管理。我现在的习惯是把 redis.conf、启动命令、挂载目录结构全部放进项目仓库的 deploy 目录里服务器上只留一份数据。这样换机器、恢复环境时拉下来代码照着命令敲一遍五分钟就能把 Redis 重新跑起来不用每次重新回忆“当初那个配置文件到底放哪了”。第三个是关于容器内daemonize的教训。第一次用 Docker 部署 Redis 时我把宿主机那套配置原封不动搬进去忘了改daemonize no结果容器一直在重启循环。后来慢慢理解到Docker 容器和传统进程管理的逻辑完全不同容器生命周期的核心是前台进程daemonize必须关闭。类似地如果你用 systemd 管理 Redis 的很多经验都不能直接迁移到容器里要按容器的规则重新审视。docker 部署 redis7 这条路把部署动作标准化之后省下的是大批重复劳动。按照这套流程走下来你得到的不只是能跑的 Redis而是一套可复制、可回滚、可监控的部署方案。如果你在部署过程中遇到上面没提到的问题欢迎留言一起讨论。