Docker从零入门实战：安装部署并跑通第一个Nginx容器

Docker这个词，只要是搞开发或运维的朋友，这几年几乎绕不开。你不需要把它想得多玄乎：简单说，Docker就是一套容器化管理工具，能让你把应用和它依赖的环境一起打包，扔到任何机器上都能直接运行。这篇东西不讲虚的，就按标题这条路线来：从零开始把Docker装到你的电脑上，再把第一个Nginx容器跑起来、访问到页面，中间该踩的坑我提前帮你踩一遍。

这套内容适合谁？刚接触后端、运维、或者想搭本地开发环境的大学生和初级工程师都合适。哪怕你连Linux命令都还没记熟，照着下文操作也能跑通。我尽量用大白话讲原理，用真实命令演示过程，遇到报错告诉你为什么报、怎么解。

1. 项目概述与整体设计思路：容器为什么值得你花时间学

1.1 传统部署的痛点：环境不一致惹的祸

我先问你一个场景。你在自己电脑上写了一个Python小服务，本地跑得好好的，代码提交上去，结果测试同事拉下来一跑——报错。一看，缺依赖；装好依赖又报，版本不对；版本调好了还报，操作系统里的库不一样。这种“我机器上能跑”的梗，做过开发的基本都经历过。

Docker解决的正是这个问题。它把应用和运行环境封装到一起，形成一个"镜像"。别人拿到这个镜像，不关心你底层用的是CentOS还是Ubuntu、装了什么Python版本，直接用Docker命令就能把整个环境启动起来。换句话说，你交付的不再是一堆源码加一篇"环境部署文档"，而是一个自带运行环境的完整制品。

从项目整体设计来看，Docker带来的收益有三个层面：

• 一致性：镜像在哪构建，行为就在哪一致，开发、测试、生产用同一个镜像跑同一个版本；
• 轻量化：相比虚拟机，容器共享宿主机内核，不模拟整套硬件，一个容器镜像往往只有几十到几百MB，启动速度毫秒级；
• 隔离性：每个容器有自己的文件系统、网络和进程空间，多个项目可以同时跑在一台机器上，互不干扰。

这也是为什么现在几乎所有的前后端项目、微服务架构、自动化测试环境都在用容器来管理运行环境。

1.2 虚拟机 vs 容器：一次对比看懂选型原因

很多新手会问：VMware里开个Ubuntu虚拟机，不也能隔离环境吗？能用，但二者的定位完全不同。我做了个对比表格，你一眼就能看出差异：

容器的隔离性确实比虚拟机弱，但它利用了Linux内核的Namespace机制做进程、网络、挂载点隔离，再用Cgroups限制资源使用。日常开发、生产部署完全够用。我见过很多团队一开始用虚拟机做开发环境，一台笔记本跑三个虚拟机直接卡死；后来换成Docker，同样的笔记本跑十几个容器还游刃有余。这就是轻量级带来的实际差别。

1.3 这篇实战的学习路径：三步带你走到第一个容器

如果你今天什么都不懂，我建议按这个节奏来：

第一步，先把Docker装在系统上，跑一个hello-world容器验证安装成功。第二步，拉取一个真实的应用镜像（Nginx），把它跑起来并访问到页面。第三步，反向拆解：如果镜像就是别人打好的包，那我能不能也打包一个自己的应用镜像？所以我们后面会写一个Dockerfile，构建一个自己的自定义镜像。

这个路径的思路是"先会用，再理解，最后自己造"。我见过太多人一上来就啃Docker底层原理，啃了三五天还没动手敲过一条命令，最后全忘了。正确的做法是先跑通一个容器，有了感性认识再回头理解镜像分层、数据卷、网络模式这些概念。这也是这篇标题里"入门实战"四个字的核心逻辑。

2. 安装准备与核心概念扫盲：先让你本机能跑Docker

2.1 各平台安装Docker：Windows、macOS、Linux实操

Docker在Windows和macOS上直接装Docker Desktop就行，带图形界面，配置最省心。Linux则用包管理器装Docker Engine。我不写太细节的界面点击流程，重点说需要留意的点，避免踩坑。

Windows系统（Windows 10/11专业版或企业版）：

1. 打开控制面板 -> 启用"适用于Linux的Windows子系统"和"虚拟机平台"；
2. 安装Docker Desktop，安装完成后按提示重启；
3. 首次启动时Docker Desktop会自动启用WSL2后端，如果没有WSL2，需要先在Microsoft Store里安装一个Ubuntu发行版并运行一次完成初始化；
4. 打开PowerShell，执行docker --version，能输出版本号就说明装好了。

macOS系统：

1. 下载Docker Desktop的macOS版本，拖进Applications目录；
2. 打开后可能提示"需要访问权限"，按提示到系统设置里允许；
3. 菜单栏出现Docker图标后，点开确认状态是Running；
4. 终端执行docker --version验证。

Linux系统（以Ubuntu/Debian为例）：

sudo apt update sudo apt install -y apt-transport-https ca-certificates curl software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" sudo apt update sudo apt install -y docker-ce

安装完之后，有一个非常重要但新手老忘的坑：默认情况下Docker命令需要root权限，直接敲docker ps会报permission denied。不想每次加sudo，就把当前用户加进docker组：

sudo usermod -aG docker $USER

然后注销重新登录，或者执行newgrp docker让组权限立即生效。这一步不做，你后面每条命令都要带sudo，遇到一些脚本式的流程会很痛苦。

CentOS/RHEL系用yum或dnf装docker-ce，流程类似，只是仓库配置稍有差异。装完后启动守护进程并设置开机自启：

sudo systemctl enable docker --now sudo systemctl status docker

看到active (running)就说明服务起来了。

2.2 三大核心概念：镜像、容器、仓库的关系

这是Docker最基础，也是最容易绕晕的一组概念。我用生活化类比来讲：镜像好比做菜的"净菜套装+菜谱"，里面已经配好了所有食材、调料和烹饪步骤；容器就是你按这个套装实际做出来的一盘菜。你可以同时做很多盘，每盘之间互不影响，但它们的来源都是同一套净菜。仓库就是存放这些"净菜套装"的超市，需要的时候拉取一份就可以了。

更精确地说：

• 镜像（Image）：一个只读的模板，由一层一层的文件系统快照叠加而成，不能被修改；
• 容器（Container）：镜像被启动后的可写实例，你可以在里面装东西、改配置，容器删除后修改也消失；
• 仓库（Repository）：集中存储和分发镜像的地方，类似GitHub之于代码。你可以推送到私有仓库，也可以从公共仓库拉取。

它们的关系可以这样理解：镜像定义了这个容器"长什么样"、里面装了什么；容器是镜像"跑起来"的动态状态；仓库则是镜像的存储与分发中心。

2.3 验证安装：跑通Hello World容器

安装完成后别急着学各种命令，先把最简单的验证跑通：

docker --version docker run hello-world

如果镜像还没有拉过，Docker会自动从仓库拉取hello-world镜像，然后启动容器。你会在终端看到一段说明文字。这代表你的整个Docker链路是通的：能拉镜像、能创建容器、能执行容器内的程序。

如果在这步卡住提示连接超时，大概率是拉镜像的网络问题。这个我在后面第5章的常见问题排查里会详细讲。

3. 实操过程与核心环节实现：运行你的第一个Web容器

3.1 拉取Nginx镜像：Tag与镜像仓库的基础操作

hello-world只是验证用的，不算真正的项目实战。现在用Nginx来跑一个真实的Web服务。

镜像拉取命令：

docker pull nginx

默认拉取的是latest标签，相当于nginx.nginx镜像的最新版本。如果你需要指定版本，加上冒号：

docker pull nginx:1.25

tag：latest，可以理解为镜像的版本号。为什么不推荐生产环境直接用latest？因为latest会跟着上游更新变动，你这次拉的和半年后拉的可能是两个不同的镜像，构建结果不具备可重现性。好的习惯是始终指定明确的版本tag。

拉取结束后可以用docker images看一下本机镜像列表，你会看到nginx镜像以及它的IMAGE ID、大小。这个IMAGE ID是镜像的唯一标识，平时操作可以用短ID或者仓库名:tag来引用。

3.2 启动Nginx容器：run命令逐参数拆解

镜像有了，开始启动容器。我先把一条最常用的启动命令贴出来，再逐段讲每个参数的含义：

docker run -d -p 8080:80 --name my-nginx nginx

拆解：

• docker run：根据镜像创建并启动一个新容器；
• -d：detached模式，让容器在后台运行，终端不附着到容器进程上；
• -p 8080:80：端口映射，宿主机8080端口转发到容器内80端口；
• --name my-nginx：给容器起个名字，方便后面管理；
• nginx：要使用的镜像名。

为什么要有-p这个映射？因为容器有自己的网络命名空间，容器内的80端口从宿主机外部不能直接访问。通过在宿主机和容器之间建立一个端口转发关系，外部请求到达宿主机的8080端口时，Docker会转发进容器的80端口。这就好比你给一个独立房间开了一扇指定的门，外面的人只能通过这扇门拜访房间里的服务。

运行之后，浏览器访问http://localhost:8080，如果看到Welcome to nginx!页面，说明你的第一个容器已经成功跑起来了。

这里有个常见误区：如果把端口映射写成-p 8080:80，你却访问localhost:80，那是必定失败的。左侧永远是宿主机端口，右侧永远是容器内端口，方向不要搞反。

3.3 容器的一生：查看、停止、重启与删除

容器跑起来之后，你需要掌握几个常用管理命令。我按实际使用频率排序：

docker ps # 只看运行中的容器 docker ps -a # 看所有容器，包括已退出、运行过的 docker stop my-nginx # 优雅停止容器 docker start my-nginx # 启动已存在的容器 docker restart my-nginx # 重启容器 docker rm my-nginx # 删除容器，删除前必须先停止

如果忘记容器名，可以直接用容器ID操作，docker ps -a会列出CONTAINER ID，取前几位即可。比如：

docker stop 1a2b docker rm 1a2b

还有个经常用到的命令是查看日志。容器后台运行了，怎么看Nginx的访问日志或报错信息？

docker logs my-nginx # 查看全部日志 docker logs -f my-nginx # 持续跟踪输出，类似tail -f docker logs --tail 50 my-nginx # 只看最近50行

如果你需要进入容器内部查看环境：

docker exec -it my-nginx bash

-i保持标准输入打开，-t分配一个伪终端，合起来就是能交互操作的意思。进入后你可以ls、cat配置文件、查看运行目录，不对容器进行永久性修改就没事；就算改了，容器删除后也会全部丢失。

我把容器的生命周期串起来说：启动中的容器可以停止，停止后不会消失，镜像生成的可写层还在；删除的容器则连同它内部的一切修改一起被清除。这正是下一小节要说数据卷的背景。

3.4 数据持久化：为什么容器一删就什么都没了

新手最容易踩的坑就在这里：容器删除后，里面存的数据全部消失。比如你跑了一个MySQL容器，往库里写了一堆数据，然后不小心执行了docker rm，数据直接归零。

因为在设计上容器是"无状态的"，它的可写层生命周期跟随容器本身。所有对文件系统的修改都保存在这个可写层，一旦容器删除，可写层一并销毁。

解决方案是数据卷（Volume）或绑定挂载（Bind Mount）。我举一个最直观的绑定挂载例子：

docker run -d -p 8080:80 --name my-nginx -v /home/user/nginx-html:/usr/share/nginx/html nginx

-v /home/user/nginx-html:/usr/share/nginx/html，意思是把宿主机上的目录挂载到容器内的网站根目录。现在你在宿主机这个目录里放一个index.html，内容写什么，访问http://localhost:8080就能看到什么。容器删除后再用相同命令重新启动，数据依旧还在，因为数据真实存在宿主机目录里。

Volume也是类似思路，区别是它由Docker托管，不依赖指定宿主机目录，适合持久化数据库这类场景：

docker volume create mydata docker run -d -p 3306:3306 --name mysql -v mydata:/var/lib/mysql mysql:8.0

用docker volume可以看到mydata的位置，后续备份、迁移都通过Docker管理，比裸绑定挂载更规范。

一句话总结：凡是需要在容器生命周期之外保留的数据，必须通过数据卷或绑定挂载落到宿主机上，这是容器化应用设计的铁律。

4. 镜像构建：从"用别人的镜像"到"打造自己的镜像"

4.1 Dockerfile入门：构建镜像的配方文件

跑通别人的容器后，你多半会想：我也要构建一个自己的应用镜像。这就需要写Dockerfile。它本质上是一个描述了"镜像应该如何一层层构建"的文本文件。

我准备了一个最简单的示例：构建一个返回固定文本的轻量Python服务。目录结构如下：

demo-app/ ├── app.py └── Dockerfile

app.py内容：

from flask import Flask app = Flask(__name__) @app.route("/") def index(): return "Hello from Docker container!"

在app.py同目录下创建Dockerfile：

FROM python:3.11-slim WORKDIR /app COPY app.py . RUN pip install flask -i https://pypi.tuna.tsinghua.edu.cn/simple EXPOSE 5000 CMD ["python", "app.py"]

逐条解释：

• FROM：基础镜像，指定构建起点。python:3.11-slim是一个精简版Python镜像，体积比完整版小很多；
• WORKDIR：设置容器内工作目录，后面所有命令都在这个目录下执行；
• COPY：从构建上下文把app.py复制到容器内；
• RUN：镜像构建时执行的命令，比如安装依赖；
• EXPOSE：向Docker声明容器内程序监听的端口。注意它只起声明作用，真正要让宿主机访问，仍需在docker run时用-p映射；
• CMD：容器启动时执行的命令，每个Dockerfile建议只写一个CMD。

4.2 构建并运行自己的镜像

在demo-app目录下执行：

docker build -t demo-app:v1 .

这句命令里，-t指定镜像名和tag为demo-app:v1，最后的.不能丢，它表示构建上下文路径。构建上下文是Docker引擎打包并发送给守护进程的目录内容，路径目录里的文件会被Dockerfile中的COPY等指令使用。

如果Dockerfile写在其他位置，可以用-f指定文件路径：

docker build -f path/to/Dockerfile -t demo-app:v1 .

构建完成后运行：

docker run -d -p 5000:5000 --name my-demo demo-app:v1

浏览器访问http://localhost:5000，看到Hello from Docker container!就说明你成功构建并运行了第一个自定义镜像。

这时候你可以在docker images里看到demo-app:v1。如果后续做了代码改动，重新执行build即可，Docker会利用构建缓存：只重新构建受影响的层，其余层直接用缓存，速度会快很多。

4.3 镜像瘦身与版本管理：几个实战必会的优化点

自己动手构建后，很快就会遇到镜像体积偏大的问题。一个Python基础镜像加上依赖可能就几百MB，直接影响拉取和部署速度。我给你几条实用的优化思路：

• 使用dockerignore文件：在构建上下文里放一个.dockerignore，排除不需要的文件，避免把日志、node_modules、缓存等一起打包进上下文。写法和.gitignore类似：

__pycache__ *.pyc .git .env

• 合并RUN命令减少镜像层数：每一个RUN、COPY、ADD都会生成一个新层。能用一条RUN完成多个操作的就合并：

RUN apt-get update && apt-get install -y some-package && rm -rf /var/lib/apt/lists/*

• 使用多阶段构建：如果你要编译代码，可以使用多个FROM阶段。编译阶段用带完整SDK的镜像，运行阶段只拷贝编译产物到精简镜像，最终镜像只保留运行需要的内容。这在Go、Java等编译型语言里特别常用。
• tag规范：给镜像打好版本tag再推送。比如：应用名+版本号+构建时间，不要直接用latest推生产。

docker tag demo-app:v1 myrepo.example.com/demo-app:1.0.0 docker push myrepo.example.com/demo-app:1.0.0

构建镜像不是"能跑就行"，而是要考虑体积、可维护性和分发效率。这些优化在刚入门时理解成本不高，但越早养成习惯，后面进团队协作时越占优势。

5. 常见问题与排查技巧实录：我踩过的那些坑

5.1 镜像拉取失败或速度极慢怎么办

新手阶段遇到最多的就是pull超时、连接重置。这通常和默认镜像源的网络链路有关。解决方案是配置镜像加速服务。

在Linux上，编辑Docker守护进程配置文件：

sudo mkdir -p /etc/docker sudo vi /etc/docker/daemon.json

写入：

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

保存后重启Docker：

sudo systemctl restart docker

Windows/macOS的Docker Desktop则直接在Settings -> Docker Engine里编辑同样的JSON配置即可。

配置镜像加速本质是让Docker从你指定的镜像仓库节点拉取公共镜像，合理、合规且是社区广泛实践。改完后重新docker pull nginx，速度往往会有肉眼可见的提升。还要注意，镜像加速只影响拉取操作，不影响推送和运行时行为。

5.2 端口冲突：端口地址已被占用的标准解法

启动容器时报错：

docker: Error response from daemon: driver failed programming external connectivity on endpoint Bind for 0.0.0.0:8080 failed: port is already allocated

原因很简单：宿主机8080端口被其他进程或者其他容器占用了。排查步骤：

sudo lsof -i :8080

或者：

netstat -tuln | grep 8080

找到占用进程，要么把它停掉，要么把容器映射改到一个没占用的端口，比如8081:

docker run -d -p 8081:80 --name my-nginx nginx

如果你觉得每次指定端口麻烦，也可以让Docker随机分配一个宿主机端口：

docker run -d -P --name my-nginx nginx

-P会把你镜像里EXPOSE声明的所有端口随机映射到宿主机高端口，然后通过docker ps查看具体的映射结果。

5.3 容器启动后立刻退出：到底是哪里错了

有时候容器启动后一两秒就退出，docker ps看不到运行中容器，只有docker ps -a能看到状态为Exited。判断原因最直接的方式是看日志：

docker logs my-container

常见原因有几类：

• 前台进程不存在：容器主进程退出，容器自然终止。比如你把Nginx配置成守护进程模式，容器没有保持前台的进程，就跑完即退。解决方法是改成前台运行，或者在CMD里显式调用nginx -g "daemon off;"。
• 启动参数错误：比如端口在容器内已被占用、配置连接了不存在的数据库。日志里一般有明确报错，顺着日志改配置就行。
• 基本镜像命令不存在：有时候你写的CMD指令在容器内并不存在，比如用了完整系统才有的路径。先用docker exec进入容器确认环境，再调整Dockerfile。

我个人的建议是：容器刚启动时，先不要加-d。直接前台运行：

docker run --name test-container -p 8080:80 nginx

前台模式下，终端会直接输出容器的标准输出和错误输出，很多问题一眼就能看出来。确认一切正常后，再改成-d后台运行。

5.4 容器虽能访问但里外不通：网络与防火墙的排查顺序

如果容器启动成功，但浏览器访问失败，别急着去容器里折腾，按这个顺序排查：

1. 先确认容器是运行中的：docker ps，状态不是Up基本不用往下查了；
2. 确认端口映射存在：docker port my-nginx，看看输出是不是8080 -> 80/tcp；
3. 在宿主机上测试转发是否生效：curl -I http://localhost:8080；
4. 如果宿主机返回正常，但局域网其他机器访问不了，继续查宿主机防火墙是否放行了8080端口；
5. 最后再考虑容器内服务是否正常监听：docker exec -it my-nginx sh，然后执行curl http://localhost:80。

这个顺序是从"外层到内层"的排查思路，先排除外部的防火墙、端口监听问题，再进入容器内部，能省下大量时间。我见过有人折腾了半天容器，最后发现是宿主机防火墙没放行端口。

5.5 磁盘空间被镜像和容器占满：清理技巧

Docker用久了，本地镜像、悬空镜像、无用容器、构建缓存会占用大量磁盘。查看占用情况：

docker system df

输出里能看到镜像占了多少、容器占了多少、构建缓存占了多少。一键清理：

docker system prune

这会清理已停止的容器、未被使用的网络、悬空镜像和构建缓存。如果还想连未使用的镜像一起清理：

docker system prune -a

清理之前建议先看清楚docker system df的情况，确认没有正在使用的资源。构建缓存庞大时清理收益特别明显，很多项目跑了一个星期后，一条prune下去能释放好几个GB。

最后再分享一点我的体会

跑通这套流程你花的时间大概在一个小时左右，但能获得的收益是以后所有容器化项目的地基。我记得自己最初学Docker的时候，在端口映射上翻过车，在"为什么容器一删数据就没了"上困惑了很久，后来发现很多问题不是靠背命令解决的，而是把"镜像层、容器生命周期、数据卷、端口转发"这几个概念搞清楚了，对应的命令自然就记住了。

建议你跑完Nginx之后，再找一个小项目练手，比如把前文那个Python服务加上MySQL和数据卷，组合成一套本地开发环境。遇到报错别急，先docker logs看日志，再看端口和网络，再检查Dockerfile里的每一条指令是否符合预期。按这个顺序排查，绝大多数问题都能在十分钟内定位。