企业官网建设流程全解析

1. 从“裸奔”到“有锁”：为什么docker里的redis必须设置密码

新装一个docker版的redis其实是件特别顺手的事，docker pull redis、docker run -d -p 6379:6379 redis两条命令下来，一个可用的redis实例就跑起来了。但如果你把它直接丢到公网服务器上，或者放在团队共享的开发机里，问题就来了：redis默认是没有任何认证机制的，只要你暴露了6379端口，任何能连到这台机器的人都能往里面读写数据。

我见过不少团队在测试环境里把redis裸奔了几个月，直到某天发现数据库里的key被清空、还多了一堆莫名其妙的挖矿任务，才意识到问题有多严重。redis本身没有内置的账号体系，它在设计上假设“运行环境是可信的”，所以它的安全防线很薄。你要是真指望它默认就安全，大概率要吃亏。

docker里设置redis密码这事儿，本质上就是在容器化环境下把redis的认证能力打开。它和直接在宿主机上装redis不太一样的地方在于：你不仅要考虑redis本身的配置，还要考虑容器环境下的文件挂载、启动参数、连接方式，以及和docker compose等编排工具的配合。这篇文章就从实战角度，把docker + redis设置密码这件事拆开了聊。

适合来看这篇内容的人：正在用docker部署redis的开发者、团队里负责环境搭建的运维新手、以及那些明明配了密码却总是不生效想搞清楚原因的同学。

2. 核心方案选型：设置redis密码的三条主流路线

2.1 路线一：启动时直接加启动参数（最快速的方式）

docker跑redis，其实底层跑的是redis-server这个进程，所以你可以在启动容器的时候，给它传一个--requirepass启动参数。这个参数是redis内置的配置项，作用是设置客户端连接时的密码校验。

对应的docker命令长这样：

docker run -d --name redis-demo \ -p 6379:6379 \ redis:7.2 redis-server --requirepass mysecretpassword

注意在redis:7.2镜像后面跟了redis-server --requirepass xxx，这段其实就是覆盖了镜像默认的启动命令。原来默认的是redis-server（后面不跟参数，读取容器内默认配置），现在你额外加了一个启动参数，redis启动后就会启用密码校验。

这种方式的优点是快、直接、不用准备配置文件。但它有两个弊端：第一，密码直接写在docker run命令里，会出现在shell的历史记录中，也会出现在docker inspect的输出里，属于一种“半暴露”状态；第二，如果需要设置很多配置项，参数会拉得很长，可维护性差。它更适合临时起一个实例验证、或者快速搭个开发环境。

2.2 路线二：挂载自定义redis.conf（最规范的方式）

生产环境更推荐的方式是：准备一份redis配置文件，通过容器卷挂载进容器里，让redis-server启动时读取它。也就是配置文件里写requirepass，启动时用redis-server /path/to/redis.conf来加载。

做法大概是这样的：

# 第一步，在宿主机准备一份redis.conf mkdir -p /data/redis-conf cat > /data/redis-conf/redis.conf <<'EOF' requirepass MyStrongPass123 appendonly yes EOF # 第二步，挂载配置文件启动容器 docker run -d --name redis-demo \ -p 6379:6379 \ -v /data/redis-conf/redis.conf:/etc/redis/redis.conf \ redis:7.2 redis-server /etc/redis/redis.conf

这种方式的好处是：所有redis配置都收敛在一个文件里，后续要调整maxmemory、appendonly等配置，改文件重启容器就行，清清楚楚。团队成员之间复制配置也方便，配置管理进入版本控制也成为可能。

但这里有一个细节容易被忽略：挂载配置文件的时候，容器内redis进程是用什么用户跑的？官方镜像默认是用redis用户，配置文件如果所属用户不对，或者容器内路径没有读权限，redis起不来。大部分情况下挂载的宿主文件权限默认是644，可以被读，但如果遇到奇怪的问题，先检查一下权限。

2.3 路线三：容器内执行CONFIG SET动态修改（临时方案，不推荐用于生产）

还有一种既便捷又危险的方式：容器已经跑起来了，想临时加个密码，直接进入容器里执行redis命令动态设置：

docker exec -it redis-demo redis-cli CONFIG SET requirepass "anotherpassword"

执行完之后，redis会立刻要求客户端输入密码才能继续操作。注意，这里用的是CONFIG SET，它修改的是运行时配置，如果你不执行CONFIG REWRITE，重启容器之后这个设置就丢了。而且官方镜像默认的redis.conf里其实没有开启CONFIG REWRITE的能力，所以这个方案基本上只是“救急”用的。

它的适用场景是：你正在排查问题，临时想把一个裸奔的redis加个锁，先挡一下外部的访问。真要长期用，还是得回归到配置文件方案。

2.4 三种方案怎么选：一张表看明白

说到底，选择哪条路取决于你的场景。我个人体会是：不管哪条路，密码都不要用太简单的，而且要记得redis的密码是直接作为命令行参数或者配置文件明文存在的，这意味着谁能拿到服务器权限、谁能看到进程列表或者配置文件，就能看到密码。所以真正严谨的部署，还得配合防火墙规则、网络隔离一起做，redis本身的密码只是第一道防线。

3. 实操全程记录：从拉取镜像到验证密码生效

3.1 环境准备与镜像选择

先确认你机器上已经有docker环境。如果还没装，去docker官网下载对应系统的安装包，装完记得把当前用户加进docker用户组（Linux环境），或者直接装docker desktop（Windows / macOS）。

然后拉取redis镜像。官方镜像的tag对应redis版本号，比如redis:7.2、redis:6.2。建议直接用带具体版本号的tag，不要用latest，因为latest会漂移，今天部署和半年后部署拉到的镜像可能不一样，排障的时候很痛苦。

docker pull redis:7.2

拉到本地后，可以通过docker images确认一下镜像已经存在：

docker images | grep redis

输出类似：

redis 7.2 a0b8d0e5... 3 weeks ago 117MB

3.2 第一步实践：先用启动参数快速验证

我们先用最简单的启动参数方式跑一个实例，确认密码机制是有效的。

docker run -d --name redis-quick \ -p 6379:6379 \ redis:7.2 redis-server --requirepass quickpass123

跑起来之后，验证密码是否生效。连接的时候，不带密码连一下看看：

docker exec -it redis-quick redis-cli

进去后执行个PING，大概率看到：

(error) NOAUTH Authentication required.

这就对了，说明redis已经要求认证了。然后用带密码的方式连：

docker exec -it redis-quick redis-cli -a quickpass123

执行PING，得到PONG。这一步通了，说明密码机制已经生效。

这里有个小坑：用-a参数的时候，redis-cli会提示“Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.”这个警告是因为密码会出现在进程参数里，能被ps命令看到。在本机调试无所谓，但如果是挂在公网或者多用户共用的机器上，要留意这个问题。更安全的做法是不带-a进入交互模式后，再用AUTH quickpass123手动认证：

docker exec -it redis-quick redis-cli AUTH quickpass123

3.3 第二步实践：用配置文件挂载方式完整搭建

快速验证没问题后，我们正式走一遍配置文件方案。这个步骤适合直接抄到生产环境。

先在宿主机上准备目录和配置文件：

mkdir -p /data/redis-demo/conf mkdir -p /data/redis-demo/data

把配置文件写到/data/redis-demo/conf/redis.conf：

cat > /data/redis-demo/conf/redis.conf <<'EOF' # 绑定监听地址，0.0.0.0表示所有网卡都能访问 bind 0.0.0.0 # 端口 port 6379 # 密码 requirepass ProdRedis@2024 # 开启AOF持久化 appendonly yes appendfilename "appendonly.aof" # 开启RDB持久化 save 900 1 save 300 10 save 60 10000 # 日志级别 loglevel notice # 最大内存限制，根据实际机器调整 maxmemory 512mb maxmemory-policy allkeys-lru EOF

然后启动容器：

docker run -d --name redis-prod \ -p 6379:6379 \ -v /data/redis-demo/conf/redis.conf:/etc/redis/redis.conf \ -v /data/redis-demo/data:/data \ redis:7.2 redis-server /etc/redis/redis.conf

这里要做几个关键说明：

第一，挂载了两个目录：一个是配置文件，一个是数据目录。数据目录挂载出来是为了让redis的RDB快照和AOF日志保存在宿主机上，这样容器删了、换了、重启了，数据还在。

第二，启动命令redis-server /etc/redis/redis.conf是显式指定配置文件路径。你不指定的话，它默认读容器内的/etc/redis/redis.conf，但那个文件是镜像自带的默认配置，没有你的密码配置。所以这一步必须显式写。

第三，配置里的requirepass如果用特殊字符（比如$、>），在shell里写的时候要注意转义。所以我在示例里用了ProdRedis@2024这种相对安全的组合。真要放$这种字符，建议用单引号包裹整个密码值。

启动后，先看容器状态：

docker ps | grep redis-prod

再查看日志，确认redis正常启动：

docker logs redis-prod

日志末尾会有一条类似：

1:M 2025... * Ready to accept connections tcp

看到这条，说明redis已经正常起来了。

然后验证密码：

docker exec -it redis-prod redis-cli -a 'ProdRedis@2024' PING

返回PONG，密码生效。

3.4 验证配置持久化：重启容器，再看看密码是否还在

很多人设置完密码后，最担心的就是“重启之后密码还在不在”。我们用最朴素的方式检验一下：

docker restart redis-prod

重启完成后，再执行一次带密码的PING，看能否通过：

docker exec -it redis-prod redis-cli -a 'ProdRedis@2024' PING

如果返回PONG，说明密码已经通过配置文件持久化，不会因为容器重启而丢失。这一步非常关键，因为如果你用的是CONFIG SET方式，重启后密码就没了，反而会给你一种“已经设置了密码”的错误安全感。

3.5 进阶：把这套配置迁移到docker compose

用docker run命令跑容器，参数一多看起来很乱，而且在团队协作时，别人看不到你启动容器的完整参数。更规范的做法是写成docker compose文件，把整个部署环境描述成代码。

在/data/redis-demo目录下创建docker-compose.yml：

version: '3.8' services: redis: image: redis:7.2 container_name: redis-prod restart: always ports: - "6379:6379" volumes: - ./conf/redis.conf:/etc/redis/redis.conf - ./data:/data command: redis-server /etc/redis/redis.conf environment: - TZ=Asia/Shanghai

然后在同目录下执行：

docker compose up -d

compose会按照配置文件创建并启动容器。看日志、验证密码的方法和上面一样。有了compose之后，整套环境的启停变得非常简单：

docker compose down # 停止并删除容器 docker compose up -d # 重建并启动 docker compose logs -f redis # 跟踪日志

一个小建议：docker compose down会把容器删掉，但你挂载出来的数据目录不受影响，所以不用担心数据丢失。但如果用了匿名卷或者没挂载数据目录，那容器删了数据也就没了，生产环境千万要注意。

4. redis客户端连接：带密码之后怎么连

4.1 命令行客户端连接

容器内连接，我们已经演示过了，用docker exec -it redis-prod redis-cli -a '密码'。这里有一个常用的写法：连进容器后用sh执行redis-cli，好处是redis-cli的版本和容器内的redis服务完全匹配：

docker exec -it redis-prod sh -c 'redis-cli -a "ProdRedis@2024" PING'

宿主机上如果也装了redis-cli（版本接近），可以直接连宿主机的映射端口：

redis-cli -h 127.0.0.1 -p 6379 -a 'ProdRedis@2024'

4.2 可视化工具连接

很多团队会用Redis Desktop Manager（现在新版叫Redis Insight，老的RDM也可以继续用）来连接redis。需要填的参数无非是host、port、password三样。注意一点：如果用docker端口映射，host填宿主机的IP，port填映射到宿主机的端口（默认6379），password填redis的requirepass值。

这里特别提醒一个容易踩的坑：如果容器是用-p 6379:6379启动的，而且redis.conf里bind设置的是127.0.0.1，那么外部工具是连不上的，因为redis只监听容器内的回环地址。要让外部客户端能连，bind要么不写，要么写0.0.0.0。如果是公网环境，建议配合防火墙只让指定IP访问。

4.3 密码和连接串的常见困惑

很多新手分不清redis的密码和连接串密码是两个不同的东西。redis的requirepass是认证密码，不管你用什么客户端，连接时提供这个密码就能通过认证。这和MySQL的多账号体系不太一样，redis在6.0之前只有单一的密码机制，从6.0开始才引入了ACL，可以设置多用户、多权限。

如果你是redis 6.0以上版本，其实还可以用ACL的方式创建独立的用户。比如只允许某台机器做只读操作，可以创建一个只读账号。当然，日常需求简单的话，requirepass就够了，ACL属于锦上添花。

5. 常见问题与排查技巧实录

5.1 密码设置后不生效：多半是配置文件没被加载

一位同事跑过来跟我说，他在redis.conf里写了requirepass，但连上去完全不需要密码。我让他看了一下docker run的启动命令，发现他用的是默认启动命令：docker run ... redis:7.2，压根没加redis-server /etc/redis/redis.conf。镜像默认启动命令会加载它自己的默认配置，你的配置文件根本没进去。

排查思路很简单：进容器里看一眼当前配置：

docker exec -it redis-prod redis-cli CONFIG GET requirepass

如果返回空值，说明你的配置文件确实没被加载。检查启动命令是否显式指定了配置文件路径；检查挂载路径是否正确；检查容器内路径是否和启动命令里写的路径一致。

还有一种情况是：配置文件挂载了，但redis运行时报“无法解析配置文件”之类的错误，容器根本没起来。这类问题看日志就能定位：

docker logs redis-prod

5.2 忘记密码了怎么办：三种思路

这个问题在开发环境经常出现。不说别人，我自己都干过这事儿。忘了redis密码，连都连不上去，怎么处理？

思路一：如果redis是在容器里跑的，停掉容器，用临时容器挂载同一个数据目录启动一个不带密码的redis实例，然后把密码改回来。步骤大概是：

# 停掉原容器 docker stop redis-prod docker rm redis-prod # 用临时容器，不带密码启动，挂载原数据目录 docker run -d --name redis-reset \ -p 6380:6379 \ -v /data/redis-demo/data:/data \ redis:7.2 # 进入临时容器，手动设置密码 docker exec -it redis-reset redis-cli CONFIG SET requirepass "NewPass123" CONFIG REWRITE

注意，CONFIG REWRITE会把你当前的运行时配置写入配置文件，但前提是容器里有配置文件且该文件可写。如果你挂载的是自己的redis.conf，这种方式是可以把密码写进去的。如果容器里没挂配置文件，CONFIG REWRITE会失败。

思路二：直接改宿主机上挂载的redis.conf，把requirepass改了，然后重启容器。这是最直接的，前提是你有宿主机权限。

思路三：如果连挂载的配置文件都没改过，那么可以直接改容器内配置。但容器内文件修改不持久，重启又恢复了。所以最终还得回到思路一或思路二。

5.3 客户端能ping通主机，但连不上redis：网络和bind的坑

有次我排查一个连不上redis的问题：客户端和宿主机网络通的，宿主机6379端口也处于监听状态，但客户端就是认证失败。

最后查出来，是redis.conf里的bind配置有问题。redis在较新版本默认bind 127.0.0.1 -::1，只监听回环地址。如果你用docker端口映射，从宿主机外部访问容器时，连接实际上是从宿主机的docker网关进入容器的。redis只监听容器内的回环地址，那外部连接根本到不了redis进程。

解决方法是把bind配置改成0.0.0.0（也就是监听所有网卡），或者干脆注释掉bind这一行。注意：bind 0.0.0.0意味着容器内所有网络接口都监听，配合docker的端口映射，外部才能访问。但公网环境下一定要配合防火墙，否则redis真的对全网开放了。

5.4 容器起不来：配置文件参数写错了

redis.conf里每一项配置都有严格的格式要求，比如requirepass后面必须跟一个空格，maxmemory必须带单位。有次我在maxmemory后面直接写了512，没带单位，redis认为单位是字节，导致内存限制被设置成512字节，然后redis启动就报错或者疯狂淘汰key。这种问题看日志才能发现，日志里会明确告诉你哪一行配置有问题。

如果你不想用配置文件，只想用启动参数，那参数的名字必须和redis配置项一一对应，比如--requirepass，注意两个短横线的格式，少一个都不行。

5.5 密码里有特殊字符：shell转义问题

密码如果包含$、!、&、空格这类特殊字符，在docker run命令行里很容易被shell解释掉。比如你写--requirepass pas$word，shell会把$word当成变量替换，结果密码变成了pas加个空值，和你想要的根本不一样。

解决方法是：命令行里用单引号包裹密码，例如--requirepass 'pas$word'。配置文件里同理，但配置文件中如果密码包含#，注意#开头会被当成注释，所以密码不要用#开头。

5.6 主从复制的密码问题：masterauth

如果搭的是redis主从架构，从节点连接主节点做同步的时候也需要认证。这时候除了requirepass，从节点的配置里还要设置masterauth，指定主节点的密码。很多人只设置了requirepass，结果主从同步一直失败，日志里报MASTER <-> REPLICA sync started然后马上断开。

处理方式：

# 从节点配置 requirepass 从节点自己的密码 masterauth 主节点的密码

如果用的是docker compose搭主从，也要同步设置这几个配置。

6. 把密码当最后一道防线：docker + redis安全加固的完整思考

设置密码是第一步，但不是全部。我在实际运维中发现，很多人以为redis设置了密码就万事大吉了，其实不然。redis的密码机制本身有个弱点：它通过明文传输密码，在网络抓包的情况下，密码等同于暴露。所以如果是跨网络访问redis，强烈建议走TLS加密或者内网隔离。

有一种常见的加固组合拳：

• 在云服务器安全组或本机防火墙层面，限制6379端口只允许业务机器IP访问，而不是对全网开放。
• 容器网络层面，尽量使用docker自定义网络，让redis容器不要暴露宿主端口，只有需要访问redis的容器接入同一网络，通过容器名互通。这样可以做到redis完全不出宿主机。
• 如果一定要映射端口到宿主机，至少不要映射到0.0.0.0，可以只绑定到内网网卡IP上，比如-p 192.168.1.100:6379:6379。

这些措施配合requirepass，才是真正比较稳妥的redis公网安全方案。密码是第一道防线，但不是唯一防线。

遇到要求protected-mode（保护模式）的场景也别慌。redis默认开启protected-mode，它会在没有密码且没有绑定内网地址的情况下，拒绝外部连接。这个其实是个保护机制，你设置了requirepass，并且bind 0.0.0.0，protected-mode一般不会捣乱。但如果遇到“本地能连、远程连不上”的情况，可以检查一下CONFIG GET protected-mode的值。

7. 一个小技巧：用环境变量配合compose管理密码

最后分享一个实用的技巧。直接用明文写在docker-compose.yml里的密码，会被提交到git仓库里，存在泄露风险。一个相对简单的处理办法是：把密码放到宿主机的一个环境变量文件里，compose启动时引用它。

比如在/data/redis-demo/.env文件中：

REDIS_PASSWORD=ProdRedis@2024

然后在docker-compose.yml中通过变量替换引用：

version: '3.8' services: redis: image: redis:7.2 container_name: redis-prod restart: always ports: - "6379:6379" volumes: - ./conf/redis.conf:/etc/redis/redis.conf - ./data:/data command: sh -c 'redis-server /etc/redis/redis.conf --requirepass $$REDIS_PASSWORD' environment: - REDIS_PASSWORD=${REDIS_PASSWORD}

注意这里的$$REDIS_PASSWORD是compose的转义写法，表示把它转成容器内的环境变量引用，而${REDIS_PASSWORD}是在宿主机层面从.env文件读取。这样redis启动后，密码通过环境变量传给容器，不会直接出现在compose文件里。

不过说实话，这种方式也有缺点：通过命令行传参，意味着在容器内的进程列表中可以看到密码。更严格的做法是使用docker secret这类密钥管理机制，比如配合docker swarm或者外部密钥管理服务。但对于大多数中小团队来说，用.env文件配合.gitignore把.env排除在版本控制之外，已经比把密码直接写进compose好很多了。

我在实际项目里更常见的做法是：redis容器的密码写入配置管理系统的统一变量里，部署时动态生成redis.conf，完全不落盘明文密码。但这个属于DevOps范畴了，不同公司脚手架不一样，这里就不展开了。