Docker Compose 怎样给服务设置资源限制

Docker Compose 给服务设置资源限制，核心不是在宿主机上临时执行一条命令，而是在目标服务的 deploy.resources.limits 下声明边界。常见字段是 cpus、memory 和 pids；如果还要表达调度时希望得到的最低资源，可以另外写 reservations。下面用服务 api 演示一套可读、可回退的配置路径。

Docker 官方地址：https://docs.docker.com/reference/compose-file/deploy/

最小可用写法是把限制放在目标服务的 deploy.resources.limits 中，例如 CPU 写 0.50、内存写 512M、进程数写 128。限制和预留不是同一个概念：前者是平台不应允许超过的上限，后者是平台应尽量保证的最低资源。

先找到服务资源设置入口

在配置工作区中，先从左侧项目树进入 应用配置 → compose 文件 → 服务列表，再点击目标服务 api。右侧设置面板应显示“服务资源”，并把“限制”和“预留”分成两个区域。这里的界面是帮助理解字段位置的原创操作示意图，不是 Docker Desktop、编辑器或浏览器的真实截图。

1. 打开项目的 Compose 配置文件。
2. 在服务列表中选择 api，不要误选数据库或反向代理服务。
3. 进入 服务资源 → 限制，先记录需要控制的 CPU、内存和进程数。

Compose Deploy Specification 把资源配置放在 deploy.resources 下，其中 limits 表示上限，reservations 表示最低资源要求。不要把预留值当成容器一定会持续占用的配额，也不要只改界面字段而忘记保存到 Compose 文件。

填写 CPU、内存和 PID 限制

进入 服务资源 → 限制 后，给 api 填入本次示例值：CPU 上限 0.50，内存上限 512M，PID 上限 128。这些值只是演示字段写法，生产值应根据服务实际负载、宿主机容量和平台约束决定。

services:
  api:
    image: example/api:stable
    deploy:
      resources:
        limits:
          cpus: "0.50"   # 限制最多使用约半个 CPU 核心
          memory: 512M    # 限制容器可分配的内存上限
          pids: 128       # 限制容器可创建的进程数量
        reservations:
          cpus: "0.25"    # 声明调度时希望得到的 CPU 资源
          memory: 256M    # 声明调度时希望得到的内存资源

配置文件是严格的 YAML，缩进决定字段层级。resources 必须属于目标服务的 deploy，不能和 image、ports 同级后再随意放一个 limits。如果只需要上限，可以暂时省略 reservations，但不要把两类字段混写成一个“资源值”。

在界面中完成填写后，依次点击 资源限制 → CPU、资源限制 → 内存、资源限制 → 进程数，最后点击 应用配置。这里的按钮路径对应的是原创配置工作区的教学布局，实际使用时以你选择的 Compose 编辑工具为准。

保存后确认字段落在正确服务下

保存不是只看绿色提示。先回到 YAML 编辑区，确认 deploy.resources.limits 仍然位于 services.api 下面；再在资源摘要中对照 CPU、内存和 PID 三项。第二张图展示的是“配置已保存”的说明状态，右侧的使用率仅用于说明界面层级，不能当成本机运行数据。

1. 点击 应用配置 → 保存，等待界面显示“配置已保存”。
2. 打开 服务 → api → 资源摘要，核对 CPU 上限、内存上限和 PID 上限。
3. 回看 Compose 文件，确保没有把字段写到了 web、db 或其他服务下。

如果项目使用的 Compose 实现或部署平台对 Deploy Specification 的支持范围不同，界面能保存字段并不自动等于运行时会施加同样的约束。应把“文件结构正确”和“目标平台支持并应用”分成两个判断，避免看到配置被保存就直接推断限制已经生效。

不生效时按配置层级排查

先看最容易出错的三点：服务名是否正确、缩进是否正确、字段是否放在 deploy.resources.limits 下。下面这个错误示例把 limits 放到了服务根部，界面可能仍能显示文本，但它不是本文所用的资源字段层级。

services:
  api:
    image: example/api:stable
    limits:              # 错误示例：不要把 limits 放在服务根部
      memory: 512M       # 正确位置应是 deploy.resources.limits.memory

然后检查目标服务最终使用的 Compose 文件和覆盖文件。多文件合并时，先确认当前命令引用了哪一组文件，再确认 api 没有在后续文件中被覆盖。不要为了掩盖字段问题直接删除整个服务或清理宿主机数据。

回退时保留服务定义和镜像配置，只移除本次新增的 deploy.resources.limits，并重新保存 Compose 文件。若同时写过预留值，也要按变更记录决定是否一起删除；不要把回退动作扩大成删除容器、卷或网络。

常见疑问

CPU 的 0.50 是百分比吗？

不是。Docker 文档把 cpus 表述为可使用的 CPU 资源数量，示例中的 0.50 更接近半个 CPU 核心的配置表达，不应当直接当作“50% 的所有机器性能”。实际可用范围仍受平台和宿主机资源影响。

limits 和 reservations 必须同时写吗？

不必须。只想控制上限时可以只写 limits；需要表达调度最低资源时再写 reservations。两者的用途不同，不能用预留值代替上限。

保存后就能证明限制生效了吗？

不能。保存只能证明 Compose 文件或配置工作区接收了字段。是否真正施加限制，还取决于使用的 Compose 实现和部署环境；应根据对应平台提供的运行状态、资源信息或文档规则另行确认。

这套配置可以压缩成一个顺序：选对服务，进入 deploy.resources，把上限写入 limits，需要最低资源时再写 reservations，保存后同时检查 YAML 层级和平台支持范围。这样既能完成 Docker Compose 的资源设置，也能避免把界面提示误读成运行时证据。

参考：https://docs.docker.com/reference/compose-file/deploy/