企业官网建设流程全解析

Alibaba Cloud Linux 3 我用了也有大半年了。当初接手一台这个系统的机器，第一件事就是装 Docker。网上零零散散的教程不少，但大多是从 CentOS 7 的思路硬套过来的，真在 Alibaba Cloud Linux 3 上跑一遍，你会发现不少细节对不上。这篇文章就把我这次完整的安装和配置过程拆开讲一遍，从环境检查、软件源选择、daemon.json 调优，到系统服务起不来的排查思路，都按实际操作顺序写出来。适合刚拿到一台 Alibaba Cloud Linux 3 服务器、准备在上面跑容器化业务的同学，也适合已经装完 Docker 但总遇到网络、存储、权限等问题的朋友。

我默认你手里已经有一台能联网的 Alibaba Cloud Linux 3 机器，而且有 root 权限。如果你用的是普通用户且能 sudo，也完全可以，只是命令前面多打一个 sudo。下面所有操作，我都先在干净系统上实测过，不会让你白折腾。

1. 环境准备与系统理解

很多人一拿到新机器就急着执行安装命令，结果装到一半报一堆依赖错误，然后开始怀疑人生。其实 Docker 安装对系统的软硬件环境有隐性要求，花几分钟把环境摸清楚，后面能省出大把排查时间。

1.1 Alibaba Cloud Linux 3 是什么，为什么要用它跑 Docker

Alibaba Cloud Linux 3 是面向云场景设计的服务器操作系统，从 CentOS 8 的生态演化而来，兼容 RHEL/CentOS 的软件包管理方式。如果你之前用过 CentOS 8，会觉得非常亲切。它的内核版本较新，默认带了很多云上常用的驱动和调优参数，尤其是针对网络包处理和存储 I/O 做过优化。这直接关系到 Docker 落地后的性能表现。

用它跑 Docker 有一个天然优势：软件包依赖体系和 RHEL 系一致性很高，Docker 官方仓库基本可以直接用，不需要做太多兼容性修补。同时，这个系统里自带的容器相关内核模块比较全，比如 overlayfs、veth、iptables 相关过滤表，都是 Docker 启动运行时的硬性依赖。之前我在其他精简版 Linux 上装过 Docker，内核里少几个模块，容器根本起不来，只能换内核或者手动加载模块，而在这套系统上基本没有这类问题。

1.2 安装前检查：内核版本、系统版本和网络连通性

在跑安装命令之前，先把下面三件事做了，总共花不了两分钟。

第一，确认系统版本。执行：

cat /etc/os-release

正常情况下你会看到 NAME 是 Alibaba Cloud Linux、VERSION_ID 是 3。如果输出不对，说明你拿到的不是 Alibaba Cloud Linux 3，后续安装步骤可能不适用。

第二，确认内核版本。Docker 对内核版本很敏感，尤其存储驱动和网络功能。执行：

uname -r

理论上建议内核不低于 5.10。Alibaba Cloud Linux 3 默认内核一般满足要求。如果发现内核很老，比如 3.x，那就先别急着装 Docker，优先升级内核。

第三，确认网络能访问 Docker 官方源。不用真的去访问那个地址，直接检查 DNS 和默认路由：

ip route | grep default ping -c 2 mirrors.aliyun.com

这里不强制要求你必须能访问某个特定站点，但至少基础 DNS 解析要正常。如果你所在环境有代理，还要确认代理配置不会干扰 dnf 连接软件源。

这三项检查做完，没有异常，就可以进入下一步了。这里插一句我踩过的坑：曾经在一个内网环境下装 Docker，DNS 配置错误导致 dnf 一直解析不了软件源，报错信息又很误导，我一度以为是 dnf 缓存损坏，后来排查半天才发现是/etc/resolv.conf里写的 DNS 服务器已经下线了。所以，网络问题永远是第一步要排除的。

2. Docker 安装实操

装 Docker 的方式不少，常见的有三种：用系统自带的包管理器装旧版，用 Docker 官方脚本一键安装，以及手动配置 Docker CE 仓库后用 dnf 安装。我更推荐第三种，理由下面详细说。

2.1 选择 Docker 官方源而不是系统默认源

Alibaba Cloud Linux 3 的默认软件源里其实也有 docker 相关包，但通常版本滞后，甚至有拆分不完整的现象。我之前尝试过直接用dnf install docker，装完以后发现可执行文件路径不对，还得手动配置很多东西，而且版本较旧，和新的 containerd、runc 不匹配。容器运行时相关的组件版本不一致，真的是隐患巨大，线上环境很容易出现镜像运行异常。

所以建议手动添加 Docker CE 官方仓库，这样可以精确控制 docker-ce、docker-ce-cli、containerd.io 这些核心组件的版本。官方仓库会针对 RHEL/CentOS 系分发适配的 RPM 包，而 Alibaba Cloud Linux 3 的兼容性足够好，可以正常使用。

如果你所在环境无法直接访问 Docker 官方仓库，可以考虑使用一些镜像站提供的 Docker CE 源，但我提醒一句：务必要确认镜像站的源文件地址和 GPG 公钥路径是正确的，不要用来源不明的 RPM 包。生产环境装容器运行时，安全第一，少用奇怪来源。

2.2 一步步安装 Docker CE 组件

添加官方仓库，先安装必需的依赖工具：

dnf install -y dnf-utils

然后用yum-config-manager添加 Docker 官方稳定的仓库地址。注意，这里我无法给你推荐具体站点的 URL，因为你所在的网络环境可能不同，请以 Docker 官方文档给出的标准地址为准，或者使用云厂商控制台里提供的 Docker 源配置行为准。加入仓库后，验证一下仓库文件是否正确写入：

yum-config-manager --add-repo <Docker官方仓库地址> dnf makecache

执行完成之后，可以搜索一下 docker-ce 相关的包名：

dnf search docker-ce

如果能看到 docker-ce.x86_64、docker-ce-cli.x86_64 等条目，说明仓库配置成功。接着直接安装：

dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

这里我把docker-buildx-plugin和docker-compose-plugin一起装了。如果你平时不需要 BuildKit 和 Compose，可以只装前三个，但作为一个成熟的开发者环境，我建议一次性装齐，后面用起来方便，也避免旧版本不兼容的问题。

安装完成后，暂时不要急着启动服务，先看看版本信息：

docker version

此时应该能看到 Client 和 Server 两部分。如果只显示 Client 部分，说明 Docker Daemon 还没运行，这是正常的，因为服务还没启动。

2.3 配置服务自启动和免 sudo 使用

启动 Docker 服务并设置开机自启：

systemctl enable --now docker

这里有个小细节：enable --now是启动服务同时设置开机自启，比先start再enable少敲一遍命令。启动后检查状态：

systemctl status docker

如果状态是 active (running)，说明服务已经起来了。再执行一次docker version，确认 Client 和 Server 都正常返回。

接下来，处理非 root 用户的使用体验。默认情况下，只有 root 和管理员组能操作 Docker 守护进程。如果你不想每次敲命令都加 sudo，可以把自己的用户加入 docker 组：

usermod -aG docker <用户名> newgrp docker

这里要注意，加入 docker 组后，需要重新登录会话或者执行newgrp docker才会生效。另外必须提醒一句，直接把用户加入 docker 组相当于授予了这个用户等同于 root 的权限，因为 Docker 提供了访问宿主机的多种途径。所以，仅在可信的个人开发机上这么做，生产环境最好通过 sudo 或更细粒度的权限管理来控制。

3. 核心配置：daemon.json 里那些该做的事

Docker 装完能启动，只是最低标准。真正决定容器运行稳定性和运维便利度的，是/etc/docker/daemon.json里那些配置项。我见过很多人跳过这一步，用默认配置跑生产环境，结果日志文件撑爆磁盘、容器数据丢失、镜像拉取慢得像蜗牛。

3.1 数据目录、日志策略和存储驱动

默认情况下，Docker 的数据目录在/var/lib/docker，所有镜像、容器、卷的数据都存在这里。如果你的系统盘容量有限，而数据盘挂载在别的位置，那就必须提前修改数据目录，否则后期迁移移动大文件会非常痛苦。

我在实际项目中就遇到过这种情况，系统盘 20G，跑十几个镜像后磁盘直接满了，容器全部处于不健康状态。后来把>{ "data-root": "/data/docker" }

如果你要改>{ "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "3" } }

这样单个日志文件超过 100M 就会轮转，最多保留三个文件。虽然不能完全替代外部日志采集，但至少避免磁盘被写满。

存储驱动方面，Alibaba Cloud Linux 3 使用的默认内核和文件系统，通常支持 overlay2，这也是 Docker 官方推荐的。你可以先检查一下当前使用的存储驱动：

docker info | grep "Storage Driver"

如果显示 overlay2，就不用改。如果显示的是 vfs 或者其他驱动，说明你的文件系统或内核可能不支持 overlay，需要检查磁盘挂载属性，确保使用 xfs 且开启 ftpric 或 ext4。这里不展开，但记住结论：优先用 overlay2，性能和空间利用率都更好。

3.2 镜像加速与私有仓库配置

在国内环境或者企业内部网络，从 Docker Hub 拉取镜像往往慢得难以忍受。设置 registry mirror 是立竿见影的优化方式。在 daemon.json 中使用registry-mirrors字段：

{ "registry-mirrors": ["https://你的加速器地址"] }

这个加速器地址怎么选？不同网络环境差异很大，请根据你所在云厂商控制台提供的加速器地址填写，或者使用企业内部搭建的镜像缓存服务。我不建议你直接抄网上任何固定的加速器地址，因为这类地址经常变动，而且如果是公共地址，并发一高就失效。正确做法是登录你所用的云平台，在容器镜像服务控制台里找到专属的加速器地址。我实测下来，云厂商提供的专属加速器地址通常比公共地址稳定得多。

另外，如果你的业务需要从私有仓库拉取镜像，可以在 daemon.json 里配置insecure-registries，用于那些未启用 TLS 的本地仓库。比如内部自建的一个 registry 服务：

{ "insecure-registries": ["registry.internal.example.com:5000"] }

生产环境我还是建议给私有仓库配置好 HTTPS，不要依赖 insecure 模式。但如果你是本地开发、内网测试，这个配置能省掉很多证书相关的心烦事。

3.3 cgroup 驱动对齐

容器运行时和 systemd 之间有一个很容易忽略但影响巨大的点：cgroup 驱动。默认情况下，Docker 会使用 cgroupfs 作为 cgroup 驱动，但如果你所在环境使用 systemd 作为 init 系统，并且你的容器编排工具（比如 Kubernetes）要求 systemd 驱动，那么两者不一致会导致资源限制失效，甚至节点状态异常。

Alibaba Cloud Linux 3 使用 systemd 管理服务，所以建议把 Docker 的 cgroup 驱动也设置为 systemd，保持和其他组件一致。在 daemon.json 中添加：

{ "exec-opts": ["native.cgroupdriver=systemd"] }

改完之后重启 Docker：

systemctl restart docker

然后确认一下：

docker info | grep -i cgroup

如果输出Cgroup Driver: systemd，说明配置生效。这个细节在单独跑几个容器时可能看不出区别，但一旦你开始使用 K8s 或者 Podman 做容器编排，cgroup 驱动不统一会直接导致组件之间的冲突，排查起来非常费劲。

4. 常见问题与排查方法

这部分是整理问题实录。我把安装配置过程中最容易遇到的四类问题列出来，每一条都给出排查思路。你在操作时如果碰上类似的，直接按顺序对照检查。

4.1 内核版本和容器运行时的坑

Docker 对宿主机内核有最低要求，3.x 内核基本无法运行新版 Docker，因为缺少 netfilter 和 overlay 相关能力。Alibaba Cloud Linux 3 默认内核足够新，但如果你在安装前曾经用过其他内核，或者系统是迁移过来的，很可能残留旧内核。

排查方法很简单，先看当前运行的内核：

uname -r

如果内核版本看起来很低，需要先升级到系统默认的最新内核。使用：

dnf update -y kernel reboot

重启后确认uname -r是否已更新。还有，如果在启动 Docker 时出现iptables: No chain/target/match by that name这样的报错，可能是内核模块没有加载。可以尝试手动加载 bridge 相关的模块：

modprobe br_netfilter

然后确认：

ls /proc/sys/net/bridge/bridge-nf-call-iptables

这个文件存在，说明模块加载成功。Alibaba Cloud Linux 3 通常默认开启，但如果你使用了裁剪过的内核，就要格外注意。

4.2 拉取镜像总是超时怎么办

docker pull超时的原因有很多，最常见的是网络无法访问 Docker Hub，或者镜像加速器配置错误。首先要确认配置文件格式是否正确。使用：

docker info | grep -A 5 "Registry Mirrors"

看输出里加速器地址对不对。如果配置文件写错了，比如 JSON 格式不合法，Docker 甚至是拒绝启动的。这时候你可以用dockerd --validate或手动检查：

python3 -m json.tool /etc/docker/daemon.json

如果提示解析错误，说明里面有语法问题，修改后保存再重启。

改动 daemon.json 后，想要让配置生效并不需要重新加载整个配置文件，执行：

systemctl reload docker

或者干脆重启 Docker，因为 daemon.json 很多字段在 reload 时不会生效，最稳妥的就是systemctl restart docker。重启后重新尝试拉取。如果还是超时，可以用docker pull加--platform参数指定平台。有些镜像仓库兼容性问题与架构有关。

4.3 服务启动失败时的排查路径

Docker 服务启动失败，这是安装配置中最容易让人崩溃的时刻。先别慌，按照下面的顺序排查，大概率能定位。

第一步，查看 Docker 服务的详细错误：

journalctl -u docker --no-pager -n 100

对比systemctl status docker的输出，日志里通常有最直接的原因提示。常见的错误包括：数据目录无法访问、权限不足、端口被占用、daemon.json 格式错误。

第二步，检查端口占用。Docker 默认监听/var/run/docker.sock，不占用 TCP 端口，但如果有其他服务占用了 2375 或 2376，而你配置了远程访问，可能会冲突。检查方式：

ss -lntp | grep 2375

第三步，确认 socket 文件权限。如果非 root 用户报权限不足，检查/var/run/docker.sock的所有者。如果确认是 docker 组，但依然没权限，通常是当前用户没有重新登录。执行id <用户名>看用户是否已经在 docker 组中。

这些排查手段熟练之后，大部分启动失败问题都能在 10 分钟内解决。我曾经因为 daemon.json 里一个多余的逗号，导致 Docker 起不来，查了半小时才意识到是 JSON 格式问题。所以配置文件和语法校验永远第一。

5. 安装后的快速验证与日常维护

装完、配完，并不能说就完事了。容器化平台是基础底座，平时不如多花点时间做验证和维护，甚至比功能开发更重要。

5.1 用 hello-world 验证整个链路

配置完成并重启 Docker 之后，拉一个极小的镜像做端到端验证，这是最稳妥的。执行：

docker run --rm hello-world

如果能看到 “Hello from Docker!” 输出，说明守护进程正常工作，镜像拉取链路正常，容器运行时也能正常启动进程。如果你的网络环境甚至拉不动 hello-world，可以用一个本地构建的最小镜像测试，但正常情况下这一步不会失败。

接着，再验证一下端口映射和文件挂载：

docker run -d --name nginx-test -p 8080:80 -v /tmp/test:/usr/share/nginx/html nginx:alpine

然后访问本机 8080 端口，看能不能返回页面。这一步同时验证了镜像拉取、数据卷挂载、端口映射三项能力。验证完毕，删除测试容器：

docker rm -f nginx-test

这一步很有用，能避免测试容器遗留在生产环境里影响监控数据。

5.2 资源限制与健康检查

容器不是没有边界的，线上环境一定要给容器设置资源限制。启动容器时用--memory和--cpus参数限制内存和 CPU：

docker run -d --name app --memory 512m --cpus 0.5 nginx:alpine

这样容器最多使用 512M 内存和半个核，避免某个异常容器把宿主机资源耗尽。如果你用的是 Compose，同样在服务的deploy.resources.limits下配置。

日常检查容器健康状态，用：

docker ps docker stats

docker stats是一个交互式实时监控，可以看到每个容器的 CPU、内存、网络 I/O 和磁盘 I/O。建议无事时开一眼，能提前发现内存泄漏的苗头。也可以把监控数据接入外部监控系统，但日常检查用这两个命令就够了。

另外，建议为每个重要容器配置 HEALTHCHECK，比如：

HEALTHCHECK --interval=5s --timeout=3s --retries=3 \ CMD curl -f http://localhost/ || exit 1

这样容器编排工具能自动重启不健康的容器，而不是一直对外提供服务却实际已经挂掉。这个小配置极其简单，但价值非常大，能减少大量手动告警处理。

5.3 卸载和升级时的注意事项

不要用dnf remove docker-ce就直接完事。Docker 卸载时会把/var/lib/docker里的所有容器、镜像、数据卷一并留下，如果不处理，磁盘空间不会被自动释放。

如果你确认不再使用 Docker，完整卸载流程是：

systemctl disable --now docker dnf remove -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

然后手动清理残留数据目录，这一步务必慎重，因为删除后所有容器和镜像数据都无法找回：

rm -rf /var/lib/docker

如果只是想升级 Docker 版本，不需要执行卸载，直接：

dnf update -y docker-ce docker-ce-cli containerd.io systemctl restart docker

升级之后，用docker version确认新版本，同时观察日志里是否有兼容性警告。特别要注意，新版 Docker 可能会改变默认的运行时行为，升级前后建议对比docker info的稳定输出。

我个人实际操作中的体会是，Alibaba Cloud Linux 3 给我的最强烈印象是省心。相比以前在别的发行版上手动编译内核模块、折腾 cgroup 驱动的经历，这套系统在容器运行时的适配性上做得很扎实。只要你不跳过环境检查，不随便乱改 daemon.json，装 Docker 的过程基本就是一次跑通。唯一要提醒的还是那句话，每台机器网络环境不一样，软件源和镜像加速器地址务必用自己的环境去确认，不要盲抄网上配置。最后再分享一个小技巧：改完 daemon.json 之后，无论觉得有没有问题，先执行一次docker info看看输出里有没有报错，如果报错，别急着重启服务，先修配置；如果需要快速回滚，备份一个原文件再动手能让你少流很多汗。祝你们装一次就过，容器全部顺利跑起来。