1. 在RHEL8上装Docker之前，必须先理解系统自带容器生态的那点事
很多人拿到一台全新的RHEL8服务器，第一反应就是敲yum install docker，结果发现装出来的是一个叫podman的东西，Docker 命令却不存在。这不是你操作有问题，而是 RHEL 8 在设计上的一个明确选择：系统默认集成了 Podman、Buildah、Skopeo 这套容器工具链，官方仓库里的 "docker" 包其实是兼容层（docker命令会映射到 Podman）。
这个差异在平时用起来可能感受不明显，但一旦你习惯了 Docker Compose、需要 Docker 守护进程（daemon）的完整行为，或者要对接某些只认 Docker API 的 CI/CD 工具，默认这套方案就会让你觉得别扭。比如 Podman 默认是无守护进程的，每个容器由独立进程管理，这本来是很先进的设计，但反过来也意味着很多“围绕守护进程做文章”的老牌运维脚本、监控探针、自动扩容组件并不直接兼容。
所以，如果你在 RHEL8 上确实需要原生 Docker Engine，核心思路就一条：走 Docker 官方提供的软件仓库来安装docker-ce，而不是依赖系统自带的模块化包。Docker 官方仓库虽然名为docker-ce-stable，但它兼容 RHEL、CentOS 这类基于 RPM 的发行版，安装源指向download.docker.com即可。
动手之前，先确认三件事：
- 系统是否已经注册并启用订阅（RHEL 需要能访问 BaseOS/AppStream 仓库，否则依赖解析会失败）。
- 是否已经存在
podman-docker、runc、containerd.io之类的包，如果有，需要评估冲突风险。 - 磁盘分区是否足够——Docker 的镜像和容器数据默认全放在
/var/lib/docker，这块分区建议至少留 20GB 以上，后续拉镜像、跑日志都会往这儿写。
我在实际项目中见过不少被这第三点坑到的情况：有人只留了 5GB，拉了两三个镜像以后磁盘直接打满，容器日志和镜像层混在一起，排查起来特别痛苦。所以麻烦一点，先df -h看清楚容量再继续。
2. 配置 Docker 官方仓库并在线安装 docker-ce：完整命令与验证
刚才说过，RHEL8 自带的包源里没有真正的 Docker Engine，所以要先把 Docker 官方仓库加到 yum 配置里。
# 安装 yum-utils，它提供 yum-config-manager 工具 sudo yum install -y yum-utils # 添加 Docker 官方稳定仓库 sudo yum-config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo这里有一个细节值得说明：yum-config-manager --add-repo会把仓库文件写到/etc/yum.repos.d/docker-ce.repo，内容指向 Docker 官方的 RHEL 专属目录。注意 URL 里的路径是linux/rhel，不是linux/centos。虽然 CentOS 和 RHEL 的包在很多情况下能通用，但既然系统是 RHEL8，就直接用对应的仓库地址，避免后续拉取到不匹配的依赖。
添加完仓库之后，直接安装：
sudo yum install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin到这里很多新手会问：containerd.io是什么？它其实是一个独立的容器运行时，负责镜像解压、容器生命周期管理等底层工作。Docker Engine 在较新版本中把 containerd 作为默认底层运行时来使用。它单独作为一个包安装，好处是版本可以独立升级，万一 Docker 主程序出问题，运行时层面还能单独排查。
我当时还踩过一个版本匹配的坑。RHEL8 的 AppStream 仓库里自带了一个containerd.io的旧版本包，如果你不加 Docker 仓库、直接yum install docker，系统可能把旧版 containerd 拉进来，后面启动 Docker 时会因为版本不匹配直接报奇怪的错误。所以，明确指定从 Docker 官方仓库安装这三个包，并且观察 yum 的解析结果，确认它选择的 containerd.io 版本是官方仓库里的，这一步很重要。
安装完成后，先别急着启动，做两件事：验证命令版本、确认软件来源。
# 查看安装的版本，确认 docker 命令可用 docker version此时大概率会看到 “Client” 部分的版本信息，但 “Server” 部分会显示错误，因为守护进程还没启动。不用慌，这是正常现象。
# 启动 Docker 服务并设置开机自启 sudo systemctl start docker sudo systemctl enable docker # 查看服务状态 sudo systemctl status docker服务状态应该是active (running)。如果启动失败，大概率是 SELinux 上下文或者依赖包缺失，这个放到后面第 5 章专门讲。服务跑起来之后，再执行一次：
docker version这次 Client 和 Server 两块都有版本信息，说明架构正常了。为了确认整个链路真的能用，跑一个最经典的验证命令：
sudo docker run --rm hello-world能正常打印出Hello from Docker!那段说明，就代表容器运行时、镜像拉取、名称解析这些核心环节全部通畅。--rm参数表示运行结束后自动删除容器，避免测试残留浪费磁盘。
3. 拉取 nginx 镜像前的网络与存储配置：这些检查不能跳过
很多人走到上一步就急着docker pull nginx，其实在 RHEL8 环境里，拉镜像之前最好把两件事确认好：防火墙对容器端口转发的影响，以及存储驱动的类型。这两件事都属于“提前做好不用花几分钟，事后出了问题要折腾一下午”的类型。
先看存储驱动：
docker info | grep -i storage正常情况下应该显示overlay2。RHEL8 的内核默认支持 overlay2，这也是目前 Docker 官方推荐的驱动。我在某台老内核的机器上见过驱动被自动降级成vfs的情况，那是一种纯文件复制方案，每次创建容器层都要完整复制镜像内容，性能和磁盘占用都很难看。如果是vfs，多半是你的内核模块没加载完整，试试更新系统内核再重启。
接着看防火墙。RHEL8 默认启用firewalld，它对 Docker 的端口映射并不总是“主动放行”。Docker 在创建端口映射时会在 iptables 里写入自己的规则，这本来是没问题的，但 firewalld 的富规则、直接规则可能会和 Docker 的规则产生冲突，导致容器端口在宿主机外访问不通。
在这个阶段，先确认一下计划要用的端口。nginx 默认监听 80，如果你不想直接占用 80（比如宿主机上已经有别的 Web 服务），可以映射到 8080 或某个高位端口。这一步想清楚，后面运行容器的命令写起来就顺了。
顺便说一句，访问 Docker Hub 拉取镜像需要在服务器上具备正常的 HTTPS 出口。如果公司网络有代理，不要忘了在 Docker 服务配置文件里写入代理环境变量，路径是/etc/systemd/system/docker.service.d/http-proxy.conf，否则docker pull会一直卡在等待连接。
我在一台客户服务器上遇到过 ping 外网正常、curl 外网也正常，但docker pull nginx死活超时的怪事，最后定位到问题出在/etc/resolv.conf里的 DNS 配置——宿主机用的 DNS 只对宿主机解析生效，但容器网络模式下 DNS 解析路径不一样。简单粗暴的解法是临时给宿主机配一个公共 DNS 再拉镜像，或者把容器的 DNS 显式指到宿主机。
网络和存储这两项都确认完后，就可以正式拉取 nginx 镜像了。
sudo docker pull nginx这个命令会从 Docker Hub 拉取nginx:latest镜像。如果希望固定大版本，避免以后latest漂移导致行为变化，更稳妥的做法是带版本号拉取：
sudo docker pull nginx:1.27-alpine用alpine变体的原因是镜像体积小（大约 50MB，相比官方debian变体的 190MB 小很多），而且不少生产环境里 nginx 跑的就是 alpine，安全性、维护性都有保障。
4. 运行 nginx 容器：端口映射、目录挂载和验证访问
镜像拉好后，第一次运行建议用前台方式快速验证，或者直接后台启动加查看日志的方式。我习惯用下面的命令一步到位：
sudo docker run -d \ --name nginx-web \ -p 8080:80 \ nginx:1.27-alpine解释一下每个参数：
-d：后台运行容器，不挂在前台终端。--name nginx-web：给容器起一个有意义的名字，之后管理起来不用记一长串容器 ID。-p 8080:80：把宿主机的 8080 端口映射到容器内部的 80 端口。nginx:1.27-alpine：指定镜像及其标签。
运行成功后，用下面几条命令依次确认状态：
# 查看容器是否处于 Up 状态 sudo docker ps # 查看容器的详细端口映射 sudo docker port nginx-web # 在宿主机上直接测试容器内服务是否响应 curl -I http://127.0.0.1:8080curl返回HTTP/1.1 200 OK就说明 nginx 已经正常响应了。这时如果浏览器打不开，问题基本锁定在 firewalld 防火墙，而不是容器本身。
说到目录挂载，这是运行 nginx 时最有价值的进阶操作。默认的 nginx 镜像只带一份默认页面，你不可能每次改 HTML 都进容器里操作，所以生产环境几乎都要把宿主机的目录挂载到容器内。常用的做法是：
sudo docker run -d \ --name nginx-web \ -p 8080:80 \ -v /data/nginx/html:/usr/share/nginx/html:Z \ nginx:1.27-alpine这里的:Z是 SELinux 标签参数，尤其重要。RHEL8 启用了强制模式的 SELinux，如果你不给挂载目录打上合适的标签，容器内进程访问宿主机目录时会被 SELinux 拦截，报出Permission denied。:Z的含义是让 Docker 自动为挂载源目录设置容器可读写的 SELinux 上下文。
还有一个常见的需求是自定义 nginx 配置。比如你想改server块、加 gzip、配反向代理，最省事的方式是把整个配置文件挂载进去：
sudo docker run -d \ --name nginx-web \ -p 8080:80 \ -v /data/nginx/conf/nginx.conf:/etc/nginx/nginx.conf:ro \ -v /data/nginx/html:/usr/share/nginx/html:Z \ nginx:1.27-alpine注意nginx.conf的挂载选项是:ro，也就是只读挂载。这样宿主机上的配置改动可以直接映射进容器，同时容器内即使被入侵也无法修改挂载进来的配置，安全性和可维护性都有提升。
每次修改宿主机上的 HTML 或者配置文件后，nginx 并不需要重启容器才能生效，如果只是静态内容，浏览器刷新就能看到。如果改了 nginx 配置，可以进入容器热加载配置：
sudo docker exec nginx-web nginx -s reload这里分享一个实战经验：容器里nginx -s reload比宿主机直接docker restart nginx-web要好得多。原因是restart会重新创建容器进程，导致现有连接全部断开，而reload是平滑重载，worker 进程优雅退出再起新的，对线上请求几乎无感。
5. RHEL8 环境下的真实踩坑记录：从 SELinux 到端口映射异常
我在不同的 RHEL8 环境上跑 Docker 和 nginx，前前后后遇过不少问题，挑几个印象最深的写出来，你能少走很多弯路。
第一个坑就是 SELinux。RHEL8 的 SELinux 默认是 enforcing 模式，这让很多从 Ubuntu 转过来的运维很不习惯。当你挂载宿主机目录进容器时，如果没有加:Z或:z参数，nginx 容器会以 nginx 用户身份读取挂载目录，而宿主机目录的默认上下文是default_t，容器进程的域是container_t，两者不匹配，SELinux 直接拒绝访问。
表象是容器日志里报Permission denied或者open() "/usr/share/nginx/html/index.html" failed (13: Permission denied)。排查方法：
# 查看最近被 SELinux 拒绝的日志 sudo ausearch -m avc -ts recent解决方案有两种：临时把 SELinux 设为 permissive 模式（不推荐，等于放弃一道重要防线），或者在挂载时加:Z让 Docker 自动修改目录上下文。如果你不想在每次启动容器时都加参数，也可以手动设置目录上下文：
sudo semanage fcontext -a -t container_file_t "/data/nginx/html(/.*)?" sudo restorecon -Rv /data/nginx/html设置之后，挂载目录时即使不加:Z也能正常访问。我建议在生产环境用这种方式，因为:Z参数会直接修改目录标签，如果目录同时还有别的进程需要访问，反而可能引入额外问题。手动设置上下文更明确，对系统管理员来说也能清楚知道这台机器上哪些目录是给容器用的。
第二个坑是 firewalld 和 Docker 端口转发的冲突。容器跑起来了，curl 127.0.0.1:8080正常，但从局域网另一台机器访问http://服务器IP:8080就是不通。这通常不是 Docker 的问题，而是 firewalld 默认 zone 没有放行 8080 端口。
# 放行 8080 端口 sudo firewall-cmd --permanent --add-port=8080/tcp sudo firewall-cmd --reload如果端口放行了还不行，就要留意 firewalld 的 masquerade 和直接规则。最典型的场景是：你先手动加了 iptables 规则，然后 firewalld reload 把规则清掉了，Docker 自身的转发链虽然会重建，但顺序跟 firewalld 的规则链可能冲突。这时候最简单的办法是把 Docker 的桥接网络整个加入 firewalld 的信任 zone：
sudo firewall-cmd --permanent --zone=trusted --change-interface=docker0 sudo firewall-cmd --reload注意这里有个权衡：把 docker0 加入 trusted zone 后，所有由 Docker 映射出来的端口都不会再被 firewalld 拦截，相当于容器端口完全对外网开放。如果是多租户环境，这么做风险不小，需要结合安全策略评估。更稳妥的做法还是精确放行业务端口。
第三个坑是容器自动重启策略。不少人跑生产 nginx 容器时忘了加--restart参数，某次服务器重启，容器没有跟着起来，等发现故障时已经过去好几个小时。第一次用 nginx 容器时建议养成习惯：
sudo docker run -d \ --name nginx-web \ --restart unless-stopped \ -p 8080:80 \ -v /data/nginx/html:/usr/share/nginx/html:Z \ nginx:1.27-alpineunless-stopped的含义是：如果容器是被手动docker stop停掉的，重启服务器后不会自动启动；如果是意外崩溃或服务器重启，会自动拉起。这个策略非常适合生产环境里跑业务的容器。
第四个坑来自镜像标签的漂移。用nginx:latest有个隐患——某天你在服务器上执行了docker pull nginx，可能拉到的是行为已经变化的新版本。比如新版默认镜像里的配置文件路径改了，或者默认监听端口变了，你的容器就可能在部署时挂掉。我建议长期项目里一律锁定镜像的精确版本号，比如nginx:1.27.3-alpine。如果真要升级，主动修改版本号并回归测试，而不是指望latest一直稳定。
6. 运行之后的管理与维护：日志、镜像管理和日常清理
nginx 容器跑起来只是第一步，真正考验人的是后续几个月里怎么维护它。
先说日志。容器日志默认通过 json-file 驱动写到宿主机，日积月累可能膨胀到几个 GB。nginx 的访问日志默认打到容器标准输出，因此docker logs nginx-web能看到所有 HTTP 记录。为了防止日志无限增长，建议在运行容器时加上日志轮转配置。
最常用的方式是在/etc/docker/daemon.json里全局配置：
{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }这段配置的意思是：每个容器日志文件最大 10MB，最多保留 3 份。超过限制就滚动清理。修改后重启 Docker 服务生效：
sudo systemctl restart docker但注意：这个全局配置只对之后新建的容器生效，已经存在的容器不会自动应用。改成之后，需要重建容器才能让日志策略生效。
再说镜像管理。拉镜像一时爽，磁盘吃紧的时候就难受了。常用清理命令：
# 查看当前磁盘占用 sudo docker system df # 删除所有停止的容器、未使用的网络、悬空镜像、构建缓存 sudo docker system prune -adocker system prune -a比较激进，它会删除所有未被已运行容器引用的镜像，包括那些你可能以后想用但暂时没跑起来的。执行前建议--dry-run看一下。
如果你经常用带版本号的镜像做部署，旧版本的镜像层不会自动清掉，时间久了磁盘占用很可观。我一般按月做一次：
# 删除所有标记为 <none> 的悬空镜像 sudo docker image prune接下来是 nginx 配置的持续演进。你在宿主机上维护/data/nginx/html和/data/nginx/conf，改完 HTML 刷新即生效，改完 nginx.conf 需要docker exec nginx-web nginx -s reload。为了让这个过程更可控，可以在宿主机上写一个简单的检查脚本：
docker exec -t nginx-web nginx -t如果输出syntax is ok，再执行 reload。先把配置语法验证这一步固化到流程里，能避免一半的配置事故。
还有一个值得养成的习惯：容器内文件的修改千万别直接改。比如想临时改/usr/share/nginx/html/index.html，可以在容器的 bash 里顺手改，但这部分改动在容器删除以后就彻底丢了。凡是要长期保留的内容，一律通过挂载目录改，宿主机文件才是“真相来源”。
最后聊聊容器的备份与回滚。nginx 这类无状态服务备份压力不大，但如果你在容器里拖入了证书文件、额外模块之类的数据，直接丢弃容器再重新构建可能很麻烦。我习惯把容器转成镜像做快照：
sudo docker commit nginx-web nginx-web-backup:20250101commit会把当前容器状态保存为新镜像，注意它存在一定的性能开销，也会在镜像里包含容器层差异数据，所以只在关键节点做，不要当成常规操作。有了这个备份镜像，出问题时：
sudo docker stop nginx-web sudo docker run -d --name nginx-web-restored -p 8080:80 nginx-web-backup:20250101恢复即等于用当天快照重新起了一个容器。
开放端口这块，如果 nginx 作为反向代理使用，需要将流量转发给其他服务，可能还需要 Docker 自建网络让容器间互相通信。比如用nginx-web代理一个运行在同一个 Docker 网络里的应用容器：
sudo docker network create my-network sudo docker run -d --network my-network --name app-server your-app-image sudo docker run -d --network my-network --name nginx-web -p 8080:80 -v /data/nginx/conf:/etc/nginx/nginx.conf:ro nginx:1.27-alpine在同一个自定义网络里，nginx 容器可以通过容器名app-server直接访问对方，不需要依赖动态 IP。相比传统方式要查容器 IP 再配到配置文件里，这套方案要省心太多。
7. 从验证到上生产的最后几步：安全加固与例行检查
如果你只是在测试环境里跑通 nginx，前面的内容已经够用了。但假设你要把这套东西接到正式环境，最后几步千万别省。
第一是镜像安全。nginx 官方镜像和 nginx 官方 Alpine 镜像相对靠谱，但它们的基础层不定时更新，建议定期执行docker pull nginx:1.27-alpine并重跑容器，让依赖层跟上安全补丁。好消息是：如果你用-v挂载了网站内容和配置文件，镜像重拉重跑的过程对线上业务几乎无感，只是容器重建那几秒内会有断连。为了更加可控，生产环境可以用蓝绿发布的方式：先起一个新容器用新镜像、验证正常，再切换流量到新容器，最后删旧容器。
第二是 Docker 守护进程自身的访问控制。Docker 默认提供 unix socket，也就是只有本机 root 才能操作。如果你图方便，在daemon.json里开启了 TCP 监听端口，就等于把 Docker 控制权暴露给了网络上其他人，恶意者一旦能调用 Docker API，相当于获得了宿主机 root 权限。我个人建议保持默认 unix socket，如果不可避免要远程管理，至少配置 TLS 证书认证，或者通过安全链路访问管理端口。
第三是资源限制。nginx 看似轻量，但不做限制的容器会消耗宿主机 CPU、内存。生产环境建议给 nginx 容器加上资源上限：
sudo docker run -d \ --name nginx-web \ --restart unless-stopped \ --memory=512m \ --cpus=0.5 \ -p 8080:80 \ -v /data/nginx/html:/usr/share/nginx/html:Z \ nginx:1.27-alpine--memory=512m限制容器最大使用 512MB 内存，--cpus=0.5限制最多使用半个 CPU 核心。这样即使 nginx 遇到突发流量，也不会把宿主机拖垮。如果你对流量峰值有评估，这个数值按平时峰值的 1.5 倍来设置比较合理。
第四是例行检查清单。我通常会在周一早上一到岗就执行一套固定的检查命令：
# 容器运行状态和资源占用 sudo docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" sudo docker stats --no-stream # 磁盘占用与清理建议 sudo docker system df df -h /var/lib/docker # 宿主机端口监听 ss -tlnp | grep 8080有人觉得这些操作重复琐碎，但生产事故的苗头往往就藏在这些例行输出里。容器状态长期显示Restarting、磁盘占用突然大涨、端口监听异常，都比用户报障要提前得多。
最后说一句关于“自动启动”的心得。很多人在服务器重启以后才发现自己精心部署的 nginx 容器没起来，原因很简单——docker.service本身开机自启了，但容器没有设置--restart。我一直建议在刚开始跑容器的时候就加上--restart unless-stopped，这条参数虽然平时不起眼，但在服务器重启、Docker 服务被误重启这些场景里，能帮你避免不少半夜被人叫起来处理的麻烦。
写在最后的经验总结
在 RHEL8 上把 Docker 和 nginx 跑通，整体并不复杂，真正的分水岭在于对系统环境的理解。我见过有人在 CentOS 7 上跑得飞快的习惯直接照搬到 RHEL8，结果在 SELinux、firewalld、模块化仓库这三个环节来回折腾。这三座山其实都是同一个道理：RHEL8 的安全基线比老版本高得多，它默认按“容器是独立域”的模型来隔离资源，所以你给容器挂目录时要打标签，要给端口开口时要用 firewalld 而不是直接关防火墙，要装软件时优先走官方仓库而不是系统仓库里的兼容包。
从安装到运行，再把 nginx 挂上目录、配置好日志轮转、锁定重启策略，这套流程熟练以后大概十几分钟就能搞定一台新机器。真正花时间的是后续的维护思路：镜像版本固定、配置文件只改宿主机、定期清理悬空镜像、容器重建对业务无感，这些习惯比任何“一键脚本”都管用。
如果你现在正要开始在一台干净的 RHEL8 上跑 nginx 容器，我的建议是把上面的环境检查、安装命令、启动参数先照抄一遍跑通，然后再根据你自己的目录结构和端口规划做调整。跑通之后一定要做一次“模拟服务器重启”的验证：sudo reboot，等机器起来后看一眼容器是否自动恢复了。这一步过了，你才算真正把 nginx 容器部署到了能上生产的水平。
