Closed andreagalle closed 1 year ago
Hi @andreagalle the test is probably just missing the correct value, since services, stacks and swarm hasn't really been inclued.
will have a look
I can see from your sources, the check is made on the containers, where in fact the MaximumRetryCount
property is 0
in my case too.
[root@172 test]# docker inspect --format MaximumRetryCount='{{ .HostConfig.RestartPolicy.MaximumRetryCount }}' 27a2ef894e2b
MaximumRetryCount=0
[root@172 test]# docker inspect --format MaximumRetryCount='{{ .HostConfig.RestartPolicy.MaximumRetryCount }}' 49d09a6bd0fd
MaximumRetryCount=0
Is it more correct to set it for containers too, rather than for services (as I am doing right now) or better for you to check both the container and the corresponding service property, replacing the above lines with the following one?
cpolicy=$(docker inspect --format MaximumRetryCount='{{ .HostConfig.RestartPolicy.MaximumRetryCount }}' "$c")
spolicy=$(docker inspect --format MaxAttempts='{{ .Spec.TaskTemplate.RestartPolicy.MaxAttempts }}' "$s")
if [ "$cpolicy" != "MaximumRetryCount=5" ] || [ "$spolicy" != "MaxAttempts"=5" ]; then
where $s
is the list of services as well as $c
is the one for containers.
yeah, the last example is what i was going for
want to write a PR?
but note that you need to exclude any service containers from $c
as well
for id in $(docker inspect $(docker ps -qa) --format '{{ .Id }}'); do if [ "$id" = "$(docker inspect $(docker service ps -q issue521_working-test) --format '{{ .Status.ContainerStatus.ContainerID }}')" ]; then echo "the container is actually a service"; fi ; done
yeah, the last example is what i was going for
want to write a PR?
Yes, I will!
Chatting with chatGPT it seems there's no workaround to set the MaximumRetryCount
at container level from the stack file.
"The
MaximumRetryCount
property is a property of theRestartPolicy
within theHostConfig
of a container. You can set this property when starting a container using the--restart
flag with the docker run command. For example, to set theMaximumRetryCount
to 5 for a container, you would use the commanddocker run --restart=on-failure:5 [image_name]
.However, when using Docker Compose and swarm mode, you cannot directly set the
MaximumRetryCount
property for individual containers. Instead, you can set themax_attempts
property of therestart_policy
within thedeploy
key in yourstack-file.yml
, which will apply to all containers created for that service .In Docker Compose and swarm mode, the
restart_policy
is specified at the service level within thedeploy
key in thestack-file.yml
. This means that the restart policy applies to all containers created for that service. Themax_attempts
property of therestart_policy
specifies the maximum number of times to restart a container before giving up .The
MaximumRetryCount
property of theRestartPolicy
within theHostConfig
of a container is not directly settable in Docker Compose and swarm mode because it is not part of the service-level configuration. Instead, you can use themax_attempts
property of therestart_policy
to achieve similar functionality."
All this sounds correct to me. Didn't find any docs talking about how to setup this container property from the stack file.
@konstruktoid I made it! #522
but note that you need to exclude any service containers from
$c
as well
for id in $(docker inspect $(docker ps -qa) --format '{{ .Id }}'); do if [ "$id" = "$(docker inspect $(docker service ps -q issue521_working-test) --format '{{ .Status.ContainerStatus.ContainerID }}')" ]; then echo "the container is actually a service"; fi ; done
Thanks for the clarification on checking whether the container was part of a service or not. I followed another path. However, I think it is worth mentioning that (there are a couple lines of comment there) the container Name is not checked against the service Name only, but the task_id
is compared between the two, providing for better consistency. I mean:
# a container name could arbitrary include a service one: it belongs to a service (created by Docker
# as part of the service), if the container task ID matches one of the task IDs of the service.
Maybe the warn message, could then be more precise:
warn " * MaximumRetryCount is not set to 5: $c"
telling whether it is the container or the service (or both!) not having the property properly set, but then I though it might be a little out of scope. I was wondering if it would be correct to provide such an information on the 5_container_runtime.sh
module.
I keep getting the false positive below (in section 5.14 of you report) running the v1.5.0
docker-bench-security.sh
script on my enveven if the
MaximumRetryCount
is properly configured (or better. the"MaxAttempts"
one)and working as expected:
I made couple tests on the following Docker images (below everything to reproduce this issue):
first service (working one) is built from the Dockerfile below:
second service (crashing one) is built from the Dockerfile below:
The two services are deployed, from the following
stack-file.yml
to docker swarm, with this command:
What's wrong with the above configuration, or rather with the
docker-bench-security.sh
utility, when it checks for theMaximumRetryCount
that seems to me properly configured and working as expected? Maybe this is just an issue of misalignment between these two properties?MaximumRetryCount
MaxAttempts
I am using Docker version 23.0.1: