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 wasnt 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://ollama主机: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_PASSWORDYourStrongPass \ -e TZAsia/Shanghai \ -v mysql-data:/var/lib/mysql \ mysql:8.0几个关键点-v mysql-data:/var/lib/mysql必须加。不然容器删掉binlog、数据目录全没这是新手最常犯的错。-e TZAsia/Shanghai设置时区容器默认是 UTC不设置的话查询NOW()和日志时间都和本地差 8 小时。字符集建议初始化时指定--character-set-serverutf8mb4 --collation-serverutf8mb4_unicode_ci避免后面遇到 emoji 或者生僻字乱码。如果你要调max_connections、innodb_buffer_pool_size加--max-connections500这类参数即可。实际开发里很多人还会用 docker compose 把 MySQL 和业务服务编排在一起这个我在第 4 部分会给出统一模板。特别提醒MySQL 容器不要在启动命令里直接挂宿主机上的普通文件夹权限问题容易踩坑建议用命名卷文件权限交给 Docker 管理。3.2 Redis 主从一条 compose 文件演练高可用Redis 容器化同样热门尤其是“docker 安装 redis 主从”。Redis 本身配置简单主从模式两条配置就够。我这里给一份简单的 docker-compose.ymlservices: 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 非常顺手。一个适合初学的最小 composeservices: 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_PASSWORDadmin123 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 pulldocker 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 wasnt detected”出现频率很高。这个问题的本质是 Docker Desktop 需要一个虚拟化环境来跑 Linux 容器通常是 WSL2 或 Hyper-V而你的机器没开启或没装对。排查步骤如下打开任务管理器 - 性能 - CPU看“虚拟化”是否显示“已启用”。如果显示未启用进 BIOS 开启 Intel VT-x 或 AMD-V。在 Windows 功能里启用“虚拟机平台”和“适用于 Linux 的 Windows 子系统”这两项然后重启。执行wsl --set-default-version 2确保 WSL 默认版本是 2。重装/更新 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.internalDocker Desktop 默认支持或者在 Linux 上用--add-hosthost.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 这类复杂编排会顺畅很多。希望这份清单能帮你少走点弯路。也欢迎你按这份清单部署后回来聊聊你踩到的坑我们评论区见。