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.ymlversion: 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_URLhttp://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-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci - --max_connections500先看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.size10GB 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_HANGUPtrue - ENABLE_WEB_PANELtrue打开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 wasnt 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年应用数量和成熟度都已经进入了一个相对平稳的阶段。你不需要追最新的技术只要把上面这些经过验证的方案部署好就已经能给日常工作和生活带来实打实的效率提升了。挑一两个自己最需要的先上手跑起来之后自然会知道下一步该部署什么。