技术入门系列 on Xiang's Blog

从零开始搭建你的第一个 Docker 服务

Thu, 16 Apr 2026 00:00:00 +0000

Docker 已经成为现代后端部署的标配工具。本文将带你用 20 分钟，从零开始把一个 Python Web 服务容器化并运行起来。

为什么要用 Docker

在没有 Docker 的时代，部署一个服务需要手动安装运行时、配置依赖、处理环境差异。“在我机器上能跑"成了经典甩锅语录。

Docker 把应用和它的运行环境打包成一个镜像（Image），在任何装了 Docker 的机器上都能以相同方式运行。核心思路很简单：用代码定义环境，而不是手动配置。

几个关键概念：

镜像（Image）：只读的模板，包含应用代码和运行所需的一切
容器（Container）：镜像的运行实例，可以启动、停止、删除
Dockerfile：构建镜像的配方文件
docker-compose.yml：定义多个容器如何协同工作的配置文件

准备工作

确保机器上已安装 Docker 和 Docker Compose：

1
2

docker --version
docker compose version

如果没装，参考 Docker 官方文档。Linux 用户装完后把当前用户加入 docker 组，免得每次都加 sudo：

`1`	`sudo usermod -aG docker $USER`

重新登录终端生效。

第一步：写一个简单的 Web 服务

创建一个项目目录：

`1`	`mkdir docker-demo && cd docker-demo`

写一个最小的 Flask 应用 app.py：

from flask import Flask

app = Flask(__name__)

@app.route("/")
def index():
    return {"message": "Hello from Docker!"}

@app.route("/health")
def health():
    return {"status": "ok"}

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

再写一个 requirements.txt：

flask==3.1.*

第二步：编写 Dockerfile

在项目根目录创建 Dockerfile：

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 5000

CMD ["python", "app.py"]

逐行解释：

指令	作用
`FROM python:3.12-slim`	基础镜像，slim 版本体积小
`WORKDIR /app`	设置容器内的工作目录
`COPY requirements.txt .`	先复制依赖文件，利用 Docker 层缓存
`RUN pip install ...`	安装依赖
`COPY . .`	再复制应用代码
`EXPOSE 5000`	声明端口（文档作用，不实际映射）
`CMD ["python", "app.py"]`	容器启动时运行的命令

为什么分两步 COPY？ Docker 会缓存每一层。如果代码改了但 requirements.txt 没变，pip install 那层会直接走缓存，构建速度更快。

第三步：编写 docker-compose.yml

services:
  app:
    build: .
    ports:
      - "5000:5000"
    restart: unless-stopped

这比直接用 docker run 更清晰，而且一条命令就能管理。

第四步：构建并运行

`1`	`docker compose up --build`

第一次会下载基础镜像并安装依赖，之后再构建会很快。看到 Flask 的启动日志后，打开另一个终端测试：

1
2

curl http://localhost:5000
# {"message":"Hello from Docker!"}

按 Ctrl+C 停止。如果想后台运行：

1
2
3

docker compose up -d      # 后台启动
docker compose logs -f     # 查看日志
docker compose down        # 停止并移除容器

第五步：加入数据库

实际项目通常需要数据库。给 docker-compose.yml 加一个 PostgreSQL：

services:
  app:
    build: .
    ports:
      - "5000:5000"
    environment:
      DATABASE_URL: postgresql://postgres:secret@db:5432/app
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: app
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 5

volumes:
  pgdata:

几个要点：

depends_on + service_healthy 确保数据库就绪后才启动应用
volumes 让数据库数据持久化，容器删了数据还在
同一个 compose 文件里的服务可以用服务名（db）作为主机名互相访问

常见问题

容器内访问宿主机服务

用 host.docker.internal（macOS/Windows）或 host.network（Linux）。

镜像太大

用 slim 或 alpine 基础镜像；多阶段构建把构建工具和运行时分开。

修改代码后不生效

挂载本地目录到容器内，开发时热更新：

services:
  app:
    build: .
    volumes:
      - .:/app
    ports:
      - "5000:5000"

如何查看运行中的容器

1
2
3

docker ps              # 查看运行中的容器
docker compose ps      # 查看当前项目的容器
docker exec -it <容器名> bash   # 进入容器内部

生产环境建议

这篇文章覆盖的是开发环境的基本用法。上生产前还需要考虑：

不要硬编码密码：用 .env 文件或密钥管理服务
网络隔离：数据库端口不要映射到宿主机，只让应用容器访问
日志管理：配置日志驱动，避免容器日志撑爆磁盘
资源限制：设置 CPU 和内存上限，防止单个容器耗尽资源

小结

整个流程就是四步：写代码 → 写 Dockerfile → 写 docker-compose.yml → docker compose up。Docker 的核心价值不在于技术有多复杂，而在于它把"部署"从一件靠记忆和运气的事，变成了一件可以版本控制、可以复现、可以自动化的事。

开源大模型生态 2025 年中盘点

Thu, 16 Apr 2026 00:00:00 +0000

2025 年上半年，开源大模型赛道持续升温。多个头部团队相继发布参数规模在 700B 以上的新模型，推理效率较去年同期提升显著。

三大趋势

端侧部署普及

4B 以下的小模型在手机、边缘设备上的落地场景快速增多。量化技术的成熟让普通消费级 GPU 也能流畅运行 7B 模型。

具体来看：

手机端：苹果的 Core ML 和高通的 AI Engine 都在加速适配小模型，Llama 3.2 3B 在 iPhone 15 Pro 上可以实现每秒 30+ token 的生成速度
边缘设备：NVIDIA Jetson、树莓派 5 等设备跑 7B 模型已经不是新鲜事，量化到 4-bit 后内存占用可以控制在 4GB 以内
桌面端：Ollama、LM Studio 等工具让本地部署变得极其简单，一行命令就能跑起来

这个趋势的意义在于：很多对延迟敏感、对隐私要求高的场景（如医疗问诊、企业内部知识库）不再需要把数据送到云端。

多模态能力标配化

图文理解已成为主流开源模型的基础能力，视频理解正在跟进。以前需要专门的视觉模型，现在一个通用模型就能搞定。

几个关键进展：

图文理解：Llama 3.2 Vision、Qwen2.5-VL 等模型在图表理解、OCR、文档解析等任务上已经接近商业 API 的水平
视频理解：虽然还处于早期，但已经出现了可以处理短视频（30 秒以内）并回答问题的开源模型
音频理解：Whisper 的后继者们在语音识别和理解上持续进步，多语言支持越来越好
跨模态生成：文生图领域 Stable Diffusion 3 和 FLUX 系列开源后，图片生成的质量和可控性有了质的飞跃

多模态能力的普及意味着开发者可以用一个模型处理多种类型的数据，降低了应用架构的复杂度。

工具调用成熟度提升

多个模型在 BFCL 等基准上接近或超越闭源模型，Agent 应用的可靠性有了实质性进步。

工具调用（Function Calling）是大模型走向实际应用的关键能力。2025 年的变化包括：

标准化：OpenAI 定义的 function calling 格式已经成为事实标准，主流开源模型都支持
准确率提升：在 Berkeley Function Calling Leaderboard 上，开源模型的最佳成绩已经非常接近 GPT-4
复杂调用：从单步调用发展到多步调用、嵌套调用、并行调用，模型可以完成更复杂的任务链
MCP 协议：Anthropic 推出的 Model Context Protocol 为工具调用提供了统一的接口规范，生态正在快速建立

值得关注的模型

Llama 系列

Meta 持续更新，生态最完善，微调资源最多。Llama 3.1 提供了 8B、70B、405B 三个规格，覆盖从端侧到云端的完整需求。Hugging Face 上的衍生模型超过 10 万个，社区活跃度无人能及。

优势：社区大、资源多、微调工具链成熟。劣势：中文能力相对弱于 Qwen，大规格模型的推理成本高。

Qwen 系列

阿里出品，中文能力突出，对中文用户友好。Qwen 2.5 在多个中文基准上表现优异，同时英文能力也在快速追赶。最新的 Qwen 2.5 提供了从 0.5B 到 72B 的完整规格线。

优势：中文能力强、规格线完整、开源协议友好。劣势：英文社区影响力不如 Llama，部分工具链适配滞后。

Mistral 系列

法国团队，以小博大，推理效率高。Mistral 的模型以参数效率著称——用更少的参数达到相近的效果。Mixtral 8x7B 的 MoE 架构在推理时只激活部分参数，实现了性能和效率的平衡。

优势：推理效率高、架构创新、欧洲数据合规友好。劣势：大规格模型缺失，中文能力一般。

DeepSeek 系列

国内团队 DeepSeek 在 2025 年初的表现令人瞩目。DeepSeek-V3 和 R1 在推理任务上展现了极强的竞争力，尤其是 R1 的思维链推理能力在数学和编程任务上接近甚至超越闭源模型。

优势：推理能力强、开源彻底、训练成本控制出色。劣势：生态还在建设中，企业级部署工具链不够完善。

闭源 vs 开源

分析人士指出，开源与闭源之间的能力差距正在缩小，但在复杂推理和超长上下文任务上仍有明显差距。对于大多数实际应用场景，开源模型已经足够。

几个具体维度的对比：

维度	开源	闭源
通用对话	接近	略优
复杂推理	差距缩小	仍有优势
代码生成	接近	接近
多模态	快速追赶	领先半年
超长上下文	差距较大	明显优势
成本控制	优势明显	API 费用高
数据隐私	完全可控	依赖第三方

对于企业来说，选择开源还是闭源不再是一个非此即彼的问题。很多团队的做法是：核心业务用开源模型私有化部署，探索性项目用闭源 API 快速验证。

开发者生态

2025 年开源大模型的开发者生态也发生了显著变化：

微调工具链成熟：Axolotl、LLaMA-Factory、Unsloth 等工具让微调的门槛大幅降低。以前需要写大量训练代码，现在准备好数据集、选好参数就能开始训练。

推理引擎竞争：vLLM、TensorRT-LLM、SGLang 等推理引擎在吞吐量和延迟上持续优化，部署成本进一步下降。

评估标准统一：Open LLM Leaderboard、AlpacaEval、MT-Bench 等评估基准帮助开发者快速对比不同模型的表现。

模型合并兴起：不需要训练，通过合并多个现有模型的权重来创造新模型。DARE、TIES 等合并策略让社区可以快速迭代出针对特定场景优化的模型。

展望

2025 年下半年，几个方向值得持续关注：

推理效率：MoE 架构和投机解码（Speculative Decoding）技术会进一步降低推理成本
长上下文：128K 以上的上下文窗口会成为标配，RAG 的必要性可能会被重新评估
Agent 生态：模型能力不再是瓶颈，Agent 框架和工具生态会成为竞争焦点
合成数据：用大模型生成训练数据来训练小模型的范式会更加成熟

开源大模型的黄金时代才刚刚开始。