One of the containers in my swarm needs to use a specific runtime value (the equivalent of the —runtime argument in the Docker run command). Is there a way to specify this value in the docker-compose.yml file?
You can use docker configs. Something like this:
services:
service-name:
image: [image-name]:[tag]
deploy:
replicas: 2
configs:
- my_config
configs:
my_config:
file: ./my_config.txt
By default, the container can access the config from “/my_config”
Hi sonicsea,
Thanks for the suggestion. From what I can tell, this only exposes a file in the container’s file system which you can then use for configuration purposes. It doesn’t look like I would be able to set the container’s runtime. Just to clarify, in my compose file, I need to recreate something like this:
docker run --runtime=nvidia nvidia/cuda /bin/bash
Thanks
Hey sanlabkevin, did you ever find out if this is possible? I haven’t been able to find any way to do this.
Hi. Not sure if it works for all cases but it worked for mine. I had to run a container using the nvidia runtime (--runtime=nvidia
) inside the swarm.
You can specify the default runtime for the container using the /etc/docker/daemon.json
(in ubuntu). In my case it looks like the following:
{
"runtimes": {
"nvidia": {
"path": "nvidia-container-runtime",
"runtimeArgs": []
}
},
"default-runtime": "nvidia"
}
Everything works well after restarting the docker (sudo systemctl restart docker.service
).
@vasniktel this would change the runtime entirely (if it even works with the swarm mode)
The --runtime
argument for docker run
in fact has a docker-compose representation, but it is only available in the v2.3 and v2.4 schema and only valid for “plain docker container”.
The orignal post was asking for a docker-compose.yml declaration for a swarm service with a feature that is not available for them. The v3+ schema lacks this configuration item entirely. It is not even properly addressed in the epic that lists the supported swarm features, just listed as --runtime
in the docker run
column without any details.
So the short answer:
– as a docker-compose deployment with a v2.3/2.4 schema: yes
– as a docker stack deploy
deployment with a v3+ schema: no