Docker Compose:把多个容器组织成一个应用
Docker Compose把多个容器组织成一个应用一个 SpringBoot 应用通常不会单独运行。它依赖 MySQL 存数据依赖 Redis 做缓存有的还依赖 RabbitMQ、Elasticsearch 等中间件。上一篇讲了如何把单个应用装进容器但实际开发中你需要同时启动这一整套服务。用docker run逐个启动显然不太方便。Docker Compose 提供了一种更适合多服务应用的管理方式。一个 YAML 文件描述所有服务及其依赖关系一条命令全部启动。目录从单个容器到完整应用环境Compose 和 docker run 的关系Compose 如何描述一个应用环境用 Compose 编排 SpringBoot MySQL Redis服务通信容器之间如何通过服务名访问服务启动依赖与健康检查开发环境中的 Compose 常用操作总结从单个容器到完整应用环境一个典型的 SpringBoot 开发环境至少需要这几个服务同时运行SpringBoot 应用 │ ├── MySQL 存储业务数据 ├── Redis 缓存和会话管理 └── RabbitMQ 消息队列可选手动启动这些服务大致是这样的流程# 启动 MySQLdockerrun-d--namemysql\-p3306:3306\-eMYSQL_ROOT_PASSWORDroot123\-eMYSQL_DATABASEmyapp\-vmysql-data:/var/lib/mysql\mysql:8.0# 启动 Redisdockerrun-d--nameredis\-p6379:6379\redis:7# 启动应用dockerrun-d--namemy-app\-p8080:8080\-eSPRING_DATASOURCE_URLjdbc:mysql://mysql:3306/myapp\-eSPRING_REDIS_HOSTredis\my-app:1.0真正麻烦的是配置分散在命令参数中难以维护和复用。每次修改配置要删掉容器重新创建换台机器又要全部重来。服务之间的启动顺序、网络连接、环境变量配置都靠人记住出错了排查也麻烦。Compose 和 docker run 的关系上一篇用docker run启动单个容器这篇用 Compose 管理多个容器。两者不是替代关系而是适用场景不同。docker run适合一次性操作——快速测试一个镜像、临时跑个工具容器、调试某个服务。它的问题是每条命令只管一个容器多个服务之间的配置全靠命令参数传递没有统一的声明文件。docker compose适合需要多个服务协作的场景——开发环境、集成测试、本地 demo。它的核心价值是把所有服务的配置集中到一个 YAML 文件中用一条命令管理整个应用环境。docker rundocker compose管理范围单个容器多个服务配置方式命令参数YAML 文件网络需手动创建和连接自动创建共享网络启动顺序不支持depends_on适用场景临时测试、单服务开发环境、多服务编排日常开发中两者经常配合使用。用docker run快速验证镜像是否能跑确认没问题后再写进docker-compose.yml。Compose 如何描述一个应用环境Compose 用一个 YAML 文件定义所有服务。核心结构services:服务名:image:镜像名ports:-宿主机端口:容器端口environment:-环境变量值volumes:-卷名:容器内路径几个关键字段services定义所有服务每个服务是一个独立的容器image指定使用的镜像。也可以用build指向 Dockerfile让 Compose 自己构建ports端口映射和docker run -p等价environment环境变量和docker run -e等价volumes数据持久化和docker run -v等价Compose 文件不需要记命令参数所有配置都在一个文件里版本管理也方便。用 Compose 编排 SpringBoot MySQL Redis把前面手动启动的三个服务用 Compose 编排services:mysql:image:mysql:8.0ports:-3306:3306environment:MYSQL_ROOT_PASSWORD:root123MYSQL_DATABASE:myappvolumes:-mysql-data:/var/lib/mysqlredis:image:redis:7ports:-6379:6379command:redis-server--requirepass redis123my-app:image:my-app:1.0ports:-8080:8080environment:SPRING_DATASOURCE_URL:jdbc:mysql://mysql:3306/myappSPRING_DATASOURCE_USERNAME:rootSPRING_DATASOURCE_PASSWORD:root123SPRING_REDIS_HOST:redisSPRING_REDIS_PASSWORD:redis123depends_on:-mysql-redisvolumes:mysql-data:把这个文件保存为docker-compose.yml在同目录下执行dockercompose up-d三个服务同时启动。docker compose down停止并删除所有容器。Redis 通过command覆盖了默认启动命令加上了密码认证。即使是开发环境也不建议跑无密码的 Redis——配置泄露时没有密码就是裸奔。注意environment中数据库连接地址写的是mysql:3306不是localhost:3306。这是因为 Compose 会自动创建一个网络所有服务都在这个网络中可以直接用服务名互相访问。服务通信容器之间如何通过服务名访问手动docker run时如果不在同一个 Docker 网络中容器之间是无法用名称通信的。Compose 会自动创建网络并将所有服务加入同一个网络。在这个网络中每个服务名就是它的主机名。my-app连接 MySQL 时地址写mysql:3306就能连上不需要知道 MySQL 容器的实际 IP。这也是为什么application.yml中的localhost在容器内不生效容器内的 localhost 指向容器自己不是宿主机也不是其他容器。用 Compose 编排时所有依赖服务的地址都应该写服务名。服务启动依赖与健康检查depends_on只保证启动顺序不保证服务就绪。MySQL 容器启动后还需要几秒钟初始化数据库。如果应用在这几秒内尝试连接会报连接失败。my-app:depends_on:-mysql-redis上面的配置只保证 MySQL 容器先启动但不保证 MySQL 已经准备好接受连接。要等服务真正就绪需要配合健康检查mysql:image:mysql:8.0ports:-3306:3306environment:MYSQL_ROOT_PASSWORD:root123MYSQL_DATABASE:myappvolumes:-mysql-data:/var/lib/mysqlhealthcheck:test:[CMD,mysqladmin,ping,-h,localhost]interval:5stimeout:3sretries:10my-app:image:my-app:1.0ports:-8080:8080environment:SPRING_DATASOURCE_URL:jdbc:mysql://mysql:3306/myappSPRING_DATASOURCE_USERNAME:rootSPRING_DATASOURCE_PASSWORD:root123SPRING_REDIS_HOST:redisSPRING_REDIS_PASSWORD:redis123depends_on:mysql:condition:service_healthyredis:condition:service_startedhealthcheck通过mysqladmin ping检测 MySQL 是否就绪。depends_on配合condition: service_healthyCompose 会根据健康检查状态决定是否启动依赖服务后的容器。Redis 启动很快用service_started就够了。MySQL 和 PostgreSQL 这类需要初始化的服务建议都加健康检查。开发环境中的 Compose 常用操作# 启动所有服务后台运行dockercompose up-d# 查看运行状态dockercomposeps# 查看某个服务的日志dockercompose logs my-app# 实时跟踪日志dockercompose logs-fmy-app# 停止所有服务dockercompose down# 停止并删除数据卷慎用会清掉数据库数据dockercompose down-v# 重新构建某个服务的镜像dockercompose build my-app# 重启某个服务dockercompose restart my-app开发中最常用的组合是docker compose up -d启动docker compose logs -f my-app跟踪应用日志docker compose down停止。如果修改了docker-compose.yml需要重新执行docker compose up -dCompose 会自动检测变化并重建受影响的容器。总结Docker Compose 把多个服务的启动、配置和网络连接集中到一个 YAML 文件中。docker compose up -d一条命令启动整套环境docker compose down一条命令全部停止。Compose 自动创建网络容器间用服务名互相访问不需要手动配置 IP。depends_on配合healthcheck可以控制服务启动顺序确保依赖服务就绪后再启动应用。

相关新闻

解决Matplotlib中文字体显示问题的跨平台方案

解决Matplotlib中文字体显示问题的跨平台方案

1. 问题现象与背景分析最近在Ubuntu 20.04和Windows 10双系统环境下做数据可视化时,遇到了一个典型的中英文字体混排显示问题。当使用Matplotlib的pyplot绘制包含中文标签的图表时,要么直接报错,要么中文显示为方框,要么出现字体错…

2026/11/4 17:33:43 阅读更多 →
业务逻辑漏洞:网络安全中的隐形威胁与防御策略

业务逻辑漏洞:网络安全中的隐形威胁与防御策略

1. 为什么业务逻辑漏洞是网络安全中的"隐形杀手"?我第一次真正意识到业务逻辑漏洞的威力,是在一次企业内部的渗透测试中。按照常规思路,我扫描了所有端口、测试了SQL注入和XSS,结果一无所获。正当准备收工时&#xff0c…

2026/10/30 11:18:42 阅读更多 →
GPT-5.6降价与快速模式:大模型成本优化与分级服务技术解析

GPT-5.6降价与快速模式:大模型成本优化与分级服务技术解析

大家好,我是专注于技术分享的博主。最近,AI领域的一个新动态引起了广泛关注:GPT-5.6模型在定价策略上做出了重大调整,并引入了新的“快速模式”。这不仅仅是价格变化,更可能预示着大模型服务在成本优化、性能分级和开发…

2026/11/5 2:27:03 阅读更多 →

最新新闻

Electron桌面应用开发实战:从环境搭建到打包发布全流程

Electron桌面应用开发实战:从环境搭建到打包发布全流程

做前端这些年,我大部分时间都在跟浏览器标签页打交道,直到第一次把桌面应用跑起来,才发现原来自己一直被限制在地址栏和刷新按钮围起来的框框里。Electron这个词,最开始是在某段时间频繁出现在同事的讨论里,一个用HTML…

2026/11/6 15:21:35 阅读更多 →
滑盖智能锁T109深度解析:结构原理、安装调试与故障排查

滑盖智能锁T109深度解析:结构原理、安装调试与故障排查

简介:亚太天能T109滑盖智能锁产品说明书是一份PDF格式的官方技术文档,主要面向智能锁安装人员、终端用户及售后维护者,帮助快速掌握产品安装、配置与常见故障处理。全包仅1个PDF文件,大小4.37MB,内容结构清晰&#xff…

2026/11/7 12:08:40 阅读更多 →
PMSM弱磁控制原理与Simulink建模:高速AGV驱动系统设计指南

PMSM弱磁控制原理与Simulink建模:高速AGV驱动系统设计指南

上个月我在调试一台高速AGV的驱动系统,整车要求空载跑到8m/s,电机转速已经拉到额定点,驱动器的输出电压也顶到了母线电压极限附近。再往上踩速度指令,转速纹丝不动,三相电流反而开始震荡。那会儿我的第一反应就是&…

2026/11/6 22:01:11 阅读更多 →
C++核心知识点:从内存管理到STL的实战指南

C++核心知识点:从内存管理到STL的实战指南

C 这门语言我前前后后折腾了十几年,用它写过嵌入式驱动、做过游戏服务端,也搭过基础组件库。每次看到新人一头扎进"C 核心知识点"这个搜索词,我其实挺感慨的——这门语言的难点从来不是语法多,而是知识点之间的耦合太深…

2026/11/6 22:01:11 阅读更多 →
T109滑盖智能锁怎么装?安装调试与故障排查全攻略

T109滑盖智能锁怎么装?安装调试与故障排查全攻略

简介:亚太天能T109滑盖智能锁产品说明书以PDF格式发布,适合智能锁用户、安装人员与售后维修人员阅读。内容围绕T109系列指纹密码刷卡锁展开,先介绍前面板、后面板、锁体、机械钥匙、电池盒盖等部件名称与功能,再给出完整安装步骤&…

2026/11/7 12:08:40 阅读更多 →
LLM知识降熵:从信息垄断到理解权下放

LLM知识降熵:从信息垄断到理解权下放

你有没有过这种经历:翻开源码注释、论文摘要或者一份专业报告,每个字都认识,连在一起却像天书。想找人聊聊,身边要么没人懂,要么懂的懒得跟你解释。后来我试着把同一段内容丢给一个大语言模型,几秒钟之后&a…

2026/11/6 22:01:09 阅读更多 →

日新闻

周新闻

月新闻