Referring to Compose file version 3 reference example:
version: "3.9"
services:
redis:
image: redis:alpine
deploy:
restart_policy:
condition: on-failure
delay: 5s
max_attempts: 3
window: 120s
max_attempts is described as follows:
max_attempts: How many times to attempt to restart a container before giving up (default: never give up). If the restart does not succeed within the configured window, this attempt doesn’t count toward the configured max_attempts value. For example, if max_attempts is set to ‘2’, and the restart fails on the first attempt, more than two restarts may be attempted.
Referring to this a restart only counts to max_attempts if it takes longer than specified in window? I would have expected the other way around. Does someone know more to this?
I also found this question on Github which refers the same, but without answer.
Related
I was looking for delay start of last service in my docker-compose.yml but dont see a sleep option as it needs a restart if it fails on first time including depends_on
for using below restart : on-failure in version 3
version: '3'
restart: on-failure
from releases here see only 2.x but no 3.x ?
https://github.com/docker/compose/releases
In order to deploy our services over docker swarm we use 2 different YAML files:
the base one;
the customized one.
base.yml example:
version: '3.6'
services:
hello-server-api:
image: hello-server
environment:
- ID=1
deploy:
mode: replicated
replicas: 1
update_config:
delay: 50s
restart_policy:
condition: on-failure
max_attempts: 3
customized.yml example:
version: '3.6'
services:
hello-server-api:
deploy:
mode: replicated
replicas: 0
update_config:
delay: 50s
restart_policy:
condition: on-failure
max_attempts: 3
We use the customized YAML file to manage variables from production and the number of replicas for each service.
Here is the Docker command we run to deploy:
docker stack deploy -c base.yml -c customized.yml server
This approach was working correctly on docker-ce 19.03.11, in fact, the docker service is always deployed 0/0.
Upgrading the docker-ce version to 20.10.0 (we also tried 20.10.8) the behavior is changed and the replicas are always 1/1, it seems like it is not possible to set 0 in the customized.yml file.
However, if we put replicas: 2 in the base.yml and replicas: 1 in the customized.yml it is working correctly (it is working properly in every increasing and decreasing scenario, except when 0 value is used in the customized one ).
How can we resolve this problem?
I also encountered this issue in 20.10.8.
This is the corresponding issue: https://github.com/moby/moby/issues/42786
I have the same use case 20.10.8.
Am following docker documentation and trying to create replica of nodes using the link --> https://docs.docker.com/get-started/part3/
I have followed the steps as mentioned in the document but am not able to get the expected application response on curl or browser.
docker decompose file looks like below :
version: "3"
services:
web:
image: vigneshnithin23/restaurant:latest
deploy:
replicas: 2
placement:
constraints: [node.role == manager]
resources:
limits:
cpus: "0.1"
memory: 50M
restart_policy:
condition: on-failure
ports:
- "8090:8090"
networks:
- webnet
networks:
webnet:
As per the documentation they are able to curl the URL. whereas am not able to do the same.
I had two IP address and initialised docker swarm with --advertise-addr - First wlan address
if I run the same code on single container am able to get the desired result.
I went through the question in below link, which was asked earlier but that didn't have proper answer
Website available in standalone container, not in swarm
Any help would be appreciated.
You need to ask yourself whether your SpringBoot app would be able to
run in that constrained environment of 50% usage of the CPU per second
and 50M.
When you run that as a single container[9ms for startup] it is running in a non-constrained environment while in your stack file you are restricting it. So when you spin up the service it takes a longer time to warm up and get started.
Here is a screenshot of the same app by just changing the replica set to '1' and increasing the memory to 100M it takes around 900ms to serve the application & serve the response.
So try to fine tune those settings for resource constraints.
I want a service to be replicated.
This service is replicated on the Worker role, in some cases the service is replicated in the same node twice instead one replication for each node.
I have in my docker-compose.yml
version: "3"
services:
api-test:
# replace username/repo:tag with your name and image details
image: some-image
deploy:
replicas: 2
placement:
constraints:
- node.role == worker
restart_policy:
condition: on-failure
ports:
- "4001:80"
networks:
- some-network
networks:
some-network:
With the HA scheduling strategy introduced in 1.13 (see this PR), this behavior should not be possible from the swarm mode scheduler unless the other nodes are unavailable for scheduling. A node may not be available for scheduling if you have defined a constraint that excludes it, or you have defined resource reservations (CPU and memory) that are not available on the node. I'm not seeing either of those in the compose file you've provided.
One potential issue is the restart policy. This defines a restart policy on individual containers, while you also have swarm mode redeploying containers after an outage. The result could be too many running replicas. Therefore I recommend removing the restart_policy section from your service and letting swarm mode handle the scheduling alone.
Otherwise, the main reason for multiple containers on a node that I've seen is restarting nodes in the cluster. Swarm mode will reschedule services on the still running nodes (or first nodes to restart) and it will not preemptively stop a running task to schedule it on another node once other nodes reconnect. You can force a service to rebalance with the command:
docker service update --force $service_name
That is actually normal behavior for Docker Swarm. You see Swarm chooses nodes to deploy a service based on many criteria (load on each worker, availability, etc.)
So if you wanna make sure a service is replicated on each node with a specific label/role (e.g worker) you should use global mode instead of replicas (see here).
That way your compose file would look like this:
version: "3"
services:
api-test:
# replace username/repo:tag with your name and image details
image: some-image
deploy:
mode: global
placement:
constraints:
- node.role == worker
restart_policy:
condition: on-failure
ports:
- "4001:80"
networks:
- some-network
networks:
some-network:
This will deploy your api-test service exactly once on each worker node.
Recently, I tried upgrading a version 2 docker-compose yaml file to version 3. Specifically, I was going from 2.1 to 3.4. Using docker-compose version 1.18.0 and docker version 18.06.01.
The first attempt caused docker-compose to abort because of the presence of the Version 2 option: mem_limit. Reading these Version 3 docs, it clearly states mem_limit was removed and to see "upgrading" to guide usage away from this option. These instruction tell you to use the deploy section with resources. Making these changes to the docker-compose.yml file and the system started normally.
Unfortunately, I missed the disclaimer in there where it states that deploy is ignored by docker-compose! My question: is there a way to use Compose file reference 3 and docker-compose while still enforcing a container memory limit?
No, there is not.
Between versions 2.x and 3.x...several options have been removed
...mem_limit, memswap_limit: These have been replaced by the resources key under deploy. deploy configuration only takes effect when using docker stack deploy, and is ignored by docker-compose.
See Compose: Upgrading from 2 to 3
And also you don't have to upgrade, you don't even have any reason to upgrade if you don't use swarm.
Sadly in the official docker docs, there is stated
Version 3 (most current, and recommended)
which isn't actually really true, if you use docker-compose without swarm, there is hardly any reason to switch or to use on new project v3. In the official repository you can see comments like this [2][3].
Also in the compatibility-matrix you can see that v2 is still upgraded even when v3 is out for quite some time. And only v1 is marked as deprecated.
Here's an example Docker Compose file version 3.8 with memory limitations:
version: '3.8'
services:
web:
image: nginx:latest
deploy:
replicas: 3
update_config:
parallelism: 2
delay: 10s
restart_policy:
condition: on-failure
resources:
limits:
memory: 256M
ports:
- "80:80"
volumes:
- type: volume
source: myapp-data
target: /var/www/html
networks:
- myapp-net
environment:
- NGINX_HOST=example.com
- NGINX_PORT=80
db:
image: mysql:latest
deploy:
replicas: 1
restart_policy:
condition: on-failure
resources:
limits:
memory: 512M
volumes:
- type: volume
source: myapp-db
target: /var/lib/mysql
networks:
- myapp-net
environment:
- MYSQL_ROOT_PASSWORD=root
- MYSQL_DATABASE=myapp
volumes:
myapp-data:
myapp-db:
networks:
myapp-net: