appexample/app:1.4.2
Runs the image example/app:1.4.2.
Restarts if it stops or after a daemon restart (unless-stopped), but stays down if you stopped it manually.
Docker Compose check · low
By default a container has no resource constraints and can use as much memory and CPU as the host gives it. One leaking or overloaded service can then slow or crash every other service on the machine. The explainer flags, as low, services with none of mem_limit, cpus or deploy.resources.limits.
$ explain docker-compose.yml ! app has no resource limits line 2 fix: see below $
What the free Docker Compose explainer reports on the risky example below.
Docker's documentation states that a container has no resource constraints unless you set them. A memory leak in one service grows until the host runs out.
When the host runs out of memory, the kernel kills processes to recover, and it does not necessarily pick the one that caused the problem.
A limit turns a host-wide outage into a single service that is restarted, which its restart policy and healthchecks can handle.
services:
app:
image: example/app:1.4.2
restart: unless-stopped
services:
app:
image: example/app:1.4.2
restart: unless-stopped
mem_limit: 512m
cpus: 1.0
The risky example is loaded below. Paste your own file to check it for this and every other Docker Compose rule. It runs in your browser; nothing is uploaded.
Parsed in your browser. Nothing is uploaded.
1 service defined: app.
Runs the image example/app:1.4.2.
Restarts if it stops or after a daemon restart (unless-stopped), but stays down if you stopped it manually.
No. Without a limit a container can use as much memory as the host kernel allows.
Either works with Docker Compose, and the explainer accepts both. Pick one style and use it across the file.
The kernel kills a process inside that container. With a restart policy, Docker then restarts it, and the rest of the host is unaffected.