Closed mathstuf closed 4 years ago
The lack of runtime selection it is creating many portability problems at Docker build time. See https://github.com/docker/app/issues/241#issuecomment-437362287
I am not particular how it is implemented, but I would really appreciate using compose v3.X with CUDA GPU containers. My current choice is either DC.yml v2.X files, or Makefiles.
This is likely now OBE given how nvidia has altered nvidia-docker, see #6691
That is... assuming folks were only using runtime
for nvidia-docker...
I was interested in it for OCI hooks personally, but have ended up not going with docker-compose anyways, so this sort of fell off my plate. Guidance for continuing this is over on #6240.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it had not recent activity during the stale period.
Why is it closed?
Why is it closed?
Most of the discussion has moved to #6691 since the API changed with newer versions of docker/nvidia-docker, breaking even v2.3 (without adding deprecated/legacy packages).
Why is it closed?
Most of the discussion has moved to #6691 since the API changed with newer versions of docker/nvidia-docker, breaking even v2.3 (without adding deprecated/legacy packages).
Thanks U
Is there a workaround for this? I'd like to use the runtime parameter to configure specific containers to run with runsc
(gVisor).
Most of the discussion has moved to #6691 since the API changed with newer versions of docker/nvidia-docker, breaking even v2.3 (without adding deprecated/legacy packages).
But what if i want to use another runtime in my docker-compose files? I e.g. am trying to use Kata as my runtime, but would like to use features from v3.x as well. Am stuck with v2.3 to set my runtimes.
v2
and v3
formats are being merged: https://github.com/docker/compose/pull/7588. This should enable you to use runtime
key (for now) in combination with newer features 🙂
PR to support runtime
in v3 spec officially: https://github.com/compose-spec/compose-spec/pull/102
Glad to see some progress on this! Specifying runtime
is a major blocker for us that keeps us on v2.
@leoluk if you try any 1.27.x
release, you will be able to use v2/v3 functionality at the same time (which includes runtime
).
https://github.com/docker/compose/issues/8107
Not sure why this was closed, 1.28 essentially broke this so to speak. We need better documentation on this. Possible related issue
It was closed due to a stalebot (something I, personally, find to be of dubious utility on issues). No idea if upstream actually looks at closed issues with any interest to undo such decisions.
I can use "runtime: sysbox-runc" with docker-compose, using "version: 3.8", on debian/bullseye / backports and ubuntu/jammy.
$ cat docker-compose.yml
version: '3.8'
services:
runner:
image: gitlab/gitlab-runner:alpine
restart: always
runtime: sysbox-runc
...
$ cat /etc/os-release | grep CODENA
VERSION_CODENAME=bullseye
$ docker-compose -v
docker-compose version 1.27.4, build unknown
apt install -t bullseye-backports docker-compose
$ docker-compose -v
docker-compose version 1.29.2, build unknown
$ dpkg -l | grep compose
ii docker-compose 1.29.2-1 all define and run multi-container Docker applications with YAML
By the way, for the people in this thread that might not be aware:
The runtime
service-level key is supported (as documented here) by the Compose Specification (here).
Using Docker Compose V2, with a compose.yaml
that omits the version
top-level key such as:
services:
app:
image: alpine
command: top
runtime: sysbox-runc
this option is respected and passed on to the docker daemon.
Description of the issue
The
runtime
option exists in v2.3, but not v3.x.