最近有人问我CentOS 上装好了 docker 之后该从哪一步开始玩。其实这类问题挺常见的因为 docker 的入门资料虽然多但很多都是按别的发行版写的放到 CentOS 上就会遇到软件源、selinux、systemd 这些差异。我自己刚接触容器那阵子也曾经因为一块网卡配置折腾到半夜后来才意识到不是命令记错而是对 docker 的运行模型理解得太浅。这篇文章就是我从零开始梳理的 docker 入门第一课核心环境是 CentOS 加 Linux 命令行适合那种已经会敲 ls、cd 和 yum但没真正把容器跑起来的人。看完之后你应该能自己完成安装、拉镜像、启动容器、查看日志这些基础操作。1. 为什么选择 CentOS 来玩 docker1.1 CentOS 和容器运行的关系CentOS 在服务器领域的分量不用我多说很多公司的线上环境都基于它。选择 CentOS 跑 docker主要图的是稳定性和系统管理方式统一。CentOS 从主流版本开始全面使用 systemd而 docker 的服务也通过 systemd 管理两者配合起来很顺手。另一个优点是对 Yum 的生态支持很完整安装软件时不需要手动去编译一堆依赖直接把官方仓库加进来就能装。这里顺便说一句如果你是拿 CentOS 的老版本做实验docker 也能正常跑但最好把内核版本确认一下因为新版 docker 对内核模块和 iptables 的依赖越来越敏感。我实际测试过的环境通常是干净的最小化安装没有多余的图形界面。这种系统在开机引导阶段不会加载太多无关服务docker 启动之后端口和 iptables 规则也好排查。相比之下带桌面的发行版虽然也能玩但防火墙上多出的节点会让人定位问题的时候多绕几个弯。所以如果你打算从零开始学我更推荐直接在一台干净的 CentOS 虚拟机里做实验既能模拟真实服务器环境又不会影响日常使用的电脑。1.2 镜像、容器、仓库这三个词必须分清docker 入门有一个非常关键的概念模型镜像、容器、仓库。我刚学的时候总是把镜像和容器当成一回事后来发现这是很多操作事故的根源。镜像相当于一个只读的模板里面装好了操作系统基础文件、运行环境和你期望的应用代码。容器则是镜像运行起来后的实例它有自己的文件系统可写层、网络命名空间和进程空间。你可以把镜像理解成安装光盘容器理解成光盘装好之后运行中的系统光盘本身不会变系统里改什么文件都对光盘没有影响。仓库则解决镜像的存储和分发问题平时我们用的 docker pull 就是从远端仓库把镜像拉到本地。拉下来之后镜像在本地以分层的形式存储所以有时候你会发现删除镜像并没有腾出预期的空间那是因为某些底层层还被别的镜像引用。理解这三者的关系之后再去看那些 docker 命令就不会觉得命令之间是孤立的docker build 是制作镜像docker run 是根据镜像启动容器docker push 是把镜像推到仓库docker pull 则是反向操作。后面所有实操都围绕这三个角色展开先把它们分清楚能少踩一半的坑。2. 在 CentOS 上搭建 docker 运行环境的完整步骤2.1 安装前必须做的系统检查拿到一台 CentOS 机器先别急着复制安装命令。我见过太多人一上来就 yum install docker结果装的是老版本或者直接被跳过了。第一步是确认系统版本和架构执行cat /etc/os-release就能看到版本信息执行uname -r看内核版本。docker 正常运行需要内核版本足够新一般不建议低于 3.10。如果内核太老会出现 storage driver 不支持、容器网络通信异常这类问题。第二步是检查命令工具链是否完整。CentOS 最小化安装默认可能没有 yum-utils这会导致你后面 yum-config-manager 用不了。我一般安装前先把这些基础工具装上yum-utils、device-mapper-persistent-data、lvm2。device-mapper 和 lvm2 主要服务于 docker 的存储驱动虽然现在默认是 overlay2但保持这些库存在可以减少不必要的麻烦。安装完之后确认 selinux 的状态这里要特别说明不建议把 selinux 直接关闭而是建议给 docker 目录打上合适的上下文标签或者使用 permissive 模式做实验。完全关闭 selinux 虽然能解决部分权限问题但线上系统这么做风险很高。2.2 用 Yum 源安装 docker 引擎前面检查没问题就可以开始安装了。在 CentOS 上推荐通过软件仓库来安装而不是下载一个二进制包手动放进去。手动包的问题在于后续升级和依赖维护只能靠你自己仓库方式则可以用 yum 自动完成。操作一般是先用 yum-config-manager 添加官方 docker 仓库再执行 yum install docker-ce docker-ce-cli containerd.io。如果你所在网络环境访问官方仓库很慢也可以换成国内可用的镜像源但换之前最好确认来源可信软件源这种入口一旦被篡改上面跑的服务器可就不只是少个文件那么简单了。装完之后先不要着急跑容器先用systemctl start docker启动服务再用systemctl enable docker设置开机自启。启动之后建议执行docker version看客户端和服务端版本是否都正常再docker info查看存储驱动和文件系统信息。这里有一个新手经常踩的坑docker version 客户端有输出但服务端显示 cannot connect。看到这个提示优先查 docker.service 是不是启动失败而不是怀疑命令敲错。用journalctl -u docker看服务日志比到处搜报错要快得多。2.3 配置镜像加速器和默认日志策略安装完成后别急着拉第一个镜像我习惯先改一下 /etc/docker/daemon.json。这个文件是 docker 守护进程的配置入口大部分运行期参数都可以在这里声明。最常见的配置是镜像加速源、默认日志大小和存储驱动。镜像加速不是必需的但如果你发现自己 docker pull 一个公共镜像总是半路卡住多半就是网络到远端仓库的链路不稳定配置一个可用的 registry-mirror 能明显提升拉取成功率。地址可以去你所在云厂商的控制台拿通常格式是 https://xxx然后放到 daemon.json 里的 registry-mirrors 数组里。日志策略也非常重要。默认情况下容器日志不限制大小如果某个程序疯狂打日志/var/lib/docker/containers 目录会一直膨胀最后把磁盘撑满。我一般会在 daemon.json 里配置log-driver: json-file和max-size: 10m、max-file: 3这样每个容器日志超过 10M 就会自动轮转最多保留 3 个文件。改完 daemon.json 之后需要执行systemctl daemon-reload然后systemctl restart docker。配置文件只要语法写错docker 服务会起不来所以改完一定要通过 docker info 检查一遍。3. 镜像和容器的核心操作与实用参数3.1 拉取镜像时要学会看版本标签弄好环境后第一个可以玩的东西就是拉镜像。很多人喜欢直接 docker pull 一个系统镜像但这样做拉下来的往往是最新版本不一定适合你的实验场景。我习惯先 docker search 或者去镜像仓库页面找到需要打的 tag比如 ubuntu:22.04、nginx:stable-alpine而不是直接用 latest。latest 的坏处在于它是个会漂移的指针今天拉的是旧版过段时间再 pull 可能就变成了新版如果你的项目依赖某个特定的行为版本漂移会成为隐患。镜像拉到本地后可以用 docker images 查看列表能看到仓库名、标签、镜像 ID、创建时间和大小。说到镜像 ID它其实是镜像唯一 ID 的前 12 位用来在命令里定位某个镜像。如果你不需要某个镜像了可以先查看有没有容器在用它再执行 docker rmi 删除。删除的时候如果提示 image is being used by container说明你的容器还停在那里需要先 docker rm 删掉容器或者加 -f 强制删除。我不建议对运行中的容器用 -f因为会掩盖你忘记清理容器的事实后续反复出现僵尸容器。3.2 启动容器的常用参数和资源限制当镜像准备好了docker run 就是最常用的启动命令。最基本的写法是docker run -d --name nginx-demo -p 8080:80 nginx:alpine。这里 -d 表示后台运行--name 给容器起一个容易识别的名字-p 做端口映射把宿主机的 8080 端口映射到容器内部的 80 端口。我一直建议每个容器都加 --name不加名字的话每次都要查容器 ID非常不直观而且像 docker logs、docker stop 这种日常操作都要带容器 ID记起来很痛苦。除了端口映射资源限制也是启动参数里的重头戏。如果不限制内存和 CPU一个出问题的容器可能会把宿主机拖垮。我常用的限制参数是 --memory 256m、--cpus 0.5分别限制内存上限和 CPU 使用上限。还有一个经常被忽略的参数是 --restart它决定容器退出后如何重启。开发环境可以用 --restart unless-stopped这样机器重启后只要容器之前没被手动停止就会自动拉起来。线上环境则需要更细致的策略不是所有容器都适合自动重启。3.3 日志查询和进入容器调试容器跑起来之后怎么看它是否正常我通常先 docker ps 看运行状态。如果容器存活但业务有异常就用 docker logs --tail 100 容器名 去看最近 100 行日志。docker logs 的另一个实用参数是 -f可以像 tail -f 一样实时跟着输出调试回调类任务时非常有用。如果业务程序有写日志文件也可以先用 docker exec 进容器直接看文件不过前提是容器里有 shell 和常用命令。进入容器的方法一般是docker exec -it 容器名 /bin/bash如果容器里没有 bash就用/bin/sh。进入之后可以查看进程、网络、文件路径等确认外部反馈的问题到底出在哪。这里要提醒你docker exec 是在运行中的容器里起了一个新进程它和 docker attach 不一样。attach 会把当前终端绑定到容器主进程上如果主进程是交互式 shell退出后容器也会退出exec 就灵活得多exit 退出容器进程不受影响。所以日常调试我更推荐 exec而不是 attach。3.4 端口映射的原理和动态端口端口映射看起来简单但理解它的原理能避免不少误操作。docker run 的时候用 -p 是手动指定映射关系格式是宿主机端口:容器端口。比如-p 8080:80意思是访问宿主机的 8080 端口流量会转发到容器的 80 端口。docker 实现这个转发主要靠 iptables 规则所以你改了宿主机防火墙之后如果发现容器端口访问不到先检查 docker 创建的 iptables 链是否还在很多防火墙重启操作会把 docker 链清掉导致端口消失。除了手动指定端口docker 还支持-P它会将容器内所有暴露的端口自动映射到宿主机上随机端口。这个功能适合拿来快速验证但不适合固定服务因为每次创建容器分配的端口都可能不同。如果你需要给服务固定入口还是用 -p 指定一个明确的宿主机端口更可靠。另外在写端口映射时要注意不要冲突比如宿主机 8080 已经被别的进程占用docker 启动容器时会直接报端口被占用但不会帮你自动换端口。看到这种报错可以用 ss -lntp 查一下宿主机是谁在监听。4. 数据卷与挂载目录解决容器数据持久化问题4.1 容器删除后数据为什么不见了玩一段时间 docker 你就会发现一个很反直觉的问题容器里写了文件然后 docker rm 删掉容器文件也没了。这不是 bug而是容器的设计行为。容器文件系统由镜像只读层和容器可写层叠起来容器删除时这个可写层会被销毁。如果你在容器里写了一个配置文件没有同步到宿主机删除容器等于连配置一起删除。为了避免数据丢失docker 提供了数据卷和 bind mount 两种方式把数据保存在宿主机上。数据卷是 docker 管理的一块存储区域和容器生命周期解耦。创建方式是在运行容器时加-v 卷名:/路径或者用docker volume create手动创建。docker 会把这个数据卷挂载到容器指定的目录。数据卷的一个显著优点是多个容器可以共享同一个卷适合做日志聚合或配置文件同步。不过数据卷的位置在 /var/lib/docker/volumes 下面直接管理起来不太直观所以很多开发场景会更喜欢用 bind mount。4.2 bind mount 的方式做本地开发bind mount 就是把宿主机的某个目录直接映射进容器。启动容器时加-v /宿主机目录:/容器目录就可以。比如你本地有个代码目录 /data/www想让 nginx 容器直接服务这个目录就可以写docker run -d --name web -v /data/www:/usr/share/nginx/html -p 8080:80 nginx:alpine。这样宿主机上改代码容器内马上能看到最新内容非常适合开发调试。生产环境也可以用 bind mount 挂载证书和配置但要注意目录权限必须匹配容器内运行的用户。bind mount 有一个常见的权限坑宿主机目录的所有者 UID 和容器内进程 UID 不一致时容器里可能无法读写文件。比如镜像里的 nginx 以 nginx 用户运行它的 UID 是 101而宿主机目录是 root 所有容器进程就只能读不能写。遇到这种情况可以调整宿主机目录属主或者在 docker run 时加 --user 参数指定以某个 UID 运行。不过 --user 会改变容器内进程的权限不能盲目设置得先想清楚业务到底需要哪个用户权限。保持 UID 一致通常是最省事的方式。4.3 数据卷备份和多容器共享数据卷虽然好用但很多人忽略了对它做备份。因为卷独立于容器存在如果你只把容器删掉卷还在但一旦把整个 /var/lib/docker 目录误删所有卷数据也会跟着没。常规思路是用一个临时容器把卷打包出来比如docker run --rm -v 卷名:/data -v 宿主机备份目录:/backup alpine tar czf /backup/volume.tar.gz /data这样就把卷内容压缩到了宿主机指定位置。tar 命令完成之后容器自动删除但备份文件保留下来逻辑很清晰。多容器共享同一份数据时数据卷也有优势。两个容器可以通过同一个卷实现文件级别的协同。比如一个容器写应用日志另一个容器负责收集日志并转发只要它们挂载同一个卷就不需要额外的网络文件传输。不过在共享时要注意并发写同一个文件可能导致内容错乱应用自身最好做过文件锁或者按目录拆分。docker 容器之间并不是天生适合共享同一份数据设计存储方案时要考虑实际业务写入模式。5. 常见问题与排查技巧实录5.1 权限问题普通用户不想每次输 sudo用 docker 最常遇到的权限问题就是普通用户执行 docker 命令会报 Permission denied。这是因为 docker 的守护进程默认以 root 运行访问它需要 root 权限。简单粗暴的做法是给 docker 命令加 sudo但如果项目里每天要敲几十条 docker 命令每次都输 sudo 会很烦。更常见的做法是把执行 docker 命令的用户加入 docker 组这样用户就不需要再提权。执行sudo usermod -aG docker 你的用户名然后重新登录 shell 才能生效。这里要注意加入 docker 组的用户实际上获得了接近于 root 的能力因为 docker 可以挂载宿主机目录、修改网络配置甚至可以启动特权容器。所以不要把随便一个用户都加进 docker 组特别是多人共用的服务器至少要保证这个用户是可信任的管理员。如果你只是临时用一次还是用 sudo 更安全。从安全角度讲docker 组权限和 sudo 权限级别很像千万不能当成普通账户权限来对待。5.2 镜像拉取失败和 DNS 排查思路新手最常见的报错是拉取镜像时卡住或提示类似 TLS handshake timeout 的信息。出现这种问题大概率是网络访问远端仓库不稳定尤其在一些跨网环境下特别明显。排查顺序我一般是先确认宿主机能否访问公网用 ping 或 curl 测试一个固定站点再看 DNS 配置是否正确。如果 DNS 有问题容器内部解析域名也可能失败会出现 temporary failure in name resolution。这时候检查 /etc/resolv.conf确认 nameserver 地址没有被改写或者手动指定容器的 DNS 参数。如果网络没问题但拉取还是慢那就考虑配置镜像加速器。在 daemon.json 里改 registry-mirrors 是推荐做法。配置完成之后不要光看配置文件里写没写要看 docker info 输出的 Registry Mirrors 列表是否更新。没有更新说明守护进程还没重载配置或者服务没重启。还有一个折中办法是使用 docker save 和 docker load 在离线环境迁移镜像把镜像从一台有网络的机器导出成 tar 包再拷到目标机器 load 进去非常适合内网环境。5.3 容器起来又秒退怎么定位原因容器一启动就退出这个问题出现的频率非常高。最常见的原因是前台进程跑完就结束。docker 容器不会自己维持一个持续存在的系统如果你启动的容器只执行了一条 echo 命令命令执行完容器回到 exited 状态。解决办法是让主进程保持前台运行。比如启动一个 nginx 容器命令里不要写成后台启动方式要保证 nginx 是前台进程容器才会持续运行。很多软件镜像已经默认做好这一点但你自己打包镜像时经常会踩中这个坑。另外要看的执行结果。先用 docker logs 容器名 看输出再 docker inspect 查看状态里的 ExitCode 和 OOMKilled 字段。如果 OOMKilled 是 true说明容器被系统杀掉了需要调高 --memory 限制。还有一个容易忽略的问题是启动命令写错路径比如镜像里实际没有 /bin/bash只有 /bin/sh你强制用 bash 启动就会直接失败。这类问题通过 docker logs 能立刻看到 error关键是养成先日志再猜测的习惯能省下大量时间。5.4 磁盘空间被容器日志和镜像占满服务器跑一段时间之后docker 占用的磁盘空间会越来越大主要集中在镜像层、容器可写层和日志文件三块。查看占用最简单的是执行docker system df它会列出镜像、容器、本地卷、构建缓存占到多少空间。如果发现日志占大头可以检查 daemon.json 里的 log-driver 和 max-size 是否生效。如果没提前配置已经存在的容器不会自动重建所以要手动清理一下日志文件或者重新创建容器。清理空间最常用的命令是 docker system prune -a。它会把所有未使用的镜像、已停止的容器、无用的网络和构建缓存一次性清掉释放空间非常明显。但这里要提醒-a会把没有被容器使用的镜像全部删除包括你可能想留作备份的镜像层。所以如果你只是想清理停止容器和空卷就用不带 -a 的 docker system prune想彻底清理再考虑加 -a。还有docker volume prune只清理未被任何容器使用的数据卷要小心操作因为卷里可能有重要数据。6. 我玩 docker 后的几条实操心得6.1 写一个小脚本记录常用命令玩了几个月 docker 之后我最大的体会是命令不要靠背靠的是场景化理解。我写了一个简单的 shell 脚本来封装最常用的启动和清理命令比如启动 web 容器、查看日志、清理未使用资源这些别名。好处是你不需要每次都咬牙切齿地敲一长串 docker run 参数尤其参数多的时候少一个 -v 或 -p 都可能导致完全不同的结果。封装脚本还能统一团队内部的操作习惯比如日志大小、重启策略都放在脚本里避免每个人手动加参导致线上配置不统一。脚本不算复杂但实用性很强。还有一个小技巧是给容器名称加上项目前缀比如 app-web、app-worker这样 docker ps 输出一眼就能看出这个容器属于哪个应用。容器名称本身只是一个标识但命令里的匹配和查看会很方便。docker 容器数量一旦上到几十个一个规范命名能帮你节省大量检索时间。6.2 定期整理 docker 配置和目录容器用多了之后宿主机上的配置文件会比较分散。我习惯每次部署完都会把 daemon.json、docker 启动参数、挂载目录整理到一个本地文档里至少记清楚哪个容器用了哪些端口和数据卷。这样做不是为了写文档而写文档而是在容器重建的时候能快速恢复。很多时候容器出现问题最简单的办法就是删掉重建但重建需要知道原来的启动参数如果你认真记录过整个过程基本就是复制粘贴。对于目录本身我建议把持久化数据统一放在 /data 下面而不是各自分散在乱七八糟的路径。这样备份、迁移和权限管理都会轻松很多。docker 本身不关心目录放在哪但一个清晰的目录约定会让排查问题的时候少走很多弯路。6.3 下一步可以往哪个方向扩展这篇教程带的还只是 docker 的基础玩法。当你熟悉了镜像和容器命令之后下一步可以尝试自己写 Dockerfile用 docker build 把应用打包成自定义镜像。还可以用 docker network 创建自定义网络让不同容器之间通过容器名直接互通。再往后就是编排层面的事比如用 compose 或集群工具管理多容器应用。这些都是同一个学习路径上很自然的方向但前提是先把这篇里的基础操作多用几遍容器生命周期真正熟悉了后面的内容学起来会轻松很多。每次踩坑之后我都会记一笔慢慢就会形成一套适合自己习惯的工作流。如果你也是刚开始在 Linux 下玩 docker建议别急着追新概念先把这篇文章里的命令逐个跑通遇到问题就翻日志、查配置跑多了自然就有感觉。基础操作扎实之后后面不管是做自动化部署还是环境隔离都会顺手很多。
最近有人问我CentOS 上装好了 docker 之后该从哪一步开始玩。其实这类问题挺常见的因为 docker 的入门资料虽然多但很多都是按别的发行版写的放到 CentOS 上就会遇到软件源、selinux、systemd 这些差异。我自己刚接触容器那阵子也曾经因为一块网卡配置折腾到半夜后来才意识到不是命令记错而是对 docker 的运行模型理解得太浅。这篇文章就是我从零开始梳理的 docker 入门第一课核心环境是 CentOS 加 Linux 命令行适合那种已经会敲 ls、cd 和 yum但没真正把容器跑起来的人。看完之后你应该能自己完成安装、拉镜像、启动容器、查看日志这些基础操作。1. 为什么选择 CentOS 来玩 docker1.1 CentOS 和容器运行的关系CentOS 在服务器领域的分量不用我多说很多公司的线上环境都基于它。选择 CentOS 跑 docker主要图的是稳定性和系统管理方式统一。CentOS 从主流版本开始全面使用 systemd而 docker 的服务也通过 systemd 管理两者配合起来很顺手。另一个优点是对 Yum 的生态支持很完整安装软件时不需要手动去编译一堆依赖直接把官方仓库加进来就能装。这里顺便说一句如果你是拿 CentOS 的老版本做实验docker 也能正常跑但最好把内核版本确认一下因为新版 docker 对内核模块和 iptables 的依赖越来越敏感。我实际测试过的环境通常是干净的最小化安装没有多余的图形界面。这种系统在开机引导阶段不会加载太多无关服务docker 启动之后端口和 iptables 规则也好排查。相比之下带桌面的发行版虽然也能玩但防火墙上多出的节点会让人定位问题的时候多绕几个弯。所以如果你打算从零开始学我更推荐直接在一台干净的 CentOS 虚拟机里做实验既能模拟真实服务器环境又不会影响日常使用的电脑。1.2 镜像、容器、仓库这三个词必须分清docker 入门有一个非常关键的概念模型镜像、容器、仓库。我刚学的时候总是把镜像和容器当成一回事后来发现这是很多操作事故的根源。镜像相当于一个只读的模板里面装好了操作系统基础文件、运行环境和你期望的应用代码。容器则是镜像运行起来后的实例它有自己的文件系统可写层、网络命名空间和进程空间。你可以把镜像理解成安装光盘容器理解成光盘装好之后运行中的系统光盘本身不会变系统里改什么文件都对光盘没有影响。仓库则解决镜像的存储和分发问题平时我们用的 docker pull 就是从远端仓库把镜像拉到本地。拉下来之后镜像在本地以分层的形式存储所以有时候你会发现删除镜像并没有腾出预期的空间那是因为某些底层层还被别的镜像引用。理解这三者的关系之后再去看那些 docker 命令就不会觉得命令之间是孤立的docker build 是制作镜像docker run 是根据镜像启动容器docker push 是把镜像推到仓库docker pull 则是反向操作。后面所有实操都围绕这三个角色展开先把它们分清楚能少踩一半的坑。2. 在 CentOS 上搭建 docker 运行环境的完整步骤2.1 安装前必须做的系统检查拿到一台 CentOS 机器先别急着复制安装命令。我见过太多人一上来就 yum install docker结果装的是老版本或者直接被跳过了。第一步是确认系统版本和架构执行cat /etc/os-release就能看到版本信息执行uname -r看内核版本。docker 正常运行需要内核版本足够新一般不建议低于 3.10。如果内核太老会出现 storage driver 不支持、容器网络通信异常这类问题。第二步是检查命令工具链是否完整。CentOS 最小化安装默认可能没有 yum-utils这会导致你后面 yum-config-manager 用不了。我一般安装前先把这些基础工具装上yum-utils、device-mapper-persistent-data、lvm2。device-mapper 和 lvm2 主要服务于 docker 的存储驱动虽然现在默认是 overlay2但保持这些库存在可以减少不必要的麻烦。安装完之后确认 selinux 的状态这里要特别说明不建议把 selinux 直接关闭而是建议给 docker 目录打上合适的上下文标签或者使用 permissive 模式做实验。完全关闭 selinux 虽然能解决部分权限问题但线上系统这么做风险很高。2.2 用 Yum 源安装 docker 引擎前面检查没问题就可以开始安装了。在 CentOS 上推荐通过软件仓库来安装而不是下载一个二进制包手动放进去。手动包的问题在于后续升级和依赖维护只能靠你自己仓库方式则可以用 yum 自动完成。操作一般是先用 yum-config-manager 添加官方 docker 仓库再执行 yum install docker-ce docker-ce-cli containerd.io。如果你所在网络环境访问官方仓库很慢也可以换成国内可用的镜像源但换之前最好确认来源可信软件源这种入口一旦被篡改上面跑的服务器可就不只是少个文件那么简单了。装完之后先不要着急跑容器先用systemctl start docker启动服务再用systemctl enable docker设置开机自启。启动之后建议执行docker version看客户端和服务端版本是否都正常再docker info查看存储驱动和文件系统信息。这里有一个新手经常踩的坑docker version 客户端有输出但服务端显示 cannot connect。看到这个提示优先查 docker.service 是不是启动失败而不是怀疑命令敲错。用journalctl -u docker看服务日志比到处搜报错要快得多。2.3 配置镜像加速器和默认日志策略安装完成后别急着拉第一个镜像我习惯先改一下 /etc/docker/daemon.json。这个文件是 docker 守护进程的配置入口大部分运行期参数都可以在这里声明。最常见的配置是镜像加速源、默认日志大小和存储驱动。镜像加速不是必需的但如果你发现自己 docker pull 一个公共镜像总是半路卡住多半就是网络到远端仓库的链路不稳定配置一个可用的 registry-mirror 能明显提升拉取成功率。地址可以去你所在云厂商的控制台拿通常格式是 https://xxx然后放到 daemon.json 里的 registry-mirrors 数组里。日志策略也非常重要。默认情况下容器日志不限制大小如果某个程序疯狂打日志/var/lib/docker/containers 目录会一直膨胀最后把磁盘撑满。我一般会在 daemon.json 里配置log-driver: json-file和max-size: 10m、max-file: 3这样每个容器日志超过 10M 就会自动轮转最多保留 3 个文件。改完 daemon.json 之后需要执行systemctl daemon-reload然后systemctl restart docker。配置文件只要语法写错docker 服务会起不来所以改完一定要通过 docker info 检查一遍。3. 镜像和容器的核心操作与实用参数3.1 拉取镜像时要学会看版本标签弄好环境后第一个可以玩的东西就是拉镜像。很多人喜欢直接 docker pull 一个系统镜像但这样做拉下来的往往是最新版本不一定适合你的实验场景。我习惯先 docker search 或者去镜像仓库页面找到需要打的 tag比如 ubuntu:22.04、nginx:stable-alpine而不是直接用 latest。latest 的坏处在于它是个会漂移的指针今天拉的是旧版过段时间再 pull 可能就变成了新版如果你的项目依赖某个特定的行为版本漂移会成为隐患。镜像拉到本地后可以用 docker images 查看列表能看到仓库名、标签、镜像 ID、创建时间和大小。说到镜像 ID它其实是镜像唯一 ID 的前 12 位用来在命令里定位某个镜像。如果你不需要某个镜像了可以先查看有没有容器在用它再执行 docker rmi 删除。删除的时候如果提示 image is being used by container说明你的容器还停在那里需要先 docker rm 删掉容器或者加 -f 强制删除。我不建议对运行中的容器用 -f因为会掩盖你忘记清理容器的事实后续反复出现僵尸容器。3.2 启动容器的常用参数和资源限制当镜像准备好了docker run 就是最常用的启动命令。最基本的写法是docker run -d --name nginx-demo -p 8080:80 nginx:alpine。这里 -d 表示后台运行--name 给容器起一个容易识别的名字-p 做端口映射把宿主机的 8080 端口映射到容器内部的 80 端口。我一直建议每个容器都加 --name不加名字的话每次都要查容器 ID非常不直观而且像 docker logs、docker stop 这种日常操作都要带容器 ID记起来很痛苦。除了端口映射资源限制也是启动参数里的重头戏。如果不限制内存和 CPU一个出问题的容器可能会把宿主机拖垮。我常用的限制参数是 --memory 256m、--cpus 0.5分别限制内存上限和 CPU 使用上限。还有一个经常被忽略的参数是 --restart它决定容器退出后如何重启。开发环境可以用 --restart unless-stopped这样机器重启后只要容器之前没被手动停止就会自动拉起来。线上环境则需要更细致的策略不是所有容器都适合自动重启。3.3 日志查询和进入容器调试容器跑起来之后怎么看它是否正常我通常先 docker ps 看运行状态。如果容器存活但业务有异常就用 docker logs --tail 100 容器名 去看最近 100 行日志。docker logs 的另一个实用参数是 -f可以像 tail -f 一样实时跟着输出调试回调类任务时非常有用。如果业务程序有写日志文件也可以先用 docker exec 进容器直接看文件不过前提是容器里有 shell 和常用命令。进入容器的方法一般是docker exec -it 容器名 /bin/bash如果容器里没有 bash就用/bin/sh。进入之后可以查看进程、网络、文件路径等确认外部反馈的问题到底出在哪。这里要提醒你docker exec 是在运行中的容器里起了一个新进程它和 docker attach 不一样。attach 会把当前终端绑定到容器主进程上如果主进程是交互式 shell退出后容器也会退出exec 就灵活得多exit 退出容器进程不受影响。所以日常调试我更推荐 exec而不是 attach。3.4 端口映射的原理和动态端口端口映射看起来简单但理解它的原理能避免不少误操作。docker run 的时候用 -p 是手动指定映射关系格式是宿主机端口:容器端口。比如-p 8080:80意思是访问宿主机的 8080 端口流量会转发到容器的 80 端口。docker 实现这个转发主要靠 iptables 规则所以你改了宿主机防火墙之后如果发现容器端口访问不到先检查 docker 创建的 iptables 链是否还在很多防火墙重启操作会把 docker 链清掉导致端口消失。除了手动指定端口docker 还支持-P它会将容器内所有暴露的端口自动映射到宿主机上随机端口。这个功能适合拿来快速验证但不适合固定服务因为每次创建容器分配的端口都可能不同。如果你需要给服务固定入口还是用 -p 指定一个明确的宿主机端口更可靠。另外在写端口映射时要注意不要冲突比如宿主机 8080 已经被别的进程占用docker 启动容器时会直接报端口被占用但不会帮你自动换端口。看到这种报错可以用 ss -lntp 查一下宿主机是谁在监听。4. 数据卷与挂载目录解决容器数据持久化问题4.1 容器删除后数据为什么不见了玩一段时间 docker 你就会发现一个很反直觉的问题容器里写了文件然后 docker rm 删掉容器文件也没了。这不是 bug而是容器的设计行为。容器文件系统由镜像只读层和容器可写层叠起来容器删除时这个可写层会被销毁。如果你在容器里写了一个配置文件没有同步到宿主机删除容器等于连配置一起删除。为了避免数据丢失docker 提供了数据卷和 bind mount 两种方式把数据保存在宿主机上。数据卷是 docker 管理的一块存储区域和容器生命周期解耦。创建方式是在运行容器时加-v 卷名:/路径或者用docker volume create手动创建。docker 会把这个数据卷挂载到容器指定的目录。数据卷的一个显著优点是多个容器可以共享同一个卷适合做日志聚合或配置文件同步。不过数据卷的位置在 /var/lib/docker/volumes 下面直接管理起来不太直观所以很多开发场景会更喜欢用 bind mount。4.2 bind mount 的方式做本地开发bind mount 就是把宿主机的某个目录直接映射进容器。启动容器时加-v /宿主机目录:/容器目录就可以。比如你本地有个代码目录 /data/www想让 nginx 容器直接服务这个目录就可以写docker run -d --name web -v /data/www:/usr/share/nginx/html -p 8080:80 nginx:alpine。这样宿主机上改代码容器内马上能看到最新内容非常适合开发调试。生产环境也可以用 bind mount 挂载证书和配置但要注意目录权限必须匹配容器内运行的用户。bind mount 有一个常见的权限坑宿主机目录的所有者 UID 和容器内进程 UID 不一致时容器里可能无法读写文件。比如镜像里的 nginx 以 nginx 用户运行它的 UID 是 101而宿主机目录是 root 所有容器进程就只能读不能写。遇到这种情况可以调整宿主机目录属主或者在 docker run 时加 --user 参数指定以某个 UID 运行。不过 --user 会改变容器内进程的权限不能盲目设置得先想清楚业务到底需要哪个用户权限。保持 UID 一致通常是最省事的方式。4.3 数据卷备份和多容器共享数据卷虽然好用但很多人忽略了对它做备份。因为卷独立于容器存在如果你只把容器删掉卷还在但一旦把整个 /var/lib/docker 目录误删所有卷数据也会跟着没。常规思路是用一个临时容器把卷打包出来比如docker run --rm -v 卷名:/data -v 宿主机备份目录:/backup alpine tar czf /backup/volume.tar.gz /data这样就把卷内容压缩到了宿主机指定位置。tar 命令完成之后容器自动删除但备份文件保留下来逻辑很清晰。多容器共享同一份数据时数据卷也有优势。两个容器可以通过同一个卷实现文件级别的协同。比如一个容器写应用日志另一个容器负责收集日志并转发只要它们挂载同一个卷就不需要额外的网络文件传输。不过在共享时要注意并发写同一个文件可能导致内容错乱应用自身最好做过文件锁或者按目录拆分。docker 容器之间并不是天生适合共享同一份数据设计存储方案时要考虑实际业务写入模式。5. 常见问题与排查技巧实录5.1 权限问题普通用户不想每次输 sudo用 docker 最常遇到的权限问题就是普通用户执行 docker 命令会报 Permission denied。这是因为 docker 的守护进程默认以 root 运行访问它需要 root 权限。简单粗暴的做法是给 docker 命令加 sudo但如果项目里每天要敲几十条 docker 命令每次都输 sudo 会很烦。更常见的做法是把执行 docker 命令的用户加入 docker 组这样用户就不需要再提权。执行sudo usermod -aG docker 你的用户名然后重新登录 shell 才能生效。这里要注意加入 docker 组的用户实际上获得了接近于 root 的能力因为 docker 可以挂载宿主机目录、修改网络配置甚至可以启动特权容器。所以不要把随便一个用户都加进 docker 组特别是多人共用的服务器至少要保证这个用户是可信任的管理员。如果你只是临时用一次还是用 sudo 更安全。从安全角度讲docker 组权限和 sudo 权限级别很像千万不能当成普通账户权限来对待。5.2 镜像拉取失败和 DNS 排查思路新手最常见的报错是拉取镜像时卡住或提示类似 TLS handshake timeout 的信息。出现这种问题大概率是网络访问远端仓库不稳定尤其在一些跨网环境下特别明显。排查顺序我一般是先确认宿主机能否访问公网用 ping 或 curl 测试一个固定站点再看 DNS 配置是否正确。如果 DNS 有问题容器内部解析域名也可能失败会出现 temporary failure in name resolution。这时候检查 /etc/resolv.conf确认 nameserver 地址没有被改写或者手动指定容器的 DNS 参数。如果网络没问题但拉取还是慢那就考虑配置镜像加速器。在 daemon.json 里改 registry-mirrors 是推荐做法。配置完成之后不要光看配置文件里写没写要看 docker info 输出的 Registry Mirrors 列表是否更新。没有更新说明守护进程还没重载配置或者服务没重启。还有一个折中办法是使用 docker save 和 docker load 在离线环境迁移镜像把镜像从一台有网络的机器导出成 tar 包再拷到目标机器 load 进去非常适合内网环境。5.3 容器起来又秒退怎么定位原因容器一启动就退出这个问题出现的频率非常高。最常见的原因是前台进程跑完就结束。docker 容器不会自己维持一个持续存在的系统如果你启动的容器只执行了一条 echo 命令命令执行完容器回到 exited 状态。解决办法是让主进程保持前台运行。比如启动一个 nginx 容器命令里不要写成后台启动方式要保证 nginx 是前台进程容器才会持续运行。很多软件镜像已经默认做好这一点但你自己打包镜像时经常会踩中这个坑。另外要看的执行结果。先用 docker logs 容器名 看输出再 docker inspect 查看状态里的 ExitCode 和 OOMKilled 字段。如果 OOMKilled 是 true说明容器被系统杀掉了需要调高 --memory 限制。还有一个容易忽略的问题是启动命令写错路径比如镜像里实际没有 /bin/bash只有 /bin/sh你强制用 bash 启动就会直接失败。这类问题通过 docker logs 能立刻看到 error关键是养成先日志再猜测的习惯能省下大量时间。5.4 磁盘空间被容器日志和镜像占满服务器跑一段时间之后docker 占用的磁盘空间会越来越大主要集中在镜像层、容器可写层和日志文件三块。查看占用最简单的是执行docker system df它会列出镜像、容器、本地卷、构建缓存占到多少空间。如果发现日志占大头可以检查 daemon.json 里的 log-driver 和 max-size 是否生效。如果没提前配置已经存在的容器不会自动重建所以要手动清理一下日志文件或者重新创建容器。清理空间最常用的命令是 docker system prune -a。它会把所有未使用的镜像、已停止的容器、无用的网络和构建缓存一次性清掉释放空间非常明显。但这里要提醒-a会把没有被容器使用的镜像全部删除包括你可能想留作备份的镜像层。所以如果你只是想清理停止容器和空卷就用不带 -a 的 docker system prune想彻底清理再考虑加 -a。还有docker volume prune只清理未被任何容器使用的数据卷要小心操作因为卷里可能有重要数据。6. 我玩 docker 后的几条实操心得6.1 写一个小脚本记录常用命令玩了几个月 docker 之后我最大的体会是命令不要靠背靠的是场景化理解。我写了一个简单的 shell 脚本来封装最常用的启动和清理命令比如启动 web 容器、查看日志、清理未使用资源这些别名。好处是你不需要每次都咬牙切齿地敲一长串 docker run 参数尤其参数多的时候少一个 -v 或 -p 都可能导致完全不同的结果。封装脚本还能统一团队内部的操作习惯比如日志大小、重启策略都放在脚本里避免每个人手动加参导致线上配置不统一。脚本不算复杂但实用性很强。还有一个小技巧是给容器名称加上项目前缀比如 app-web、app-worker这样 docker ps 输出一眼就能看出这个容器属于哪个应用。容器名称本身只是一个标识但命令里的匹配和查看会很方便。docker 容器数量一旦上到几十个一个规范命名能帮你节省大量检索时间。6.2 定期整理 docker 配置和目录容器用多了之后宿主机上的配置文件会比较分散。我习惯每次部署完都会把 daemon.json、docker 启动参数、挂载目录整理到一个本地文档里至少记清楚哪个容器用了哪些端口和数据卷。这样做不是为了写文档而写文档而是在容器重建的时候能快速恢复。很多时候容器出现问题最简单的办法就是删掉重建但重建需要知道原来的启动参数如果你认真记录过整个过程基本就是复制粘贴。对于目录本身我建议把持久化数据统一放在 /data 下面而不是各自分散在乱七八糟的路径。这样备份、迁移和权限管理都会轻松很多。docker 本身不关心目录放在哪但一个清晰的目录约定会让排查问题的时候少走很多弯路。6.3 下一步可以往哪个方向扩展这篇教程带的还只是 docker 的基础玩法。当你熟悉了镜像和容器命令之后下一步可以尝试自己写 Dockerfile用 docker build 把应用打包成自定义镜像。还可以用 docker network 创建自定义网络让不同容器之间通过容器名直接互通。再往后就是编排层面的事比如用 compose 或集群工具管理多容器应用。这些都是同一个学习路径上很自然的方向但前提是先把这篇里的基础操作多用几遍容器生命周期真正熟悉了后面的内容学起来会轻松很多。每次踩坑之后我都会记一笔慢慢就会形成一套适合自己习惯的工作流。如果你也是刚开始在 Linux 下玩 docker建议别急着追新概念先把这篇文章里的命令逐个跑通遇到问题就翻日志、查配置跑多了自然就有感觉。基础操作扎实之后后面不管是做自动化部署还是环境隔离都会顺手很多。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
