2026年Docker部署清单：从AI大模型到中间件，一篇搞定

2026年了，如果你还在犹豫“Docker值不值得部署”，我的建议是别再纠结，先把你最常用的那套服务容器化试试。过去一年里，我帮团队和个人环境搭过的容器方案不算少，从AI大模型本地部署（Ollama、Dify、vLLM 这些词我都在热搜榜上刷到过）到 MySQL、Redis 这类基础中间件，再到监控告警、定时任务这些日常工具，几乎都能一两条命令拉起来。这篇文章就按我实际部署过的顺序，把2026年最值得部署的Docker应用清单整理出来，同时把 docker compose、数据持久化、桌面版踩坑这些绕不开的细节一并说清楚。清单里既有新手友好的入门项，也有偏生产环境的进阶项，你可以按自己的需求直接挑着抄作业。

1. 为什么到了2026年，Docker依然是部署绕不开的选项

1.1 热搜词背后的三个信号

这三四年Docker相关的讨论热度没怎么降，搜索词反而越来越多：docker安装教程、docker compose、ollama本地部署、dify本地部署教程、docker安装mysql8.0、prometheus监控部署…… 表面上看是各种各样的“安装教程”，背后其实是三个趋势。

第一，AI大模型本地部署成为普通开发者的日常需求。DeepSeek、Qwen 这些开源模型早已能跑在消费级显卡甚至纯CPU设备上，但模型自带一堆Python依赖、CUDA版本、推理框架，手动装一遍能让人抓狂。Docker的作用就是把“环境地狱”压缩成一个镜像，拉下来就能跑，这也是“deepseek部署”“ollama本地部署”这类词持续火热的核心原因。

第二，中间件容器化已经是默认操作。MySQL、Redis、Nacos、Prometheus，这些服务过去需要下载安装包、配置注册服务、管理目录权限；现在一条 docker run 或者一个 compose 文件就能搞定，而且迁移成本极低。2026年了，大家关心的不再是怎么装，而是数据怎么不丢、网络怎么通、性能怎么不拉胯。

第三，Windows 和 macOS 上使用 Docker 的人明显变多。搜索词里“docker desktop 使用教程”“docker desktop failed to start because virtualisation support wasn't detected”这种问题高频出现，说明大量非 Linux 工程师也开始把 Docker 当作本地开发工具来用。这个趋势还会持续，因为桌面端的容器体验已经足够顺畅，尤其适合搭本地开发环境。

1.2 这套清单适合谁，不适合谁

我按“收益/成本”给出一份应用清单，但先泼一点冷水：Docker 不是所有场景的银弹。如果你是下面几类人，优先级可以往后放：

  • 需要极致性能、依赖特殊硬件驱动的场景：比如容器里直接操作 DPDK、SR-IOV 网卡、GPU 直通做大规模训练，容器网络和驱动管理会带来额外复杂度，这类场景更适合裸机或虚拟机。
  • 对数据安全极度敏感的团队：容器不等于安全边界，镜像漏洞、配置疏忽都可能造成风险，需要配合镜像扫描和权限治理。
  • 已经上了统一容器管理平台（K8s、Rancher 一类）的团队：平台层已经把调度、滚动更新、配置下发都管起来了，这时候你再手工 docker run 反而是开倒车。
  • 纯静态、零运维的个人小项目：比如一个没有依赖的单文件脚本，直接跑反而更清爽。

反过来说，如果你属于这几类，Docker 对你就是性价比极高的选择：个人开发者做AI模型验证和工具落地；中小团队需要快速搭建开发/测试环境；运维和全栈工程师想用一套 compose 管理服务器上所有应用；或者你只是想在 Windows 笔记本上干净地跑一个 MySQL、Redis 做实验。我下面推荐的应用，基本都围绕这几类人来选。

2. 第一梯队：AI大模型与智能体应用，今年最值得先部署的容器

2.1 Ollama + 开源大模型：本地跑 LLM 最顺手的组合

如果今年你只想部署一个 AI 相关容器，我先推 Ollama。Ollama 把模型管理、底层推理、API 服务封装得极其顺手，你只需要确认三点：有没有 NVIDIA/AMD 显卡、显存多大、磁盘剩余空间够不够。

部署命令非常简单：

docker run -d --name ollama \ -v ollama:/root/.ollama \ -p 11434:11434 \ ollama/ollama

注意-v这一条，模型默认放在容器内的/root/.ollama，不挂载出来重新拉容器模型就没了。数据卷是成本最低的持久化方案，建议第一次部署就养成习惯。

拉模型一般这样：

docker exec -it ollama ollama run deepseek-r1:1.5b

也可以先ollama pull deepseek-r1:7b，再调用/api/generate接口。这个 API 是 OpenAI 格式兼容的，很多第三方工具可以直接接，省去自己封装推理接口的工作。

实战中要留意两个参数：

  • OLLAMA_MODELS环境变量可以指定模型存放目录，如果系统盘空间紧张，把它指向数据盘；
  • OLLAMA_HOST默认0.0.0.0:11434，局域网内别的机器可以直接访问，个人使用时注意通过防火墙控制访问范围。

个人经验是：没有独显纯 CPU 跑，选 1.5b/7b 的量化模型做体验完全够用；有 8G 以上显存可以尝试 14b/32b 级别；真的要大规模并发推理，再往上走 vLLM。另外，Ollama 更新频率不低，建议每隔一段时间docker pull ollama/ollama拉一次新镜像，再把容器 recreate 一下，避免长期停在旧版本。

2.2 Dify：把大模型接进业务流程的编排中枢

Ollama 解决的只是“模型跑起来”，真正想让大模型干活，还需要工作流、知识库、API Key 管理、用户权限这一整套东西，这就是 Dify 的主场。Dify 是非常典型的 docker compose 部署，我直接给出精简版本：

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

等待镜像拉完，访问http://localhost/install初始化管理员账号。Dify 内置了向量数据库选项，默认是 Weaviate，也支持 pgvector 等。如果你手头已经部署了 Ollama，在 Dify 的模型供应商设置里填http://:11434就能把本地模型接进来，整套链路都不出内网。

部署 Dify 最容易踩的坑有三个：一是.env里的 SECRET_KEY 要改，别用默认值；二是端口占用，80 端口被占时要把.env里的端口映射改掉；三是内存别太小，Dify 的 API、Worker、DB、向量库一起启动后，2G 内存会非常紧张，建议 4G 起步。这一步走顺之后，做 RAG 问答、Agent 工作流基本就是配置问题而不是开发问题了。

2.3 vLLM、MinerU、LM Studio 怎么选

除了 Ollama 和 Dify，搜索词里还有 vllm、mineru、lm studio 这些，我按使用场景给个选型逻辑：

  • vLLM：适合把开源模型服务化，追求吞吐量和高并发。它支持 OpenAI 兼容 API，做生产级推理服务首选，但对显存和工程能力的要求也更高，不建议纯新手第一天上。
  • MinerU：适合做 PDF 转 Markdown、文档解析、版面还原。如果你要做 RAG 知识库，先把原始文档用 MinerU 处理成干净文本，后面一切都会顺很多。它也提供 Docker 镜像，部署时注意模型下载路径挂载。
  • LM Studio：本质是桌面 GUI 工具，本地直接装反而比装容器省事。它支持在本地起一个类似 OpenAI 的 API，适合个人电脑快速试模型，不太适合服务器端多用户使用。

一句话总结：想体验本地模型，Ollama；想搭完整的 LLM 应用平台，Dify；想高性能服务化，vLLM；想处理文档进知识库，MinerU。按需求选，别全装，否则你的服务器内存和磁盘会先抗议。

3. 第二梯队：数据与可观测性基础设施，稳定服务的地基

3.1 MySQL 8.0 容器化部署，数据目录必须挂出来

MySQL 是搜索词里的常客：docker 安装 mysql、docker 安装 mysql8.0 并使用。原因很简单，本地开发、测试环境、中小业务跑一个 MySQL 容器，比在宿主机上装一大堆依赖省心得多。

推荐命令：

docker run -d --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=YourStrongPass \ -e TZ=Asia/Shanghai \ -v mysql-data:/var/lib/mysql \ mysql:8.0

几个关键点：

  • -v mysql-data:/var/lib/mysql必须加。不然容器删掉，binlog、数据目录全没，这是新手最常犯的错。
  • -e TZ=Asia/Shanghai设置时区，容器默认是 UTC，不设置的话查询NOW()和日志时间都和本地差 8 小时。
  • 字符集建议初始化时指定：--character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci，避免后面遇到 emoji 或者生僻字乱码。
  • 如果你要调max_connections、innodb_buffer_pool_size，加--max-connections=500这类参数即可。

实际开发里，很多人还会用 docker compose 把 MySQL 和业务服务编排在一起，这个我在第 4 部分会给出统一模板。特别提醒：MySQL 容器不要在启动命令里直接挂宿主机上的普通文件夹，权限问题容易踩坑，建议用命名卷，文件权限交给 Docker 管理。

3.2 Redis 主从：一条 compose 文件演练高可用

Redis 容器化同样热门，尤其是“docker 安装 redis 主从”。Redis 本身配置简单，主从模式两条配置就够。

我这里给一份简单的 docker-compose.yml：

services: redis-master: image: redis:7 container_name: redis-master command: ["redis-server", "--requirepass", "masterpass"] ports: - "6379:6379" volumes: - redis-master-data:/data redis-slave: image: redis:7 container_name: redis-slave command: ["redis-server", "--slaveof", "redis-master", "6379", "--masterauth", "masterpass", "--requirepass", "slavepass"] depends_on: - redis-master ports: - "6380:6379" volumes: - redis-slave-data:/data volumes: redis-master-data: redis-slave-data:

要点：

  • 主从之间用容器服务名redis-master通信，比写 IP 更稳定，这也是 compose 网络带来的方便。
  • 主从都要求密码时，从库记得加--masterauth，不然复制会一直报错。
  • 生产环境更建议用哨兵或 Redis Cluster，但主从是理解复制原理最直观的入门实验。

我的建议是别把 6379 直接暴露到公网，除非你有非常明确的访问需求；否则 Redis 未授权访问是安全重灾区。容器内部网络访问完全够用，需要对外再单独加一层认证，这是最低成本的安全纪律。

3.3 Prometheus + Grafana：给服务器和容器装上仪表盘

可观测性这一组是我最近用得最多的。Prometheus 负责采集指标，Grafana 负责画图，两者都可以容器化部署，而且结合 docker-compose 非常顺手。

一个适合初学的最小 compose：

services: prometheus: image: prom/prometheus container_name: prometheus ports: - "9090:9090" volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prom-data:/prometheus grafana: image: grafana/grafana container_name: grafana ports: - "3000:3000" environment: - GF_SECURITY_ADMIN_PASSWORD=admin123 volumes: - grafana-data:/var/lib/grafana volumes: prom-data: grafana-data:

prometheus.yml 里加入要抓取的目标，比如宿主机的 node_exporter、cAdvisor 等。cAdvisor 也是容器化的，它会暴露/metrics接口，Prometheus 每隔 15 秒或 30 秒拉一次，Grafana 连接 Prometheus 数据源后就能看到容器 CPU、内存、网络曲线。

这里提醒一句：Grafana 默认密码是 admin/admin，第一次登录必须改；Prometheus 的告警规则虽然有 alertmanager 那一套，但初期建议先配置一个进去，真到告警时要保证你的钉钉/邮件/webhook 通道是通的，别等到凌晨三点才发现告警没发出去。我踩过这个坑，当时告警规则配了，但 webhook 地址写错，服务挂了半小时都没人知道。

4. 第三梯队：效率工具与自动化，把日常重复工作交给容器

4.1 青龙面板：定时任务和依赖管理的双面手

搜索词里的“docker 青龙 依赖管理”很有代表性。青龙面板是目前社区里很流行的定时任务管理工具，支持 Node.js、Python、Shell 等多种脚本，容器部署基本是官方推荐姿势。

部署命令不复杂：

docker run -d --name qinglong \ -p 5700:5700 \ -v ql-data:/ql/data \ whyour/qinglong

完成管理面板的初始化后，你可以在里面配置定时规则、写脚本、查看日志。很多人用青龙的出发点是把重复性脚本（签到、报表、数据采集、健康检查）集中管理起来，这种用法完全没问题。

但我必须强调两点安全建议。第一，青龙面板能力很强，不要把它盲目暴露到公网，设置强密码、打开两步验证、限制 IP 白名单，至少要选一项。第二，面板里的“依赖管理”能安装 JS/Python 依赖，但容器重启后依赖会丢失，建议把依赖安装写成初始化脚本，或者接受这个现实，在更新后重新装一遍。依赖管理是它最方便的特性，也是最容易忽略的持久化盲区。

4.2 Hexo 博客容器化部署：一篇 Markdown 就能发布

“hexo 部署到 github”也是热搜常客。Hexo 是静态博客生成器，把 Markdown 转成 HTML，然后推到 GitHub Pages 或者自己的服务器。用 Docker 部署 Hexo 的好处是：不用在宿主机上装 Node.js 和一堆 npm 依赖，换电脑也能一键复现构建环境。

经典做法是写一个 Hexo 的 Dockerfile，比如：

FROM node:20-alpine WORKDIR /blog COPY package*.json ./ RUN npm install COPY . . CMD ["npx", "hexo", "server", "-p", "4000"]

构建镜像：docker build -t my-hexo .，跑起来：docker run -p 4000:4000 -v $(pwd):/blog my-hexo。

开发时把源码目录挂载进容器，改完 Markdown 刷新页面就能看；发布时在容器里执行hexo clean && hexo generate，把public目录推上去即可。

这里有个我在实践中踩过的坑：容器内生成的public目录默认归属 root，如果宿主机当前用户对挂载目录没有写权限，部署脚本会报权限错误。解决办法是在 Dockerfile 里用USER指令指定一个非 root 用户，或者运行容器时加--user $(id -u):$(id -g)。这也是很多 Docker 化项目忽略的一点，日志里看到 permission denied 时先别怀疑代码，查一下文件属主往往更快。

4.3 docker compose 编排：一套文件管理所有应用

上面讲的应用，单独跑各自都没问题。但当服务器上有七八个容器时，手动一条条 docker run 就是灾难：端口记不清、卷名对不上、重启顺序乱。docker compose 是解决这个问题的正题，它用 YAML 描述一组服务，一条docker compose up -d全部启动。

我个人的统一管理习惯是这样的：

  • 一个应用一个目录，目录里放 docker-compose.yml 和 .env；
  • 环境变量放在 .env，不在 yml 里写死密码/IP；
  • 所有数据目录都用命名卷或固定子目录，避免容器重建丢数据；
  • 对外只需要暴露必要端口，服务间通信用 compose 内部网络；
  • 更新镜像用docker compose pull+docker compose up -d，避免重复编排。

这里给一个 MySQL + Redis + 业务服务的简单示意：

services: db: image: mysql:8.0 env_file: .env volumes: - db-data:/var/lib/mysql restart: unless-stopped cache: image: redis:7 volumes: - cache-data:/data restart: unless-stopped app: build: . ports: - "8080:8080" depends_on: - db - cache restart: unless-stopped volumes: db-data: cache-data:

depends_on只控制启动顺序，不等服务就绪；真正要“等 MySQL 可连接”的话，要么在应用里做重试，要么加 healthcheck。这个细节我见过很多人踩坑，尤其是第一次用 compose 编排完整项目时，数据库还没初始化完，应用已经连不上直接崩了。加一段 healthcheck 再用 condition: service_healthy 控制依赖，才算完整方案。

5. 部署避坑指南与排查实录

5.1 Windows 下 Docker Desktop 启动失败，先查虚拟化

搜索词里“docker desktop failed to start because virtualisation support wasn't detected”出现频率很高。这个问题的本质是 Docker Desktop 需要一个虚拟化环境来跑 Linux 容器，通常是 WSL2 或 Hyper-V，而你的机器没开启或没装对。

排查步骤如下：

  1. 打开任务管理器 -> 性能 -> CPU，看“虚拟化”是否显示“已启用”。如果显示未启用，进 BIOS 开启 Intel VT-x 或 AMD-V。
  2. 在 Windows 功能里启用“虚拟机平台”和“适用于 Linux 的 Windows 子系统”这两项，然后重启。
  3. 执行wsl --set-default-version 2，确保 WSL 默认版本是 2。
  4. 重装/更新 Docker Desktop，启动后到 Settings -> Resources -> WSL Integration 确认集成选项。

还有一个相关报错是failed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine。这种一般是 Docker Desktop 引擎没起来，先看托盘图标是企鹅还是红色报错，然后退出重开；如果一直不行，检查 WSL 发行版是否损坏，wsl --shutdown再打开往往能救回来。

我以前遇到过一台老笔记本，BIOS 设置里虚拟化被关了，折腾一天才反应过来，真心建议新手遇到启动问题第一件事就是去 BIOS 看一眼，别先重装系统。

5.2 容器访问不了外部服务？先分三层排查

部署完应用最常见的问题是“容器里连不上宿主机服务”或者“外部访问不了容器端口”。我的排查顺序固定三层：

第一层，端口映射是否生效。docker ps看 PORTS 列，宿主机端口外部访问不到，先检查防火墙是否放行端口；容器在 Windows 下还要确认网络类型是 NAT 还是 bridge。

第二层，容器到宿主机通信。容器里访问宿主机服务时，localhost指的是容器自己，不是宿主机。如果你在容器里要连宿主机的 MySQL，需要把地址换成host.docker.internal（Docker Desktop 默认支持），或者在 Linux 上用--add-host=host.docker.internal:host-gateway。

第三层，容器间通信。多个容器用 compose 编排时，直接用服务名；手工 docker run 时，把容器放到同一自定义网络里，比如docker network create mynet，然后运行时都加--network mynet。

记住：网络问题 80% 出在“我连的是不是我以为的那台主机”上。先用docker exec进容器ping一下目标地址，往往能快速定位。

5.3 常用命令速查，部署前先背熟这几条

给一份我用下来最高频的命令清单，适合打印出来贴显示器旁边：

场景命令说明
启动/停止docker compose up -d/docker compose down组合编排的日常操作
查看日志docker logs -f 容器名实时看容器日志
进入容器docker exec -it 容器名 bash调试容器内部环境
查看资源docker stats实时看容器CPU/内存
清理垃圾docker system prune -a清理无用镜像和容器，小心使用
拷贝文件docker cp 容器名:/路径 ./本地路径从容器里取文件
查看端口docker port 容器名看端口映射实际生效情况
指定网络docker run --network mynet ...容器间用服务名互通

说一个我自己反复强调的原则：删容器之前先确认数据卷。docker rm不会删数据卷，但docker compose down -v会，后面带-v的时候尤其要谨慎。数据无价，持久化这关过不了，其他都是空谈。

写到这里，我有一个很真实的感受：2026年值得部署的 Docker 应用，其实没有一个固定答案，关键在于你先解决哪个痛点。我这一年最大的体会是，Docker 的复杂度从来不在“安装”这一步，而在数据怎么持久化、网络怎么互通、依赖怎么管理这些细节上。如果你刚开始，先从 Ollama 或 MySQL 这种最简单的容器入手，把数据卷和端口映射这两个概念吃透，后面再上 Dify、Prometheus 这类复杂编排会顺畅很多。希望这份清单能帮你少走点弯路。也欢迎你按这份清单部署后回来聊聊你踩到的坑，我们评论区见。