在Docker 19.03.0 Beta 2下,以新的CLI API --gpus的形式引入了对NVIDIA GPU的支持。 https://github.com/docker/cli/pull/1714讨论此启用。
现在,只需为GPU加速的基于Docker的应用程序传递--gpus选项。
$ docker run -it --rm --gpus all ubuntu nvidia-smi
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
f476d66f5408: Pull complete
8882c27f669e: Pull complete
d9af21273955: Pull complete
f5029279ec12: Pull complete
Digest: sha256:d26d529daa4d8567167181d9d569f2a85da3c5ecaf539cace2c6223355d69981
Status: Downloaded newer image for ubuntu:latest
Tue May 7 15:52:15 2019
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.116 Driver Version: 390.116 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla P4 Off | 00000000:00:04.0 Off | 0 |
| N/A 39C P0 22W / 75W | 0MiB / 7611MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
:~$
到目前为止,Compose不支持此功能。 这是一项功能请求,用于使Compose支持NVIDIA GPU。
既然(现在)旧版的'nvidia runtime'似乎在Docker 19.03.0和nvidia-container-toolkit-1.0.0-2
中被破坏了,这变得越来越重要: https :
$ cat docker-compose.yml
version: '2.3'
services:
nvidia-smi-test:
runtime: nvidia
image: nvidia/cuda:9.2-runtime-centos7
$ docker-compose run nvidia-smi-test
Cannot create container for service nvidia-smi-test: Unknown runtime specified nvidia
这有效: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
这不是: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
有什么工作要做吗?
我在新的Ubuntu 18.04 LTS计算机上获得了新的Docker CE 19.03.0,具有当前和匹配的NVIDIA Container Toolkit(néenvidia-docker2)版本,但无法使用它,因为docker-compose.yml 3.7不支持--gpus
标志。
有没有解决方法?
这有效:
docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
这不是:
docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
你需要
{
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
}
}
在您的/etc/docker/daemon.json
为--runtime=nvidia
继续工作。 更多信息在这里。
ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone。 这事有进一步更新吗?
迫切需要。 感谢你的付出!
是否打算让用户在迁移到docker> = 19.03
并删除nvidia-docker2
来使用nvidia-container-toolkit
之后手动填充/etc/docker/daemon.json
?
看来这破坏了许多安装。 特别是,由于--gpus
在compose
不可用。
不,这是一种解决方法,直到compose支持gpus标志。
安装nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
添加到/etc/docker/daemon.json
{
“运行时间”:{
“ nvidia”:{
“ path”:“ / usr / bin / nvidia-container-runtime”,
“ runtimeArgs”:[]
}
}
}
码头工人组成:
运行时:nvidia
环境:
-NVIDIA_VISIBLE_DEVICES =全部
不再有“ / usr / bin / nvidia-container-runtime”之类的东西。 问题仍然很关键。
它将有助于通过docker-compose运行nvidia环境,直到修复docker-compose
安装nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
添加到/etc/docker/daemon.json
{
“运行时间”:{
“ nvidia”:{
“ path”:“ / usr / bin / nvidia-container-runtime”,
“ runtimeArgs”:[]
}
}
}码头工人组成:
运行时:nvidia
环境:
- NVIDIA_VISIBLE_DEVICES =全部
这对我不起作用,尝试运行docker-compose up
时仍会获得Unsupported config option for services.myservice: 'runtime'
docker-compose up
有任何想法吗?
这对我不起作用,尝试运行
docker-compose up
时仍会获得Unsupported config option for services.myservice: 'runtime'
docker-compose up
有任何想法吗?
修改/etc/docker/daemon.json后,重启docker服务
systemctl重新启动docker
使用Compose格式2.3并将运行时:nvidia添加到您的GPU服务。 Docker Compose必须为1.19.0或更高版本。
docker-compose文件:
版本:“ 2.3”
服务:
nvsmi:
图片: ubuntu:16.04
运行时:nvidia
环境:
-NVIDIA_VISIBLE_DEVICES =全部
命令:nvidia-smi
@cheperuiz ,您可以在daemon.json中将nvidia设置为默认运行时,而不依赖于docker-compose。 但是您所有的Docker容器都将使用nvidia运行时-到目前为止,我还没有问题。
{
"default-runtime": "nvidia",
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
},
}
啊! 谢谢@Kwull ,我错过了default-runtime
部分...现在一切正常:)
@uderik , runtime
不再存在于当前的3.7撰写文件格式架构中,也不再存在于最终应与Docker 19.03保持一致的未决3.8版本中: https :
@johncolby runtime
从来不是3.x标志。 它仅出现在2.x轨道(2.3和2.4)中。
是的,我知道,即使我的docker-compose.yml文件包含version: '2.3'
(在过去有效),它似乎也被最新版本所忽略...
对于将来的项目,启用/禁用对GPU的访问的正确方法是什么? 只是使其成为默认+ env变量? 还是会支持--gpus
标志?
@johncolby在3.X中替换runtime
是什么?
@ Daniel451我一直在外围关注,但看起来它会在generic_resources
键下,类似:
services:
my_app:
deploy:
resources:
reservations:
generic_resources:
- discrete_resource_spec:
kind: 'gpu'
value: 2
(来自https://github.com/docker/cli/blob/9a39a1/cli/compose/loader/full-example.yml#L71-L74)
在此处设计文档: https :
这是关于compose 3.8模式支持的compose问题,该问题已合并在: https :
在守护程序方面,可以通过将gpu
功能包含在daemon.json
或dockerd
CLI中(例如以前的硬编码运行时解决方法)来注册该功能。
/usr/bin/dockerd --node-generic-resource gpu=2
然后通过挂接到NVIDIA docker实用程序进行注册:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go
看来机器已经基本到位,可能只需要记录在案...
任何更新?
还等待更新,将bash
与docker run --gpus
直到正式修复...
等待更新。
也正在等待更新:)
好的...我不明白为什么它仍然打开。 这3条额外的行使其可以与架构版本3.7一起使用。 很高兴知道码头工人对琐碎的社区问题做出了回应。 因此,克隆此存储库,添加这三行,然后python3 setup.py build &&安装它,并确保您的docker-compose.yml是3.7版。
[ruckc<strong i="6">@omnilap</strong> compose]$ git diff
diff --git a/compose/config/config_schema_v3.7.json b/compose/config/config_schema_v3.7.json
index cd7882f5..d25d404c 100644
--- a/compose/config/config_schema_v3.7.json
+++ b/compose/config/config_schema_v3.7.json
@@ -151,6 +151,7 @@
"external_links": {"type": "array", "items": {"type": "string"}, "uniqueItems": true},
"extra_hosts": {"$ref": "#/definitions/list_or_dict"},
+ "gpus": {"type": ["number", "string"]},
"healthcheck": {"$ref": "#/definitions/healthcheck"},
"hostname": {"type": "string"},
"image": {"type": "string"},
diff --git a/compose/service.py b/compose/service.py
index 55d2e9cd..71188b67 100644
--- a/compose/service.py
+++ b/compose/service.py
@@ -89,6 +89,7 @@ HOST_CONFIG_KEYS = [
'dns_opt',
'env_file',
'extra_hosts',
+ 'gpus',
'group_add',
'init',
'ipc',
@@ -996,6 +997,7 @@ class Service(object):
dns_opt=options.get('dns_opt'),
dns_search=options.get('dns_search'),
restart_policy=options.get('restart'),
+ gpus=options.get('gpus'),
runtime=options.get('runtime'),
cap_add=options.get('cap_add'),
cap_drop=options.get('cap_drop'),
我只是添加了一个内部问题来跟踪该问题。
请记住,PR是受欢迎的:smiley:
好的...我不明白为什么它仍然打开。 这3条额外的行使其可以与架构版本3.7一起使用。 很高兴知道码头工人对琐碎的社区问题做出了回应。 因此,克隆此存储库,添加这三行,然后python3 setup.py build &&安装它,并确保您的docker-compose.yml是3.7版。
[ruckc<strong i="7">@omnilap</strong> compose]$ git diff diff --git a/compose/config/config_schema_v3.7.json b/compose/config/config_schema_v3.7.json index cd7882f5..d25d404c 100644 --- a/compose/config/config_schema_v3.7.json +++ b/compose/config/config_schema_v3.7.json @@ -151,6 +151,7 @@ "external_links": {"type": "array", "items": {"type": "string"}, "uniqueItems": true}, "extra_hosts": {"$ref": "#/definitions/list_or_dict"}, + "gpus": {"type": ["number", "string"]}, "healthcheck": {"$ref": "#/definitions/healthcheck"}, "hostname": {"type": "string"}, "image": {"type": "string"}, diff --git a/compose/service.py b/compose/service.py index 55d2e9cd..71188b67 100644 --- a/compose/service.py +++ b/compose/service.py @@ -89,6 +89,7 @@ HOST_CONFIG_KEYS = [ 'dns_opt', 'env_file', 'extra_hosts', + 'gpus', 'group_add', 'init', 'ipc', @@ -996,6 +997,7 @@ class Service(object): dns_opt=options.get('dns_opt'), dns_search=options.get('dns_search'), restart_policy=options.get('restart'), + gpus=options.get('gpus'), runtime=options.get('runtime'), cap_add=options.get('cap_add'), cap_drop=options.get('cap_drop'),
我尝试了您的解决方案,但有关该标志的错误很多:
ERROR: for <SERVICE_NAME> __init__() got an unexpected keyword argument 'gpus'
Traceback (most recent call last):
File "/usr/local/bin/docker-compose", line 11, in <module>
load_entry_point('docker-compose==1.25.0.dev0', 'console_scripts', 'docker-compose')()
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/cli/main.py", line 71, in main
command()
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/cli/main.py", line 127, in perform_command
handler(command, command_options)
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/cli/main.py", line 1106, in up
to_attach = up(False)
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/cli/main.py", line 1102, in up
cli=native_builder,
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/project.py", line 569, in up
get_deps,
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/parallel.py", line 112, in parallel_execute
raise error_to_reraise
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/parallel.py", line 210, in producer
result = func(obj)
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/project.py", line 555, in do
renew_anonymous_volumes=renew_anonymous_volumes,
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 546, in execute_convergence_plan
scale, detached, start
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 468, in _execute_convergence_create
"Creating"
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/parallel.py", line 112, in parallel_execute
raise error_to_reraise
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/parallel.py", line 210, in producer
result = func(obj)
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 466, in <lambda>
lambda service_name: create_and_start(self, service_name.number),
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 454, in create_and_start
container = service.create_container(number=n, quiet=True)
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 337, in create_container
previous_container=previous_container,
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 913, in _get_container_create_options
one_off=one_off)
File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 1045, in _get_container_host_config
cpu_rt_runtime=options.get('cpu_rt_runtime'),
File "/usr/local/lib/python3.6/dist-packages/docker-4.0.2-py3.6.egg/docker/api/container.py", line 590, in create_host_config
return HostConfig(*args, **kwargs)
TypeError: __init__() got an unexpected keyword argument 'gpus'
我需要特定的python docker
软件包吗?
@DarioTurchi是的,我遇到了确切的问题。 似乎还需要更新HostConfig的类型。
我不相信@ruckc描述的docker -py也需要更改。 而且似乎仍在进行必要的docker-py更改。 看这里:
https://github.com/docker/docker-py/pull/2419
这是具有更改的分支:
https://github.com/sigurdkb/docker-py/tree/gpus_parameter
因此,如果您现在想对此进行修补,则必须针对https://github.com/sigurdkb/docker-py/tree/gpus_parameter上的修改后的docker-py构建docker-compose
我不明白这是怎么回事:
1)我有/etc/docker/daemon.json
{
"runtimes": {
"nvidia": {
"path": "nvidia-container-runtime",
"runtimeArgs": []
}
}
}
但是runtime
键无法在v3.x中像https://github.com/docker/compose/issues/6239那样使用
我也尝试过:
{
"default-runtime": "nvidia",
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
}
}
因此,我无法再在docker-compose
上使用gpu支持启动我的容器了:
bertserving_1 | I:VENTILATOR:[__i:_ge:222]:get devices
bertserving_1 | W:VENTILATOR:[__i:_ge:246]:no GPU available, fall back to CPU
在这些更改生效之前,我现在该怎么办?
+1在docker-compose中具有此功能将非常有用!
有eta吗?
+1对于docker-compose非常有用
此功能是对docker-compose
的出色补充
现在,我为此的解决方案是使用支持运行时的2.3版本的docker-compose文件,并手动安装nvidia-container-runtime(因为它不再与nvidia-docker一起安装)。
另外,我还在/etc/docker/daemon.json中设置运行时配置(不是默认值,只是可用的运行时)。
有了这个,我可以像这样使用compose文件:
version: '2.3'
services:
test:
image: nvidia/cuda:9.0-base
runtime: nvidia
现在,我为此的解决方案是使用支持运行时的2.3版本的docker-compose文件,并手动安装nvidia-container-runtime(因为它不再与nvidia-docker一起安装)。
另外,我还在/etc/docker/daemon.json中设置运行时配置(不是默认值,只是可用的运行时)。
有了这个,我可以像这样使用compose文件:version: '2.3' services: test: image: nvidia/cuda:9.0-base runtime: nvidia
@arruda您介意分享您的daemon.json
吗?
现在,我为此的解决方案是使用支持运行时的2.3版本的docker-compose文件,并手动安装nvidia-container-runtime(因为它不再与nvidia-docker一起安装)。
另外,我还在/etc/docker/daemon.json中设置运行时配置(不是默认值,只是可用的运行时)。
有了这个,我可以像这样使用compose文件:version: '2.3' services: test: image: nvidia/cuda:9.0-base runtime: nvidia
@arruda您介意分享您的
daemon.json
吗?
是的,没问题,这里是:
{
"runtimes": {
"nvidia": {
"path": "nvidia-container-runtime",
"runtimeArgs": []
}
}
}
你好
我有一个需要NVIDIA驱动程序的应用程序。 我已经基于(FROM)构建了一个docker镜像
NVIDIA / cudagl:10.1-runtime-ubuntu18.04
使用上面推荐的方法-是否表示我的图像不需要来自nvidia / cudagl:10.1-runtime-ubuntu18.04 ? 即我可以简单地从(FROM) python:3.7.3-stretch派生
并将运行时:nvidia添加到docker-compose中的服务?
谢谢
我们需要这个功能
@ Daniel451我一直在外围关注,但看起来它会在
generic_resources
键下,类似:services: my_app: deploy: resources: reservations: generic_resources: - discrete_resource_spec: kind: 'gpu' value: 2
(来自https://github.com/docker/cli/blob/9a39a1/cli/compose/loader/full-example.yml#L71-L74)
在此处设计文档: https :以下是有关compose 3.8模式支持的撰写问题,该支持已合并在#6530中
在守护程序方面,可以通过将
gpu
功能包含在daemon.json
或dockerd
CLI中(例如以前的硬编码运行时解决方法)来注册该功能。/usr/bin/dockerd --node-generic-resource gpu=2
然后通过挂接到NVIDIA docker实用程序进行注册:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go看来机器已经基本到位,可能只需要记录在案...
嘿, @johncolby ,我尝试了这个,但是失败了:
ERROR: The Compose file './docker-compose.yml' is invalid because:
services.nvidia-smi-test.deploy.resources.reservations value Additional properties are not allowed ('generic_resources' was unexpected)
有什么建议?
谢谢
大卫
从https://github.com/NVIDIA/nvidia-container-runtime安装nvidia-container-runtime 3.1.4.1
并放入
runtime: nvidia
在这里可以很好地与docker-compose 1.23.1
和1.24.1
使用,该命令是从https://docs.docker.com/compose/install/使用以下狡猾的命令安装的:
sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
例如dockerhub中的nvidia / cudagl / 10.1-base容器。 我已经尝试过cuda和OpenGL渲染,而且都接近本机性能。
内部跟踪为COMPOSE-82
请注意,为了保持一致性,还需要在docker stack
(https://github.com/docker/cli/blob/master/cli/compose/types/types.go#L156)中实现这样的更改
从https://github.com/NVIDIA/nvidia-container-runtime安装
nvidia-container-runtime 3.1.4.1
并放入runtime: nvidia
在这里可以很好地与
docker-compose 1.23.1
和1.24.1
使用,该命令是从https://docs.docker.com/compose/install/使用以下狡猾的命令安装的:sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
例如dockerhub中的nvidia / cudagl / 10.1-base容器。 我已经尝试过cuda和OpenGL渲染,而且都接近本机性能。
你可以分享你的docker-compose.yml吗?
嘿,@ jdr-face,
这是根据您的建议进行的测试,方法是在主机上安装nvidia-container-runtime
。
version: '3.0'
services:
nvidia-smi-test:
runtime: nvidia
volumes:
- /tmp/.X11-unix:/tmp/.X11-unix
environment:
- NVIDIA_VISIBLE_DEVICES=0
- DISPLAY
image: vkcube
它仍然给出错误:
Unsupported config option for services.nvidia-smi-test: 'runtime'
@ david-gwa,如andyneff先前所述:
runtime
从来都不是3.x标志。 它仅出现在2.x轨道(2.3和2.4)中。
@ david-gwa
你可以分享你的docker-compose.yml吗?
version: '2.3'
services:
container:
image: "nvidia/cudagl/10.1-base"
runtime: "nvidia"
security_opt:
- seccomp:unconfined
privileged: true
volumes:
- $HOME/.Xauthority:/root/.Xauthority:rw
- /tmp/.X11-unix:/tmp/.X11-unix:rw
environment:
- NVIDIA_VISIBLE_DEVICES=all
根据您的需求,其中一些选项可能是不必要的。 正如@muru预测的那样,诀窍是指定一个旧版本。 至少对于我的用例而言,这不是问题,但是我仅提供此配置作为解决方法,实际上应该使用最新版本使它成为可能。
谢谢你们,@ JDR面,@muru,撰写V2不工作,
我误解了您的解决方案是针对v3撰写的。
出于传统上的考虑,记录:compose v2不早于compose v3。 它们是不同的用例。 v3面向群体,而v2则不适合。 v1旧。
是否有关于Docker-compose对Docker的本地GPU支持的支持的讨论?
将来,支持runtime
选项不是GPU支持的解决方案。 NVIDIA在https://github.com/NVIDIA/nvidia-docker中描述了nvidia-docker2的未来,如下所示。
请注意,随着Docker 19.03的发布,不赞成使用nvidia-docker2软件包,因为Docker运行时中现在已将NVIDIA GPU作为设备本地支持。
当前,可以通过更改运行时来实现对GPU的支持,但是将来很有可能无法使用它。
坦率地说,这可能不是最好的做法,但是我们还是设法使它起作用。
棘手的部分是,由于我们使用的是docker swarm,因此必须坚持使用docker-compose v3.x,同时我们想使用Nvidia Runtime在容器中支持GPU / CUDA。
为避免在docker-compose文件中明确告知Nvidia运行时,我们在/etc/docker/daemon.json
中将Nvidia设置为默认运行时,它看起来像
{
"default-runtime":"nvidia",
"runtimes": {
"nvidia": {
"path": "nvidia-container-runtime",
"runtimeArgs": []
}
}
}
这样,在GPU机器上运行的所有容器将默认启用Nvidia运行时。
希望这可以帮助面临类似障碍的人
坦率地说,这可能不是最好的做法,但是我们还是设法使它起作用。
棘手的部分是,由于我们使用的是docker swarm,因此必须坚持使用docker-compose v3.x,同时我们想使用Nvidia Runtime在容器中支持GPU / CUDA。
为避免在docker-compose文件中明确告知Nvidia运行时,我们在
/etc/docker/daemon.json
中将Nvidia设置为默认运行时,它看起来像{ "default-runtime":"nvidia", "runtimes": { "nvidia": { "path": "nvidia-container-runtime", "runtimeArgs": [] } } }
这样,在GPU机器上运行的所有容器将默认启用Nvidia运行时。
希望这可以帮助面临类似障碍的人
这确实是我们所做的。 它现在可以使用,但是对我来说有点不客气。 希望尽快获得全面的compose-v3支持。 :)
是否打算让用户在迁移到docker> =
19.03
并删除nvidia-docker2
来使用nvidia-container-toolkit
之后手动填充/etc/docker/daemon.json
?看来这破坏了许多安装。 特别是,由于
--gpus
在compose
不可用。
--gpus在compose中不可用
我无法使用pycharm链接docker以运行tensorflow-gpu
关于此问题有任何更新吗? 是否有可能在docker-compose中很快支持--gpus?
在Docker 19.03.0 Beta 2下,以新的CLI API --gpus的形式引入了对NVIDIA GPU的支持。 docker / cli#1714讨论此启用。
现在,只需为GPU加速的基于Docker的应用程序传递--gpus选项。
$ docker run -it --rm --gpus all ubuntu nvidia-smi Unable to find image 'ubuntu:latest' locally latest: Pulling from library/ubuntu f476d66f5408: Pull complete 8882c27f669e: Pull complete d9af21273955: Pull complete f5029279ec12: Pull complete Digest: sha256:d26d529daa4d8567167181d9d569f2a85da3c5ecaf539cace2c6223355d69981 Status: Downloaded newer image for ubuntu:latest Tue May 7 15:52:15 2019 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 390.116 Driver Version: 390.116 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 Tesla P4 Off | 00000000:00:04.0 Off | 0 | | N/A 39C P0 22W / 75W | 0MiB / 7611MiB | 0% Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+ :~$
到目前为止,Compose不支持此功能。 这是一项功能请求,用于使Compose支持NVIDIA GPU。
我已经解决了这个问题,您可以尝试以下操作,我的csdn博客地址为: https :
〜$ sudo apt-get install nvidia-container-runtime
〜$ sudo vim /etc/docker/daemon.json
然后,在此daemon.json文件中,添加以下内容:
{
“默认运行时”:“ nvidia”
“运行时间”:{
“ nvidia”:{
“ path”:“ / usr / bin / nvidia-container-runtime”,
“ runtimeArgs”:[]
}
}
}
〜$ sudo systemctl守护进程重新加载
〜$ sudo systemctl重新启动docker
对于想要设置上述解决方法的烦躁用户,可以安装nvidia-container-runtime并将/etc/docker/deamon.json配置为使用runtime: nvidia
:
https://github.com/NVIDIA/ansible-role-nvidia-docker
(由于某种原因,它只能在Ubuntu和RHEL上运行,但是修改起来很容易。我在Debian上运行它)
然后在您的docker-compose.yml中:
version: "2.4"
services:
test:
image: "nvidia/cuda:10.2-runtime-ubuntu18.04"
command: "nvidia-smi"
支持gpu的官方3.x版本有任何更新吗? 我们需要大量:)
是否有计划添加此功能?
此功能取决于实现device_requests
参数的docker-py,即--gpus
转换为的参数。 有多个请求请求添加了此功能(https://github.com/docker/docker-py/pull/2419,https://github.com/docker/docker-py/pull/2465,https:/ /github.com/docker/docker-py/pull/2471),但任何维护者都没有反应。 #7124使用https://github.com/docker/docker-py/pull/2471在Compose中提供它,但仍未收到任何人的答复。
正如我在#7124中提到的那样,我很乐意使PR更加合规,但是由于获得的关注很少,我不想在不会合并的事情上浪费我的时间...
请添加此功能,将会很棒!
请添加此功能! 我对旧的nevidia-docker2感到非常满意,这使我可以在daemon.json中更改运行时。 回来就好了。
请需要它。 真的需要它:/
我也想继续...我们需要这个功能!
我需要在同一台计算机上同时运行CPU和GPU容器,因此默认运行时破解对我不起作用。 我们有什么想法可以在撰写时知道吗? 假设我们没有在运行时标记,这表示功能严重退化,不是吗? 为了使这项工作有效,我不得不编写脚本-糟糕!
我需要在同一台计算机上同时运行CPU和GPU容器,因此默认运行时破解对我不起作用。 我们有什么想法可以在撰写时知道吗? 假设我们没有在运行时标记,这表示功能严重退化,不是吗? 为了使这项工作有效,我不得不编写脚本-糟糕!
您可以通过docker cli(docker run --gpu ....)来做到这一点,我有这种技巧(通过添加代理,以便能够与在swarm上其他节点上运行的其他容器进行通信)。 我们都在等待在swarm上运行它的能力,因为它无法通过docker service命令(如我所知)或compose起作用。
@dottgonzo 。 嗯,是 ;-)。 我知道这一点,因此也了解脚本。 但这是一种非常糟糕且不可移植的方式,因此我想以一种更加动态的方式来进行。 如我所说,我认为这代表回归,而不是功能要求。
COMPOSE_API_VERSION=auto docker-compose run gpu
@ggregoire我们在哪里运行:COMPOSE_API_VERSION =自动docker-compose运行gpu?
您的shell中的@joehoeller就是您可以执行其他任何命令的地方。
现在,我们正在决定是否需要每个项目3.x功能,或者是否可以使用仍支持GPU选项的docker-compose2.x。 如果需要GPU,则无法使用诸如从Dockerfile运行多阶段目标之类的功能。 请重新添加!
我想为docker-compose推荐一个类似“其他选项”字段的内容,我们可以在docker-start / run命令中添加--gpus=all
类的标志,而docker-compose中尚不支持但是是最新的docker版本。 这样,如果撰写用户需要一个尚不支持的新docker功能,则不必等待docker-compose赶上来。
对于生产环境,仍然需要在Docker Swarm上运行它。 这对Docker Swarm有用吗?
@sebastianfelipe如果要使用compose部署到
比较:
docker service create --generic-resource "gpu=1" --replicas 10 \
--name sparkWorker <image_name> \"service ssh start && \
/opt/spark/bin/spark-class org.apache.spark.deploy.worker.Worker spark://<spark_master_ip>:7077\"
像这样
docker stack deploy --compose-file docker-compose.yml stackdemo
@sebastianfelipe如果要使用compose部署到
比较:
docker service create --generic-resource "gpu=1" --replicas 10 \ --name sparkWorker <image_name> \"service ssh start && \ /opt/spark/bin/spark-class org.apache.spark.deploy.worker.Worker spark://<spark_master_ip>:7077\"
像这样
docker stack deploy --compose-file docker-compose.yml stackdemo
抱歉,它已经使用docker-compose yaml文件与Docker Swarm一起使用了吗? 只是要确保:O。 谢谢!
仅适用于docker compose 2.x
这个问题的全部重点是要求为docker-compose 3+提供nvidia-docker gpu支持
从最初的请求到现在已经快一年了! 为什么要延迟? 我们可以向前推进吗?
ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone。 这事有进一步更新吗?
对于那些正在寻找解决方法的人,我们最终要做的是:
- 从此PR安装docker-py: docker / docker-py#2471
- 从此PR安装docker-compose:#7124
然后使用以下文件运行
COMPOSE_API_VERSION=auto docker-compose run gpu
:version: '3.7' services: gpu: image: 'nvidia/cuda:9.0-base' command: 'nvidia-smi' device_requests: - capabilities: - "gpu"
对于像我一样急躁的人,下面是上述解决方法的简单pip install
版本:
pip install git+https://github.com/docker/docker-py.git@refs/pull/2471/merge
pip install git+https://github.com/docker/compose.git@refs/pull/7124/merge
pip install python-dotenv
@yoanisgil的巨大荣誉!
仍在焦急地等待官方补丁。 有了所有的PR,就任何标准而言似乎都不困难。
ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone。 这事有进一步更新吗?
不,我不知道为什么叫我。
我要你告诉我该怎么办?
我希望对此有更新。
是的,已经一年多了...为什么他们不合并到docker-py中...
我不确定建议的实现是否适合Compose格式。 好消息是,我们已经开放了Compose格式规范,旨在添加此类内容。 您可以在https://github.com/compose-spec中找到该规范
我建议我们做的是在规范上添加一个问题,然后在即将到来的Compose社区会议之一中进行讨论(请链接到此页面底部的)。
这有效:
docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
这不是:docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
你需要
{ "runtimes": { "nvidia": { "path": "/usr/bin/nvidia-container-runtime", "runtimeArgs": [] } } }
在您的
/etc/docker/daemon.json
为--runtime=nvidia
继续工作。 更多信息在这里。
Dockerd不是以这个daemon.json开头
基督,这将需要几年时间:@
这有效:
docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
@deniswal :是的,我们知道这一点,但是我们正在询问撰写功能。
@ chris-crone:我很困惑:这代表了以前行为的回归,为什么它需要新的功能规范? 在同一个物理盒子上运行容器(其中一些使用GPU以及某些使用CPU)是否合理?
感谢您的考虑。
@ vk1z AFAIK Docker Compose从未获得过GPU支持,因此这不是回归。 需要设计的部分是如何以Compose格式声明服务对GPU(或其他设备)的需求-具体来说就是这样的更改。 在那之后,它应该只是进入后端。
嗨,大家好,我已经尝试过这里提出的一些解决方案,但对我没有任何帮助,例如@miriaford在我的情况下
我的i7配备了16GB的ram,但是某些项目的构建需要太长时间才能完成,我的目标是也要使用GPU来加速过程,这可能吗? 谢谢!
@ chris-crone:再次,我愿意得到纠正,但这不是因为在配置2.4之后,runtime:参数从compose消失了吗? 这就是为什么我认为这是一种回归。 但是现在不重要了,因为无论如何我们都应该使用3.x。
我很乐意提出一个问题,我们是否按照规范存储库中的规范进行操作,对吗?
但这不是因为在配置2.4之后,runtime:参数从compose消失了吗? 这就是为什么我认为这是一种回归。
对,就是这样。 我有几个项目依赖于我们在docker-compose文件中使用runtime: nvidia
,而这个问题使我们无法升级到3.x,因为我们还没有找到使用GPU的方法。
嗨,请,请解决此问题。
这应该标记为关键任务优先级-20
再次,我愿意得到纠正,但这不是因为在配置2.4之后,runtime:参数从compose消失了吗? 这就是为什么我认为这是一种回归。 但是现在不重要了,因为无论如何我们都应该使用3.x。
进行更改时我不在这里,所以我不确定100%为什么删除了它。 我知道您不再需要NVIDIA运行时来使用GPU ,并且我们正在此处公开开发Compose v3规范,目的是制作该规范的单个版本。 这可能意味着将某些v2功能移至v3。
对于runtime
字段,我认为这不是应该添加到Compose规范中的方式,因为它非常特定于在单个节点上运行。 理想情况下,我们希望有一些东西可以让您指定您的工作负载有设备需求(例如:GPU,TPU,接下来是什么),然后让协调器将工作负载分配给提供该功能的节点。
该讨论应在规范上进行,因为它不是特定于Python Docker Compose的。
@ chris-crone:我基本上同意你的说法。 添加短期黑客可能是执行此操作的不正确方法,因为我们拥有大量的边缘设备,每个边缘设备都有自己的运行时。 如您所指出的,Pi上的TPU(Google),VPU(Intel)和ARM GPU。 因此,我们确实需要一个更完整的故事。
我今天将针对规范提出问题,并在完成后更新此线程。 但是,我确实认为协调器应该是独立的-例如,如果我想使用Kube,我应该能够这样做。 我假设这将在范围内。
但是,我确实不同意使用GPU的声明,因为这不适用于compose -这就是全部内容。 但是我认为我们都知道我们想解决什么问题。
@ chris-crone:请参阅提交的docker-compose规范问题。 从现在开始,我将针对该问题跟踪更新。
我们可以简单地添加一个选项(如extra_docker_run_args
)将参数直接传递给基础docker run
吗? 这不仅将解决当前的问题,而且将是面向未来的:如果docker添加对“ XPU”,“ YPU”或将来可能出现的任何其他新功能的支持?
如果每次Docker添加新功能时我们都需要进行漫长的来回讨论,它将非常低效,并在docker-compose
和docker
更新之间造成不可避免的延迟(以及不必要的混乱)。 支持论据的委派可以为所有将来的功能暂时缓解此反复出现的问题。
@miriaford我不确定传递未解释的Blob是否支持声明性的
但我同意应该使compose和docker保持同步,并且改变人们所依赖的工作功能(即使它是主要版本)也不是很合算。
@ vk1z我同意- compose
和docker
之间应该有更好的同步机制。 但是,我不希望这种机制会很快被设计出来。 同时,我们还需要一种临时的方式来进行我们自己的同步,而不必深入研究源代码。
如果论点委托提案不是一个选择,那么我们建议我们怎么做? 我同意这不是一个很好的解决方案,但至少比该解决方法要好得多,不是吗? https://github.com/docker/compose/issues/6691#issuecomment -616984053
@miriaford搬运工,撰写不调用带有参数的泊坞窗执行,它实际上使用它使用HTTP API将泊坞窗守护进程docker_py。 因此,没有“底层docker run
”命令。 docker CLI不是API,套接字连接是API的联系点。 这就是为什么它并不总是那么容易的原因。
为了简化起见,在运行docker的过程中,有两个主要的调用,一个是创建容器的调用,另一个是启动容器的调用,每个调用都会吸收不同的信息,并且知道哪个是需要API知识的人,哪个是我不知道我是否喜欢docker
CLI。 我认为,除了选择使用案例外,能够向docker_py调用添加额外的args不会像您想的那样有用。
为了使事情变得更加困难,有时docker_py库位于API的后面,并且没有立即提供的所有内容,您必须等待其更新。 综上所述, extra_docker_run_args
不是一个简单的解决方案。
@andyneff感谢您的解释。 确实,我对Docker的内部运作不太熟悉。 如果我理解正确,那么对于任何新功能更新,都需要手动同步4个API :
docker_py
向套接字API提供python前端这就引出了一个问题:为什么没有自动(或至少是半自动)同步机制? 跨4个API手动传播新功能更新似乎注定容易出错,容易延迟并且令人困惑...
PS我并不是说自动同步是一项简单的任务,但我确实认为应该有一项使将来的生活变得更轻松。
我现在有点儿学...但是正如我将其描述为...
socat
)docker
CLI使用该API为我们的用户提供了一个很棒的工具所以是的,它去了:
我不能代表docker_py或compose,但我想他们为此贡献了有限的工时,因此很难跟上Docker不断添加的所有疯狂的疯狂docker功能。 但是由于docker是一个go库,我的理解是python支持(当前)不是一流的公民。 尽管两个项目都在Docker的保护下是很好的,但是至少从github组织的角度来看。
因此,所有人都在说...我也正在等待同等的--gpus
支持,而不得不使用旧的runtime: nvidia
方法,这至少将给我“一条”前进的道路在docker-compose 2.x中转发。
@andyneff仅供参考,最新的docker-compose中提供了Docker CLI支持。 例如,它允许使用buildkit。 https://www.docker.com/blog/faster-builds-in-compose-thanks-to-buildkit-support/
@andyneff这是一个非常有用的概述! 再次感谢
@lig太棒了! 感谢您的指正! 在写这篇文章时,我实际上是在思考“如何将buildkit融入所有这些内容”
我有点惊讶的是docker-compose是新docker-app框架的相当内在的部分,我想至少出于这个原因,他们想同步docker-compose和docker。 我想知道真正的阻止者是:没有足够的python带宽吗? 似乎有点不可思议。
那么Docker Swarm如何适应@andyneff刚刚描述的结构? Swarm使用compose文件格式版本3(由“ compose”项目定义?),但作为docker
一部分开发的?
抱歉,如果对这个特定问题不合时宜。 我不太了解哪个问题是哪个问题,但是我开始关注这个问题,因为我希望能够告诉在集群中运行的服务需要使用特定的运行时。 我们只能使用compose-file规范的v2来做到这一点,这意味着我们不能使用需要v3的Swarm来做到这一点。 换句话说,我对docker-compose CLI的功能并不真正感兴趣,而只是对为docker swarm使用的docker-compose.yml文件定义的规范感兴趣。
哦,一群人,那个逃脱了……(从我这里)。 不幸的是#6239被BOT关闭。 :(有人尝试#6240,但被告知...
@miriaford ,看来有一个与他们同步的PR! #6642 ?! (这仅适用于v3吗?)
因此,由于群集的性质,在群集节点上有某些事情可以做,而不能做。 因此,Docker API并不总是允许您在群体运行中像常规运行那样执行相同的选择。 我不知道运行时是否是其中之一,但这通常就是为什么您无法在v3(群体兼容版本)和v2(非群兼容版本)中执行操作的原因。
没有人读过这篇文章,不知道你们在说什么。
我们所有人都试图通过硬件加速来部署jellyfin。
直到你们把它改回它应该是的样子时,才说服务3.x不好。
不要使用它。
您需要放置2.4进行维修。
然后您可以对jellyfin,ez使用硬件加速
那么,伙计们,一年,两年的ETA是多少?
@KlaasH @ulyssessouza @Goryudyuma @ chris-
@fakabbir我以为可以使用COMPOSE_DOCKER_CLI_BUILD
来确定。 添加提供和docker run
参数的任意列表的功能甚至可以帮助避免将来出现类似问题。
@lig当只有一项服务需要访问GPU时如何处理?
@lig AFAICS compose使用docker-py
代替docker run
cli。 因此,除非docker-py
支持,否则添加任意的docker run
参数将不起作用。
参考: https :
这件事降低了docker-compose对许多人的有用性。 它并没有引起太多关注,也没有修复它的愿望,特别是当它在较旧的docker-compose中工作时,令人惊讶。
一种可行的方法不是允许在docker-compose文件中提供任意docker --run参数吗? 然后--gpus全部可以传递给docker。
我了解有人可能出于某种哲学或技术原因想要以特定方式进行操作。 但是不动手并以任何方式进行操作都会使您的想法混乱。
@lig当只有一项服务需要访问GPU时如何处理?
那么环境变量NVIDIA_VISIBLE_DEVICES将允许您控制否?
这件事降低了docker-compose对许多人的有用性。 它并没有引起太多关注,也没有修复它的愿望,特别是当它在较旧的docker-compose中工作时,令人惊讶。
一种可行的方法不是允许在docker-compose文件中提供任意docker --run参数吗? 然后--gpus全部可以传递给docker。
我认为不允许传递docker --run
args是要走的路。 compose
本身并不真正调用docker
而是使用docker-py
。
我了解有人可能出于某种哲学或技术原因想要以特定方式进行操作。 但是不动手并以任何方式进行操作都会使您的想法混乱。
有关此内容的PR已打开: https :
我相信,根据docker compose规范中的更改,我们应该尽快恢复到compose 2.4之前的兼容性,并且nvidia运行时将正常工作。 它显然不适用于TPU或其他加速器-这是非常不幸的,但是对于那些想要运行(昂贵的)NVIDIA GPU的人来说,它将起作用。
所以只需在docker-py中等待绿色PR合并https://github.com/docker/docker-py/pull/2471
是的! docker-py的PR已被批准! https://github.com/docker/docker-py/pull/2471
下一步是什么?
这是怎么回事? 能够在docker-compose中支持nvidia运行时会很酷
现在docker / docker-py#2471已合并,我们可以从master安装docker-py。 但是由于@yoanisgil很酷的[PR](https://github.com/docker/compose/pull/7124)(恭喜!)之后
对于那些最终没有看到以前的评论的人:
pip install git+https://github.com/docker/docker-py.git
pip install git+https://github.com/yoanisgil/compose.git@device-requests
然后在撰写文件中使用以下模板。 (来源:评论):
然后使用以下文件运行
COMPOSE_API_VERSION=auto docker-compose run gpu
:version: '3.7' services: gpu: image: 'nvidia/cuda:9.0-base' command: 'nvidia-smi' device_requests: - capabilities: - "gpu"
我确认这在我的本地计算机上有效。 不知道它与Swarm一起使用。
在生产中不能进行特定的docker-compose提交。 #7124是否需要重新设置基础,或者是否还有其他PR要合并新的docker-py
?
嗨@bkakilli ,
谢谢您的帮助! 我只是尝试了您的建议,但运行docker-compose时遇到错误
ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.analysis: 'device_requests'
_分析是我的容器的名称_
我从以下位置更改了我的docker-compose.yml
:
version: '2.3'
services:
analysis:
container_name: analysis
image: analysis:${TAG}
runtime: nvidia
restart: always
ports:
- "8000:80"
至:
version: '3.7'
services:
analysis:
container_name: analysis
image: analysis:${TAG}
device_requests:
- capabilities:
- "gpu"
restart: always
ports:
- "8000:80"
除了两个pip install git+
以外,还有其他什么可以正确设置此设置的吗? 还是我编辑过的配置文件不好?
@frgfm确保您从正确的链接安装compose和
pip install git+https://github.com/yoanisgil/compose.git@device-requests
您可以尝试将--upgrade
参数设置为pip安装。 否则我会怀疑虚拟环境设置。 也许您有另一个docker-compose安装,默认情况下正在使用? 例如,您可能已按照此处的“ Linux”说明为系统安装了它: https :
嗨!
感谢您提供所有信息。 我试图运行您的方法@bkakilli , docker-compose build
起作用了,但是运行docker-compose up
出现错误:
docker.errors.InvalidVersion: device_requests param is not supported in API versions < 1.40
我的docker_compose.yml看起来像这样:
version: '3.7'
networks:
isolation-network:
driver: bridge
services:
li_t5_service:
build: .
ports:
- "${GRAPH_QL_API_PORT}:5001"
device_requests:
- capabilities:
- "gpu"
environment:
- SSH_PRIVATE_KEY=${SSH_PRIVATE_KEY}
- PYTHONUNBUFFERED=${PYTHONUNBUFFERED}
networks:
- isolation-network
提前致谢!
@ugmSorcero设置环境变量COMPOSE_API_VERSION=1.40
然后重新运行命令
@ugmSorcero您是否设法解决该错误? @EpicWink @bkakilli我正在运行从pip安装中声明的版本,但是即使将此类变量导出为1.40,我仍然会收到device_requests param is not supported in API versions < 1.40
的错误
对于给定的撰写文件
version: "3.7"
services:
spam:
image: nvidia/cuda:10.1-cudnn7-runtime
command: nvidia-smi
device_requests:
- capabilities:
- gpu
使用上述安装的docker-compose
版本,在Linux上的Bash中,以下命令成功执行:
COMPOSE_API_VERSION=1.40 docker-compose up
以下命令失败:
docker-compose up
输出错误:
ERROR: for tmp_spam_1 device_requests param is not supported in API versions < 1.40
...
docker.errors.InvalidVersion: device_requests param is not supported in API versions < 1.40
@EpicWink非常感谢。 我没有意识到必须以这种方式执行docker-compose up
。 我将其作为第2步,首先我分别导出COMPOSE_API_VERSION
。 一起运行似乎可行:)
不过,我还有另一个问题。 如果我运行COMPOSE_API_VERSION=1.40 docker-compose run nvidiatest
则在路径中找不到nvidia-smi
,而如果我直接从映像运行,则没有问题。
这是我复制它的方式。
docker-compose本地文件包含:
nvidiatest:
image: nvidia/cuda:10.0-base
device_requests:
- capabilities:
- gpu
command: nvidia-smi
如果运行当前安装程序(api版本为auto和1.40),则会出现以下错误:
COMPOSE_API_VERSION=auto docker-compose -f docker-compose.yml -f docker-compose.local.yml run nvidiatest
Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"nvidia-smi\": executable file not found in $PATH": unknown
是否可能与使用替代文件有关? 如果我仅使用Docker运行cuda基本映像,则从nvidia-smi
获取输出没有问题:
docker run --gpus all nvidia/cuda:10.0-base nvidia-smi
Mon Aug 24 11:40:04 2020
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 440.100 Driver Version: 440.100 CUDA Version: 10.2 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce RTX 2070 Off | 00000000:29:00.0 On | N/A |
| 0% 46C P8 19W / 175W | 427MiB / 7974MiB | 2% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
+-----------------------------------------------------------------------------+
在卸载了从官方文档安装的版本后,我按照上述git的说明安装了docker-compose
。 这是安装版本的信息:
pip3 show --verbose docker-compose
Name: docker-compose
Version: 1.26.0.dev0
Summary: Multi-container orchestration for Docker
Home-page: https://www.docker.com/
Author: Docker, Inc.
Author-email: None
License: Apache License 2.0
Location: /home/jurugu/.local/lib/python3.8/site-packages
Requires: docopt, docker, requests, PyYAML, texttable, websocket-client, six, dockerpty, jsonschema, cached-property
Required-by:
Metadata-Version: 2.1
Installer: pip
Classifiers:
Development Status :: 5 - Production/Stable
Environment :: Console
Intended Audience :: Developers
License :: OSI Approved :: Apache Software License
Programming Language :: Python :: 2
Programming Language :: Python :: 2.7
Programming Language :: Python :: 3
Programming Language :: Python :: 3.4
Programming Language :: Python :: 3.6
Programming Language :: Python :: 3.7
Entry-points:
[console_scripts]
docker-compose = compose.cli.main:main
我有什么想念的吗? 谢谢您的帮助!
@jjrugui,这已成为题外话,而我无法复制您的问题。 抱歉无法提供帮助
@EpicWink没问题,很抱歉偏离主题:)。 如果我发现自己的特定问题,则将其发布在此处。
是有人在另一个PR上工作,还是我们在调试device-requests
分支以便为PR做准备?
当PR卡住时,我将master
7124的更改从https://github.com/beehiveai/compose您可以使用pip install git+https://github.com/beehiveai/compose.git
安装docker-compose.yml
的版本更改为3.8
:
version: "3.8"
services:
gpu-test:
image: nvidia/cuda:10.2-runtime
command: nvidia-smi
device_requests:
- capabilities:
- gpu
在这种情况下,一切都会按预期进行。
正如昨天在作文规范管理会议上讨论的那样,我们将开始制定一项提案,以采用与#7124相类似的内容,该价格可能接近deploy
部分中已有的generic_resouces
。
@ndeloof太好了! 如果可能,请在此处发布该提案的链接。 我认为许多人都会乐于为此做出贡献,因为GPU支持对于深度学习部署至关重要。
@ndeloof历史上,指导委员会一年要花多长时间(6个月)?
+1
+1
@visheratin是否有可能改善您的修补程序,以便在使用多个撰写yml文件时可以正常使用? 我有一个使用非nvidia容器的基本docker-compose.yml,当有GPU时,我想用nvidia容器覆盖它,但是如果您使用“- f”,则“ device_requests”字段会退出配置。
@proximous您
尝试在docker-compose up中使用--scale选项时,compose / service.py中的代码有问题。 不支持吗?
追溯(最近一次通话):
在第11行的文件“ / usr / local / bin / docker-compose”
load_entry_point('docker-compose == 1.27.0.dev0','console_scripts','docker-compose')()
main中的文件“ /usr/local/lib/python3.6/site-packages/compose/cli/main.py”,第67行
命令()
perform_command中的文件“ /usr/local/lib/python3.6/site-packages/compose/cli/main.py”,第123行
处理程序(命令,命令选项)
文件“ /usr/local/lib/python3.6/site-packages/compose/cli/main.py”,行1067,向上
to_attach = up(False)
文件“ /usr/local/lib/python3.6/site-packages/compose/cli/main.py”,行1063,向上
cli = native_builder,
向上的文件“ /usr/local/lib/python3.6/site-packages/compose/project.py”,第648行
get_deps,
文件“ /usr/local/lib/python3.6/site-packages/compose/parallel.py”,第108行,在parallel_execute中
提高error_to_reraise
生产者中的文件“ /usr/local/lib/python3.6/site-packages/compose/parallel.py”,行206
结果= func(obj)
在do中的文件“ /usr/local/lib/python3.6/site-packages/compose/project.py”,第634行
overlay_options = override_options,
在execute_convergence_plan中的文件“ /usr/local/lib/python3.6/site-packages/compose/service.py”,行579
renew_anonymous_volumes,
_execute_convergence_recreate中的文件“ /usr/local/lib/python3.6/site-packages/compose/service.py”,行509
规模-len(容器),分离,开始
_execute_convergence_create中的文件“ /usr/local/lib/python3.6/site-packages/compose/service.py”,行479
“创造”
文件“ /usr/local/lib/python3.6/site-packages/compose/parallel.py”,第108行,在parallel_execute中
提高error_to_reraise
生产者中的文件“ /usr/local/lib/python3.6/site-packages/compose/parallel.py”,行206
结果= func(obj)
文件“ /usr/local/lib/python3.6/site-packages/compose/service.py”,位于第477行
lambda service_name:create_and_start(自己,service_name.number),
在create_and_start中的文件“ /usr/local/lib/python3.6/site-packages/compose/service.py”,第456行
容器= service.create_container(数字= n,安静=真)
create_container中的第333行的文件“ /usr/local/lib/python3.6/site-packages/compose/service.py”
previous_container =上一个容器,
_get_container_create_options中的文件“ /usr/local/lib/python3.6/site-packages/compose/service.py”,第936行
one_off = one_off)
_get_container_host_config中的文件“ /usr/local/lib/python3.6/site-packages/compose/service.py”,行1014
device.request ['capabilities']]中元素的element.split(',')
文件“ /usr/local/lib/python3.6/site-packages/compose/service.py”,行1014,在
device.request ['capabilities']]中元素的element.split(',')
AttributeError:“列表”对象没有属性“分割”
经过进一步调试后,我发现使用--scale时,由于某种原因,一个实例将device_requests ['capabilities']设置为['gpu']。 但是对于所有其他要启动的容器,device_request ['capabilities']看起来像[['gpu']]。
我在本地进行了临时修复,以解决此问题,只是使我的容器在compose / service.py的第1010行开始运行:
```
对于device_requests中的device_request:
如果“功能”不在device_request中:
继续
如果type(device_request ['capabilities'] [0])==列表:
device_request ['capabilities'] = [
device.request ['capabilities'] [0]]中元素的element.split('。')
其他:
device_request ['capabilities'] = [
device_request ['capabilities']]中元素的element.split('。')
``
@proximous您
@visheratin看到这个示例,我是否期望得到不同的结果?
docker-compose.nogpu.yml:
version: '3.8'
services:
df:
build: miniconda-image.Dockerfile
docker-compose.gpu.yml:
version: '3.8'
services:
df:
build: nvidia-image.Dockerfile
device_requests:
- capabilities:
- gpu
仅使用nogpu.yml:
$ docker-compose -f docker-compose.nogpu.yml config
services:
df:
build:
context: /home/jerry/gpu-test/miniconda-image.Dockerfile
version: '3'
仅使用gpu.yml:
$ docker-compose -f docker-compose.gpu.yml config
services:
df:
build:
context: /home/jerry/gpu-test/nvidia-image.Dockerfile
device_requests:
- capabilities:
- gpu
version: '3'
以非gpu yml开头的链配置ymls(注意...缺少运行时):
$ docker-compose -f docker-compose.nogpu.yml -f docker-compose.gpu.yml config
services:
df:
build:
context: /home/jerry/gpu-test/nvidia-image.Dockerfile
version: '3'
预期输出:
$ docker-compose -f docker-compose.nogpu.yml -f docker-compose.gpu.yml config
services:
df:
build:
context: /home/jerry/gpu-test/nvidia-image.Dockerfile
device_requests:
- capabilities:
- gpu
version: '3'
(显然,我正在尝试更详细的说明,这只是一个简化的案例,以突出显示意外的行为。)
@jlaule @proximous为了使话题保持话题,请在派生的
对于那些在等待时需要一些东西的人,我只是在30分钟内使用Docker作为容器运行时设置了具有GPU支持的K3S(Kubernetes的边缘版本)(即在安装脚本中使用--docker
选项)。 请遵循https://github.com/NVIDIA/k8s-device-plugin使Nvidia设备插件正常工作。
希望有帮助!
@EpicWink没问题,很抱歉偏离主题:)。 如果我发现自己的特定问题,则将其发布在此处。
您解决了吗?
不再有“ / usr / bin / nvidia-container-runtime”之类的东西。 问题仍然很关键。
按照此处的说明安装nvidia-docker2
香港专业教育学院一直在解决这个问题,我想我的方法。
我的问题是我需要泊坞窗部署并且它不想听。 docker compose我曾经使用过docker api版本的hack,但是感觉并不正确,无论如何,堆栈部署都无法工作。
所以在我的docker compose中没有设置任何运行时pr设备请求的情况下,我将其添加到了守护进程中:
{
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
},
"default-runtime": "nvidia",
"node-generic-resources": [
"NVIDIA-GPU=0"
]
}
您还可以使用GPU- {gpu guid的第一部分}
但这比较容易。 除了NV容器工具包外,无需安装任何pip +或类似的工具。 它展开并像魅力一样工作。
Tks很多@haviduck ,只是在我自己的机器上尝试过(Ubuntu 20.04,docker CE 19.03.8),它就像一个魅力。
对于其他人:不要忘记重启您的docker守护进程。
@pommedeterresautee啊,我很高兴为其他人工作! 应该提到重装。
必须说在不停泊码头3周后,我似乎很困惑,似乎什么都没有起作用。
@haviduck :谢谢! 最后,一个可行的简单解决方案。 我花了很多时间尝试添加放弃的设备等。 然后出现这种情况,尝试一下,几分钟后,我在Plex中进行了硬件转码。
我将为此加2美分。。。我读了很多文章,最后解决的方法很简单。
它对我有用:(也许稍微低一点也可以工作-不知道...)
docker-compose版本1.27.4,内部版本40524192
而已 !
使用YML进行部署,您将在docker-compose中获得GPU支持
5. in your docker-compose YML you should add: **runtime: nvidia**
哦,天哪,整个线程都是关于版本3的,该版本没有运行时。
1.27.0及更高版本已合并了v2 / v3文件格式,因此现在可以在任何地方使用runtime
。 此外,尽管尚未在docker-compose
实现,但加速器的规范也已发布(https://github.com/compose-spec/compose-spec/pull/100)。
我将为此加2美分。。。我读了很多文章,最后解决的方法很简单。
它对我有用:(也许稍微低一点也可以工作-不知道...)
docker -compose版本1.27.4,内部版本
- 在docker主机上安装nvidia-container-toolkit和nvidia-container-runtime软件包
- 在docker主机上:输入
nvidia-smi并检查右侧显示的CUDA版本- 在docker主机上:输入:(将cuda版本替换为已安装的版本)
docker run --rm --gpus所有nvidia / cuda:10.1-base nvidia-smi
您应该获得与在主机上运行nvidia-smi时相同的输出- 在文件/etc/docker/daemon.json中,您应该设置:
“ runtimes”:{“ nvidia”:{“ path”:“ / usr / bin / nvidia-container-runtime”,“ runtimeArgs”:[]}}- 在您的docker-compose YML中,您应该添加:
运行时:nvidia而已 !
使用YML进行部署,您将在docker-compose中获得GPU支持
仅供参考,您可以在nvidia-smi
的输出中看到的cuda版本是指nvidia cuda驱动程序版本,也就是您的nvidia驱动程序(它们也称为cuda,这令人困惑)。 泊坞窗映像中的版本号,例如nvidia/cuda:10.1-base nvidia-smi
指的是nvidia工具包版本(再次,令人困惑的是相同的版本编号系统,不同的野兽)。
该驱动程序与该工具包向后兼容,因此只要<version>
小于或等于驱动程序版本,便可以运行任何nvidia/cuda:<version>-base nvidia-smi
。
此处提供更多信息: https :
我看不到可用于基于ARM的系统的Docker Compose 1.27.4二进制文件。
pip install docker-compose
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: docker-compose in /usr/local/lib/python3.6/dist-packages (1.26.2)
嗨@collabnix!
pip --version
的输出是什么?
Compose 1.27放弃了对Python 2的支持,因此如果您的系统具有Python 2,则可能看不到1.27.x版本。
@collabnix那是因为您已经安装了compose,请尝试pip install --upgrade docker-compose
现在我可以升级到1.27.4。 点升级就成功了。 谢谢@ kshcherban &@ chris-crone
看到我过去从事的大多数项目都很疯狂,并且使用Python 2.7的确需要升级。
将docker-compose升级到1.27.4解决了该问题。
(以后可能会升级到1.19.3来解决问题)
$ cat /etc/docker/daemon.json
{
"default-runtime": "nvidia",
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
}
}
version: '3.5'
runtime: nvidia
environment:
- NVIDIA_VISIBLE_DEVICES=all
- NVIDIA_DRIVER_CAPABILITIES=all
image: 'detectme'
ipc: 'host'
tty: true
stdin_open: true
$ sudo docker-compose up -d --build
ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.engine: 'runtime'
$ docker-compose --version
docker-compose version 1.17.1, build unknown
$ sudo curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose
$ sudo rm /usr/bin/docker-compose
$ sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
$ sudo docker-compose up -d --build
与docker-compose一起运行良好。
在主机上检查nvidia-smi使用的gpu。
@ bttung-2020
@PyCod
如果我在docker-hub中使用dokcer-nvidia-devel(not runtime):nvidia / cuda:10.1-cudnn7-devel-ubuntu18.04
它有效吗? 我应该如何编辑docker-compose.yaml文件?
最有用的评论
迫切需要。 感谢你的付出!