[Fix] Configure resource limits to fix development server timeout#93
[Fix] Configure resource limits to fix development server timeout#93
Conversation
📝 WalkthroughWalkthroughResource constraints are added to the Docker Compose configuration for the backend and redis services, specifying CPU and memory limits and reservations to define resource boundaries for container execution. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@docker/docker-compose.yml`:
- Around line 13-20: The compose uses deploy.resources.reservations which Docker
Compose (non‑Swarm) ignores; update the services that have
deploy.resources.limits/reservations to also set service‑level resource keys
(add mem_limit, mem_reservation, and cpus under each service alongside the
existing deploy section) so reservations are enforced during docker compose up,
or alternatively change deployment to use swarm mode (use docker stack deploy)
if you intend to rely on deploy.resources.reservations; apply the same change
for the other service that has a reservations block.
| deploy: | ||
| resources: | ||
| limits: | ||
| cpus: '0.80' | ||
| memory: 768M | ||
| reservations: | ||
| cpus: '0.20' | ||
| memory: 256M |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, examine the docker-compose.yml structure and context
cat -n docker/docker-compose.yml | head -50Repository: Team-PIDA/Pida-Server
Length of output: 1376
🏁 Script executed:
# Check for any deployment scripts or documentation
find . -type f \( -name "*.md" -o -name "*.txt" -o -name "Makefile" -o -name "*.sh" \) | head -20Repository: Team-PIDA/Pida-Server
Length of output: 381
🏁 Script executed:
# Search for references to docker compose deployment strategy
rg -i "docker.*stack\|docker.*compose\|swarm" --max-count=20Repository: Team-PIDA/Pida-Server
Length of output: 47
🌐 Web query:
Docker Compose deploy.resources non-Swarm mode behavior compatibility flag
💡 Result:
deploy.*is part of the Compose Specification, but it’s primarily a “platform/orchestrator” section. In practice,docker stack deploy(Swarm) is the environment where alldeploysemantics are intended to apply (replicas, update/rollback policies, placement, etc.). (docs.docker.com)- In non‑Swarm mode (
docker compose up) the only widely useful/implemented piece ofdeployisdeploy.resources(resource limits). Docker documentsdeploy.resourcesas constraints (limits/reservations) in the spec, but what actually gets enforced locally depends on the Compose implementation/version. (docs.docker.com) - What the
--compatibilityflag is for: historically (Compose v1 era),--compatibilitymadedocker-composereaddeployand translate a small subset into non‑Swarm runtime options—notably resource limits / memory reservations, replicas, and parts of restart_policy; everything else was ignored (often with warnings). (docs4dev.com) - In Compose v2,
--compatibilityis no longer “the” way to get resource limits fromdeploy—it’s described as deprecated for YAML-field migration, and it also has behavior around name formatting to match v1 expectations. (docs.docker.com)
So, if your goal is “make deploy.resources work in non‑Swarm”:
- On older
docker-compose(v1), you generally neededdocker-compose --compatibility upto havedeploy.resourcestranslated into local container limits. (docs4dev.com) - On modern
docker compose(v2), resource limits may already be honored without--compatibility, but many otherdeploykeys still won’t behave like Swarm (because there’s no orchestrator). (docs.docker.com)
Citations:
- 1: https://docs.docker.com/reference/compose-file/deploy/?utm_source=openai
- 2: https://docs.docker.com/reference/compose-file/deploy/?utm_source=openai
- 3: https://www.docs4dev.com/docs/docker/18.09/compose/compose-file/compose-versioning/index.html?utm_source=openai
- 4: https://docs.docker.com/compose/migrate/?utm_source=openai
- 5: https://www.docs4dev.com/docs/docker/18.09/compose/compose-file/compose-versioning/index.html?utm_source=openai
- 6: https://docs.docker.com/reference/compose-file/deploy/?utm_source=openai
🏁 Script executed:
# Check README for deployment guidance
cat README.md | grep -i "docker\|compose\|deploy\|version" -A 3 -B 1Repository: Team-PIDA/Pida-Server
Length of output: 47
🏁 Script executed:
# Look for .github workflows or CI files that might indicate Docker version
fd "\.yml|\.yaml" .github/workflows 2>/dev/null | head -10 | xargs cat 2>/dev/null | grep -i "docker\|compose\|version" | head -20Repository: Team-PIDA/Pida-Server
Length of output: 979
🏁 Script executed:
# Check Dockerfile for version hints
fd "Dockerfile" | head -5 | xargs cat 2>/dev/null | head -30Repository: Team-PIDA/Pida-Server
Length of output: 597
🏁 Script executed:
# Search for any requirements or configuration files mentioning docker/compose versions
rg "docker.*compose|compose.*version" --type yml --type yaml --type json --max-count=10Repository: Team-PIDA/Pida-Server
Length of output: 92
🌐 Web query:
Docker Compose v2 deploy.resources non-Swarm local mode enforcement 2024 2025
💡 Result:
In Docker Compose v2 (local / non‑Swarm mode), deploy.resources is partially applied:
deploy.resources.limitsis enforced (Compose translates it into the container runtime’s hard limits, e.g., cgroup CPU/memory caps). Docker’s Compose Deploy spec defineslimitsas “the platform must prevent the container from allocating more resources.” [1]deploy.resources.reservationsis generally not enforced in local Compose (no scheduler/orchestrator to “guarantee” capacity). This is a long-standing Compose behavior/bug report: reservations “has no effect in NON SWARM mode,” while limits do. [2]- More broadly, local
docker composedoes not deploy across a Swarm (all containers run on the current node). To use Swarm’s deployment semantics, usedocker stack deploy. [3]
Implication for 2024–2025: if you need hard enforcement in local Compose, rely on deploy.resources.limits; don’t expect reservations to be honored unless your target platform/orchestrator implements it.
Sources:
[1] Docker Docs – Compose Deploy Specification (resources.limits / resources.reservations) (docs.docker.com)
[2] docker/compose issue #10046 – reservations no effect in non‑Swarm (github.com)
[3] Docker Docs – “Deploy a stack to a swarm” (Compose doesn’t use swarm; use docker stack deploy) (docs.docker.com)
Citations:
- 1: https://docs.docker.com/reference/compose-file/deploy/?utm_source=openai
- 2: [BUG] Resources reservations has no effect in v3 for non swarm docker/compose#10046
- 3: https://docs.docker.com/engine/swarm/stack-deploy/?utm_source=openai
deploy.resources.reservations won't be enforced in non‑Swarm Compose mode.
While deploy.resources.limits are correctly applied by Docker Compose v2, deploy.resources.reservations are ignored without a Swarm orchestrator. Since this is meant to fix development timeouts, if resource reservations matter for your use case, add service-level keys (mem_limit, mem_reservation, cpus) alongside the deploy section, or ensure the dev workflow uses docker stack deploy instead of docker compose up.
💡 Suggested adjustment for enforcing reservations in non‑Swarm Compose
services:
backend:
image: ${IMAGE_FULL_URL}
container_name: ${DOCKERHUB_IMAGE_NAME}
restart: always
environment:
- TZ=Asia/Seoul
network_mode: host
env_file:
- ~/.env
depends_on:
- redis
deploy:
resources:
limits:
cpus: '0.80'
memory: 768M
reservations:
cpus: '0.20'
memory: 256M
+ mem_limit: 768M
+ mem_reservation: 256M
redis:
image: redis:7.2-alpine
container_name: p-local-redis
command: [ "redis-server", "/usr/local/etc/redis/redis.conf" ]
network_mode: "host"
volumes:
- /opt/redis/data:/data
- /opt/redis/redis.conf:/usr/local/etc/redis/redis.conf:ro
environment:
- TZ=Asia/Seoul
restart: unless-stopped
healthcheck:
test: [ "CMD", "redis-cli", "PING" ]
interval: 5s
timeout: 3s
retries: 10
deploy:
resources:
limits:
cpus: '0.20'
memory: 64M
reservations:
cpus: '0.10'
memory: 32M
+ mem_limit: 64M
+ mem_reservation: 32MAlso applies to: 37-44
🤖 Prompt for AI Agents
In `@docker/docker-compose.yml` around lines 13 - 20, The compose uses
deploy.resources.reservations which Docker Compose (non‑Swarm) ignores; update
the services that have deploy.resources.limits/reservations to also set
service‑level resource keys (add mem_limit, mem_reservation, and cpus under each
service alongside the existing deploy section) so reservations are enforced
during docker compose up, or alternatively change deployment to use swarm mode
(use docker stack deploy) if you intend to rely on
deploy.resources.reservations; apply the same change for the other service that
has a reservations block.
char-yb
left a comment
char-yb
left a comment
There was a problem hiding this comment.
LGTM
이런 옵션이 있을 줄 몰랐는데, 첨알았네요👍
2 participants
🌱 관련 이슈
📌 작업 내용 및 특이 사항
📝 참고
📌 체크 리스트
Summary by CodeRabbit
Release Notes