谈国平1. 安装前的准备工作：别急着敲命令
先聊点实在的。很多人装 Docker，习惯性打开搜索引擎，复制粘贴第一条命令就开干，结果装到一半报错，或者装完了发现版本不对、服务起不来，然后又是一通百度，浪费时间不说，还把系统环境搞得一团糟。我自己早期踩过不少这种坑，所以这篇文章先从准备工作讲起，把该确认的事情都确认好，后面基本就是一路畅通。
1.1 确认你的 Linux 发行版和内核版本
Docker 的核心依赖是 Linux 内核的一些特性，比如 cgroups、namespaces 这些。所以安装前必须确认两件事：你的系统是哪个发行版、内核版本够不够新。
执行下面这条命令：
bash复制cat /etc/os-release
输出结果里主要看 ID、VERSION_ID 和 PRETTY_NAME 这三个字段。比如常见的输出是 ID=ubuntu、VERSION_ID="22.04"，或者 ID=centos、VERSION_ID="7"。这决定了你后续该用哪套安装源和安装命令。
再看内核版本：
bash复制uname -r
Docker 官方要求内核版本不低于 3.10。实际上如果你是 CentOS 7 这类老系统，内核一般是 3.10 起的，能跑，但体验不是最好。Ubuntu 22.04 默认内核基本都是 5.15 或更高，完全没问题。如果你用的是那种内核特别老的系统（比如 CentOS 6），那我不建议硬装，要么升级系统，要么考虑换发行版。
还有一个小细节，x86_64 架构基本没问题，但如果你是 ARM 架构的机器（比如树莓派、飞腾、鲲鹏这类），安装源和镜像拉取会有些区别，后面会提到。可以先查一下 CPU 架构：
bash复制uname -m
输出 x86_64 就是标准的 64 位 x86 架构，输出 aarch64 就是 ARM 64 位。
1.2 检查网络连通性和软件源可用性
Docker 安装过程需要从软件源下载软件包，所以网络必须先通。这里说的网络有两层意思：
第一层是你能不能访问你的软件源。比如 Ubuntu 系统，执行 apt update 看有没有报错；CentOS 系统，执行 yum makecache 或者 dnf makecache 看是否正常。这一步其实就是确认系统的软件源配置没毛病。
第二层是 Docker 官方仓库的连通性。因为后续需要通过官方源或者镜像源来安装 Docker，如果这一层不通，你得提前准备替换方案，比如用阿里云镜像源、中科大源，或者直接下载离线安装包。建议提前就配置好国内镜像源，别等到装到一半才发现拉不下来，那就被动了。
检查连通性可以用这条命令：
bash复制curl -I https://mirrors.aliyun.com/docker-ce/
如果能看到返回的 HTTP 状态码信息，说明网络层面没问题。如果卡住不动或者超时，说明你可能需要换个源或者检查网络配置。
1.3 清理系统里残留的旧版 Docker
这个步骤很多人会忽略。如果你以前在机器上装过 Docker、Podman 或者其他容器运行时，直接覆盖安装很可能会出新问题，比如命令冲突、服务启动异常、配置文件被覆盖等。
先把可能残留的旧包列出来看看：
bash复制dpkg -l | grep -i docker # Debian/Ubuntu 系
rpm -qa | grep -i docker # RHEL/CentOS 系
清理旧版 Docker 的卸载命令（Ubuntu/Debian）：
bash复制sudo apt-get remove docker docker-engine docker.io containerd runc
CentOS/RHEL 系：
bash复制sudo yum remove docker docker-client docker-common docker-latest docker-latest-logrotate docker-logrotate docker-engine
需要说明一下，上面这些命令卸载的是旧版本的管理工具和守护进程，默认不会删除你已有的镜像、容器、数据卷。这些默认存放在 /var/lib/docker 目录下。如果你是打算彻底重来，可以把 /var/lib/docker 也清掉：
bash复制sudo rm -rf /var/lib/docker
不过做这一步之前务必想清楚，这是一个不可逆的操作，所有本地镜像和容器数据都会消失。我一般只建议在确认不需要旧数据的时候才删。
1.4 后端存储驱动和系统环境的预检查
Docker 默认用的存储驱动叫 overlay2，这个驱动依赖内核模块 overlayfs。绝大部分现代发行版默认支持，但个别精简版系统或者用了特殊内核的，可能没开。可以提前检查一下：
bash复制cat /proc/filesystems | grep overlay
如果有输出 nodev overlay 之类的信息，就说明内核支持，可以放心。如果没有，那很可能你的系统内核比较精简，装完 Docker 后需要额外调存储驱动配置，比如改成 vfs（性能较差，不推荐）。
另外，如果你用的是带 SELinux 的系统（比如 CentOS、RHEL 默认开启），Docker 安装完后一般能自动处理，但要注意容器内访问文件时可能遇到权限问题。如果不想折腾，可以先临时把 SELinux 设为宽容模式来排除问题：
bash复制sudo setenforce 0
注意这只是临时生效，重启会恢复。生产环境不建议长期关闭 SELinux，更好的做法是搞清楚权限配置规则。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 安装方式选型：不同场景用不同方案
Docker 的安装方式其实有五六种，刚接触的人可能不知道该怎么选。我根据自己的经验，把主流方式整理成一个对比表格，你看看哪种更适合自己的场景。
| 安装方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 官方源在线安装 | 服务器能正常访问外网的常规场景 | 安装便捷、能拿官方最新版 | 对网络要求高，国内可能较慢 |
| 国内镜像源安装 | 国内云服务器或访问官方源困难的场景 | 速度快、稳定 | 需要额外配置镜像源 |
| 离线安装包 | 内网环境、生产隔离网络 | 不受网络限制，版本可控 | 需要自行下载依赖包，升级麻烦 |
| 发行版自带软件包 | 对版本要求不高、追求稳定 | 与系统集成度高 | 版本可能较旧，功能不全 |
| 官方安装脚本 | 快速测试或者临时环境 | 一条命令完成安装 | 难以自定义参数，出问题不易排查 |
我自己大多数情况下的选择是：国内云服务器用镜像源安装，内网环境用离线包，个人测试机图省事用官方脚本。下面逐一展开说明每种方式的关键步骤和注意事项。
2.1 官方脚本一键安装：最快但最不可控
官方提供了自动安装脚本，下载完后直接执行就能完成全流程安装：
bash复制curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
这个脚本的原理是自动检测你的系统类型和发行版，然后配置对应的 Docker 官方软件源、安装最新稳定版、配置开机自启。整个过程不需要你手动干预。
但是，我必须提醒你，这种方式有几个明显的坑：
一是脚本默认使用 Docker 官方源，在国内服务器上经常出现下载超时的情况，装到一半就卡住，重试几次也没用。二是脚本会直接安装最新版，如果你想装指定版本，脚本并不太方便处理。三是脚本做了太多"自动"的事情，如果执行环境比较特殊（比如系统里已经装了一半的旧 Docker），它可能会覆盖掉你已有的配置。
所以我只在临时测试机和全新的系统上用这个方式，可靠的生产环境我都是手动操作。
2.2 通过国内镜像源安装：最推荐的常规方案
以 Ubuntu/Debian 系统为例，用阿里云镜像源的方式装 Docker 是我最常用的方案。整个流程分几步：
第一步，安装必要的依赖包：
bash复制sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg lsb-release
第二步，添加 Docker 官方的 GPG 密钥。这一步是为了让系统信任 Docker 软件的签名，避免被非法篡改。我直接用阿里云的镜像源来导入密钥：
bash复制sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
第三步，添加 Docker 软件源。注意区分架构，我这里是 amd64 为例：
bash复制echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list
第四步，更新索引并安装：
bash复制sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
装完之后先不要着急用，先把服务启动检查一遍：
bash复制sudo systemctl enable docker
sudo systemctl start docker
sudo systemctl status docker
看到 active (running) 就说明服务正常了。然后验证一下 Docker 是否真的可用：
bash复制sudo docker version
如果输出能看到 Client 和 Server 两段信息，且 Server 段的版本号和 Client 一致（或者 Server 比 Client 新），就说明 Docker 安装成功且服务运行正常。
上面是 Ubuntu/Debian 系的方法。如果你的系统是 CentOS/RHEL 系，差异主要在软件源配置这一步，需要这样写：
bash复制sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
sudo yum install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
CentOS 8 默认的包管理器是 dnf，但 yum 命令同样兼容，不需要刻意换。
2.3 离线安装：内网环境的关键方案
有些生产环境是隔离的内网，没法访问外网，这时候就得用离线包安装。思路是找一台能上网的同版本系统的机器，把软件包下载好，再拷贝进内网安装。
下载离线包我推荐用 yumdownloader 或 apt download。这里以 CentOS 7 为例：
首先在一台能联网的 CentOS 7 机器上配置好 Docker 的 yum 源，然后执行：
bash复制sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
mkdir /opt/docker-offline
cd /opt/docker-offline
yumdownloader --resolve docker-ce docker-ce-cli containerd.io docker-compose-plugin
下载完成后把 /opt/docker-offline 整个目录拷贝到内网机器上，然后进入该目录执行：
bash复制sudo yum install -y ./docker-ce-*.rpm ./docker-ce-cli-*.rpm ./containerd.io-*.rpm ./docker-compose-plugin-*.rpm
如果是 Ubuntu/Debian 系统，离线方式要用 apt download 逐个下载，而且依赖关系更复杂，建议用 apt-get install --download-only 加上 apt-get download 组合操作。实际上更省事的办法是利用 apt-get install --print-uris 查看所有依赖包的下载链接，然后批量下载。不过这个过程比较繁琐，一般公司都会搭建内网软件源，直接配置内网源在线安装反而更方便。
2.4 发行版自带软件包安装：不推荐但要说
有些人的习惯是直接用 apt install docker.io 或 yum install docker，也就是系统自带的软件仓库里的 Docker 包，我不太推荐这样干。原因很简单：自带的 Docker 版本通常落后官方好几个大版本，而且官方经常把一些安全补丁和关键特性放入新版本，你在老版本上跑容器，遇到坑的概率大得多。
当然，如果你只是随便玩一玩，不想折腾软件源，这种方式也能用。装完后的基本验证方法一样，这里不多说。但我建议真心想用好 Docker 的人，还是上官方源或者可靠的镜像源装新版。
3. 安装后的基础配置：这些不做迟早出事
Docker 装好并不代表就完事了。说实话，装完之后的配置才是让 Docker 真正"好用"的关键。我见过不少人在这一步偷懒，结果后面要么拉镜像慢到怀疑人生，要么动不动就要输 sudo，要么日志把磁盘写满。
3.1 把普通用户加入 docker 组：告别每次 sudo
Docker 默认情况下，只有 root 用户（以及有 sudo 权限的用户）才能执行 docker 命令。如果你每次想运行 docker ps 都要敲 sudo，几次之后就会觉得很烦。
解决办法是把你要用的普通用户加入 docker 组：
bash复制sudo usermod -aG docker $USER
执行完这条命令后，必须退出当前终端重新登录一次（或者执行 newgrp docker 临时生效），因为组权限的变更要在新的会话中才生效。重新登录后执行：
bash复制docker ps
如果你能看到一个空列表（或者只有表头），不再提示权限错误，就说明配置成功了。
这里有个安全提醒：加入了 docker 组实际上等同于赋予了这个用户 root 级别的权限。因为 Docker 的能力太强了，可以通过挂载宿主目录等方式直接控制宿主机文件系统。所以，只给信得过的用户加 docker 组，不要给不相关的人开这个权限。生产环境如果多人共用服务器，更得要小心分配权限。
3.2 配置镜像加速器：拉取镜像速度翻倍
Docker 默认从 Docker Hub 拉取镜像，国内访问 Docker Hub 的速度不太稳定，经常几十 KB/s 甚至超时。解决办法是配置镜像加速器，我推荐阿里云镜像加速，注册一个阿里云账号后，在容器镜像服务控制台就能看到专属加速地址，格式类似 https://xxxx.mirror.aliyuncs.com。
配置方式很简单，编辑 /etc/docker/daemon.json 文件（如果不存在就新建）：
json复制{
"registry-mirrors": [
"https://你的加速地址.mirror.aliyuncs.com"
]
}
保存后重启 Docker：
bash复制sudo systemctl daemon-reload
sudo systemctl restart docker
验证加速器是否生效：
bash复制docker info | grep -A 10 "Registry Mirrors"
如果你没有阿里云账号，也可以使用其他公共镜像加速源，比如中科大镜像（https://docker.mirrors.ustc.edu.cn）等。需要说明的是，公共加速源的稳定性和速度取决于服务提供方的状况，有时候会失效，这时候可以切换其他可用源。
一个实际的体验是，配置了加速器之后，拉取一些常用且体积较大的镜像（比如 MySQL、Redis、Nginx），速度可以从几十 KB/s 提升到几十 MB/s，体感完全是两个世界。
3.3 配置 Docker 日志轮转：防止日志撑爆磁盘
这是个很隐蔽的坑。Docker 默认情况下，一个容器的日志文件大小是没有上限的，它会一直写入宿主机的 /var/lib/docker/containers/xxx/xxx-json.log 文件。如果你的程序打印日志比较频繁，几天时间就能产生几个 GB 甚至几十 GB 的日志文件，直接把磁盘占满。
为了避免这种情况，我强烈建议在 daemon.json 里做日志轮转配置。以下是我常用的配置：
json复制{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
这个配置的含义是：单个日志文件最大 10MB，最多保留 3 个文件，超过就自动滚动清理。也就是说每个容器最多产生 30MB 日志。
配置完同样需要重启 Docker：
bash复制sudo systemctl daemon-reload
sudo systemctl restart docker
注意：这个配置只对新建的容器生效，已经存在的容器不会自动套用新配置。要想让现有容器也限制日志大小，需要重建容器。所以最好的习惯是建容器之前就把日志配置写好。
3.4 设置正确的存储目录：有条件就换个大分区
Docker 默认把所有数据（镜像、容器、数据卷）存放在 /var/lib/docker。如果你的系统盘空间不够大，比如默认系统盘才 40GB，几个镜像加容器数据可能就不够了。
可以通过配置更改数据存储目录，比如挂载一个数据盘到 /data/docker：
json复制{
"data-root": "/data/docker"
}
然后重启 Docker。注意一点：改存储目录相当于搬家，原有的镜像和容器数据不会自动迁移，需要你先停掉 Docker，手动把数据搬过去，或者接受"重新开始"——反正镜像可以再拉，数据卷想办法备份就行。
这里我特别建议：在生产环境，如果你有独立的数据盘，尽早规划好把 Docker 数据目录指到数据盘上，别等磁盘满了再迁移，那很麻烦。
3.5 开启 Docker 远程 API（可选，不推荐默认开）
开发调试时，有时候会想通过本机 Docker Desktop 去连远程主机的 Docker，也就是配置 Docker 远程 API。这个功能很强大，但默认情况下千万不要直接对外开放，因为 Docker 的 API 没有内置认证，被扫描到就会被人拿去挂载宿主机目录，等于直接被人控制主机。
如果确实有需求，安全做法是配置 TLS 证书认证，或者通过 SSH 隧道连接。最省事的方式是通过 SSH 标准连接，而不是直接暴露端口。我不建议在本文展开讲远程 API 的开放细节，因为对大多数读者来说，这个暂时用不到，等你真需要了又已经明白安全风险了。
4. 走上正轨：验证安装并部署第一个容器
配置好基本环境之后，可以部署一个简单的容器来验证整个链路是否通畅。我推荐先跑一个 Nginx 容器，因为 Nginx 镜像体积小、启动快、验证方式直观。
4.1 运行 Nginx 容器验证全链路
先拉取镜像：
bash复制docker pull nginx:alpine
这里用了 nginx:alpine 而不是默认的 nginx:latest，原因是 Alpine 版镜像体积小得多，只有几十 MB，拉取速度快，磁盘占用少。
拉取完成后启动一个测试容器：
bash复制docker run -d --name test-nginx -p 8080:80 nginx:alpine
这条命令的含义：
-d表示后台运行--name test-nginx给容器命名为 test-nginx-p 8080:80把宿主机的 8080 端口映射到容器的 80 端口nginx:alpine指定使用的镜像
启动后确认容器状态：
bash复制docker ps
看到 STATUS 列为 Up 就说明容器在正常运行。然后在浏览器访问 http://你的服务器IP:8080，如果能看到 Nginx 的欢迎页，说明整套 Docker 环境完全打通了。
验证完把这个测试容器删掉，免得占着资源：
bash复制docker stop test-nginx
docker rm test-nginx
4.2 用 hello-world 验证 Docker 引擎（可选）
如果你不确定 Nginx 起不来是因为镜像问题还是 Docker 问题，可以先跑一个更轻量级的测试：
bash复制docker run --rm hello-world
这个镜像本身就是一个简单的可执行程序，运行完打印一段欢迎信息就退出。--rm 参数表示容器运行结束后自动清理，避免留下垃圾容器。
能正常打印欢迎信息，就说明 Docker 引擎最核心的功能——守护进程、容器运行时、镜像管理——都是正常的。
4.3 常用命令速查：装完马上能用起来
这里整理一份我平时最常用的命令清单，刚上手的朋友可以收藏一份：
| 操作 | 命令 |
|---|---|
| 查看所有容器（含停止的） | docker ps -a |
| 查看所有镜像 | docker images |
| 进入运行中的容器内部 | docker exec -it 容器名 /bin/bash |
| 查看容器日志 | docker logs 容器名 |
| 停止容器 | docker stop 容器名 |
| 删除容器 | docker rm 容器名 |
| 删除镜像 | docker rmi 镜像名:标签 |
| 批量清理无用的容器和悬空镜像 | docker system prune |
| 查看磁盘占用 | docker system df |
这些命令够你日常使用绝大多数场景了。更高级的命令没必要一次性背上，用到的时候再查完全来得及。
5. 常见问题和坑：我把踩过的坑都写出来
安装 Docker 的过程中，有几个问题几乎每个新手都会遇到，我干脆集中写出来，省得你再一遍遍搜索。
5.1 安装时报 "Unable to locate package docker-ce"
这个问题几乎都出在软件源配置没生效这一步。最常见的原因是：apt update 没执行成功，或者软件源配置文件里的系统版本代号不对。
排查思路按顺序来：
bash复制# 1. 更新软件源
sudo apt-get update
# 2. 查看 docker-ce 包是否存在
apt-cache search docker-ce
# 3. 如果没有输出，检查源配置文件内容
cat /etc/apt/sources.list.d/docker.list
我遇到最多的情况是用了 $(lsb_release -cs) 得到了错误的版本代号。比如 Ubuntu 刚发布新版的时候，Docker 官方源可能还没支持该版本，这时候你就得手动把源配置里的版本代号改成上一版支持的代号。比如我在 Ubuntu 23.04 刚发布时遇到过这个情况，手动改成 lunar（22.04 的代号）后，问题就解决了。
5.2 运行 docker 命令提示 "Cannot connect to the Docker daemon"
这个提示的意思是：Docker 守护进程没有运行。先检查服务状态：
bash复制sudo systemctl status docker
如果服务没启动，可以用以下命令启动：
bash复制sudo systemctl start docker
但如果启动时报了错误，比如 failed to start docker.service: Unit docker.service not found，说明你装的是二进制版而不是软件包版，或者安装过程不完整，得回头检查安装步骤。
还有一种情况：你安装完后服务其实已经启动了，但依然报这个错。这时可以试试重新加载配置：
bash复制sudo systemctl daemon-reload
sudo systemctl restart docker
如果还不行，八成是 Docker 客户端 socket 权限问题，先把用户加入 docker 组（前面说过），再重新登录终端。
5.3 拉取镜像超时或极慢
这个问题的根本原因就是网络问题。除了配置镜像加速器（参见 3.2 节），还可以考虑设置代理或者换用多个镜像源。我这里列几个常见加速源地址，仅供参考：
- 阿里云：
https://xxxx.mirror.aliyuncs.com（需登录获取专属地址） - 中科大：
https://docker.mirrors.ustc.edu.cn - 腾讯云：
https://mirror.ccs.tencentyun.com
需要提醒大家，公共加速源随时可能调整策略或失效，如果你发现某个加速源突然不好用了，去网上搜一下最新的可用源，或者改用阿里云的专属地址，稳定性和速度都有保障。
5.4 容器启动后马上退出，看日志也没啥异常
有时候你执行 docker run -d nginx 后，docker ps 看容器根本没在运行，docker ps -a 看状态是 Exited。这种情况多半是容器中的应用启动方式不对，比如你用的是桌面版的镜像但没指定常驻进程。
排查方法：
bash复制# 查看容器退出码
docker inspect 容器名 --format='{{.State.ExitCode}}'
# 查看容器日志
docker logs 容器名
容器退出是一个很经典的问题，原因五花八门。如果你使用 -d 参数后台运行，那么容器内的主进程必须是一个前台运行的进程。如果主进程跑到后台去了，或者执行完就结束了，Docker 会认为容器使命完成，然后把容器停掉。比如用 docker run -d ubuntu 启动一个 Ubuntu 容器，Ubuntu 的默认命令是 bash，bash 执行完就退出，容器自然就结束了。这时候你需要指定一个常驻进程，例如：
bash复制docker run -d ubuntu tail -f /dev/null
这样就保证了容器一直在前台挂着，可以随时进去操作。
5.5 安装 Docker 后修改了 daemon.json，重启失败
daemon.json 是 Docker 的核心配置文件，里面任何 JSON 格式错误都会导致 Docker 服务启动失败。常见错误包括：多写了一个逗号、引号用了中文输入法、缺少右括号等。
排查方法很直接：
bash复制# 用 JSON 解析工具检查文件是否合法
cat /etc/docker/daemon.json | python3 -m json.tool
如果输出类似 Expecting ',' delimiter 之类的报错，就说明某个地方格式不对。这时候冷静下来逐行检查，或者重新复制一份正确的配置模板再改。改完后记得：
bash复制sudo systemctl daemon-reload
sudo systemctl restart docker
5.6 磁盘空间越用越少：学会清理 Docker 数据
容器跑得久了，你会发现在不清除不用镜像的情况下，磁盘慢慢被占满。这时可以用：
bash复制docker system df
查看各类数据的占用情况。然后根据实际情况清理：
bash复制# 清理悬空镜像（没有标签的镜像）
docker image prune
# 清理所有不用的镜像（谨慎）
docker image prune -a
# 清理停止的容器、悬空镜像、未使用的网络和构建缓存
docker system prune -a
docker system prune -a 这个命令威力很大，会把所有没在使用的镜像都清掉。执行前它会询问你确认，而且会提示你释放多少空间。建议第一次执行前先用 docker ps -a 确认有哪些容器是重要的，避免误伤。我自己习惯在跑完一个大项目后清理一次，通常能释放几个 GB 的空间。
6. 进阶一点：docker compose 和后续学习建议
走到这一步，Docker 基础环境已经非常牢靠了。接下来如果你要继续深入，最值得学的就是 Docker Compose。它是一个用于定义和运行多容器应用的工具，通过一个 YAML 文件把你整套服务（比如数据库、缓存、应用服务）的配置写清楚，一条命令全部拉起来。
6.1 快速了解 docker compose
前面安装 Docker 时，我提到安装了 docker-compose-plugin，也就是说你的系统上已经有 Compose 命令了（新版本叫 docker compose，中间有空格，而不是老版本的 docker-compose）。验证一下：
bash复制docker compose version
如果输出版本号，说明可以直接用。Compose 的核心是一个 docker-compose.yml 文件。举个例子，一个简单的 Nginx + MySQL 组合：
yaml复制version: '3'
services:
nginx:
image: nginx:alpine
ports:
- "8080:80"
restart: always
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: my-secret-pw
volumes:
- mysql_data:/var/lib/mysql
restart: always
volumes:
mysql_data:
在 docker-compose.yml 所在的目录下，执行：
bash复制docker compose up -d
两个服务就同时启动了。停掉整个项目：
bash复制docker compose down
用 Compose 管理容器，比一个个敲 docker run 要省心太多，配置文件还能提交到 Git 里做版本管理，团队协作非常方便。
6.2 适合入门练手的方向
如果装好了 Docker 但不知道用它来干嘛，我建议从这几个方向练手：
一是把常用的开发中间件容器化，比如在容器里跑 MySQL、Redis、Nginx、RabbitMQ。这样做的好处是开发环境与本地系统完全隔离，换个版本、升级、删除都非常干净，不会把宿主机搞得一团糟。
二是在容器里搭建一些开源系统。比如下一套 WordPress 跑起来，把整个站点通过 Docker Compose 组织起来，你能从中学会镜像、数据卷、端口映射、环境变量等知识点，收获非常大。
三是学习写自己的 Dockerfile。拿一个简单的 Python 或 Node.js 项目，写一个 Dockerfile 把它构建成镜像，然后运行容器。这是从"无障碍用户"跨向"容器工程化"的关键一步。
6.3 关于 docker-compose 容器编排，说说我自己的一点体会
我在实际的生产环境中跑过不少多容器项目，最直观的体会是：Compose 解决的不只是"一条命令起多个容器"的问题，更重要的是它把服务的生命周期管理做了统一处理。你在一个文件里就能看到端口映射、环境变量、挂载目录、网络配置，整个项目依靠这个文件就能复现到另一台机器上。提交到 Git 仓库里，换人接手也能快速跑起来。对于想用 Docker 提升效率、规范环境的人来说，Compose 是绕不过去的一道坎。
最后分享一个小经验：刚装好 Docker 的那几天，先别急着折腾太多容器，把基础操作练熟，比如镜像的拉取和删除、容器的启动和停止、日志的查看和清理。只有基础操作熟练了，再看那些复杂的编排和调度概念，才会有自然的理解基础。装 Docker 只是一个开始，把这一整套容器工作流融入日常使用中，才是值得长期投入的方向。