Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support runtime in v3.x compose files #6239

Closed
mathstuf opened this issue Sep 30, 2018 · 19 comments
Closed

Support runtime in v3.x compose files #6239

mathstuf opened this issue Sep 30, 2018 · 19 comments

Comments

@mathstuf
Copy link

Description of the issue

The runtime option exists in v2.3, but not v3.x.

@bhack
Copy link

bhack commented Nov 9, 2018

The lack of runtime selection it is creating many portability problems at Docker build time. See docker/app#241 (comment)

@xkortex
Copy link

xkortex commented Mar 2, 2019

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.

@qhaas
Copy link

qhaas commented Jul 24, 2019

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...

@mathstuf
Copy link
Author

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.

@stale
Copy link

stale bot commented Jan 20, 2020

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.

@stale stale bot added the stale label Jan 20, 2020
@stale
Copy link

stale bot commented Jan 27, 2020

This issue has been automatically closed because it had not recent activity during the stale period.

@stale stale bot closed this as completed Jan 27, 2020
@EscapeLife
Copy link

Why is it closed?

@qhaas
Copy link

qhaas commented Jan 28, 2020

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).

@EscapeLife
Copy link

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

@khimaros
Copy link

Is there a workaround for this? I'd like to use the runtime parameter to configure specific containers to run with runsc (gVisor).

@robbmue
Copy link

robbmue commented Jul 22, 2020

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.

@EricHripko
Copy link

v2 and v3 formats are being merged: #7588. This should enable you to use runtime key (for now) in combination with newer features 🙂

@AkihiroSuda
Copy link

PR to support runtime in v3 spec officially: compose-spec/compose-spec#102

@leoluk
Copy link

leoluk commented Sep 14, 2020

Glad to see some progress on this! Specifying runtime is a major blocker for us that keeps us on v2.

@EricHripko
Copy link

@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).

@Motophan
Copy link

Motophan commented Feb 8, 2021

#8107

Not sure why this was closed, 1.28 essentially broke this so to speak. We need better documentation on this. Possible related issue

@mathstuf
Copy link
Author

mathstuf commented Feb 9, 2021

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.

@mqu
Copy link

mqu commented Sep 20, 2022

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
  • on debian/bullseye, need to install docker-compose with backports : apt install -t bullseye-backports docker-compose
  • on ubuntu/jammy, work out of the box, with docker-compose version : 1.29.2
$ 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

@laurazard
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.