2026年Docker部署实战：从AI大模型到数据库的完整指南-开发者社区

1. 为什么2026年还要聊Docker部署这件事

说实话，从Docker火起来到现在已经过去快十年了，中间唱衰的声音一直没断过，什么“K8s要取代单机Docker”“容器技术已经过时了”之类的论调每隔一阵就会冒出来一次。但你看这两年实际的情况：Docker依然是个人开发者、小团队、甚至很多中型公司部署应用的首选方式。原因很简单，它解决了“在我机器上明明是好的”这个经典问题。

我自己的服务器上跑着十几个容器，从数据库、博客、下载工具到AI大模型推理服务，全是靠docker compose一把梭管理起来的。2026年这个时间点，Docker的基本用法大家早就熟了，但什么应用值得部署、怎么部署才能少踩坑，反而是更值钱的信息。这篇内容我把这两年亲手部署过、实测稳定、真正解决实际需求的应用整理了一遍，按使用场景分类，每一类里都有我认为值得花时间部署的东西。

先说几个前置条件，方便后面内容对号入座：

我默认你用的是一台Linux服务器，Debian 12或Ubuntu 22.04/24.04都行，2核4G起步，有条件上4核8G体验会舒服很多。
所有方案都是用Docker Compose编排，不建议再手动docker run一串参数去维护了，那属于自己给自己找麻烦。
部署前先把Docker和Compose插件装好，这个我后面会单独说一嘴，因为太多人被第一步卡住了。

这篇内容适合的人群很明确：有台云服务器不知道跑什么的人、想用Docker把重复劳动自动化的人、以及想把AI大模型私有化部署在自己机器上但要找一套省心方案的人。

2. AI大模型本地部署：2026年最值得投入的方向

2.1 Ollama配合Open WebUI，半小时拥有私人AI助手

如果说这两年Docker生态里哪个方向最火，"本地跑大模型"绝对排第一。从热搜词里就能看到，ollama本地部署、deepseek部署、minimax本地部署这些词的搜索量一直居高不下。这不奇怪，谁不想要一个数据不出自己服务器、随时能用、不用按token付费的AI助手呢。

部署方案其实已经非常成熟了。核心就两个容器：Ollama负责跑模型推理，Open WebUI提供一个长得像ChatGPT的网页界面。Ollama这个工具早就不是当年那个只能命令行交互的东西了，它现在支持OpenAI兼容的API接口，意味着你本地起的这个模型可以无缝接入各种第三方工具，比如NextChat、LobeChat甚至一些笔记软件。

我的标准部署方式是写一个docker-compose.yml：

version: '3.8' services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - "11434:11434" volumes: - ./ollama_data:/root/.ollama deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: unless-stopped ports: - "3000:8080" volumes: - ./webui_data:/app/backend/data environment: - OLLAMA_BASE_URL=http://ollama:11434 extra_hosts: - "host.docker.internal:host-gateway"

这里有几个细节值得展开说。

先看资源限制那块的写法，NVIDIA设备那段只有你的机器装了NVIDIA容器工具包才会生效，没有GPU的机器直接把deploy那段整个删掉就行。CPU跑模型不是不行，但参数量超过7B的模型速度会很难受，建议还是搞张显卡，哪怕是二手的老显卡都比纯CPU强好几个量级。

再看volumes挂载。Ollama的数据目录是关键，因为所有下载下来的模型文件都存在这个目录里。我第一次部署的时候没挂载这个目录，后来容器重建，几个G的模型全部重新下载，那种痛你应该能理解。所以数据卷挂载对于有状态服务来说是标配，血的教训。

部署完了之后，SSH进服务器执行：

docker compose up -d docker exec -it ollama ollama pull deepseek-r1:7b

模型下载好之后，浏览器访问http://服务器IP:3000，注册一个账号，在模型选择里切到deepseek-r1:7b就能开始对话了。

2.2 Dify：把本地模型变成能落地的工作流

单一个聊天界面只能算玩具，真正想让模型干活的场景还需要一个工作流编排平台。我推荐Dify，原因有三个：全中文界面原生支持、模型管理做得省心、可视化的工作流对不怎么会写代码的人极度友好。

Dify的部署在2026年已经很成熟了，官方直接给了一键部署脚本：

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

安装过程没什么坑，比较值得关注的是环境配置。Dify默认会把所有组件都拉起来，包括PostgreSQL、Redis、Weaviate向量数据库这些。如果你的服务器内存只有4G，建议手动改一下docker-compose.yaml，把不用的组件注释掉，比如你不做文档问答的话，向量数据库就可以先不启动，等真用到了再加回来也不迟。

Dify里面接Ollama特别顺，进入"设置-模型供应商"，找到Ollama类型的供应商，填上http://host.docker.internal:11434就行。这里用host.docker.internal而不是localhost是因为Dify容器内部访问宿主机端口必须走这个特殊域名，很多人在这一步卡住。

我自己用Dify搭了一个自动日报生成的工作流，每天早上定时拉取服务器上的日志和监控数据，让本地模型总结成日报发到群里。整个过程模型完全不出内网，数据安全性是实打实的，这在办公场景里是刚需。

2.3 LM Studio和ComfyUI：别忽略桌面端和图像生成

热搜里还有个容易被人忽略的词：LM Studio。这个工具严格来说不是Docker部署，是桌面应用，但它定位是"本地模型管理的最小白友好方案"，下载个安装包点点点就能在Windows/Mac上跑大模型。如果你还没上Docker这条船，又急着一个能用的本地模型环境，LM Studio是上手成本最低的了。

另一个方向是ComfyUI。图像生成这两年的热度持续不减，ComfyUI是不折不扣的工作流王者。Docker部署ComfyUI我用的是一个第三方镜像，ghcr.io/ai-dock/comfyui:latest，里面预装了Python环境和各种依赖，省去了本地配环境的痛苦。关键参数就两个：

# 注意需要挂载模型目录和输出目录 docker run -d \ --name comfyui \ --gpus all \ -p 8188:8188 \ -v ./models:/opt/ComfyUI/models \ -v ./output:/opt/ComfyUI/output \ ghcr.io/ai-dock/comfyui:latest

这个镜像启动的时候会自动下载基础模型，第一次可能需要等一段时间。如果你需要跑SDXL类的模型，建议至少16G显存起步，8G显存跑小的SD1.5模型还凑合，再大就吃力了。

3. 开发效率与协作类应用：把日常高频工具容器化

3.1 GitLab：自托管的代码仓库和CI/CD全家桶

代码托管这件事，很多人一直纠结是用Gitea还是GitLab。我个人的建议很直接：小团队或个人项目用Gitea，追求完整的DevOps流程上GitLab。GitLab在2026年的版本已经集成了非常完善的CI/CD能力，单容器就能跑起一整套DevOps工具链，从代码托管、Merge Request审查、流水线构建到容器镜像仓库全都有。

部署GitLab的docker compose配置参考这个：

services: gitlab: image: gitlab/gitlab-ce:latest container_name: gitlab restart: unless-stopped hostname: gitlab.example.com ports: - "8929:80" - "2224:22" volumes: - ./gitlab/config:/etc/gitlab - ./gitlab/logs:/var/log/gitlab - ./gitlab/data:/var/opt/gitlab environment: GITLAB_OMNIBUS_CONFIG: | external_url 'http://gitlab.example.com' gitlab_rails['gitlab_shell_ssh_port'] = 2224

有个细节必须提醒：GitLab的SSH端口建议改掉，不要用默认的22，不仅因为22端口容易被扫描攻击，更因为宿主机上很可能已经有别的服务占用了。

资源这块，GitLab是出了名的内存大户。实测下来，2G内存勉强能跑，但操作会明显卡顿，4G内存才是舒适区。所以如果你手上的服务器配置太寒酸，建议先等等再部署GitLab。

GitLab的runner也可以容器化，在服务器上起一个gitlab-runner容器作为Docker executor，这样流水线里可以跑任意Docker镜像，构建、测试、打包一步到位。这一套组合拳打下来，从代码提交到自动部署，全程不需要手动操作。

3.2 JumpServer：适合团队用的堡垒机方案

运维安全在2026年已经被提到了很高的位置，你不可能让每个开发都拿服务器密码直接ssh上去，出事了连审计日志都没有。JumpServer是我目前用过最顺手的开源堡垒机，Docker Compose一键起全套。

JumpServer官方提供的docker-compose文件会自动拉起所有依赖组件，包括MySQL、Redis、Kafka这些，配置可以参考官方文档，核心思路就是：

curl -sSL https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash

一键脚本跑完，整个JumpServer就起来了。默认的端口是80/443，打开之后按提示配置管理员密码。

我实际用下来的体验是：核心账号（比如服务器root）永远不需要直接暴露给开发。开发想登录服务器，先登录JumpServer，再点对应的资产连接，全程录屏加操作日志。真出了什么问题，回放一下就清楚是谁干的、干了什么。这对团队协作的安全感提升是实打实的。

3.3 Hexo和静态博客容器化：低成本维护一个个人站点

热搜里的"hexo部署到github"说明写博客这件事到现在依然是个高频需求。我自己之前写过文章介绍怎么把Hexo这种静态站点生成器容器化部署，这里就一句话带过：

services: hexo-server: image: node:20-alpine container_name: hexo-server working_dir: /app volumes: - ./blog:/app - /app/node_modules ports: - "4000:4000" command: npx hexo server

这么做的好处是本地不用装Node环境，换电脑随时把代码拉下来、容器起起来就能写文章。配合GitHub Actions或者git hook还能实现push代码后自动构建发布，写博客这件事在2026年完全可以做到全流程自动化。

不过要说句公道话，如果你的博客流量不大，直接用Cloudflare Pages或者GitHub Pages这些托管平台就行，Docker部署主要是为了自托管可控性。哪种方案更适合你要看你的核心诉求是什么。

4. 数据存储与基础设施类应用：稳定运行的底座

4.1 MySQL 8.0生产环境部署：那些容易踩的配置坑

数据库容器化部署在2026年已经是公开的秘密了，但很多初次上手的人还是会踩同样的坑。热搜词里的"docker安装mysql8.0并使用"、"redis docker compose 生产环境部署"就是最好的证明。先看MySQL的正确写法：

services: mysql: image: mysql:8.0 container_name: mysql8 restart: unless-stopped ports: - "3306:3306" volumes: - ./mysql_data:/var/lib/mysql - ./my.cnf:/etc/mysql/conf.d/my.cnf - ./mysql_log:/var/log/mysql environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_DATABASE: ${MYSQL_DATABASE} MYSQL_USER: ${MYSQL_USER} MYSQL_PASSWORD: ${MYSQL_PASSWORD} command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci - --max_connections=500

先看my.cnf挂载。生产环境下必须自己指定配置，默认配置很多参数不适合实际业务场景。我一般会设置这几项：

[mysqld] innodb_buffer_pool_size = 1G innodb_log_file_size = 256M slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 2 binlog_format = ROW

再强调一次内核参数。MySQL容器运行需要较高的文件描述符限制，需要在宿主机上配置：

echo "fs.file-max = 65535" >> /etc/sysctl.conf sysctl -p

不配置这个的话，高并发场景下MySQL容器会报"Too many open files"错误，排查起来非常隐蔽。

密码环境变量建议用.env文件管理，不要把密码直接明文写在compose文件里。这个习惯从第一天就要养成。

4.2 Redis主从复制：高可用要提前布局

Redis也是容器化部署的重灾区，很多人只部署一个单节点就觉得很稳，直到出现缓存穿透或者宕机才想起高可用。推荐的方案是主从加Sentinel哨兵模式。

一个标准的Redis主从compose配置：

services: redis-master: image: redis:7-alpine container_name: redis-master restart: unless-stopped ports: - "6379:6379" command: ["redis-server", "--appendonly", "yes", "--requirepass", "${REDIS_PASSWORD}"] volumes: - ./master_data:/data redis-slave-1: image: redis:7-alpine container_name: redis-slave-1 restart: unless-stopped ports: - "6380:6379" command: ["redis-server", "--slaveof", "redis-master", "6379", "--requirepass", "${REDIS_PASSWORD}", "--masterauth", "${REDIS_PASSWORD}"] depends_on: - redis-master volumes: - ./slave1_data:/data

注意redis-sentinel这一层我到现在都没用docker compose正式跑起来过，因为真实环境我直接用云厂商的托管Redis更省心。但如果你追求的是环境一致性、一套compose文件拉起来全链路本地环境，那哨兵模块也是可以容器化的，逻辑都在官方镜像里，配置好sentinel.conf里的master地址和密码就行。

Redis数据持久化这块，AOF一定要开启，RDB快照建议保留但不要依赖它做唯一恢复手段。AOF appendonly设为yes之后，最多丢失一秒数据，这对大多数应用足够用了。

4.3 Prometheus与监控告警：把服务器状态掌握在手里

当你的Docker容器超过三个的时候，"打开一个网页看一下当前状态"的需求就出现了。Prometheus加上Grafana的组合本身就是一个超级经典的Docker部署案例，docker-compose把监控全家桶整合起来非常方便。

我的监控套装通常包含四个服务：Prometheus采集指标、Grafana做可视化、cAdvisor收集容器指标、node-exporter收集宿主机指标。它们之间的配合关系可以理解为：node-exporter告诉Prometheus宿主机CPU和内存使用率，cAdvisor告诉Prometheus每个容器吃了多少资源，Grafana把这些数字画成面板给你看。

核心配置大概是：

services: prometheus: image: prom/prometheus container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - ./prometheus_data:/prometheus ports: - "9090:9090" command: - '--config.file=/etc/prometheus/prometheus.yml' - '--storage.tsdb.retention.size=10GB' grafana: image: grafana/grafana container_name: grafana ports: - "3001:3000" environment: - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD} volumes: - ./grafana_data:/var/lib/grafana node-exporter: image: prom/node-exporter container_name: node-exporter network_mode: host pid: host restart: unless-stopped cadvisor: image: gcr.io/cadvisor/cadvisor:latest container_name: cadvisor ports: - "8080:8080" volumes: - /:/rootfs:ro - /var/run:/var/run:ro - /sys:/sys:ro - /var/lib/docker/:/var/lib/docker:ro privileged: true devices: - /dev/kmsg

有个小技巧：Grafana默认端口是3000，跟Open WebUI冲突了，所以我习惯把Grafana映射到3001或改成Open WebUI的端口。你的服务器上跑了很多服务之后，端口规划要提前想清楚。

告警规则的配置是监控系统真正发挥价值的地方。比如CPU持续5分钟超过90%就告警这类规则，配置在Prometheus里，告警推送给Alertmanager，再由Alertmanager发送到企业微信或钉钉。不用复杂的前端监控系统，光靠这套就能提前发现大部分服务器问题。

5. 自动化与生活服务类应用：让服务器自己干活

5.1 青龙面板：定时任务的瑞士军刀

青龙面板在2026年依然是Docker生态里安装量最高的应用之一，它的本质是一个定时任务管理平台，支持Python和JavaScript脚本，你可以把它理解为"云原生版本的crontab"。加上Web界面、日志查看、环境变量管理这些增强功能。

部署方式很简单：

services: qinglong: image: whyour/qinglong:latest container_name: qinglong restart: unless-stopped ports: - "5700:5700" volumes: - ./qinglong_data:/ql/data environment: - ENABLE_HANGUP=true - ENABLE_WEB_PANEL=true

打开http://IP:5700，设置账号密码，就可以开始建定时任务了。

我用青龙面板干过哪些实际的事：定时备份服务器MySQL数据库并上传到对象存储、定时签到类脚本（比如论坛签到）、定时清除系统日志、定时检查SSL证书有效期并推送到期提醒。本质上它就是一个可以托管任意脚本的调度器，你可以往里面扔任何Python或JS脚本。

青龙面板的依赖管理其实是个痛点，容器环境里缺Python包是常有的事。热搜词里的"docker青龙依赖管理"说明很多人在问这个问题。我的经验是：在青龙面板内置的"依赖管理"模块直接安装就行，它支持从requirements.txt导入，不用进容器手动pip install。

5.2 ERPNEXT与自动化办公：开源ERP的可行解

ERPNEXT是热搜词里的一个冷门词，但恰恰是很多有业务需求的用户高频搜索的。它是开源ERP里做得相当完整的一套系统，涵盖采购、销售、库存、会计、CRM这些模块，而且有中文支持。对于不想被SaaS年费绑死的小公司来说，自己部署一套ERPNEXT是个性价比很高的选择。

Docker部署ERPNEXT官方直接给出了一键方案，比较吃资源，4G内存是底线，8G才能真正跑得舒服。这也是为什么很多人部署到一半放弃了——机器配置跟不上。

这里只提醒一点：ERPNEXT首次初始化需要的时间比较长，因为要初始化数据库和站点，SSD硬盘和足够的磁盘IO会明显缩短等待时间。如果你用的是那种便宜的低配云主机，耐心等个十几分钟是正常的，别以为卡死了就强行重启，白白浪费时间。

5.3 Uptime Kuma：服务状态监控面板

这个工具我强烈推荐，尤其适合像我一样在服务器上跑了十几个Docker应用的人。Uptime Kuma是一个开源的服务监控工具，支持HTTP、TCP、Ping、DNS等协议，甚至能监控特定端口是否开放，当服务不可用时会通过Telegram、Bark、企业微信等多种方式推送告警。

部署就一条命令：

docker run -d --name uptime-kuma -p 3002:3001 -v ./uptime-kuma-data:/app/data louislam/uptime-kuma:latest

界面可视化做得很直观，状态历史、响应时间曲线、SSL证书到期提醒全都内置好了。把服务器上所有对外提供的服务都加进去，之后每天打开看一眼，心里有数。

6. Docker部署避坑指南和一些心里话

6.1 网络与虚拟化问题：最常见的启动失败原因

热搜词里有一条特别典型的："docker desktop failed to start because virtualisation support wasn't detected"。这个问题从Docker Desktop诞生到现在就没消失过。本质原因就一个：Windows或macOS上Docker Desktop依赖硬件虚拟化功能，而这个功能在BIOS/UEFI里默认没开启。

解决思路很简单：

重启电脑，进入BIOS（通常是开机时按Del或F2）
找到Intel VT-x或AMD-V的选项，设为Enabled
打开Windows功能里的"虚拟机平台"和"适用于Linux的Windows子系统"

如果你是用Windows跑Docker Desktop，建议直接装WSL2后端，比Hyper-V后端稳定不少。当然如果条件允许，我还是推荐直接上Linux服务器跑Docker，容器环境是Linux原生的，而Docker Desktop本质上是在虚拟机里套了一层，性能和稳定性都有差距。

6.2 容器部署的通用原则：数据持久化与健康检查

部署了这么多应用之后，我越来越认同一个观点：Docker部署的技术难度不在"把它跑起来"，而在"把它长久地、稳定地跑下去"。

总结下来无非这几条：

所有有状态服务（数据库、文件存储、用户配置）都要挂载数据卷，容器可以随时删掉重建，但数据必须留在宿主机的持久化目录里。
每个服务能加healthcheck就加，尤其在生产环境。健康检查不通过，编排工具才能帮你自动重启，不然状态异常了你都不知道。
多实例管理优先考虑docker compose，别再用裸的docker run一把梭了。用compose可以做到配置即代码，换机器迁移环境无比丝滑。
日志要定期清理，容器日志写到一定程度会撑爆磁盘，一句logrotate或者定时清空日志容器的任务就能避免这个隐患。
版本镜像别一味追latest。上线久了之后你会发现，"这个版本在线上跑了三个月没出问题"比"最新版有几十个好用的新特性"值钱得多。

6.3 关于"部署到哪台机器"的一些思考

最后聊点题外话。这么多年部署下来，什么样的机器适合跑什么样的应用，我心里基本有一本账：

低配机器（1核1G）只适合跑静态博客、Nginx反代、Uptime Kuma这类轻量服务，别妄想跑大模型和GitLab。
中配（2核4G）是甜点位，青龙面板、Open WebUI、MySQL、Redis、Prometheus全家桶都能塞进去，注意别同时跑太多重型服务就行。
高配或带GPU的机器，适合跑Dify工作流、Ollama推理服务、ComfyUI出图这些吃资源且值得投入的场景。
对于"本地部署AI"这个热门需求，我的建议是：如果你是图新鲜，LM Studio在个人电脑上就足够了；如果你要正经长期用，一台纯CPU的小主机跑7B模型实际效果并不差，功耗还低，完全可以7x24小时跑着当一个家庭AI服务。

我自己目前用得最顺手的一套搭配是：一台N100小主机负责跑青龙面板、Uptime Kuma、Nginx反代这些轻量服务，一台带3060显卡的机器专门跑Ollama和ComfyUI，再加上一台2核4G的云服务器跑GitLab和监控系统。三者通过Tailscale组网，从外面看就像一个整体。这套组合我跑了将近一年，基本没出过大问题。

Docker这个生态走到2026年，应用数量和成熟度都已经进入了一个相对平稳的阶段。你不需要追最新的技术，只要把上面这些经过验证的方案部署好，就已经能给日常工作和生活带来实打实的效率提升了。挑一两个自己最需要的先上手，跑起来之后自然会知道下一步该部署什么。