Docker 入门：从第一个容器到可复用的开发环境

很多新手第一次接触 Docker，都会被镜像、容器、仓库这几个词绕晕。其实可以先记住一个比喻：镜像是做好的菜谱和半成品，容器是按菜谱真正开火做出来的一份菜，仓库则是存放菜谱的货架。理解了这一层，后面的命令就不再是死记硬背。

为什么要用 Docker？最常见的痛点不是程序写不出来，而是换一台机器就跑不起来。本地 Python 版本不同、系统库缺失、端口被占用，都可能让昨天还能运行的项目今天报错。把运行环境连同依赖一起装进镜像，别人拿到同一个镜像，就能在很大程度上复现你的运行结果。这对团队协作和部署来说，比反复口头交代环境配置可靠得多。

先跑通第一个容器。安装完成后，不必急着写复杂配置，先用一个最小镜像验证环境是否正常，再查看正在运行的容器和日志。看到容器正常启动、日志没有报错，才说明基础链路是通的。这个习惯很重要：很多问题不是配置写错了，而是第一步就没有验证，后面越调越乱。

接下来做一个真正可用的小例子。假设有一个简单的 Python 服务，我们可以写一个 Dockerfile：选择一个体积较小的官方基础镜像，设置工作目录，把代码复制进去，安装依赖，最后声明启动命令。构建时给镜像起一个清晰的名字和版本，运行时把容器端口映射到本机端口，并用名字启动，方便后续查看和停止。

日常最常用的几个命令，其实围绕三件事：看状态、看日志、进容器。查看容器列表可以确认它是否还在运行；查看日志可以定位启动失败的原因；进入容器可以检查文件和环境变量。停止和删除容器时要分清：停止只是让它暂停，删除才会真正清理。数据如果重要，一定不要只放在容器内部，要用数据卷挂载到本机目录，这样即使容器被删，数据也不会跟着消失。

新手排错可以按这个顺序来：先看日志，再看端口映射，最后看镜像版本和环境变量。端口冲突时换一个本机端口；依赖安装失败时先确认网络和基础镜像版本；程序在容器里找不到文件时，先检查复制路径和工作目录。把每一次报错的完整日志保存下来，比凭感觉反复改配置更有效。

最后给自己定三条规矩：第一，基础镜像尽量固定版本，不要长期使用含义会变的最新标签；第二，不要把密码和密钥写进镜像，改用环境变量或密钥管理；第三，镜像构建要尽量精简，不需要的文件不要复制进去，构建速度和安全性都会更好。掌握这些，你就已经把 Docker 从一个时髦名词，变成了日常开发中真正可靠的工具。