2025年底到2026年初我帮几位朋友清理了几台“塞满了Docker容器”的机器。它们的共同点是热门教程里推荐的应用基本都装了但真正坚持用了三个月以上的往往只有四五个。所以拿到“2026年最值得部署的Docker应用推荐”这个题目时我脑子里第一个念头是与其列一份“能装什么”的清单不如聊聊“装完之后你还愿意一直用下去的有哪些”。结合近一年技术社区和搜索平台上高频出现的部署词——ollama本地部署、dify部署、prometheus监控部署、docker青龙、docker安装mysql8.0、erpnext安装部署、jumpserver部署教程——其实已经能看出2026年容器化的几条主线。这篇文章我就按自己实际部署、长期维护的视角按优先级拆解哪些容器值得上、怎么上、上了之后怎么养。1. 先定一个选型标准不是“能装什么”而是“装完还愿意用多久”1.1 我给容器定的三道关频率、成本、资源面对一个“看起来不错”的Docker应用我会先问自己三个问题。第一装完之后的使用频率。是隔三差五就要用还是只在安装那天打开过一次那些装完就吃灰的容器往往是因为需求本身并不存在只是“别人的教程勾起了兴趣”。第二升级和维护成本。镜像更新时配置和数据能平滑迁移吗还是每次升级都要重新折腾半天有些一体化平台功能很全但每次升级都伴随配置文件的breaking change最后只能含泪卸载。第三资源占用是否可控。一个容器吃掉多少内存、多少磁盘是否会拖垮同一台机器上的其他服务。我自己吃过亏一台2G内存的小服务器为了跑一个“全家桶”应用把其他服务都挤到OOM边缘最后只能砍掉重来。这三道关过滤下来能留下的容器其实不多。真正值得长期部署的往往是那些看似不起眼的基础服务比如mysql、redis它们运行一两年都不太需要操心反而是很多功能花哨的应用装完两周就卸载了。1.2 2026年的几条容器主线从搜索热词看2026年的Docker部署热度集中在四个方向。本地AI与大模型应用代表是ollama、dify、deepseek、lm studio、comfyui它们解决的是数据隐私、调用成本、离线可用的问题。数据服务与可观测性代表是mysql8.0、redis主从、doris、prometheus它们解决的是稳定、可迁移、可观测的问题。研发协作与自动化运维代表是gitlab、jumpserver、青龙面板解决的是团队协作、权限审计、重复劳动的问题。业务系统容器化代表是erpnext解决的是中小企业后台系统的快速交付问题。这四条线的需求各不相同。如果你部署容器是为了解决其中某一类问题那这一类里的核心容器基本可以放心上如果没有对应需求再热门的应用也只是占资源的摆设。1.3 一张表快速对号入座应用容器核心用途适合谁最低资源参考推荐优先级ollama本地大模型推理有隐私需求、频繁调用模型的个人或团队2核4G起步跑大模型看显存极高difyLLM应用开发平台想把模型接入业务流的人4G内存起高mysql8.0业务数据库几乎所有服务1核1G、500MB磁盘极高redis主从缓存、队列、会话需要高可用的后端2G内存起高prometheus grafana监控与告警运维、后端开发1核2G高gitlab代码托管与CI/CD研发团队4核8G中高青龙定时任务管理个人自动化1核1G中erpnext企业资源管理小企业、团队4核8G中jumpserver堡垒机、审计团队、运维4核8G中这张表仅供参考真正的取舍还是看你的实际场景。2. 本地AI与大模型ollama、dify、comfyui这波容器为什么值得留2.1 ollama本地部署从一行命令到模型管理的完整链路ollama本身是一个本地模型运行时但很多人第一次接触它就是通过Docker。用Docker跑ollama的好处特别明显宿主机环境再乱也不影响模型文件统一放在数据卷里以后升级ollama镜像不会导致模型重新下载。最基本的部署命令很轻量docker run -d \ -v ollama:/root/.ollama \ -p 11434:11434 \ --name ollama \ ollama/ollama如果是Linux且装了nvidia-container-toolkit想调用GPU就加个--gpus all。启动后拉模型docker exec -it ollama ollama pull deepseek-r1:7b模型文件从几GB到上百GB都有下载前一定看清标签。显存不够就选量化版本比如q4_k_m这类能明显降低显存占用推理质量损失在可接受范围内。这里有个容易忽略的细节Docker跑ollama和原生装ollama推理性能差距很小用容器主要是为了环境隔离和回滚方便。你在宿主机上装了一堆Python环境、CUDA版本之后再想换模型运行时容器这种“推倒重来”的体验是真的省心。2.2 dify本地部署为什么它让ollama从“玩具”变成“工具”dify在搜索热度里排得很前这很正常。它把AI应用从“调模型接口”变成了“搭工作流”带知识库、带Agent、带可视化编排界面。dify官方提供了整套docker compose编排包含api、worker、web以及postgres、redis、向量数据库等组件。部署方式直接在官方仓库克隆下来的docker目录里操作git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d首次启动要拉不少镜像整个过程需要耐心。启动后访问本机80端口配置模型供应商时选Ollama类型填入http://host.docker.internal:11434或http://172.17.0.1:11434就能把本地模型接进来。这里有个经典坑在dify容器里访问宿主机上的ollama不能用localhost因为容器里的localhost指向容器自己必须用host.docker.internal或docker0网桥的网关地址。这个小问题能让一个不熟悉容器网络的人卡半小时。dify为什么值得留因为它解决了“模型只有能力、没有流程”的问题。你可以在它上面建知识库、接外部工具、做对话流和Agent编排。对一个想把本地模型投入实际业务的人来说dify基本是2026年“装了就不想删”的容器之一。2.3 deepseek、comfyui以及GPU透传的实际经验搜索热度里还有deepseek部署、lm studio bionic本地部署、comfyui本地部署。DeepSeek本地部署的路径和ollama类似核心还是模型体积和显存规划。你选7B、14B还是32B参数版本直接决定需要多大显存。以7B量化模型为例一般8G显存可以跑14B量化模型建议16G显存以上32B级别就需要24G以上的卡了。ComfyUI则是AI绘画工作流工具Docker部署时同样需要GPU透传。如果你在Windows上用Docker Desktop跑这些容器GPU支持依赖WSL2后端需要在Docker Desktop设置里开启GPU。Linux环境下先装好nvidia-container-toolkit再启动容器。一个通用建议部署前先去对应模型的官方页面看一眼硬件要求别盲目拉一个几十GB的大模型结果启动时直接OOM白白浪费时间。3. 数据服务与监控底座mysql、redis、prometheus部署时最该盯住的细节3.1 mysql8.0容器化数据卷才是真正的容器mysql容器大概是Docker生态里被部署次数最多的数据库了。但不少人只是docker run mysql就直接用结果容器一删数据全没了才意识到问题。正确的做法是挂数据卷docker run -d \ --name mysql8 \ -e MYSQL_ROOT_PASSWORDyourpassword \ -e TZAsia/Shanghai \ -v mysql_data:/var/lib/mysql \ -p 3306:3306 \ mysql:8.0有几个细节值得注意。MYSQL_ROOT_PASSWORD只在数据卷为空、首次初始化时生效之后想改密码得进容器用SQL改。字符集最好在配置文件里显式指定utf8mb4否则默认排序规则可能让你在中文场景下踩坑。时区也要处理不设置TZ的话容器时间会是UTC比北京时间慢8小时。另外别用latest标签镜像版本固定到8.0.40这种具体小版本避免将来拉镜像时无意间跨了小版本导致行为变化。3.2 redis主从与生产环境的docker compose“redis docker compose 生产环境部署”是搜索热词里很有代表性的一条。单机redis用一条docker run就能跑但如果要上主从建议直接用compose编排services: redis-master: image: redis:7-alpine command: [redis-server, --appendonly, yes] volumes: - redis_master_data:/data ports: - 6379:6379 redis-replica: image: redis:7-alpine command: [redis-server, --slaveof, redis-master, 6379] depends_on: - redis-master volumes: - redis_replica_data:/data这种写法的好处是容器间通过服务名redis-master解析通信不需要写死IP。生产环境如果要做高可用一般还会加哨兵Sentinel。容器化部署哨兵时要单独起redis-sentinel容器并确保三个节点互相能通信。数据层面建议开启appendonly yes这样即使容器重启也能通过AOF文件恢复大部分数据。Redis的数据都在内存里如果只是当缓存用丢了也就丢了但涉及会话、队列、业务状态时持久化配置绝对不能省。3.3 prometheus和doris监控与分析型数据库的部署要点prometheus监控部署是运维侧非常经典的容器组合。标准搭配是prometheus node_exporter grafana用compose编排三个容器分别映射9090和3000端口。Grafana第一次登录默认admin/admin进去后添加数据源时URL填http://prometheus:9090。很多人会疑惑为什么不是localhost因为在同一个compose网络里容器服务名就是域名。这是Docker内置DNS带来的便利但也要求你理解容器网络的基本概念。doris安装部署相对复杂一些。它是分析型MPP数据库镜像通常要区分FE和BE角色前端负责SQL解析和调度后端负责数据存储和计算。启动时需要给不同容器指定对应角色并通过配置文件或环境变量告诉它自己是FE还是BE。没有明确需求的话不建议一开始就折腾doris先用mysql解决业务存储真到了需要跑大规模OLAP查询时再考虑它。4. 研发协作与自动化容器gitlab、jumpserver、青龙、erpnext的取舍4.1 gitlab容器化内存规划与第一次启动的耐心gitlab是“看起来很重装起来也确实重”的典型。官方镜像gitlab/gitlab-ce运行时最低建议4G内存推荐8G。如果机器只有2G内存启动过程中很可能会触发OOM容器反复重启网页一直打不开。部署时最重要的配置是external_url它决定了GitLab在网页上生成的克隆地址不配对的话会出现刷新循环或者克隆地址错误。数据目录一定要挂到宿主机docker run -d \ --name gitlab \ --hostname gitlab.example.com \ -p 8022:22 -p 80:80 -p 443:443 \ -v gitlab_etc:/etc/gitlab \ -v gitlab_log:/var/log/gitlab \ -v gitlab_data:/var/opt/gitlab \ gitlab/gitlab-ce:latest第一次启动会经历一个比较长的初始化过程耐心等两三分钟后初始root密码在容器里的/etc/gitlab/initial_root_password文件中。如果想自己搭代码托管又嫌GitLab太重可以先用gitea过渡只有团队需要自带CI/CD的完整平台时才值得把GitLab当成正式基础设施来部署。4.2 青龙面板与依赖管理定时任务容器的正确打开方式青龙面板在技术社区里热度一直不低它本质上是一个带Web界面的定时任务管理工具主要用于完成周期性脚本、自动化运维、站点监控等场景。Docker部署非常轻docker run -dit \ -p 5700:5700 \ -v ql_data:/ql/data \ --name qinglong \ whyour/qinglong:latest首次访问网页会引导你初始化管理员账号。搜索词里“docker青龙 依赖管理”很靠前因为脚本跑起来经常缺各种Python、Node.js依赖。青龙面板里可以安装依赖但不同脚本对依赖版本要求不一致混在一起装容易冲突。我的经验是多任务环境要做隔离一个容器只处理一类任务或者用虚拟环境、独立容器来跑不同依赖要求的脚本同时建议把脚本限定在合法合规的个人自动化场景比如数据同步、定时备份、健康检查这类用途避免触碰任何灰产场景。4.3 erpnext和jumpserver给团队用的两套重服务erpnext是开源ERP系统适合小企业的进销存、财务、HR管理。它通过frappe_docker仓库提供一套compose编排包含前端、后端、worker、redis、mariadb等。部署命令git clone https://github.com/frappe/frappe_docker.git cd frappe_docker docker compose -f pwd.yml up -d首次启动需要初始化和建站日志刷到“site created”才算真正完成。这类系统对磁盘和内存要求都不低没有实际业务需求的话不建议个人去折腾。jumpserver是堡垒机用于多服务器环境下的资产管理、权限控制和操作审计。它包含core、koko、lion等多个组件官方提供compose编排。部署时关键是持久化目录和数据库配置要配好。第一次部署完成后通过网页初始化资产列表、创建用户、分配权限就能把团队所有服务器的登录统一收口。对合规要求高、账号审计需求明确的团队jumpserver几乎是必备工具。5. 部署高频故障的完整排查链路Windows虚拟化、npipe失败、离线内网5.1 Windows环境Docker Desktop无法启动先查BIOS和WSL2搜索热词里“virtualization support not detected docker desktop failed to start”这个很常见。遇到这个报错不用急着重装按顺序排查进BIOS确认CPU虚拟化开关已开启Intel对应VT-xAMD对应SVM。不少品牌机默认关闭这是最大元凶。在Windows的“启用或关闭Windows功能”里确认“虚拟机平台”和“适用于Linux的Windows子系统”两项都已勾选。管理员PowerShell执行wsl --status看WSL内核和默认版本是否正常。如果WSL异常执行wsl --update升级内核。重启电脑后再启动Docker Desktop。很多教程默认用户的虚拟化已经开启直接跳到安装步骤结果大量用户卡在这一步。如果你的CPU太老或者Windows版本过旧也可能不支持WSL2这时要么退回WSL1后端要么换机器。5.2 npipe连接失败服务没起来的信号别急着重装报错failed to connect to the docker api at npipe:////./pipe/dockerdesktop-linux意思是Docker CLI连不上Docker Desktop的Linux后端管道。常见场景是开机后Docker Desktop还没完全启动或者后端进程崩溃了。排查步骤看系统托盘里的Docker鲸鱼图标是否还在转圈。如果五分钟都没起来去Windows服务里检查com.docker.service是否在运行。在任务管理器里结束Docker Desktop相关进程重新启动。如果还不行管理员PowerShell执行wsl --shutdown再启动Docker Desktop。检查当前contextdocker context ls确认当前使用的是desktop-linuxdocker context use desktop-linux。这类问题大部分人靠“重启”解决但根本原因往往是WSL2后端意外退出。与其反复重装不如学会看docker context和WSL状态排查链路会清晰很多。5.3 Linux内网离线部署没有外网时镜像怎么传在内网机器上部署Docker没有公网也能完成核心思路是离线传递镜像找一台能联网且CPU架构相同的机器提前docker pull需要的镜像。用docker save -o mysql8.tar mysql:8.0导出镜像文件。将tar包拷贝到内网机器执行docker load -i mysql8.tar导入镜像。导入后正常用docker compose或docker run启动容器。如果连Docker引擎本身都要离线安装就在联网机器上下载docker-ce及其依赖的deb或rpm包再传到内网用dpkg -i或rpm -ivh安装。这个方法在政企机房、金融内网等环境里非常常用也是Docker离线交付的标准做法。5.4 容器起不来时先看日志再动手很多新手启动容器失败第一反应是删了重建其实更应该先看日志。docker logs 容器名能直接看到应用启动时的报错docker inspect能看容器配置和环境变量是否正确docker ps -a看退出状态码很多问题在状态码里就有线索。常见原因无非端口被占用、环境变量缺失、数据卷权限不对。学会按日志定位问题比盲目重建容器高效得多。6. 容器上线之后升级、备份、清理与安全这些养护动作不能省6.1 升级策略全自动watchtower不一定适合你很多人喜欢用watchtower做容器自动升级一条命令就能定期拉新镜像并重建容器docker run -d \ --name watchtower \ -v /var/run/docker.sock:/var/run/docker.sock \ containrrr/watchtower但我不建议无脑全自动升级。对mysql、redis、gitlab这类有状态的中间件一旦镜像大版本变化配置和数据格式可能不兼容自动升级反而坏事。我的做法是区分对待核心服务手动升级步骤是先备份数据再docker compose pull拉新镜像执行docker compose down和docker compose up -d边角服务可以用watchtower但只监控指定容器名避免它把所有服务都动一遍。6.2 备份与恢复先演练一次再放心数据库容器的备份是底线操作。mysql的备份命令docker exec mysql8 sh -c exec mysqldump --all-databases -uroot -p$MYSQL_ROOT_PASSWORD backup.sqlredis的持久化文件直接复制docker cp redis-master:/data/dump.rdb ./dump.rdb数据卷本身的备份可以挂载一个临时容器打包docker run --rm -v mysql_data:/data -v $(pwd):/backup alpine tar czf /backup/mysql_data.tar.gz /data备份做完一定手动恢复一次确认文件可用。我见过太多“备份文件存在但恢复失败”的案例等到真正出事才发现备份是坏的那种绝望感没必要体验。6.3 资源限制与安全基线容器运行一段时间后最容易忽略的是资源和安全。compose里可以用mem_limit限制内存用cpus限制CPU占用避免单个容器拖垮整台机器。日志文件也要限制大小在/etc/docker/daemon.json里配置日志驱动为json-file并设置max-size: 100m、max-file: 3否则日志文件会悄悄吃满磁盘。安全方面不用来路不明的镜像不随意用privileged模式启动容器不把无认证的redis或数据库端口直接映射到公网。Docker的2375管理端口更是要避免暴露否则等于把Docker的控制权交给公网。我个人长期留存的容器其实不多一个mysql、一个redis、一个prometheus加grafana、一个dify加ollama偶尔开一下comfyui。它们共同的特点是稳定运行之后几乎不需要花时间照顾。部署“什么”从来不是目的能长期跑得稳、升级不痛苦、出问题有日志可查这才是2026年把Docker用好的真正标准。如果你年初正打算重新盘点自己的服务器建议少一点“图新鲜”多一点“真正用到生产”先把基础服务养熟再折腾AI工具链。你会发现Docker的乐趣不在于装了多少个应用而在于终于不用反复折腾了。