تحت Docker 19.03.0 Beta 2 ، تم تقديم دعم NVIDIA GPU في شكل واجهة برمجة تطبيقات CLI الجديدة - gpus. https://github.com/docker/cli/pull/1714 تحدث عن هذا التمكين.
الآن يمكن للمرء ببساطة تمرير خيار gpus لتطبيق Docker المسرع بواسطة GPU.
$ 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" القديم (الآن) معطلاً مع Docker 19.03.0 و nvidia-container-toolkit-1.0.0-2
: https://github.com/NVIDIA/nvidia-docker/issues/1017
$ 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
أي عمل يحدث على هذا؟
حصلت على Docker CE 19.03.0 الجديد على جهاز Ubuntu 18.04 LTS جديد ، ولدي الإصدار الحالي والمطابق من مجموعة أدوات حاوية NVIDIA (née nvidia-docker2) ، لكن لا يمكنني استخدامه لأن docker-compose.yml 3.7 لا يدعم --gpus
flag.
هل هناك حل لهذا؟
هذا يعمل:
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
لمواصلة العمل. مزيد من المعلومات هنا .
MustafaHosny اللهم امين يارب . أي تحديث على هذا؟
إنها حاجة ملحة. شكرا على مجهودك!
هل المقصود أن يقوم المستخدم بتعبئة /etc/docker/daemon.json
يدويًا بعد الترحيل إلى عامل الإرساء> = 19.03
وإزالة nvidia-docker2
لاستخدام nvidia-container-toolkit
بدلاً من ذلك؟
يبدو أن هذا يكسر الكثير من المنشآت. بشكل خاص ، نظرًا لأن --gpus
غير متوفر في compose
.
لا ، هذا حل بديل حتى يدعم الإنشاء علامة gpus.
تثبيت nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -Engine-setup
أضف إلى /etc/docker/daemon.json
{
"أوقات التشغيل": {
"nvidia": {
"المسار": "/ usr / bin / nvidia-container-runtime" ،
"runtimeArgs": []
}
}
}
عامل ميناء يؤلف:
وقت التشغيل: nvidia
بيئة:
- NVIDIA_VISIBLE_DEVICES = الكل
لم يعد هناك شيء مثل "/ usr / bin / nvidia-container-runtime" بعد الآن. القضية لا تزال حرجة.
سيساعد في تشغيل بيئة nvidia باستخدام عامل إنشاء عامل التركيب ، حتى يتم إصلاح تكوين عامل الإرساء
تثبيت nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -Engine-setup
أضف إلى /etc/docker/daemon.json
{
"أوقات التشغيل": {
"nvidia": {
"المسار": "/ usr / bin / nvidia-container-runtime" ،
"runtimeArgs": []
}
}
}عامل ميناء يؤلف:
وقت التشغيل: nvidia
بيئة:
- NVIDIA_VISIBLE_DEVICES = الكل
هذا لا يعمل بالنسبة لي ، ما زلت أحصل على Unsupported config option for services.myservice: 'runtime'
عند محاولة تشغيل docker-compose up
أيه أفكار؟
هذا لا يعمل بالنسبة لي ، ما زلت أحصل على
Unsupported config option for services.myservice: 'runtime'
عند محاولة تشغيلdocker-compose up
أيه أفكار؟
بعد تعديل /etc/docker/daemon.json ، أعد تشغيل خدمة عامل الإرساء
إعادة تشغيل عامل ميناء systemctl
استخدم تنسيق الإنشاء 2.3 وأضف وقت التشغيل: nvidia إلى خدمة GPU الخاصة بك. يجب أن يكون إصدار Docker Compose هو 1.19.0 أو أعلى.
ملف إنشاء عامل ميناء:
الإصدار: '2.3'
خدمات:
nvsmi:
الصورة: أوبونتو: 16.04
وقت التشغيل: nvidia
بيئة:
- NVIDIA_VISIBLE_DEVICES = الكل
الأمر: nvidia-smi
cheperuiz ، يمكنك تعيين nvidia كوقت تشغيل افتراضي في daemon.json ولن يعتمد على عامل إنشاء السفن. لكن كل حاويات عامل الإرساء ستستخدم وقت تشغيل nvidia - ليس لدي أي مشاكل حتى الآن.
{
"default-runtime": "nvidia",
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
},
}
آه! شكرًا لك Kwull ، فاتني جزء default-runtime
... كل شيء يعمل الآن :)
uderik ، لم يعد runtime
موجودًا في مخطط تنسيق ملف الإنشاء الحالي 3.7 ، ولا في الإصدار 3.8 المعلق الذي يجب أن يتماشى في النهاية مع Docker 19.03: https://github.com/docker/compose/blob/ 5e587d574a94e011b029c2fb491fb0f4bdeef71c / compose / config / config_schema_v3.8.json
johncolby runtime
لم يكن أبدًا علامة 3.x. إنه موجود فقط في المسار 2.x (2.3 و 2.4).
نعم ، أعلم ، وعلى الرغم من أن ملف docker-compose.yml الخاص بي يتضمن version: '2.3'
(الذي نجح في الماضي) يبدو أنه تم تجاهله من خلال أحدث الإصدارات ...
بالنسبة للمشاريع المستقبلية ، ما هي الطريقة الصحيحة لتمكين / تعطيل الوصول إلى وحدة معالجة الرسومات؟ فقط جعلها الافتراضي + متغيرات env؟ أم أنه سيكون هناك دعم للعلامة --gpus
؟
@ johncolby ما هو استبدال runtime
في 3.X؟
@ 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://github.com/docker/swarmkit/blob/master/design/generic_resources.md
فيما يلي مشكلة الإنشاء المتعلقة بدعم مخطط 3.8 ، والذي تم دمجه بالفعل في: https://github.com/docker/compose/issues/6530
على الجانب الخفي ، يمكن تسجيل إمكانية gpu
خلال تضمينها في daemon.json
أو dockerd
CLI (مثل الحل السابق لوقت التشغيل المشفر مسبقًا) ، شيء مثل
/usr/bin/dockerd --node-generic-resource gpu=2
والتي يتم تسجيلها بعد ذلك عن طريق التثبيت في الأداة المساعدة لرسو السفن NVIDIA:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go
يبدو أن الماكينة موجودة بشكل أساسي ، وربما تحتاج فقط إلى التوثيق ...
أي تحديث؟
أيضًا في انتظار التحديثات ، باستخدام bash
مع docker run --gpus
حتى الإصلاح الرسمي ...
في انتظار التحديثات asw ell.
أيضا في انتظار التحديثات :)
حسنًا ... لا أفهم لماذا لا يزال هذا مفتوحًا. هذه الأسطر الثلاثة الإضافية تجعله يعمل مع الإصدار 3.7 من المخطط. يسعدني معرفة أن عامل الشحن يستجيب لقضايا المجتمع التافهة. لذا ، قم باستنساخ هذا الريبو ، وقم بإضافة هذه الأسطر الثلاثة ، و python3 setup.py قم ببنائه وتثبيته ، وتأكد من أن 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'),
لقد أضفت للتو مشكلة داخلية لتتبع ذلك.
تذكر أن العلاقات العامة موضع ترحيب: مبتسم:
حسنًا ... لا أفهم لماذا لا يزال هذا مفتوحًا. هذه الأسطر الثلاثة الإضافية تجعله يعمل مع الإصدار 3.7 من المخطط. يسعدني معرفة أن عامل الشحن يستجيب لقضايا المجتمع التافهة. لذا ، قم باستنساخ هذا الريبو ، وقم بإضافة هذه الأسطر الثلاثة ، و python3 setup.py قم ببنائه وتثبيته ، وتأكد من أن 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 كافٍ ، لأن
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
لا أفهم ما يجري هنا:
1) لدي في /etc/docker/daemon.json
{
"runtimes": {
"nvidia": {
"path": "nvidia-container-runtime",
"runtimeArgs": []
}
}
}
ولكن لا يمكن استخدام المفتاح runtime
بعد الآن في الإصدار 3.x كما هو الحال في https://github.com/docker/compose/issues/6239
لقد حاولت أيضا:
{
"default-runtime": "nvidia",
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
}
}
لذلك لا يمكنني بدء حاوياتي بدعم gpu على docker-compose
بعد الآن:
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!
أي إتا؟
يتم تتبعها داخليًا كـ https://docker.atlassian.net/browse/COMPOSE-82
+1 ستكون ميزة مفيدة لإنشاء عامل ميناء
ستكون هذه الميزة إضافة رائعة إلى docker-compose
الآن الحل الخاص بي لهذا هو استخدام الإصدار 2.3 من ملف إنشاء عامل ميناء ، والذي يدعم وقت التشغيل ، وتثبيت وقت تشغيل nvidia-container-runtime يدويًا (حيث لم يعد مثبتًا مع nvidia-docker)
كما أنني أقوم بإعداد إعدادات وقت التشغيل في /etc/docker/daemon.json (ليس كإعداد افتراضي ، فقط كوقت تشغيل متاح).
باستخدام هذا يمكنني استخدام ملف إنشاء على النحو التالي:
version: '2.3'
services:
test:
image: nvidia/cuda:9.0-base
runtime: nvidia
الآن الحل الخاص بي لهذا هو استخدام الإصدار 2.3 من ملف إنشاء عامل ميناء ، والذي يدعم وقت التشغيل ، وتثبيت وقت تشغيل nvidia-container-runtime يدويًا (حيث لم يعد مثبتًا مع nvidia-docker)
كما أنني أقوم بإعداد إعدادات وقت التشغيل في /etc/docker/daemon.json (ليس كإعداد افتراضي ، فقط كوقت تشغيل متاح).
باستخدام هذا يمكنني استخدام ملف إنشاء على النحو التالي:version: '2.3' services: test: image: nvidia/cuda:9.0-base runtime: nvidia
arruda هل تمانع في مشاركة daemon.json
فضلك؟
الآن الحل الخاص بي لهذا هو استخدام الإصدار 2.3 من ملف إنشاء عامل ميناء ، والذي يدعم وقت التشغيل ، وتثبيت وقت تشغيل nvidia-container-runtime يدويًا (حيث لم يعد مثبتًا مع nvidia-docker)
كما أنني أقوم بإعداد إعدادات وقت التشغيل في /etc/docker/daemon.json (ليس كإعداد افتراضي ، فقط كوقت تشغيل متاح).
باستخدام هذا يمكنني استخدام ملف إنشاء على النحو التالي:version: '2.3' services: test: image: nvidia/cuda:9.0-base runtime: nvidia
arruda هل تمانع في مشاركة
daemon.json
فضلك؟
نعم ، لا مشكلة ، ها هي:
{
"runtimes": {
"nvidia": {
"path": "nvidia-container-runtime",
"runtimeArgs": []
}
}
}
مرحبا
لدي تطبيق يتطلب برامج تشغيل NVIDIA. لقد قمت ببناء صورة عامل إرساء بناءً على (من)
nvidia / cudagl: 10.1-runtime-ubuntu18.04
باستخدام النهج الموصى به أعلاه - هل يعني ذلك أن صورتي لا تحتاج إلى الاشتقاق من nvidia / cudagl: 10.1-runtime-ubuntu18.04 ؟ أي يمكنني ببساطة الاشتقاق من (من) بيثون: 3.7.3 امتداد
وأضف وقت التشغيل: nvidia إلى الخدمة في docker-compose؟
شكر
rfsch لا ، هذا شيء مختلف. يشير runtime: nvidia
in docker-compose إلى وقت تشغيل Docker. هذا يجعل وحدة معالجة الرسومات متاحة للحاوية. لكنك لا تزال بحاجة إلى طريقة ما لاستخدامها بمجرد إتاحتها. يشير runtime
في nvidia/cudagl:10.1-runtime-ubuntu18.04
إلى مكونات وقت تشغيل CUDA. يتيح لك هذا استخدام وحدات معالجة الرسومات (المتوفرة في حاوية بواسطة Docker) باستخدام CUDA.
في هذه الصورة:
يستبدل runtime: nvidia
جزء runc / containerd. nvidia/cudagl:10.1-runtime-ubuntu18.04
خارج الصورة تمامًا .
نحن بحاجة إلى هذه الميزة
@ 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://github.com/docker/swarmkit/blob/master/design/generic_resources.mdفيما يلي مشكلة الإنشاء المتعلقة بإنشاء 3.8 دعم المخطط ، والذي تم دمجه بالفعل في: # 6530
على الجانب الخفي ، يمكن تسجيل إمكانية
gpu
خلال تضمينها فيdaemon.json
أوdockerd
CLI (مثل الحل السابق لوقت التشغيل المشفر مسبقًا) ، شيء مثل/usr/bin/dockerd --node-generic-resource gpu=2
والتي يتم تسجيلها بعد ذلك عن طريق التثبيت في الأداة المساعدة لرسو السفن NVIDIA:
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)
أي اقتراحات؟
شكر
ديفيد
تثبيت nvidia-container-runtime 3.1.4.1
من https://github.com/NVIDIA/nvidia-container-runtime ووضع
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
على سبيل المثال ، حاوية nvidia / cudagl / 10.1-base من dockerhub. لقد جربت عرض cuda و OpenGL وكلها قريبة من الأداء الأصلي.
متتبع داخليا كـ COMPOSE-82
يرجى ملاحظة أن مثل هذا التغيير يجب أن يتم تنفيذه أيضًا في docker stack
(https://github.com/docker/cli/blob/master/cli/compose/types/types.go#L156) لتحقيق الاتساق
تثبيت
nvidia-container-runtime 3.1.4.1
من https://github.com/NVIDIA/nvidia-container-runtime ووضع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
على سبيل المثال ، حاوية nvidia / cudagl / 10.1-base من dockerhub. لقد جربت عرض cuda و OpenGL وكلها قريبة من الأداء الأصلي.
هل يمكنك مشاركة عامل البناء 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
هل يمكنك مشاركة عامل البناء 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-face ، muru ، تأليف v2 يعمل ،
لقد أخطأت في فهم الحل الخاص بك هو إنشاء الإصدار 3.
للسجل ، من الناحية التقليدية: إنشاء الإصدار 2 ليس أقدم من إنشاء الإصدار 3. إنها حالات استخدام مختلفة. v3 موجه نحو سرب بينما v2 ليس كذلك. الإصدار 1 قديم.
هل هناك أي نقاش حول دعم Docker-compose لدعم Docker الأصلي لوحدة معالجة الرسومات؟
دعم الخيار runtime
ليس هو الحل لدعم GPU في المستقبل. تصف NVIDIA مستقبل nvidia-docker2 في https://github.com/NVIDIA/nvidia-docker على النحو التالي.
لاحظ أنه مع إصدار Docker 19.03 ، تم إهمال استخدام حزم nvidia-docker2 نظرًا لأن وحدات معالجة الرسومات NVIDIA مدعومة الآن كأجهزة في وقت تشغيل Docker.
حاليًا ، يمكن تحقيق دعم GPU من خلال تغيير وقت التشغيل ، ولكن من المحتمل جدًا ألا ينجح ذلك في المستقبل.
لأكون صريحًا ، قد لا تكون هذه هي أفضل ممارسة ، ولكن بطريقة ما نجعلها تعمل.
الجزء الصعب هو أنه يتعين علينا التمسك بـ docker-compose v3.x نظرًا لأننا نستخدم docker swarm ، وفي الوقت نفسه نريد استخدام Nvidia Runtime لدعم GPU / CUDA في الحاويات.
لتجنب إخبار Nvidia Runtime صراحةً داخل ملف إنشاء عامل ميناء ، قمنا بتعيين Nvidia كوقت تشغيل افتراضي في /etc/docker/daemon.json
، وسيبدو
{
"default-runtime":"nvidia",
"runtimes": {
"nvidia": {
"path": "nvidia-container-runtime",
"runtimeArgs": []
}
}
}
بحيث تعمل جميع الحاويات التي تعمل على أجهزة GPU على تمكين وقت تشغيل Nvidia افتراضيًا.
آمل أن يساعد هذا شخصًا ما في مواجهة مانع مماثل
لأكون صريحًا ، قد لا تكون هذه هي أفضل ممارسة ، ولكن بطريقة ما نجعلها تعمل.
الجزء الصعب هو أنه يتعين علينا التمسك بـ docker-compose v3.x نظرًا لأننا نستخدم docker swarm ، وفي الوقت نفسه نريد استخدام Nvidia Runtime لدعم GPU / CUDA في الحاويات.
لتجنب إخبار Nvidia Runtime صراحةً داخل ملف إنشاء عامل ميناء ، قمنا بتعيين Nvidia كوقت تشغيل افتراضي في
/etc/docker/daemon.json
، وسيبدو{ "default-runtime":"nvidia", "runtimes": { "nvidia": { "path": "nvidia-container-runtime", "runtimeArgs": [] } } }
بحيث تعمل جميع الحاويات التي تعمل على أجهزة GPU على تمكين وقت تشغيل Nvidia افتراضيًا.
آمل أن يساعد هذا شخصًا ما في مواجهة مانع مماثل
هذا في الواقع ما نقوم به أيضًا. إنه يعمل في الوقت الحالي ، لكنه يشعر ببعض الاختراق بالنسبة لي. على أمل الحصول على الدعم الكامل لـ compose-v3 قريبًا. :)
هل المقصود أن يقوم المستخدم بتعبئة
/etc/docker/daemon.json
يدويًا بعد الترحيل إلى عامل الإرساء> =19.03
وإزالةnvidia-docker2
لاستخدامnvidia-container-toolkit
بدلاً من ذلك؟يبدو أن هذا يكسر الكثير من المنشآت. بشكل خاص ، نظرًا لأن
--gpus
غير متوفر فيcompose
.
--gpus غير متوفر في عملية الإنشاء
لا يمكنني استخدام pycharm لربط عامل ميناء لتشغيل tensorflow-gpu
أي تحديثات بشأن هذه المسألة؟ هل هناك احتمال أن --gpus سيتم دعمه في Docker-compose قريبًا؟
لأولئك منكم الذين يبحثون عن حل بديل ، انتهى بنا الأمر إلى القيام به:
ثم قم بتشغيل 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"
تحت Docker 19.03.0 Beta 2 ، تم تقديم دعم NVIDIA GPU في شكل واجهة برمجة تطبيقات CLI الجديدة - gpus. docker / cli # 1714 يتحدث عن هذا التمكين.
الآن يمكن للمرء ببساطة تمرير خيار gpus لتطبيق Docker المسرع بواسطة GPU.
$ 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://blog.csdn.net/u010420283/article/details/104055046
~ sudo apt-get install nvidia-container-runtime
~ sudo vim /etc/docker/daemon.json $
ثم ، في ملف daemon.json هذا ، أضف هذا المحتوى:
{
"وقت التشغيل الافتراضي": "nvidia"
"أوقات التشغيل": {
"nvidia": {
"المسار": "/ usr / bin / nvidia-container-runtime" ،
"runtimeArgs": []
}
}
}
~ $ sudo systemctl البرنامج الخفي لإعادة التحميل
~ $ sudo systemctl إعادة تشغيل عامل ميناء
بالنسبة للمستخدمين المجهولين الذين يرغبون في إعداد الحل البديل الموصوف سابقًا ، هناك دور لتثبيت nvidia-container-runtime وتهيئة /etc/docker/deamon.json لاستخدام runtime: nvidia
:
https://github.com/NVIDIA/ansible-role-nvidia-docker
(لسبب ما ، يتم تشغيله فقط على Ubuntu و RHEL ، ولكن من السهل تعديله. أقوم بتشغيله على دبيان)
ثم في docker-compose.yml :
version: "2.4"
services:
test:
image: "nvidia/cuda:10.2-runtime-ubuntu18.04"
command: "nvidia-smi"
أي تحديث على إصدار 3.x الرسمي مع دعم gpu؟ نحن بحاجة إلى سرب :)
هل هناك أي خطة لإضافة هذه الميزة؟
تعتمد هذه الميزة على تطبيق docker-py للمعلمات device_requests
، وهو ما يترجم إليه --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 ، أنا أكثر من سعيد لجعل العلاقات العامة أكثر امتثالًا ولكن نظرًا لأنه لم يحظ باهتمام كبير ، لا أريد أن أضيع وقتي في شيء لن يتم دمجه ...
الرجاء إضافة هذه الميزة ، ستكون رائعة!
من فضلك ، أضف هذه الميزة! كنت أكثر من سعيد مع nevidia-docker2 القديم ، والذي سمح لي بتغيير وقت التشغيل في daemon.json. سيكون لطيفا للغاية لاستعادة هذا.
في حاجة إليها من فضلك. أحتاجه حقًا: /
أود أن أتراكم أيضًا ... نحن بحاجة إلى هذه الميزة!
أحتاج إلى تشغيل حاويات وحدة المعالجة المركزية ووحدة معالجة الرسومات على نفس الجهاز حتى لا يعمل اختراق وقت التشغيل الافتراضي بالنسبة لي. هل لدينا أي فكرة متى سيعمل هذا على التأليف؟ بالنظر إلى أنه ليس لدينا علامة وقت التشغيل في الإنشاء ، فهذا يمثل تراجعًا وظيفيًا خطيرًا ، أليس كذلك؟ أنا مضطر إلى كتابة نصوص لكي أجعل هذا العمل - رائع!
أحتاج إلى تشغيل حاويات وحدة المعالجة المركزية ووحدة معالجة الرسومات على نفس الجهاز حتى لا يعمل اختراق وقت التشغيل الافتراضي بالنسبة لي. هل لدينا أي فكرة متى سيعمل هذا على التأليف؟ بالنظر إلى أنه ليس لدينا علامة وقت التشغيل في الإنشاء ، فهذا يمثل تراجعًا وظيفيًا خطيرًا ، أليس كذلك؟ أنا مضطر إلى كتابة نصوص لكي أجعل هذا العمل - رائع!
يمكنك القيام بذلك عن طريق docker cli (docker run - GPU ....) ، لدي هذا النوع من الحيل (عن طريق إضافة وكيل ، حتى أكون قادرًا على التواصل مع الحاويات الأخرى التي تعمل على العقد الأخرى على السرب). نحن جميعًا ننتظر القدرة على تشغيله على سرب ، لأنه لا يعمل بأمر خدمة عامل التحميل (كما أعرف) ولا عن طريق الإنشاء.
تضمين التغريدة نعم ؛-). إنني على علم بهذا ومن ثم الإشارة إلى النصوص. لكن هذه طريقة فظيعة جدًا وغير محمولة للقيام بذلك ، لذا أود القيام بذلك بطريقة أكثر ديناميكية. كما قلت ، أعتقد أن هذا يمثل تراجعًا ، وليس ميزة تسأل.
COMPOSE_API_VERSION=auto docker-compose run gpu
ggregoire أين ندير: COMPOSE_API_VERSION = إنشاء عامل تشغيل تلقائي لتشغيل gpu؟
joehoeller من
في الوقت الحالي ، نقرر لكل مشروع ما إذا كنا بحاجة إلى ميزات 3.x أو إذا كان بإمكاننا استخدام docker-compose 2.x حيث لا يزال خيار GPU مدعومًا. لا يمكن للأسف استخدام ميزات مثل تشغيل أهداف متعددة المراحل من Dockerfile إذا كانت GPU ضرورية. الرجاء إضافة هذا مرة أخرى!
أود أن أوصي بشيء مثل حقل "الخيارات الإضافية" لـ Docker-compose حيث يمكننا فقط إضافة علامات مثل --gpus=all
إلى أمر بدء / تشغيل عامل الإرساء ، والتي لم يتم دعمها بعد / بعد الآن في docker-compose ولكن في أحدث إصدار عامل ميناء. بهذه الطريقة ، لن يضطر المستخدمون المؤلفون إلى انتظار إنشاء عامل ميناء للحاق بالركب إذا كانوا بحاجة إلى ميزة عامل إرساء جديدة غير مدعومة بعد.
لا يزال من الضروري تشغيل هذا على Docker Swarm لبيئات الإنتاج. هل سيكون هذا مفيدًا بواسطة Docker Swarm؟
sebastianfelipe إنه مفيد جدًا إذا كنت تريد
قارن:
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 إنه مفيد جدًا إذا كنت تريد
قارن:
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 Swarm باستخدام ملف yaml-compose docker؟ فقط للتأكد: يا. شكر!
فقط لعمال الإرساء يؤلف 2.x.
بيت القصيد من هذه المشكلة هو طلب دعم nvidia-docker gpu ل docker-compose 3+
لقد مر عام تقريبا على الطلب الأصلي !! لماذا التأخير؟؟ هل يمكننا المضي قدما ؟؟
MustafaHosny اللهم امين يارب . أي تحديث على هذا؟
لأولئك منكم الذين يبحثون عن حل بديل ، انتهى بنا الأمر إلى القيام به:
- قم بتثبيت docker-py من PR: docker / docker-py # 2471
- قم بتثبيت docker-compose من PR: # 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 !
لا تزال تنتظر بفارغ الصبر التصحيح الرسمي. مع وجود جميع العلاقات العامة في مكانها الصحيح ، لا يبدو الأمر صعبًا بأي معيار.
MustafaHosny اللهم امين يارب . أي تحديث على هذا؟
لا ، لا أعرف لماذا تم استدعائي.
أريدك أن تخبرني ماذا أفعل؟
آمل أن يكون هناك تحديث لهذا.
نعم ، لقد مر أكثر من عام الآن ... لماذا لم يتم دمجهم في 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: أنا في حيرة من أمري: هذا يمثل تراجعًا عن السلوك السابق ، فلماذا يحتاج إلى مواصفات ميزة جديدة؟ أليس من المعقول تشغيل الحاويات ، وبعضها يستخدم وحدة معالجة الرسومات وبعضها يستخدم وحدة المعالجة المركزية في نفس الصندوق المادي؟
شكرا للنظر.
@ vk1z لم يكن لدى AFAIK Docker هذه . بعد ذلك ، يجب أن يكون مجرد سباكة في الخلفية.
مرحبًا يا شباب ، لقد جربت بعض الحلول المقترحة هنا ولم ينجح شيء معي ، على سبيل المثال miriaford لم تنجح في حالتي ، هل هناك أيضًا طريقة ما لاستخدام GPU لتشغيل حاويات الإرساء الموجودة لدي؟
لديّ i7 بسعة 16 غيغابايت من ذاكرة الوصول العشوائي ، لكن بناء بعض المشاريع يستغرق وقتًا طويلاً لإكماله ، وهدفي هو أيضًا استخدام طاقة وحدة معالجة الرسومات لتسريع العملية ، فهل هذا ممكن؟ شكر!
@ chris-crone: مرة أخرى ، سأكون على استعداد للتصحيح ، لكن لم يكن ذلك بسبب وقت التشغيل: اختفت المعلمة من الإنشاء بعد 2.4 config؟ لهذا شعرت أنه كان تراجعًا. لكن لا ، يهم الآن لأننا جميعًا يجب أن نكون في 3.x على أي حال.
يسعدني تقديم مشكلة ، فهل نفعل ذلك مقابل المواصفات الموجودة في الريبو الخاص بالمواصفات ، صحيح؟
ولكن ألم يكن ذلك لأن وقت التشغيل: اختفت المعلمة من الإنشاء بعد تكوين 2.4؟ لهذا شعرت أنه كان تراجعًا.
نعم بالضبط. لديّ مشروعان نعتمد فيهما على استخدام runtime: nvidia
في ملفات إنشاء عامل الإرساء ، وهذه المشكلة تمنعنا من الترقية إلى 3.x لأننا لم نجد طريقة لاستخدام وحدات معالجة الرسومات هناك.
مرحبًا ، من فضلك ، من فضلك ، أصلح هذا.
يجب وضع علامة على الأولوية الحرجة للمهمة - 20
مرة أخرى ، سأكون على استعداد للتصحيح ، لكن لم يكن ذلك لأن وقت التشغيل: اختفى المعامل من الإنشاء بعد 2.4 config؟ لهذا شعرت أنه كان تراجعًا. لكن لا ، يهم الآن لأننا جميعًا يجب أن نكون في 3.x على أي حال.
لم أكن هنا عند إجراء التغيير ، لذا لست متأكدًا بنسبة 100٪ من سبب إسقاطه. أعلم أنك لم تعد بحاجة إلى وقت تشغيل NVIDIA لاستخدام وحدات معالجة الرسومات وأننا نعمل على تطوير مواصفات Compose v3 في العراء هنا بهدف إنشاء إصدار واحد من المواصفات. قد يعني هذا نقل بعض وظائف v2 إلى v3.
فيما يتعلق بالحقل runtime
، لا أعتقد أن هذه هي الطريقة التي يجب إضافتها إلى مواصفات Compose لأنها خاصة جدًا للتشغيل على عقدة واحدة. من الناحية المثالية ، نرغب في شيء يسمح لك بتحديد أن عبء العمل لديك يحتاج إلى جهاز (على سبيل المثال: GPU ، TPU ، أي شيء يأتي بعد ذلك) ثم ندع المنظم يعين عبء العمل إلى عقدة توفر هذه الإمكانية.
يجب إجراء هذه المناقشة حول المواصفات على الرغم من أنها ليست محددة في Python Docker Compose.
@ كريس كرون: أنا أتفق في الغالب مع بيانك. ربما تكون إضافة الاختراقات قصيرة المدى هي الطريقة غير الصحيحة للقيام بذلك نظرًا لأن لدينا عددًا متنوعًا من الأجهزة المتطورة لكل منها أوقات التشغيل الخاصة بها. على سبيل المثال ، كما أشرت ، TPU (Google) و VPU (Intel) و ARM GPU على Pi. لذلك نحن بحاجة إلى قصة أكثر اكتمالاً.
سأرفع قضية مقابل المواصفات اليوم وأقوم بتحديث هذا الموضوع بمجرد القيام بذلك. ومع ذلك ، أعتقد أن المنسق يجب أن يكون مستقلاً - مثل إذا كنت أرغب في استخدام Kube ، يجب أن أكون قادرًا على القيام بذلك. أفترض أن هذا سيكون في النطاق.
ومع ذلك ، فأنا لا أتفق مع بيان استخدام وحدات معالجة الرسومات ، لأن ذلك لا يعمل مع إنشاء - وهو ما يدور حوله كل هذا. لكن أعتقد أننا جميعًا نفهم المشكلة التي نرغب في حلها.
@ كريس كرون: يرجى الاطلاع على قضية مواصفات عامل عامل البناء المؤلفة المقدمة. سأتابع التحديثات الخاصة بهذه المشكلة من الآن فصاعدًا.
هل يمكننا ببساطة إضافة خيار (شيء مثل extra_docker_run_args
) لتمرير الوسائط مباشرة إلى docker run
؟ لن يحل هذا المشكلة الحالية فحسب ، بل سيكون أيضًا دليلًا على المستقبل: ماذا لو أضاف عامل الشحن دعمًا لأي "XPU" أو "YPU" أو أي ميزات جديدة أخرى قد تأتي في المستقبل؟
إذا احتجنا إلى مناقشة طويلة ذهابًا وإيابًا في كل مرة يضيف فيها عامل التحميل ميزة جديدة ، فسيكون ذلك غير فعال للغاية وسيؤدي إلى تأخير لا مفر منه (وارتباك غير ضروري) بين docker-compose
و docker
تحديثات يمكن أن يوفر دعم تفويض الحجة راحة مؤقتة لهذه المشكلة المتكررة لجميع الميزات المستقبلية.
miriaford لست متأكدًا من أن تمرير النقطة غير المفسرة يدعم فكرة الإنشاء عن كونها
لكنني أوافق على أنه يجب مزامنة التركيب و docker وأن تشغيل ميزات العمل التي يعتمد عليها الأشخاص (على الرغم من أنه كان إصدارًا رئيسيًا) ليس كوشير تمامًا.
@ vk1z أوافق - يجب أن تكون هناك آلية مزامنة أفضل بكثير بين compose
و docker
. ومع ذلك ، لا أتوقع أن يتم تصميم مثل هذه الآلية في أي وقت قريب. وفي الوقت نفسه ، نحتاج أيضًا إلى طريقة مؤقتة لإجراء المزامنة الخاصة بنا دون الاختراق بعمق في شفرة المصدر.
إذا لم يكن اقتراح تفويض النقاش خيارًا ، فماذا نقترح أن نفعل؟ أوافق على أنه ليس حلاً جيدًا ، لكنه على الأقل أفضل بكثير من هذا الحل ، أليس كذلك؟ https://github.com/docker/compose/issues/6691#issuecomment -616984053
miriaford عامل ميناء-يؤلف لا يدعو السلطة التنفيذية عامل ميناء مع الحجة، ويستخدم في الواقع docker_py الذي يستخدم API HTTP إلى الخفي عامل ميناء. لذلك لا يوجد أمر "أساسي docker run
". إن Docker CLI ليس واجهة برمجة تطبيقات ، اتصال المقبس هو نقطة اتصال API. هذا هو السبب في أن الأمر ليس بهذه السهولة دائمًا.
لتبسيط الأمور ، في عملية تشغيل عامل الإرساء ، هناك مكالمتان رئيسيتان ، أحدهما يقوم بإنشاء الحاوية ، والآخر يبدأ تشغيله ، ويستوعب كل منهما أجزاء مختلفة من المعلومات ، ومعرفة أيهما يستغرق شخصًا ما لديه معرفة بواجهة برمجة التطبيقات ، والتي لا أعرف أنني أميل إلى معرفة CLI docker
. لا أعتقد أن القدرة على إضافة حجج إضافية إلى مكالمات docker_py ستكون مفيدة كما تعتقد ، باستثناء حالات الاستخدام المحددة.
لجعل الأمور أكثر صعوبة ، أحيانًا تكون مكتبة docker_py خلف واجهة برمجة التطبيقات ، ولا تحتوي على كل ما تحتاجه على الفور أيضًا ، وعليك الانتظار حتى يتم تحديثها. كل ما يقال ، extra_docker_run_args
ليس حلاً بسيطًا.
andyneff شكرا على 4 واجهات برمجة تطبيقات يجب مزامنتها يدويًا لأي تحديثات ميزات جديدة:
docker_py
يوفر واجهة Python الأمامية لواجهة برمجة تطبيقات المقبسهذا يطرح السؤال: لماذا لا توجد آلية مزامنة تلقائية (أو على الأقل شبه آلية)؟ يبدو أن نشر تحديثات الميزات الجديدة عبر 4 واجهات برمجة تطبيقات محكوم عليه بأن يكون عرضة للخطأ ، وعرضة للتأخير ، ومربك ...
ملاحظة: لا أقول إنها مهمة _بسيطة_ أن يكون لديك مزامنة تلقائية ، لكنني أعتقد حقًا أنه يجب أن يكون هناك واحد لجعل الحياة أسهل في المستقبل.
أنا أدخل الآن نوعا ما في التحذلق ... لكن كما سأصفها على أنها ...
socat
)docker
واجهة برمجة التطبيقات هذه لمنحنا المستخدمين أداة رائعةإذن نعم ، إنه يذهب:
لا يمكنني التحدث عن docker_py أو الإنشاء ، لكني أتخيل أن لديهم ساعات عمل محدودة تساهم في ذلك ، لذلك من الصعب مواكبة جميع ميزات عامل الإرساء المجنونة التي يضيفها عامل الإرساء باستمرار. ولكن نظرًا لأن docker هي مكتبة go ، وأنا أفهم أن دعم Python ليس (حاليًا) مواطنًا من الدرجة الأولى. على الرغم من أنه من الجيد أن يكون كلا المشروعين تحت مظلة عامل ميناء ، على الأقل من وجهة نظر مؤسسة جيثب.
بعد كل ما قيل ... أنا أيضًا أنتظر دعمًا يعادل --gpus
، ويجب أن أستخدم طريقة runtime: nvidia
القديمة بدلاً من ذلك ، والتي ستمنحني على الأقل مسارًا للتحرك إلى الأمام في Docker-Compose 2.x.
andyneff FYI ، يوجد دعم Docker CLI في أحدث تكوين عامل عامل ميناء. يسمح باستخدام buildkit على سبيل المثال. https://www.docker.com/blog/faster-builds-in-compose-thanks-to-buildkit-support/
andyneff هذه نظرة عامة مفيدة للغاية! شكرا لك مرة أخرى
lig رائع! شكرا على التصحيح! كنت أفكر في الواقع "كيف ستلائم مجموعة البناء كل هذا" بينما كنت أكتب ذلك
ما أدهشني بعض الشيء هو أن تكوين عامل الإرساء هو جزء جوهري جدًا من إطار عمل تطبيق عامل الإرساء الجديد ، وأتخيل أنهم سيرغبون في مزامنة تكوين عامل الإرساء وعمال الإرساء لهذا السبب على الأقل. أتساءل ما هو هذا المانع حقًا: لا يكفي عرض نطاق بيثون؟ يبدو قليلا لا يصدق.
إذن كيف يتناسب Docker Swarm مع الهيكل الذي وصفه andyneff للتو؟ يستخدم Swarm الإصدار 3 من تنسيق ملف الإنشاء (محدد بواسطة مشروع "إنشاء"؟) ولكن تم تطويره كجزء من docker
؟
نعتذر إذا كان هذا خارج الموضوع عن هذه المشكلة بالذات. لقد فقدت تتبع أي مشكلة لكنني بدأت في متابعة هذا لأنني أود أن أكون قادرًا على إخبار خدمة تعمل على سرب أنها تحتاج إلى استخدام وقت تشغيل معين. لا يمكننا فعل ذلك إلا باستخدام الإصدار 2 من مواصفات ملف الإنشاء مما يعني أنه لا يمكننا فعل ذلك باستخدام Swarm الذي يتطلب الإصدار 3. بعبارة أخرى ، لست مهتمًا حقًا بما يفعله عامل الإرساء CLI ولكن فقط في المواصفات المحددة لملفات docker-compose.yml التي يستهلكها docker swarm.
يا سرب اللي هرب مني ... (مني). للأسف هذا هو # 6239 الذي أغلقه BOT. (حاول شخص ما في # 6240 لكن قيل له ...
miriaford ، يبدو أن هناك
لذلك بسبب طبيعة السرب ، هناك أشياء معينة تفعلها ولا تفعلها على عقد السرب. لذلك لا تسمح لك Docker API دائمًا بالقيام بنفس الخيارات في تشغيل سرب ، مثل التشغيل العادي. لا أعرف ما إذا كان وقت التشغيل هو أحد هذه الأشياء خارج متناول اليد ، ولكن هذا غالبًا ما يجعلك لا تستطيع فعل أشياء في الإصدار 3 (الإصدار المتوافق مع السرب) ويمكنه في الإصدار 2 (الإصدار غير المتوافق مع السرب).
لا أحد يقرأ هذا يعرف ما تتحدث عنه يا رفاق.
نحاول جميعًا نشر jellyfin مع تسريع الأجهزة.
حتى تقوموا بإصلاح هذا مرة أخرى بالطريقة التي يفترض أن تكون ، عندما تقول الخدمة ، 3.x ليست جيدة.
لا تستخدمها.
تحتاج إلى وضع 2.4 للخدمة.
ثم يمكنك استخدام تسريع الأجهزة لـ jellyfin ، ez
هيا يا رفاق ، ما هو ETA في هذا ، 1 سنة ، 2 سنة؟
KlaasHulyssessouzaGoryudyuma @ كريس-شمطاء مرحبا، أنا أعمل على هذا الموضوع، وجدت أن الدعم كان في عداد المفقودين في "عامل ميناء-الحمر"، عملت على هذا الجزء. الآن لكي تعمل ، أحتاج إلى تمرير التكوينات عبر ملف docker-compose.yml. هل يمكنك مساعدتي في المخطط؟ على سبيل المثال ، من أجل إضافته ، يجب أن أقوم بإضافته إلى مخطط جديد أو هل هناك أي مكان يمكن فيه تمرير التكوينات
fakabbir أفترض أنه لا بأس من استخدام COMPOSE_DOCKER_CLI_BUILD
لهذا الغرض. يمكن أن تساعد إضافة القدرة على توفير قائمة تعسفية للوسائط docker run
على تجنب مشكلات مماثلة في المستقبل.
lig كيف تتعامل عندما تتطلب خدمة واحدة فقط الوصول إلى وحدة معالجة الرسومات؟
يستخدم تطبيق docker-py
بدلاً من docker run
cli. لذا فإن إضافة وسيطات docker run
تعسفية لن تعمل إلا إذا كان docker-py
يدعمها أيضًا.
المرجع: https://github.com/docker/compose/issues/6691#issuecomment -585199425
هذا الشيء الوحيد يقلل من فائدة عامل عامل البناء بشكل كبير لكثير من الناس. إنه لم يلاحظ الكثير من الاهتمام والرغبة في إصلاحه ، خاصةً عندما كان يعمل في إنشاء عامل عمال أقدم ، وهو أمر مذهل للغاية.
ألن تكون إحدى الطرق التي يجب اتباعها هي السماح بإعطاء وسيطات تشغيل عامل ميناء تعسفي في ملف إنشاء عامل ميناء؟ ثم يمكن تمرير --gpus all على سبيل المثال إلى عامل الإرساء.
أفهم أنه يمكن أن تكون هناك أسباب فلسفية أو تقنية قد تجعل المرء يرغب في القيام بذلك بطريقة معينة. لكن عدم القيام بذلك بأي شكل من الأشكال يذهل العقل.
lig كيف تتعامل عندما تتطلب خدمة واحدة فقط الوصول إلى وحدة معالجة الرسومات؟
حسنًا ، متغير البيئة NVIDIA_VISIBLE_DEVICES سيسمح لك بالتحكم في أنه لا؟
هذا الشيء الوحيد يقلل من فائدة عامل عامل البناء بشكل كبير لكثير من الناس. إنه لم يلاحظ الكثير من الاهتمام والرغبة في إصلاحه ، خاصةً عندما كان يعمل في إنشاء عامل عمال أقدم ، وهو أمر مذهل للغاية.
ألن تكون إحدى الطرق التي يجب اتباعها هي السماح بإعطاء وسيطات تشغيل عامل ميناء تعسفي في ملف إنشاء عامل ميناء؟ ثم يمكن تمرير --gpus all على سبيل المثال إلى عامل الإرساء.
لا أعتقد أن السماح بتمرير docker --run
args هو السبيل للذهاب. compose
باستدعاء docker
من تلقاء نفسه ولكنه يستخدم بدلاً من ذلك docker-py
.
أفهم أنه يمكن أن تكون هناك أسباب فلسفية أو تقنية قد تجعل المرء يرغب في القيام بذلك بطريقة معينة. لكن عدم القيام بذلك بأي شكل من الأشكال يذهل العقل.
العلاقات العامة مفتوحة حول هذا الموضوع: https://github.com/docker/compose/pull/7124. لا تتردد في "الحصول على يديك".
أعتقد أنه وفقًا للتغيير في مواصفات تكوين عامل الإرساء ، يجب أن نعود قريبًا إلى التوافق السابق وفقًا لتكوين 2.4 وسيعمل وقت تشغيل nvidia. من الواضح أنه لن يعمل مع TPU أو المسرعات الأخرى - وهو أمر مؤسف للغاية ولكن بالنسبة لأولئك الذين يرغبون في تشغيل nvidia gpus (باهظ الثمن) ، فسوف يعمل.
لذا ، فقط انتظر على العلاقات العامة الخضراء في docker-py ليتم دمجها https://github.com/docker/docker-py/pull/2471
بلى! تمت الموافقة على العلاقات العامة في Docker-py! https://github.com/docker/docker-py/pull/2471
ما هي الخطوة التالية هنا؟
ما الأمر هنا ؟ سيكون من الرائع أن تكون قادرًا على دعم وقت تشغيل nvidia في docker-compose
الآن بعد دمج docker / docker-py # 2471 ، يمكننا تثبيت docker-py من master. ولكن نظرًا لتغير تكوين عامل الإرساء منذ [PR]
بالنسبة لأولئك الذين انتهى بهم المطاف هنا دون رؤية التعليقات السابقة:
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 إلى إعادة تأسيس أم أن هناك علاقات عامة أخرى ستدرج docker-py
؟
مرحبًا بكbkakilli ،
شكرا للمساعدة! لقد جربت للتو اقتراحك ، لكنني حصلت على خطأ أثناء تشغيل إنشاء عامل الإرساء
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 تأكد من تثبيت
pip install git+https://github.com/yoanisgil/compose.git@device-requests
يمكنك محاولة وضع --upgrade
param للتثبيت. وإلا فإنني أشك في إعدادات البيئة الافتراضية. ربما لديك تثبيت آخر لرسو السفن ، والذي يتم استخدامه افتراضيًا؟ على سبيل المثال ، ربما قمت بتثبيته للنظام باستخدام إرشادات "Linux" هنا: https://docs.docker.com/compose/install/ أقترح عليك إلقاء نظرة على "خيارات التثبيت البديلة" والتثبيت عبر النقطة في البيئة الافتراضية (لكن استخدم أمر تثبيت النقطة أعلاه. لا تقم بتثبيت عامل التثبيت الافتراضي من PyPI).
مرحبا!
شكرا على كل المعلومات. كنت أحاول تشغيل أسلوبك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 هل تمكنت من إصلاح هذا الخطأ؟ bkakilliEpicWink أنا بتشغيل إصدار ذكر من نقطة تثبيت ولكن لا يزال الحصول على خطأ ل device_requests param is not supported in API versions < 1.40
حتى لو كنت تصدير هذا المتغير إلى 1.40
لملف تكوين معين
version: "3.7"
services:
spam:
image: nvidia/cuda:10.1-cudnn7-runtime
command: nvidia-smi
device_requests:
- capabilities:
- gpu
باستخدام إصدار docker-compose
المثبت على النحو الوارد أعلاه ، في Bash على Linux ، ينجح الأمر التالي:
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
إذا قمت بتشغيل إعدادي الحالي (كلا الإصدارين التلقائي و 1.40 من api) ، فسأحصل على الخطأ التالي:
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
هل من الممكن أن يكون لها علاقة باستخدام ملفات التجاوز؟ إذا قمت للتو بتشغيل صورة cuda الأساسية باستخدام Docker ، فلا مشكلة في الحصول على ناتج من 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 |
|=============================================================================|
+-----------------------------------------------------------------------------+
لقد قمت بتثبيت docker-compose
باتباع الإرشادات أعلاه من git بعد إلغاء تثبيت الإصدار المثبت من المستندات الرسمية. إليك معلومات الإصدار المثبت:
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 ليست مشكلة ، وآسف
هل يعمل شخص ما على علاقات عامة أخرى أم أننا نقوم بتصحيح أخطاء فرع device-requests
أجل الاستعداد للعلاقات العامة؟
أثناء توقف العلاقات العامة ، قمت بنقل التغييرات من # 7124 إلى أحدث إصدار من الفرع master
لمطابقة التبعيات ، وما إلى ذلك - 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 ، والذي قد يكون قريبًا من generic_resouces
المتاح بالفعل في قسم deploy
.
ndeloof هذا شيء عظيم! إذا كان ذلك ممكنا ، يرجى نشر الرابط للاقتراح هنا. أعتقد أن الكثير من الناس سيكونون سعداء بالمساهمة في ذلك لأن دعم وحدة معالجة الرسومات أمر بالغ الأهمية لعمليات نشر التعلم العميق.
ndeloof تاريخيًا ، ما هي المدة التي تستغرقها اللجنة التوجيهية لاتخاذ القرار ، 6 أشهر ، في السنة؟
+1
+1
visheratin هل هناك فرصة لتحسين الإصلاح بحيث يعمل عند استخدام ملفات yml متعددة الإنشاء؟ لدي قاعدة docker-compose.yml تستخدم حاوية غير nvidia ، والتي أريد تجاوزها مع حاوية nvidia عندما يكون هناك GPU ، ولكن يبدو أنه مع الإصلاح الخاص بك ، إذا قمت بتحديد عدة ملفات yml مع "- f "، تسقط حقول" device_requests "من ملف config.
proximous ماذا تقصد ب "يسقط من التكوين"؟ هل جميع ملفات الإنشاء لها الإصدار 3.8؟ هل يمكنك مشاركة المثال حتى يسهل إعادة إنتاجه؟
وجود مشكلة في الكود في compose / service.py عند محاولة استخدام خيار --scale مع docker-compose up. هل هذا غير مدعوم؟
Traceback (أحدث مكالمة أخيرة):
ملف "/ usr / local / bin / docker-compose" ، السطر 11 ، بتنسيق
load_entry_point ('docker-compose == 1.27.0.dev0'، 'console_scripts'، 'docker-compose') ()
ملف "/usr/local/lib/python3.6/site-packages/compose/cli/main.py" ، السطر 67 ، بشكل رئيسي
أمر()
ملف "/usr/local/lib/python3.6/site-packages/compose/cli/main.py" ، السطر 123 ، في Perform_command
معالج (الأمر ، خيارات الأوامر)
ملف "/usr/local/lib/python3.6/site-packages/compose/cli/main.py" ، السطر 1067 ، في الأعلى
to_attach = up (خطأ)
ملف "/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 ، بالتوازي مع التنفيذ
رفع error_to_reraise
ملف "/usr/local/lib/python3.6/site-packages/compose/parallel.py" ، السطر 206 ، في المنتج
النتيجة = func (obj)
ملف "/usr/local/lib/python3.6/site-packages/compose/project.py" ، السطر 634 ، قيد التنفيذ
override_options = override_options ،
ملف "/usr/local/lib/python3.6/site-packages/compose/service.py" ، السطر 579 ، في execute_convergence_plan
تجديد_ مجهول_المجلدات ،
ملف "/usr/local/lib/python3.6/site-packages/compose/service.py" ، السطر 509 ، في _execute_convergence_recreate
مقياس - لين (حاويات) ، منفصلة ، ابدأ
ملف "/usr/local/lib/python3.6/site-packages/compose/service.py" ، السطر 479 ، في _execute_convergence_create
"خلق"
ملف "/usr/local/lib/python3.6/site-packages/compose/parallel.py" ، السطر 108 ، بالتوازي مع التنفيذ
رفع 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 (self، service_name.number) ،
ملف "/usr/local/lib/python3.6/site-packages/compose/service.py" ، السطر 456 ، في create_and_start
الحاوية = service.create_container (العدد = n ، الهدوء = صحيح)
ملف "/usr/local/lib/python3.6/site-packages/compose/service.py" ، السطر 333 ، في create_container
Previous_container = الحاوية السابقة ،
ملف "/usr/local/lib/python3.6/site-packages/compose/service.py" ، السطر 936 ، في _get_container_create_options
one_off = one_off)
ملف "/usr/local/lib/python3.6/site-packages/compose/service.py" ، السطر 1014 ، في _get_container_host_config
element.split ('،') للعنصر في device_request ['features']]
ملف "/usr/local/lib/python3.6/site-packages/compose/service.py" ، السطر 1014 ، في
element.split ('،') للعنصر في device_request ['features']]
AttributeError: الكائن "قائمة" ليس له سمة "تقسيم"
بعد مزيد من التصحيح ، وجدت أنه عند استخدام مقياس - ، فإنه لسبب ما يحتوي مثيل واحد على device_requests ['إمكانيات'] مثل ['gpu']. ولكن لكي يتم بدء تشغيل جميع الحاويات الأخرى ، فإن device_request ["القدرات"] يبدو بدلاً من ذلك مثل [['gpu']].
لقد أجريت إصلاحًا مؤقتًا محليًا للتغلب على هذه المشكلة لمجرد تشغيل الحاويات الخاصة بي وتشغيلها بدءًا من السطر 1010 في إنشاء / خدمة.
""
من أجل device_request في device_requests:
إذا لم تكن "القدرات" موجودة في device_request:
استمر
إذا اكتب (device_request ['features'] [0]) == list:
device_request ['القدرات'] = [
element.split ('.') للعنصر في device_request ['القدرات'] [0]]
آخر:
device_request ['القدرات'] = [
element.split (".") للعنصر في device_request ['القدرات']]
""
proximous ماذا تقصد ب "يسقط من التكوين"؟ هل جميع ملفات الإنشاء لها الإصدار 3.8؟ هل يمكنك مشاركة المثال حتى يسهل إعادة إنتاجه؟
visheratin انظر هذا المثال ، هل أنا مخطئ في توقع نتيجة مختلفة؟
عامل ميناء compose.nogpu.yml:
version: '3.8'
services:
df:
build: miniconda-image.Dockerfile
عامل ميناء-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'
تكوين سلسلة ymls يبدأ بـ yml غير gpu (ملاحظة ... يفتقد وقت التشغيل):
$ 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'
(من الواضح أنني أحاول القيام بشيء أكثر تفصيلاً وهذه مجرد حالة مبسطة لإبراز السلوك غير المتوقع.)
jlauleproximous من أجل الحفاظ على هذا الموضوع في الموضوع ، يرجى إنشاء مشكلات في الريبو وسأبحث فيها عندما يكون لدي وقت.
بالنسبة لأولئك الذين يحتاجون إلى شيء أثناء الانتظار ، قمت فقط بإعداد K3S (إصدار حافة من Kubernetes) مع دعم GPU في 30 دقيقة باستخدام عامل الإرساء كوقت تشغيل الحاوية (على سبيل المثال ، استخدم الخيار --docker
للتثبيت النصي). اتبع https://github.com/NVIDIA/k8s-device-plugin لتشغيل المكون الإضافي لجهاز Nvidia.
امل ان يساعد!
EpicWink ليست مشكلة ، وآسف
هل سبق لك حل هذا؟
لم يعد هناك شيء مثل "/ usr / bin / nvidia-container-runtime" بعد الآن. القضية لا تزال حرجة.
قم بتثبيت nvidia-docker2 كما هو موضح هنا
لقد تم التعامل مع هذا في الآونة الأخيرة ومعرف الفكر مشاركة مقاربتي.
كانت مشكلتي أنني بحاجة إلى نشر مكدس عامل التحميل ولم أرغب في الاستماع. docker compose لقد عملت مع اختراق إصدار docker api ولكن لم أشعر بالرضا ولن يعمل نشر المكدس بغض النظر.
لذلك بدون تعيين أي وقت تشغيل لطلبات الجهاز في إنشاء عامل الإرساء ، أضفت هذا إلى البرنامج الخفي الخاص بي:
{
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
},
"default-runtime": "nvidia",
"node-generic-resources": [
"NVIDIA-GPU=0"
]
}
يمكنك أيضًا استخدام GPU- {الجزء الأول من دليل gpu}
لكن هذا كان أسهل. لم يكن لديك لتثبيت أي نقطة + أو أي شيء من هذا القبيل باستثناء مجموعة أدوات حاوية NV. ينشر ويعمل مثل السحر.
الكثير من haviduck ، جربت للتو على الجهاز الخاص بي (Ubuntu 20.04 ، docker CE 19.03.8) وعملت مثل السحر.
بالنسبة للآخرين: لا تنس إعادة تشغيل برنامج Docker daemon.
pommedeterresautee آه أنا سعيد جدًا لأنه عمل للآخرين! يجب أن يكون ذكر إعادة التحميل.
يجب أن أقول بعد 3 أسابيع من الالتحام المستمر ، أنا محير جدًا كيف لا شيء يبدو أنه يعمل ..
haviduck : شكرا لك! أخيرًا حل بسيط يعمل فقط. لقد قضيت الكثير من الوقت في محاولة إضافة أجهزة وما إلى ذلك لدرجة أنني استسلمت. ثم يأتي هذا ، ويحاول ذلك وبعد بضع دقائق لديّ تحويل ترميز للأجهزة في Plex يعمل.
سأضيف 2 سنت لهذا الأمر ... قرأت الكثير من المنشورات وأخيراً كان الحل بسيطًا جدًا.
عملت معي مع: (ربما كان من الممكن أن تعمل أيضًا أقل قليلاً - لا توجد فكرة ...)
إصدار docker-compose 1.27.4 ، النسخة 40524192
هذا هو !
النشر باستخدام YML وسيكون لديك دعم GPU في تكوين عامل الإرساء
5. in your docker-compose YML you should add: **runtime: nvidia**
يا فتى ، هذا الموضوع كله يتعلق بالإصدار 3 الذي لا يحتوي على وقت تشغيل.
تحتوي الإصدارات runtime
أي مكان الآن. بالإضافة إلى ذلك ، تم تحديد مواصفات المسرّعات أيضًا (https://github.com/compose-spec/compose-spec/pull/100) على الرغم من عدم تنفيذها في docker-compose
حتى الآن.
سأضيف 2 سنت لهذا الأمر ... قرأت الكثير من المنشورات وأخيراً كان الحل بسيطًا جدًا.
عملت معي مع: (ربما كان من الممكن أن تعمل أيضًا أقل قليلاً - لا توجد فكرة ...)
إصدار docker-compose 1.27.4 ، بناء 4052419
- على الجهاز المضيف عامل الإرساء ، قم بتثبيت مجموعة أدوات nvidia-container-toolkit و nvidia-container-runtime pack
- على الجهاز المضيف عامل الإرساء: اكتب
nvidia-smi وفحص إصدار CUDA الذي يظهر على اليمين- على جهاز مضيف عامل ميناء: اكتب: (استبدل إصدار cuda بالإصدار الذي قمت بتثبيته)
Docker run --rm --gpus all nvidia / cuda: 10.1-base nvidia-smi
يجب أن تحصل على نفس الإخراج كما فعلت عند تشغيل nvidia-smi على الجهاز المضيف- في ملف /etc/docker/daemon.json ، يجب عليك قراءة:
"أوقات التشغيل": {"nvidia": {"المسار": "/ usr / bin / nvidia-container-runtime"، "runtimeArgs": []}}- في ملف YML الذي أنشأه عامل الإرساء ، يجب إضافة:
وقت التشغيل: nvidiaهذا هو !
النشر باستخدام YML وسيكون لديك دعم GPU في تكوين عامل الإرساء
FYI ، إصدار cuda الذي يمكنك رؤيته في الناتج nvidia-smi
يشير إلى إصدار برنامج تشغيل nvidia cuda ، المعروف أيضًا باسم برنامج تشغيل nvidia (يسمونه cuda أيضًا ، وهو أمر محير). رقم الإصدار في صورة عامل الإرساء ، على سبيل المثال ، يشير nvidia/cuda:10.1-base nvidia-smi
إلى إصدار مجموعة أدوات nvidia (مرة أخرى ، مما يربك نفس نظام ترقيم الإصدار ، حيوانات مختلفة).
برنامج التشغيل متوافق مع مجموعة الأدوات ، لذا يمكنك تشغيل أي nvidia/cuda:<version>-base nvidia-smi
تريده ، طالما أن <version>
أصغر أو يساوي إصدار برنامج التشغيل.
مزيد من المعلومات هنا: https://stackoverflow.com/questions/53422407/different-cuda-versions-shown-by-nvcc-and-nvidia-smi
لا أرى ثنائيات Docker Compose 1.27.4 متاحة للنظام القائم على ARM.
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
؟
قام بإنشاء 1.27 بإسقاط دعم Python 2 لذلك من المحتمل ألا ترى إصدارات 1.27.x إذا كان نظامك يحتوي على Python 2
collabnix لأنك قمت بتثبيت الإنشاء بالفعل ، جرب pip install --upgrade docker-compose
الآن يمكنني الترقية إلى 1.27.4. أدت ترقية النقطة إلى الحيلة. شكرا kshcherban & @ كريس كرون
من الجنون رؤية معظم المشاريع التي عملت عليها في الماضي والتي تستخدم Python 2.7 تحتاج حقًا إلى ترقية.
أدت ترقية عامل الإرساء إلى 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
تعمل بشكل جيد مع عامل البناء.
على الكمبيوتر المضيف تحقق من gpu المستخدمة من قبل nvidia-smi.
@ bttung-2020
تضمين التغريدة
إذا استخدمت dokcer-nvidia-devel (ليس وقت التشغيل): nvidia / cuda: 10.1-cudnn7-devel-ubuntu18.04 في
هل نجحت؟ كيف يمكنني تحرير ملف docker-compose.yaml؟
التعليق الأكثر فائدة
إنها حاجة ملحة. شكرا على مجهودك!