Compose: دعم وحدات معالجة الرسومات NVIDIA ضمن Docker Compose

تم إنشاؤها على ٩ مايو ٢٠١٩  ·  160تعليقات  ·  مصدر: docker/compose

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

kinenhancement statu0-triage

التعليق الأكثر فائدة

إنها حاجة ملحة. شكرا على مجهودك!

ال 160 كومينتر

تزداد أهمية هذا الآن بعد أن ظهر "وقت تشغيل 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.

في هذه الصورة:

Docker architecture

يستبدل 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

عذرًا ، فهل يعمل بالفعل مع Docker Swarm باستخدام ملف yaml-compose docker؟ فقط للتأكد: يا. شكر!

فقط لعمال الإرساء يؤلف 2.x.

بيت القصيد من هذه المشكلة هو طلب دعم nvidia-docker gpu ل docker-compose 3+

لقد مر عام تقريبا على الطلب الأصلي !! لماذا التأخير؟؟ هل يمكننا المضي قدما ؟؟

MustafaHosny اللهم امين يارب . أي تحديث على هذا؟

لأولئك منكم الذين يبحثون عن حل بديل ، انتهى بنا الأمر إلى القيام به:

ثم قم بتشغيل 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 واجهات برمجة تطبيقات يجب مزامنتها يدويًا لأي تحديثات ميزات جديدة:

  1. Docker socket API
  2. docker_py يوفر واجهة Python الأمامية لواجهة برمجة تطبيقات المقبس
  3. Docker CLI (نقطة دخولنا المألوفة إلى Docker Toolchain)
  4. واجهة Docker-Compose التي تستدعي واجهة برمجة تطبيقات Docker socket

هذا يطرح السؤال: لماذا لا توجد آلية مزامنة تلقائية (أو على الأقل شبه آلية)؟ يبدو أن نشر تحديثات الميزات الجديدة عبر 4 واجهات برمجة تطبيقات محكوم عليه بأن يكون عرضة للخطأ ، وعرضة للتأخير ، ومربك ...

ملاحظة: لا أقول إنها مهمة _بسيطة_ أن يكون لديك مزامنة تلقائية ، لكنني أعتقد حقًا أنه يجب أن يكون هناك واحد لجعل الحياة أسهل في المستقبل.

أنا أدخل الآن نوعا ما في التحذلق ... لكن كما سأصفها على أنها ...

  • مقبس عامل الإرساء هو واجهة برمجة التطبيقات الرسمية لعمال الإرساء. غالبًا ما يكون مقبس ملف ، ولكن يمكن أيضًا أن يكون TCP (أو أي شيء آخر ، أتخيل استخدام socat )
  • يستخدم CLI docker واجهة برمجة التطبيقات هذه لمنحنا المستخدمين أداة رائعة

    • يكتب Docker API و CLI ، بحيث تتم مزامنتهما دائمًا في وقت الإصدار. (أعتقد أنه من الآمن القول ، CLI هو مواطن من الدرجة الأولى في النظام البيئي لعمال السفن)

  • تأخذ مكتبة docker_py واجهة برمجة التطبيقات هذه وتضعها في مكتبة رائعة يمكن أن تستخدمها مكتبات Python الأخرى. بدون هذا ، كنت ستجري كل مكالمات HTTP هذه بنفسك ، وتسحب شعرك.

    • ومع ذلك ، فقد بدأ docker_py كمكتبة تابعة لجهة خارجية ، وبالتالي فقد تتبع تقليديًا واجهة برمجة تطبيقات docker ، وإضافة أشياء لاحقًا أو حسب الحاجة (موارد محدودة).

  • يستخدم إنشاء نسخة من docker_py ثم يضيف كل هذه الميزات الرائعة ، مرة أخرى حسب الحاجة (بناءً على مشكلات مثل هذه تمامًا)

    • ومع ذلك ، لا يمكن للكتابة أن تفعل الكثير حتى docker_py (الذي لا أقوله أنه يؤخر هذه المشكلة ، لا أعرف ، أنا أتحدث فقط بشكل عام)

إذن نعم ، إنه يذهب:

  • "إنشاء yaml + إنشاء مجموعات" -> "docker_py" -> "docker_api"
  • و CLI ليس جزءًا من هذا ، (وصدقوني ، هذه هي الطريقة الصحيحة للقيام بالأشياء)

لا يمكنني التحدث عن 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

  1. على الجهاز المضيف عامل الإرساء ، قم بتثبيت مجموعة أدوات nvidia-container-toolkit و nvidia-container-runtime pack
  2. على الجهاز المضيف عامل الإرساء: اكتب
    nvidia-smi وفحص إصدار CUDA الذي يظهر على اليمين
    image
  3. على جهاز مضيف عامل ميناء: اكتب: (استبدل إصدار cuda بالإصدار الذي قمت بتثبيته)
    Docker run --rm --gpus all nvidia / cuda: 10.1-base nvidia-smi
    يجب أن تحصل على نفس الإخراج كما فعلت عند تشغيل nvidia-smi على الجهاز المضيف
  4. في ملف /etc/docker/daemon.json ، يجب عليك قراءة:
    "أوقات التشغيل": {"nvidia": {"المسار": "/ usr / bin / nvidia-container-runtime"، "runtimeArgs": []}}
  5. في ملف YML الذي أنشأه عامل الإرساء ، يجب إضافة:
    وقت التشغيل: nvidia

هذا هو !
النشر باستخدام 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

  1. على الجهاز المضيف عامل الإرساء ، قم بتثبيت مجموعة أدوات nvidia-container-toolkit و nvidia-container-runtime pack
  2. على الجهاز المضيف عامل الإرساء: اكتب
    nvidia-smi وفحص إصدار CUDA الذي يظهر على اليمين
    image
  3. على جهاز مضيف عامل ميناء: اكتب: (استبدل إصدار cuda بالإصدار الذي قمت بتثبيته)
    Docker run --rm --gpus all nvidia / cuda: 10.1-base nvidia-smi
    يجب أن تحصل على نفس الإخراج كما فعلت عند تشغيل nvidia-smi على الجهاز المضيف
  4. في ملف /etc/docker/daemon.json ، يجب عليك قراءة:
    "أوقات التشغيل": {"nvidia": {"المسار": "/ usr / bin / nvidia-container-runtime"، "runtimeArgs": []}}
  5. في ملف 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؟

هل كانت هذه الصفحة مفيدة؟
4 / 5 - 1 التقييمات