Docker通过cgroups自动管理容器资源限制，--cgroup-parent可将容器纳入指定父cgroup（如systemd slice）继承其MemoryMax、CPUQuota等策略，但需注意v1/v2兼容性、权限及生效优先级。
直接在 docker run 中指定资源参数，Docker 会自动为容器创建对应 cgroup 子路径，并将其进程加入其中——你不需要、也不应该手动指定或修改父级 cgroup 路径。所谓“配置父级资源限制”，本质是让容器归属于某个已存在的、带资源策略的 cgroup（例如 systemd slice 或自定义 cgroup），从而继承其上限或权重。这在混合部署、服务分级或与 systemd 深度集成的场景中很实用。
用 systemd slice 统一管控容器资源（推荐）
如果你的宿主机使用 systemd（绝大多数现代 Linux 发行版默认），Docker 容器可天然纳入 systemd 的资源控制体系：
- 启动容器时加
--cgroup-parent=myservice.slice，容器进程就会归属到myservice.slice下，受该 slice 的MemoryMax、CPUQuotaSec等设置约束 - 先创建 slice：
sudo systemctl set-property myservice.slice MemoryMax=2G CPUQuota=50% - 再运行容器：
docker run -d --cgroup-parent=myservice.slice --name app1 nginx - 验证：进容器查
/proc/1/cgroup，看是否出现在myservice.slice路径下；宿主机上执行systemctl status myservice.slice可查看实时资源占用
手动挂载并指定自定义 cgroup 父路径（需 root + cgroup v2）
适用于需要精细分层控制、或绕过 systemd 的场景（如某些嵌入式或定制化环境）：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 确保系统启用 cgroup v2：
mount | grep cgroup2应显示挂载点（如/sys/fs/cgroup） - 手动创建父 cgroup：
sudo mkdir /sys/fs/cgroup/myapp - 设资源上限：
echo "1G" | sudo tee /sys/fs/cgroup/myapp/memory.max，echo "50000 100000" | sudo tee /sys/fs/cgroup/myapp/cpu.max - 运行容器：
docker run -d --cgroup-parent=myapp --name demo alpine sleep 3600 - 注意：Docker 不会为你自动清理该父目录；容器退出后，需手动
rmdir或由上层编排工具管理生命周期
避免踩坑的关键细节
配置父级 cgroup 时容易忽略但影响实际效果的点：
-
不能混用 v1/v2：如果系统启用了 cgroup v2（
systemd.unified_cgroup_hierarchy=1），就不要尝试往/sys/fs/cgroup/cpu/这类 v1 路径写值，否则无效甚至报错 - 权限与命名规范：cgroup 路径名只能含字母、数字、下划线、短横线；父路径必须由 root 创建且对 docker daemon 可读写
-
优先级覆盖逻辑：若同时设置了
--cgroup-parent和--memory=512m，Docker 仍会把memory.max写入容器自己的子 cgroup，但最终生效的是更严格的那个值（父级或容器级取小者） -
不支持 swarm deploy：
--cgroup-parent是docker run级别参数，compose 的deploy.resources或 swarm service create 均不支持该字段
真正起作用的是 cgroup 文件里的数值，不是 Docker 启动命令本身。跑起来之后，务必进容器或查宿主机 /sys/fs/cgroup/xxx/xxx 下的原始文件确认 memory.max、cpu.max 是否已按预期写入。
