企业官网建设流程全解析

简介：这份资源面向需要在 Linux 环境下快速搭建容器运行环境的开发与运维人员，尤其适合刚接触容器化部署、希望一次性完成 Docker 与 Docker Compose 安装配置的初学者和测试人员。压缩包共 4 个文件，整体约 84.53MB，包含 Docker 安装包（tgz）、systemd 服务配置文件（service）、自动化安装脚本（sh）以及 Docker Compose 编排文件，覆盖从引擎安装到多容器编排的完整链路，无需逐条手动执行命令即可完成环境准备。目前已有 265 人学习下载，说明其在同类安装资源中具备一定参考价值。借助其中的安装脚本与服务配置，读者可以省去手动下载、解压、注册服务等繁琐步骤，快速获得可用的 Docker 运行环境，并利用 Compose 文件实践多容器应用的统一编排与启停，为后续部署测试和生产环境迁移打下基础。

1. Docker 与 Docker Compose 安装包：从离线包到一键编排的落地路径

手里只有一台不能连外网的服务器，或者内网机器连镜像仓库都访问不了，这时候谈docker pull就是空话。真正卡住人的往往不是命令本身，而是「安装包从哪来、怎么装、装完 compose 怎么配」。这篇讲的就是围绕docker 和 docker-compose 安装包这条线，把离线安装、版本对齐、编排落地一次说清楚。适合两类人：一类是刚接触容器、想在自己机器上把 docker 安装教程走通的新手；另一类是在内网、信创环境或麒麟系统里做部署，需要离线安装包和 docker-compose 二进制的一线运维。核心结论先放这：docker 引擎和 compose 是两套独立的安装包，版本必须对齐，否则编排文件里的语法会直接报错。

2. 安装包到底包含什么：引擎、CLI、compose 三件套拆解

很多人以为「docker 安装包」就是一个 exe 或者一个 rpm，装完就万事大吉。实际上一套完整的容器运行环境至少由三部分组成，理解这三者的关系，后面选包和排错才不会懵。

2.1 引擎、客户端、编排器各自的职责

Docker Engine 是后台守护进程（dockerd），负责真正跑容器、管镜像、管网络和存储。Docker CLI 是你敲的docker命令，它只是个客户端，通过 socket 跟守护进程通信。Docker Compose 则是独立的一个二进制（v2 之后是docker-compose或作为 docker CLI 插件docker compose），它读compose.yaml，把里面定义的多容器应用翻译成一堆引擎 API 调用。

这三者可以分开装。Linux 上常见做法是用发行版仓库装 engine + cli，再单独下 compose 二进制；Windows 和 macOS 上 Docker Desktop 把三者打包成一个安装包，省事但体积大。内网离线场景下，你往往需要自己凑齐这三样：engine 的静态二进制包（docker-xx.tgz）、compose 的独立二进制、以及可选的镜像离线包。

提示：compose v1（Python 写的docker-compose）和 v2（Go 写的，命令是docker compose）差别很大，v1 已经停止维护，新部署一律上 v2。

2.2 离线安装包和在线安装的取舍

在线安装走官方脚本或包管理器，优点是自动处理依赖，缺点是必须有网、且要能访问对应仓库。离线安装包的优势是可控、可复制，适合批量部署和内网。代价是你得自己解决依赖，比如 engine 静态包依赖iptables、libc、cgroup这些系统组件，缺一个dockerd就起不来。

选型上我的习惯是：能联网的开发机用官方仓库装，图省心；生产内网一律用离线包，版本锁死，避免某天自动升级把编排搞崩。下面这张表是两种方式的对比，方便你按场景选。

2.3 版本对齐：为什么 compose 会报语法错

最常见的翻车现场：engine 装的是老版本，compose 下了个最新的 v2.32.1，结果compose.yaml里用了新语法，引擎不认，报unsupported config option。反过来，engine 很新但 compose 是 v1，docker compose命令根本不存在。

对齐原则很简单：compose v2 的二进制对 engine 版本要求不高，但compose.yaml里用到的deploy、profiles、depends_on条件语法，需要 engine 达到对应版本。稳妥做法是 engine 用较新的稳定版，compose 用同期的 v2 版本。查版本用下面两条命令，装完先跑一遍确认。

# 查看引擎和客户端版本 docker version # 查看 compose 版本（v2 是 docker compose，注意中间是空格） docker compose version

docker version会分别打印 Client 和 Server 两段，Server 段出不来说明守护进程没起来，这时候别急着怀疑 compose，先解决引擎。docker compose version输出形如Docker Compose version v2.x.x，如果提示docker: 'compose' is not a docker command，说明 compose 插件没装或没放进 CLI 插件目录。

3. Linux 离线安装 Docker 引擎：静态包解压到 systemd 托管

内网 Linux 是最典型的离线场景，这一章把从拿到安装包到dockerd被 systemd 托管的完整流程走一遍。以常见的 x86_64 为例，ARM 或麒麟系统把包名里的架构换掉即可，步骤一致。

3.1 下载与解压静态二进制包

官方提供的是静态编译的docker-<version>.tgz，里面包含dockerd、docker、containerd、runc等一堆二进制。拿到包后传到目标机器，解压到/usr/bin。

# 解压静态包，-C 指定目标目录，--strip-components 去掉顶层目录 tar -xzvf docker-24.0.7.tgz \ --strip-components=1 \ -C /usr/bin \ docker/docker docker/dockerd docker/containerd docker/runc docker/ctr # 确认关键二进制就位 ls -l /usr/bin/docker /usr/bin/dockerd /usr/bin/containerd

--strip-components=1的作用是剥掉压缩包里那层docker/目录，否则二进制会散落在/usr/bin/docker/下，systemd 找不到。只挑需要的几个文件解压，能少占空间，但如果你不确定依赖，直接全量解压到/usr/bin也行。解压完docker和dockerd必须在同一目录，否则 CLI 找不到守护进程。

3.2 配置 systemd 服务单元

静态包不带服务文件，得自己写一个/etc/systemd/system/docker.service，让 systemd 能拉起和守护dockerd。

[Unit] Description=Docker Application Container Engine Documentation=https://docs.docker.com After=network-online.target firewalld.service Wants=network-online.target [Service] Type=notify ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock ExecReload=/bin/kill -s HUP $MAINPID LimitNOFILE=infinity LimitNPROC=infinity TimeoutStartSec=0 Delegate=yes KillMode=process Restart=on-failure StartLimitBurst=3 StartLimitInterval=60s [Install] WantedBy=multi-user.target

Type=notify表示dockerd启动完会主动通知 systemd，这样systemctl start不会假成功。Delegate=yes让 docker 能自己管理 cgroup 子层级，不加这个在部分系统上容器起不来。ExecStart里的-H unix:///var/run/docker.sock是默认监听地址，保持默认即可。

3.3 启动、验证与开机自启

服务文件写好后重载 systemd，启动并设为开机自启，然后跑一个最小验证。

# 重载配置并启动 systemctl daemon-reload systemctl enable --now docker # 查看状态，确认 active (running) systemctl status docker --no-pager # 最小验证：跑一个 hello-world（需本地有镜像或能拉取） docker run --rm hello-world

enable --now一步完成开机自启和立即启动。systemctl status里如果看到Active: active (running)就说明守护进程活了。docker run那步在纯离线环境会失败，因为拉不到镜像，这时候用docker load导入一个离线镜像包再验证，或者直接docker info看引擎信息是否正常输出。

注意：如果systemctl status显示start request repeated too quickly，多半是dockerd启动即崩，用journalctl -u docker -n 50看具体报错，常见原因是 iptables 缺失或 cgroup 版本不匹配。

4. Docker Compose 安装包：单文件二进制与 CLI 插件两种装法

compose 的安装比引擎简单得多，因为它就是一个静态编译的单文件二进制。但装在哪、叫什么名字，直接决定你用docker-compose还是docker compose。

4.1 独立二进制装法：放到 PATH 并赋权

最直接的方式是把 compose 二进制下载下来，改名放到/usr/local/bin，加执行权限。

# 下载对应架构的 compose 二进制（离线场景提前传好） # 放到 PATH 并重命名为 docker-compose install -m 755 docker-compose-linux-x86_64 /usr/local/bin/docker-compose # 验证 docker-compose version

install -m 755一步完成复制和赋权，比cp加chmod干净。这样装完命令是docker-compose（带横杠），属于 v2 的独立调用方式。注意别把它和 v1 的 Python 版搞混，v2 的二进制同样叫docker-compose，但version输出里会写明Docker Compose version v2.x.x。

4.2 CLI 插件装法：让 docker compose 生效

如果你习惯docker compose（空格）这种子命令写法，需要把二进制放到 CLI 插件目录，命名规则是docker-compose，放在~/.docker/cli-plugins/或/usr/local/lib/docker/cli-plugins/。

# 创建插件目录（用户级） mkdir -p ~/.docker/cli-plugins # 放入插件，命名必须是 docker-compose install -m 755 docker-compose-linux-x86_64 ~/.docker/cli-plugins/docker-compose # 验证子命令形式 docker compose version

插件目录的命名规则是硬性的：文件名必须是docker-compose，docker CLI 启动时会扫描这个目录，把符合命名规则的二进制注册成子命令。放对之后docker compose就能用了。系统级安装把路径换成/usr/local/lib/docker/cli-plugins/，对所有用户生效。

4.3 两种装法的差异与选择

两种装法功能完全一样，区别只在调用形式和生效范围。下面这张表帮你快速决定。

我的建议是新部署一律用插件装法，命令统一，未来官方主推也是这个方向。老脚本里如果写死了docker-compose，那就两种都装，互不冲突，因为一个是 PATH 里的可执行文件，一个是 CLI 插件。

5. 避坑与排查：安装包里最容易翻车的五个点

装 docker 和 compose 看着简单，实际踩的坑一点不少。这一章按「现象 → 原因 → 解决」列五个高频问题，都是我在内网和信创环境里真实遇到过的。

5.1 守护进程起不来，报 iptables 相关错误

现象：systemctl start docker失败，journalctl里看到Failed to start Docker Application Container Engine，伴随 iptables 或modprobe报错。

原因：离线精简系统里iptables或iptables-legacy没装，或者内核模块br_netfilter、overlay没加载。docker 默认用 iptables 做 NAT 和端口映射，缺了直接崩。

解决：先确认iptables -V能输出，没有就装对应包；再检查内核模块，lsmod | grep overlay和lsmod | grep br_netfilter，缺了用modprobe overlay && modprobe br_netfilter加载，并写进/etc/modules-load.d/持久化。

5.2 compose 报 unsupported config option

现象：docker compose up直接报unsupported config option: xxx，指向compose.yaml里某个字段。

原因：compose 文件用了新语法，但引擎版本太老，不认识这个配置项。典型的是deploy.resources或profiles。

解决：要么升级引擎到支持该语法的版本，要么把 compose 文件降级到引擎支持的格式。用docker compose config先校验文件，它会指出具体哪一行不兼容。别硬改，先对齐版本。

5.3 离线环境 docker run 拉不到镜像

现象：引擎装好了，docker run hello-world卡在Unable to find image locally，然后超时。

原因：纯离线环境没有镜像仓库，docker run默认去 Docker Hub 拉，自然失败。这不是安装包的问题，是镜像来源的问题。

解决：在有网的机器上docker pull后docker save -o xxx.tar image:tag导出，传到目标机docker load -i xxx.tar导入。批量场景把常用镜像一次性导出，配合 compose 的image字段直接用本地镜像。

5.4 麒麟等系统上二进制不兼容

现象：解压完dockerd一执行就报cannot execute binary file或GLIBC not found。

原因：下载的静态包架构不对，或者系统 glibc 版本太低。麒麟系统常见的是 ARM64 架构，却下了 x86_64 的包。

解决：uname -m确认架构，aarch64 就下aarch64或arm64版本的包。glibc 问题优先用官方静态包（它自带大部分依赖），实在不行换用发行版自带的 docker 包。

5.5 权限问题导致必须 sudo

现象：每次敲docker都要加sudo，不加就报permission denied连不上 socket。

原因：/var/run/docker.sock默认属主是 root，普通用户没权限。

解决：把用户加进 docker 组，usermod -aG docker $USER，然后重新登录生效。注意这一步等于给了该用户 root 级权限，生产环境谨慎，别随便加。

6. 用 compose 编排一个多容器应用验证整套安装

装完不验证等于没装。这一章用一个最小但完整的多容器例子，把 engine 和 compose 一起跑通，顺便讲几个进阶技巧。

6.1 写一个 compose.yaml 跑通服务编排

下面这个例子起一个 web 服务加一个缓存，覆盖了镜像、端口、依赖、环境变量几个核心字段。

services: web: image: nginx:alpine ports: - "8080:80" depends_on: - cache restart: unless-stopped cache: image: redis:7-alpine command: redis-server --appendonly yes volumes: - cache-data:/data volumes: cache-data:

depends_on保证启动顺序，但注意它只保证容器先起，不保证服务就绪，真要等就绪得配healthcheck。restart: unless-stopped让容器异常退出后自动重启，生产必备。volumes声明具名卷，数据持久化到cache-data，删容器不丢数据。

6.2 启动、查看与清理的完整命令链

# 后台启动，-d 分离模式 docker compose up -d # 查看服务状态和端口映射 docker compose ps # 看某个服务日志，-f 跟随 docker compose logs -f web # 停止并删除容器和网络，保留卷 docker compose down # 连卷一起删（慎用） docker compose down -v

up -d是最常用的启动方式，前台跑会占住终端。ps能看到每个容器的状态和端口。logs -f排查启动失败必用。down默认保留具名卷，加-v才删，这个设计是为了防手滑丢数据，记住别在生产随手加-v。

6.3 验证安装是否真正可用的三个检查点

装完别只看命令能跑，做三个检查才算稳。第一，docker info能完整输出引擎信息，包括存储驱动和 cgroup 版本；第二，docker compose config能无错解析你的编排文件；第三，跑一次up -d再down，确认容器能正常起停、网络能创建销毁。三个都过，这套安装包才算真正落地。

我自己的习惯是：每台新机器装完，先跑一遍这三步，把结果记进部署清单。踩过的坑告诉我，安装包本身很少出问题，出问题的永远是版本对齐和系统依赖。把这两样锁死，后面编排就是顺水推舟。希望帮到你。

本文还有配套的精品资源，点击获取