Moby: الاسم "/ data-container-name" مستخدم بالفعل في الحاوية<hash>. يجب عليك إزالة (أو إعادة تسمية) تلك الحاوية لتتمكن من إعادة استخدام هذا الاسم.</hash>

كيف نظفت تلك الحاويات؟ أي استثناءات تحدث لماذا تقوم بتنظيف هذه الموارد (بما في ذلك شبكة التخزين وما إلى ذلك)؟

لديّ وظيفة مساعدة لإخراج كل شيء نوويًا حتى يمكن اختبار دورة بلاه المستمرة ، erm ... باستمرار. يتلخص الأمر في الأساس في ما يلي:

لمسح الحاويات:

docker rm -f $(docker ps -a -q)

لمسح الصور:

docker rmi -f $(docker images -a -q)

لمسح الأحجام:

docker volume rm $(docker volume ls -q)

لمسح الشبكات:

docker network rm $(docker network ls | tail -n+2 | awk '{if($2 !~ /bridge|none|host/){ print $1 }}')

لدي مجموعة سرب حيث يتم إحضار الحاويات لأعلى ولأسفل كثيرًا لأغراض ci ولدي نفس المشكلة. في حالتي ، لست بحاجة إلى إعادة تشغيل الجهاز ، وعادةً ما يتم قتل جميع الحاويات باستخدام

$ docker rm -f $(docker ps -a -q)

ثم إعادة تشغيل عامل الإرساء

$ sudo service docker restart

ثم إعادة تكوين السرب إلى إصلاحه.

هذا هو سجل فشل نموذجي. أستخدم ansible لتشغيل أوامر إنشاء عامل الميناء على إحدى عقد السرب ضد السرب.

TASK: [Run docker-compose up] ************************************************* 
failed: [XX.XX.XX.XX] => {"changed": true, "cmd": ["/usr/local/bin/docker-compose", "-f", "/containers/docker-compose/docker-compose-booking-pre-eng-811.yml", "--project-name", "booking-eng-811", "--verbose", "up", "-d"], "delta": "0:00:00.355991", "end": "2016-06-15 12:02:11.623256", "rc": 255, "start": "2016-06-15 12:02:11.267265", "warnings": []}
stderr: compose.config.config.find: Using configuration files: /containers/docker-compose/docker-compose-booking-pre-eng-811.yml
docker.auth.auth.load_config: Found 'auths' section
docker.auth.auth.parse_auth: Found entry (registry=u'my-private-registry', username=u'redacted-username')
compose.cli.command.get_client: docker-compose version 1.7.1, build 0a9ab35
docker-py version: 1.8.1
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
compose.cli.command.get_client: Docker base_url: http://127.0.0.1:4000
compose.cli.command.get_client: Docker version: KernelVersion=3.10.0-327.18.2.el7.x86_64, Os=linux, BuildTime=Fri May 27 17:25:03 UTC 2016, ApiVersion=1.22, Version=swarm/1.2.3, GitCommit=eaa53c7, Arch=amd64, GoVersion=go1.5.4
compose.cli.verbose_proxy.proxy_callable: docker inspect_network <- ('back')
compose.cli.verbose_proxy.proxy_callable: docker inspect_network -> {u'Containers': {u'0f4c1b89e2ae9476a53f07552f678d2914bb391d1d80ab051f74925eb9fbf65a': {u'EndpointID': u'5f07ba0940ffcb4b0c2f0acf5424b6976b28bd8344a56b0464ab6517da884bc8',
                                                                                       u'IPv4Address': u'10.0.0.3/24',
                                                                                       u'IPv6Address': u'',
                                                                                       u'MacAddress': u'02:42:0a:00:00:03',
                                                                                       u'Name': u'registrator_registrator_1'},
                 u'782c1d07d51f6871400da38e8840e81e9300f54a195b9e6ff2e931b23274655a': {u'EndpointID': u'c8654b5b73eaca7f630d6e2c4c898122a3ae6a86bd0cfab68a8654414fe4821a',
                                                                                       u'IPv4Address': u'10.0.0.2/24',
                                                                                       u'IPv6Address': u'',
                                                                                       u'MacAddress': u'02:42:0a:00:00:02',
                                                                                       u'Name': u'stdb1'},
...
compose.network.ensure: Network back declared as external. No new network will be created.
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=False, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=redis1', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=web', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=api_locations', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=booking', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('redis:2.8.21')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'redis-server'],
             u'Domainname': u'',
             u'Entrypoint': [u'/entrypoint.sh'],
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('my-private-registry/web:master')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u"Emmet O'Grady",
 u'Comment': u'',
 u'Config': {u'ArgsEscaped': True,
             u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/sh', u'-c', u'/entrypoint.sh'],
             u'Domainname': u'',
             u'Entrypoint': None,
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('my-private-registry/api-locations:master')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u"Emmet O'Grady",
 u'Comment': u'',
 u'Config': {u'ArgsEscaped': True,
             u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/sh', u'-c', u'/entrypoint.sh'],
             u'Domainname': u'',
             u'Entrypoint': None,
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('my-private-registry/booking:eng-811')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'ArgsEscaped': True,
             u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/sh', u'-c', u'/entrypoint.sh'],
             u'Domainname': u'',
             u'Entrypoint': None,
...
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=redis1', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.project._get_convergence_plans: web has upstream changes (redis1)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=web', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.project._get_convergence_plans: api_locations has upstream changes (redis1)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=api_locations', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.project._get_convergence_plans: booking has upstream changes (redis1)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=booking', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.parallel.feed_queue: Pending: set([<Service: web>, <Service: redis1>, <Service: api_locations>, <Service: booking>])
compose.parallel.feed_queue: Starting producer thread for <Service: redis1>
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('redis:2.8.21')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'redis-server'],
             u'Domainname': u'',
             u'Entrypoint': [u'/entrypoint.sh'],
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
...
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=redis1', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('redis:2.8.21')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'redis-server'],
             u'Domainname': u'',
             u'Entrypoint': [u'/entrypoint.sh'],
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
...
compose.service.build_container_labels: Added config hash: ae3be0880fdcb78073a419c6102617b730bfb42171c8204bf51e5c36eb8a85f3
compose.cli.verbose_proxy.proxy_callable: docker create_host_config <- (memswap_limit=None, links=[], devices=None, pid_mode=None, log_config={'Type': u'', 'Config': {}}, cpu_quota=None, read_only=None, dns=None, volumes_from=[], port_bindings={}, security_opt=None, extra_hosts=None, cgroup_parent=None, network_mode='back', shm_size=None, tmpfs=None, cap_add=None, restart_policy={u'MaximumRetryCount': 0, u'Name': u'always'}, dns_search=None, privileged=False, binds=[], ipc_mode=None, mem_limit='64M', cap_drop=None, ulimits=None)
compose.cli.verbose_proxy.proxy_callable: docker create_host_config -> {'Binds': [],
 'Links': [],
 'LogConfig': {'Config': {}, 'Type': u''},
 'Memory': 67108864L,
 'NetworkMode': 'back',
 'PortBindings': {},
 'RestartPolicy': {u'MaximumRetryCount': 0, u'Name': u'always'},
 'VolumesFrom': []}
compose.service.create_container: Creating bookingeng811_redis1_1
compose.cli.verbose_proxy.proxy_callable: docker create_container <- (name=u'bookingeng811_redis1_1', image='redis:2.8.21', labels={u'com.docker.compose.service': u'redis1', u'com.docker.compose.project': u'bookingeng811', u'com.docker.compose.config-hash': 'ae3be0880fdcb78073a419c6102617b730bfb42171c8204bf51e5c36eb8a85f3', u'com.docker.compose.version': u'1.7.1', u'com.docker.compose.oneoff': u'False', u'com.docker.compose.container-number': '1'}, host_config={'NetworkMode': 'back', 'Links': [], 'PortBindings': {}, 'Binds': [], 'RestartPolicy': {u'MaximumRetryCount': 0, u'Name': u'always'}, 'Memory': 67108864L, 'LogConfig': {'Type': u'', 'Config': {}}, 'VolumesFrom': []}, environment=[], volumes={}, detach=True, networking_config={u'EndpointsConfig': {'back': {u'IPAMConfig': {}, u'Aliases': ['redis1']}}})
compose.parallel.parallel_execute_iter: Failed: <Service: redis1>
compose.parallel.feed_queue: Pending: set([<Service: booking>, <Service: api_locations>, <Service: web>])
compose.parallel.feed_queue: <Service: booking> has upstream errors - not processing
compose.parallel.feed_queue: <Service: api_locations> has upstream errors - not processing
compose.parallel.feed_queue: <Service: web> has upstream errors - not processing
compose.parallel.parallel_execute_iter: Failed: <Service: booking>
compose.parallel.feed_queue: Pending: set([])
compose.parallel.parallel_execute_iter: Failed: <Service: api_locations>
compose.parallel.feed_queue: Pending: set([])
compose.parallel.parallel_execute_iter: Failed: <Service: web>
compose.parallel.feed_queue: Pending: set([])

ERROR: for redis1  Error response from daemon: Conflict. The name "/bookingeng811_redis1_1" is already in use by container 5ecf77fc7bbad0548cf34c891ac4d043b2692816b63ed97744924bc1296b8e65. You have to remove (or rename) that container to be able to reuse that name.
Traceback (most recent call last):
  File "<string>", line 3, in <module>
  File "compose/cli/main.py", line 63, in main
AttributeError: 'ProjectError' object has no attribute 'msg'
docker-compose returned -1

لقد حاولت إزالة الحاوية المسماة "bookingeng811_redis1_1" يدويًا ولكنها غير موجودة في أي مكان.

لديك نفس المشكلة هناك.

كثيرا ما أكرر الدورة:

• توقف عامل الإرساء٪ name٪
• عامل ميناء rm -f٪ name٪
• سحب عامل الإرساء٪ name٪
• تشغيل عامل الإرساء٪ name٪

في مرحلة ما (2-3 أيام) يتوقف عن العمل:
عامل ميناء: استجابة خطأ من البرنامج الخفي: تعارض. الاسم "٪ name٪" قيد الاستخدام من قبل الحاوية٪ container_id٪ . يجب عليك إزالة (أو إعادة تسمية) تلك الحاوية لتتمكن من إعادة استخدام هذا الاسم ..

عندما أحاول إزالة الحاوية٪ container_id٪ يدويًا ، تقول:
فشل إزالة الحاوية (٪ container_id٪): استجابة خطأ من البرنامج الخفي: لا توجد مثل هذه الحاوية:٪ container_id٪

الحاوية٪ container_id٪ ليست في قائمة عامل الإرساء ps -a وليست في المجلد / var / lib / docker / الحاويات

ربما جذر المشكلة هو إزالة الحاوية مع المعلمة -f؟ لذلك لا يقوم عامل الإرساء بالتنظيف بشكل صحيح ويعتقد برنامج عامل الإرساء أن الحاوية لا تزال موجودة.

إخراج إصدار Docker:

عميل:
الإصدار: 1.10.3.1
إصدار API: 1.22
إصدار Go: go1.5.3
Git الالتزام: 8acee1b
مبني:
OS / Arch: لينكس / amd64

الخادم:
الإصدار: 1.10.3.1
إصدار API: 1.22
إصدار Go: go1.5.3
Git الالتزام: 8acee1b
مبني:
OS / Arch: لينكس / amd64

إخراج معلومات عامل الإرساء:

الحاويات: 27
الجري: 13
متوقف مؤقتًا: 0
متوقف: 14
الصور: 1512
إصدار الخادم: 1.10.3
برنامج تشغيل التخزين: devicemapper
اسم البركة: docker-8: 9-521647-pool
حجم حوض السباحة: 65.54 kB
حجم الجهاز الأساسي: 107.4 جيجا بايت
دعم نظام الملفات: xfs
ملف البيانات: / dev / loop2
ملف البيانات الوصفية: / dev / loop3
مساحة البيانات المستخدمة: 53.62 جيجابايت
إجمالي مساحة البيانات: 107.4 جيجا بايت
مساحة البيانات المتوفرة: 53.76 جيجابايت
مساحة البيانات الوصفية المستخدمة: 129.9 ميجا بايت
إجمالي مساحة البيانات الوصفية: 2.147 جيجابايت
مساحة البيانات الوصفية المتوفرة: 2.018 جيجابايت
دعم Udev Sync: صحيح
تم تمكين الإزالة المؤجلة: خطأ
تم تمكين الحذف المؤجل: خطأ
عدد الأجهزة المحذوفة المؤجلة: 0
ملف حلقة البيانات: / var / lib / docker / devicemapper / devicemapper / data
تحذير: لا ينصح بشدة باستخدام أجهزة الاسترجاع لاستخدام الإنتاج. استخدم إما --storage-opt dm.thinpooldev أو استخدم --storage-opt dm.no_warn_on_loop_devices=true لمنع هذا التحذير.
ملف حلقة البيانات الوصفية: / var / lib / docker / devicemapper / devicemapper / metadata
إصدار المكتبة: 1.02.93 (2015/01/30)
سائق التنفيذ: أصلي -0.2
برنامج تشغيل التسجيل: ملف json
الإضافات:
الحجم: محلي
الشبكة: جسر المضيف فارغ
إصدار النواة: 4.5.0-coreos-r1
نظام التشغيل: CoreOS 1010.5.0 (MoreOS)
OSType: لينكس
العمارة: x86_64
وحدات المعالجة المركزية: 8
إجمالي الذاكرة: 11.74 جيجا بايت
الاسم: xx-slave
المعرّف: LVGE: QBNA : DXFP: AWR7 : NAVO: LQLR : 7 CGF: UDOF : CTES: VZQJ : SRZJ: JLKW

يستخدم عامل الإرساء "nameIndex" لحفظ المرجع للحاويات. من الوصف ، يبدو أن المشكلة تعود إلى أن nameIndex غير متزامن مع الحاويات التي تمت إزالتها. هذا هو المكان الذي يتم فيه إرجاع الخطأ.

قد نتمكن من تنظيف فهرس الاسم غير المتزامن لمعالجة المشكلة مؤقتًا. على الرغم من أن عامل الإرساء يستخدم عدة مؤشرات (على سبيل المثال ، linkIndex) بالإضافة إلى nameIndex لذلك قد يكون هناك العديد من الأماكن التي تحتاج إلى تنظيف. قد يكون العثور على مكان حدوث عدم المزامنة حلاً أفضل على المدى الطويل.

هل هناك أي طريقة لتنظيف فهرس الأسماء غير المتزامن؟
في الوقت الحالي ، الحل الوحيد الذي أملكه هو إعادة تشغيل العقدة وهي ليست جيدة. إعادة تشغيل Docker daemon ليس جيدًا أيضًا.

بالنسبة لي ، ما ينجح هو إيقاف برنامج Docker daemon وإزالة كل شيء من /var/lib/docker/* وبدء عامل الإرساء مرة أخرى. إنه خادم تكامل مستمر لذا يمكنني التعامل مع عدم تحميل أي صورة في سياق عامل الإرساء ، بحيث يعمل هذا بالنسبة لي ، YMMV.

أرى نفس السلوك في 1.10.3

Containers: 105
 Running: 75
 Paused: 0
 Stopped: 30
Images: 1434
Server Version: 1.10.3
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 4.5.0-coreos-r1
Operating System: CoreOS 1010.5.0 (MoreOS)
OSType: linux
Architecture: x86_64

نشهد هذه المشكلة كل يوم على CoreOS و Docker 1.10.3:

 # journalctl -fu docker
Aug 22 12:37:53 stateless-0.novalocal dockerd[8215]: time="2016-08-22T12:37:53.857617384+10:00" level=error msg="Handler for POST /v1.22/containers/create returned error: Conflict. The name \"/bridge-clockwork\" is already in use by container a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0. You have to remove (or rename) that container to be able to reuse that name."

# docker inspect a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0
Error: No such image or container: a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0

# docker rm -f a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0
Failed to remove container (a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0): Error response from daemon: No such container: a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0

في 50٪ من جميع الحالات ، تؤدي إعادة تشغيل برنامج Docker daemon إلى إصلاح المشكلة. في الحالات الأخرى ، يتعين علينا rm -rf / var / lib / docker. كلا الحلين معطلين لأعباء الإنتاج.

cdwertmann إذا كان عليك rm -rf /var/lib/docker ، فهذا يعني وجود حاوية بهذا الاسم ويتم إعادة تحميلها بعد إعادة تشغيل البرنامج الخفي. إذا كنت تحصل على نفس الأخطاء عند محاولة إزالة هذه الحاويات ، فسيكون من المفيد للغاية معرفة ما يوجد في /var/lib/docker/containers/<id>

@ cpuguy83 إليك ما يوجد داخل دليل الحاوية:

 # ls /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/ -lah
total 184K
drwx------.  3 root root 4.0K Aug 20 23:14 .
drwx------. 16 root root 4.0K Aug 23 14:41 ..
-rw-r-----.  1 root root 102K Aug 23 14:39 69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a-json.log
-rw-r--r--.  1 root root 2.9K Aug 23 14:41 config.v2.json
-rw-r--r--.  1 root root  975 Aug 23 14:41 hostconfig.json
-rw-r--r--.  1 root root   17 Aug 20 23:14 hostname
-rw-r--r--.  1 root root  185 Aug 20 23:14 hosts
-rw-r--r--.  1 root root   45 Aug 20 23:14 resolv.conf
-rw-r--r--.  1 root root   71 Aug 20 23:14 resolv.conf.hash
drwx------.  2 root root 4.0K Aug 20 23:14 shm

في config.v2.json يمكنني رؤية "RemovalInProgress":true :

# cat /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/config.v2.json 
{"State":{"Running":false,"Paused":false,"Restarting":false,"OOMKilled":false,"RemovalInProgress":true,"Dead":true,"Pid":0,"ExitCode":2,"Error":"","StartedAt":"2016-08-20T13:14:17.864964407Z","FinishedAt":"2016-08-23T04:41:29.775183062Z"},"ID":"69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a","Created":"2016-08-20T13:13:58.579971761Z","Path":"/bin/registrator","Args":["-ip","172.16.0.102","-resync","300","consul://172.16.0.102:8500"],"Config":{"Hostname":"sphinx","Domainname":"novalocal","User":"","AttachStdin":false,"AttachStdout":true,"AttachStderr":true,"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],"Cmd":["-ip","172.16.0.102","-resync","300","consul://172.16.0.102:8500"],"Image":"registry/registrator","Volumes":null,"WorkingDir":"","Entrypoint":["/bin/registrator"],"OnBuild":null,"Labels":{},"StopSignal":"SIGTERM"},"Image":"sha256:3b59190c6c800907d7a62c245bf93888db802b00407002fff7e08fed24e5557e","NetworkSettings":{"Bridge":"","SandboxID":"7713b13649c7964520180342f99914dd4720833ed39a51793ed483c356e0bd85","HairpinMode":false,"LinkLocalIPv6Address":"","LinkLocalIPv6PrefixLen":0,"Networks":{"bridge":{"IPAMConfig":null,"Links":null,"Aliases":null,"NetworkID":"5c0baa715bb76ea2eb5a6a32deb36a8093391ba6c76e55f31768838560c10f22","EndpointID":"","Gateway":"","IPAddress":"","IPPrefixLen":0,"IPv6Gateway":"","GlobalIPv6Address":"","GlobalIPv6PrefixLen":0,"MacAddress":""}},"Ports":null,"SandboxKey":"/var/run/docker/netns/7713b13649c7","SecondaryIPAddresses":null,"SecondaryIPv6Addresses":null,"IsAnonymousEndpoint":false},"LogPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a-json.log","Name":"/registrator","Driver":"overlay","MountLabel":"system_u:object_r:svirt_lxc_file_t:s0:c631,c718","ProcessLabel":"system_u:system_r:svirt_lxc_net_t:s0:c631,c718","RestartCount":0,"HasBeenStartedBefore":true,"HasBeenManuallyStopped":false,"MountPoints":{"/etc/localtime":{"Source":"/etc/localtime","Destination":"/etc/localtime","RW":false,"Name":"","Driver":"","Relabel":"ro","Propagation":"rprivate","Named":false},"/tmp/docker.sock":{"Source":"/var/run/docker.sock","Destination":"/tmp/docker.sock","RW":true,"Name":"","Driver":"","Relabel":"","Propagation":"rprivate","Named":false}},"AppArmorProfile":"","HostnamePath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/hostname","HostsPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/hosts","ShmPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/shm","ResolvConfPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/resolv.conf","SeccompProfile":""}

بعد حذف /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/ يدويًا وإعادة تشغيل برنامج Docker daemon ، تم حل التعارض.

رؤية الشيء نفسه هنا:

docker -v      
Docker version 1.10.3, build 3cd164c
docker-compose -v
docker-compose version 1.8.0, build f3628c7
cat /etc/os-release 
NAME=CoreOS
ID=coreos
VERSION=1068.10.0
VERSION_ID=1068.10.0
BUILD_ID=2016-08-23-0220
PRETTY_NAME="CoreOS 1068.10.0 (MoreOS)"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues" 

وهذه هي الطريقة التي أبدأ بها / أوقف / أعيد تشغيل الحاويات الخاصة بي:

cat /etc/systemd/system/u\@.service 
[Unit]
Description=%p-%i

# Requirements
Requires=docker.service

# Dependency ordering
After=docker.service

[Service]
Restart=always
RestartSec=10
TimeoutStartSec=60
TimeoutStopSec=15
EnvironmentFile=-/data/domains/%i/env
WorkingDirectory=/data/domains/%i/
ExecStartPre=-/opt/bin/docker-compose rm -f
ExecStart=/bin/bash -euxc "VIRTUAL_HOST=%i /opt/bin/docker-compose up"
ExecStop=/opt/bin/docker-compose stop

[Install]
WantedBy=multi-user.target

حصلت على نفس الخطأ ، وبعد ذلك ، لا يوجد شيء أقل من docker ps -a ، ولكن كان هناك مجلد أقل من /var/lib/docker/containers مع تجزئة الحاوية ، أزلتها ، ما زلت لا حظ. لقد أعدت تشغيل برنامج Docker daemon ، لقد نجح.

يعمل هذا الحل البديل لـ https://github.com/docker/compose/issues/3277#issuecomment -238080180 أيضًا على إصلاح هذه المشكلة ...

marcelmfs ليس لي. لا بد لي من حذف كامل /var/lib/docker

غريب ، لقد نجح الأمر بالنسبة لي. سأحاول مرة أخرى للتأكد.

marcelmfs هل حذفت للتو عامل ميناء / شبكة / ملفات / local-kv.db؟

ليس ذلك فحسب ، فقد أزال أيضًا جميع الحاويات قيد التشغيل docker rm -f $(docker ps -aq) ، وربما جميع الشبكات ، نظرًا لأنه يزيل أيضًا network/files/local-kv.db .

لم أر هذه المشكلة منذ الترقية إلى docker 1.12

هل لا يزال أي شخص آخر يرى هذا بـ 1.12.x؟

ما زلت بحاجة إلى الترقية للتحقق ... سأخصص نافذة للترقية غدًا.

تمت ترقية خادم CI الخاص بنا وأزلنا الحل البديل الذي كان حذف ملف local-kv.db . في الأسبوع القادم ، سيكون لدي المزيد من الأخبار حول هذا الموضوع.

نفس الشيء هنا: حدثت المشكلة في 1.11.x ولكن لم تعد منذ 1.12.x

نعم ، لاحظت عدم وجود أحد يشكو من هذا في 1.12.
أتساءل ما الذي قمنا بتغييره ، فأنا متأكد من أنه لا يوجد شيء متعلق مباشرة بالتسمية.

tl ؛ dr: جميع الإصدارات> = 1.10.0 تتأثر ولكن في> = 1.12.0 من غير المرجح حدوثها.

لقد تتبعت هذه المشكلة في الكود ويمكن أن تحدث بالتأكيد في جميع الإصدارات> = 1.10.0 حيث تم تقديم بنية nameIndex . كما ذكر yongtang ، يصبح هذا الهيكل غير متزامن مع الحاويات التي تمت إزالتها.

يحدث الخطأ عندما يصبح nameIndex غير متزامن مع daemon.containers .

تكمن المشكلة في وظيفة Daemon.create () . nameIndex في السطر 64 بواسطة daemon.newContainer() ولكن تم تحديث daemon.containers لاحقًا في السطر 149 بواسطة daemon.Register() .

إذا فشل أي شيء بين هذين ، يكون عامل الإرساء في حالة غير متسقة. قبل الالتزام https://github.com/docker/docker/commit/114be249f022535f0800bd45987c4e9cd1b321a4 (تم الهبوط في 1.12.0) ، كان هذا هو كل ما يلزم لبدء المشكلة. غيّر هذا الالتزام وظيفة التنظيف من docker.ContainerRm ، والتي لا تعمل أبدًا في هذه الحالة لأنها تحتاج إلى تسجيل الحاوية ، إلى docker.cleanupContainer .

ومع ذلك ، يمكن أن يفشل docker.cleanupContainer قبل أن يتمكن من التنظيف. يقوم فقط بحذف الإدخالات من nameIndex في السطر 113 ولكن هناك الكثير من الأشياء التي يمكن أن تسوء قبل ذلك.

يشرح كل ما سبق الحالة التي تؤدي فيها إعادة تشغيل البرنامج الخفي البسيط إلى إصلاح المشكلة لأن nameIndex لا يستمر على القرص. لقد ضربت رأسي ضد الكود لمحاولة اكتشاف كيف يمكن لهذا الخطأ أن ينجو من إعادة التشغيل ولكن لا يمكنني معرفة كيف. لقد رأينا ذلك بالتأكيد في الإنتاج على الرغم من أنني أنتظر حاليًا حدوث ذلك مرة أخرى وأحاول إجراء مزيد من التحقيق.

لقد أصلحت النسخة الموجودة في الذاكرة من المشكلة في # 27956

ظهرت هذه المشكلة للتو قبل التحديث إلى الأحدث (1.12.3) ، قمت بإلغاء تثبيت عامل الإرساء وإعادة تثبيته ، ولسوء الحظ ما زلت أراه.

ناتج docker version :

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      windows/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      linux/amd64

ناتج docker info

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 11
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.27-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.919 GiB
Name: moby
ID: XZHZ:262M:ENKG:Z62J:U4OX:FVKN:CGZW:7OCZ:IU5R:D7OM:F3MT:K3ND
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 12
 Goroutines: 22
 System Time: 2016-11-09T01:01:32.4577814Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
WARNING: No kernel memory limit support
Insecure Registries:
 127.0.0.0/8

يختلف سير العمل الخاص بي قليلاً عما تم ذكره في هذا الموضوع ، ولكنه مشابه من حيث أنني أقوم بالكثير من الإعداد وتفكيك الحاويات في مجموعة الاختبار الخاصة بي. قد يكون من المهم أيضًا أن يتم ذلك من خلال الطلبات إلى Remote API.

أنا في حيرة من أمري فيما يتعلق بكيفية المضي قدمًا. إذا طُلب مني ذلك ، يمكنني بالتأكيد إعداد حالة اختبار لمشكلتي ، ولكن اعتبارًا من الآن هو جزء من مشروع أكبر في العمل ، لذا سأحتاج إلى قطع الأمور.

هل لديكم أي اقتراحات؟

davidglivar هل

@ cpuguy83 إذا كنت تقصد من خلال إعادة تشغيل البرنامج الخفي إيقاف / بدء تشغيل عامل ميناء تطبيق windows ، نعم. لقد أعدت أيضًا تثبيت عامل الإرساء ، بالإضافة إلى إجراء إعادة تعيين "المصنع". لم أتطرق إلى Hyper-V لأنني لست واثقًا من طريقة عمله الداخلية.

davidglivar إذن أنت ترى هذا:

1. افعل اشياء
2. الحصول على خطأ
3. إعادة تشغيل docker4win
4. الحصول على خطأ

؟

تضمين التغريدة لقد مررت للتو بهذا التسلسل عدة مرات للتأكد.

davidglivar هل يمكنك docker ps -a ومعرفة ما إذا كنت ترى الحاوية هناك؟

@ cpuguy83 docker ps -a لا ينتج أي حاويات. أود أن أقول ذلك بسبب تفكيك الاختبار والإعداد ، ولكن حتى عند اكتشاف الخطأ في اختباراتي ، وإنشاء عملية فرعية على الفور docker ps -a فإن النتيجة هي نفسها.

فقط لمتابعة تعليقات اليوم السابق: ما زلت أواجه الخطأ 409 في سياق طلبي ؛ ومع ذلك ، فإن البرنامج النصي للاختبار ( هنا ) لم يعرض بعد أي مشكلة.

لقد ابتكرت طريقة موثوقة لإعادة إنتاج هذا. يمكنك استخدام نص Python النصي التالي لعمل أي تعارض في اسم الحاوية:

# pip install docker-py
from docker import Client

NAME = 'foobar'

cli = Client(version='auto')

# Create an invalid security option that will cause an error in
# https://github.com/docker/docker/blob/v1.10.3/daemon/create.go#L82
host_config = cli.create_host_config(security_opt=['invalid_opt'])

# After this, NAME will always conflict until the daemon gets restarted
try:
    cli.create_container(name=NAME, host_config=host_config, image='', command='/')
except:
    pass

يمكن أيضًا تشغيل هذه المشكلة في أحد الشروط التالية التي تشرح بعض الحالات التي تتطلب مسح /var/lib/docker :

• /var/lib/docker نفذ من inodes
• نفدت مساحة /var/lib/docker
• /var/lib/docker/<storage-driver> للقراءة فقط

الإصلاح هو التحديث إلى عامل الإرساء> = 1.12.0

آسف للتأخير في العودة بشأن هذه المسألة.

حتى الآن ، منذ إزالة الحل البديل ، لم يعد خادم CI يعاني من هذه المشكلة.

Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:
 OS/Arch:      linux/amd64

تواجه هذا أيضًا مع:

CentOS 7.2
Docker 1.12.1

لا يوجد مجلد به التجزئة المحددة تحت /var/lib/docker/containers ، ولم يكن لإعادة تشغيل البرنامج الخفي أي تأثير.

orodbhen إذا لم تنجح إعادة تشغيل البرنامج الخفي ، فيجب أن يكون هناك حاوية محملة بهذا الاسم.
هل يمكنك التحقق من docker ps -a ؟

@ cpuguy83 لا ، لا توجد حاوية بهذا الاسم.

أعتقد في الواقع أن هذا قد يكون مشكلة مع docker-py . أتساءل كم من الناس هنا يستخدمونه. يبدو أن petrosagg هو.

يحدث ذلك عند استدعاء create_container() حتى إذا لم يتم استخدام اسم الحاوية المخالفة. لكن ليس لدي مشكلة مع أمر docker shell ، باستخدام docker create أو docker run .

غريب ، رغم ذلك ، لأنه يبدو أنه يطبع رسالة الخطأ التي أنتجها البرنامج الخفي.

petrosagg هل لديك نفس المشكلة باستخدام أمر

orodbhen هل أنت متأكد من أن مثيل

هناك برنامج خفي واحد فقط قيد التشغيل: كلاهما يستخدم /var/run/docker.sock .

لقد أنشأت مشكلة لـ docker-py. لكنني لست مقتنعًا حتى الآن بأنه لا توجد مشكلة أساسية في عامل الرصيف تسبب المشكلة.

orodbhen عند إعادة تشغيل البرنامج الخفي ، هل يمكنك الحصول على السجلات من تسلسل التحميل (على وجه التحديد تحميل الحاويات)؟

لا يمكن أن تكون هذه مشكلة في حساب المرجع إذا قمت بإعادة تشغيل البرنامج الخفي. يتم الاحتفاظ بالاسم المسجل فقط في الذاكرة ويتم إعادة بنائه عند إعادة تشغيل البرنامج الخفي.

عذرا ، من فضلك تجاهل. كانت مشكلة في الطريقة التي كنت أسجل بها الأخطاء التي جعلت الأمر يبدو وكأن الخطأ كان يتكرر.

orodbhen أنا لا أستخدم حقيبة اختبار صغيرة قابلة للتكرار. السبب في عدم حدوث ذلك مع Docker CLI هو أن العميل يقوم بتعقيم الإدخال قبل تمريره إلى الخادم ، لكنني أردت أن يكون لدي وصول مباشر إلى الخادم وأتسبب في فشل القسم الحرج.

حذف الخدمة التي تعمل في الخلفية.
خدمة عامل ميناء rm service_name
ثم ckeck docker info فإنه يظهر c ontainers: 0

تمت إزالته ، إعادة نشره على # 3277

كنت أواجه نفس المشكلة أيضًا مع الأخطاء التالية:

   x Start Mongo: FAILED

-----------------------------------STDERR-----------------------------------
Error response from daemon: Cannot update container 78dc6f6a43d0e6cfb7aa6bba2f0a377bd39620bff79ca308540a13ddd4e62886: container is marked for removal and cannot be "update"
Error response from daemon: removal of container mongodb is already in progress
docker: Error response from daemon: Conflict. The container name "/mongodb" is already in use by container "78dc6f6a43d0e6cfb7aa6bba2f0a377bd39620bff79ca308540a13ddd4e62886". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.
-----------------------------------STDOUT-----------------------------------
3.4.1: Pulling from library/mongo
Digest: sha256:aff0c497cff4f116583b99b21775a8844a17bcf5c69f7f3f6028013bf0d6c00c
Status: Image is up to date for mongo:3.4.1
no such container
Running mongo:3.4.1

لقد قمت للتو بتشغيل الأمر: sudo service docker أعد تشغيل

وكل شيء يعمل بشكل جيد الآن.

كنت أواجه هذه المشكلة أيضًا مع الأخطاء التالية:

docker-compose up -d --no-build api
Creating api ... 
Creating api ... error

ERROR: for api  Cannot create container for service api: Conflict. The name "/api" is already in use by container 2788cdc091645f0dcef417f189f9c80fddd3f6f99eaba3771d0f4a87e2295841. You have to remove (or rename) that container to be able to reuse that name.

ERROR: for api  Cannot create container for service api: Conflict. The name "/api" is already in use by container 2788cdc091645f0dcef417f189f9c80fddd3f6f99eaba3771d0f4a87e2295841. You have to remove (or rename) that container to be able to reuse that name.
ERROR: Encountered errors while bringing up the project.

اتضح أن الدليل الذي يوجد به ملف الإنشاء قد تمت إعادة تسميته من وقت تشغيل الحاوية الحالية وعندما حاولت إعادة تشغيل الحاوية. لقد تحققت من خلال تشغيل ما يلي:

docker inspect api | grep -i compose
"com.docker.compose.config-hash": "c0e3e88ad502faf806288e16419dc52b113cae18abeac1769fa0e98a741de48a",
"com.docker.compose.container-number": "1",
"com.docker.compose.oneoff": "False",
"com.docker.compose.project": "api",
"com.docker.compose.service": "api",
"com.docker.compose.version": "1.14.0"

لقد لاحظت أنه تم تعيين تسمية المشروع على api لكن الدليل الحالي حيث قمت بتشغيل هذا كان في الواقع api.git لذا يبدو أنه تمت إعادة تسميته في وقت ما بين آخر مرة قمت فيها بتشغيله والآن. لقد قمت ببساطة بإعادة تسمية الدليل إلى api ، وأعدت الحاوية مرة أخرى (بدون إزالة الحاوية الحالية أو إعادة تشغيل عامل الإرساء) وكل شيء يعمل كما هو متوقع.

لدينا العديد من الحاويات قيد التشغيل ، لذا فإن إعادة تشغيل عامل الإرساء لم يكن الحل الأمثل.

docker container prune لحذف الحاويات المتوقفة.

اضطررت إلى فرض إزالة الحاوية docker rm -f /<container_name>