Compose: فشل إنشاء عامل ميناء لأنه "تم تخصيص المنفذ بالفعل"

netstat | grep 5432 ؟

مرحبًا @ shin- ،

لقد أجريت للتو عملية إعادة ضبط للجهاز وحصلت على:

$ docker-compose up
_collections.so could not be extracted!

بعد ذلك لدي نفس المشكلة كما نشرتها patrickconnors :

أيه أفكار؟

budnik حاول تشغيل docker-compose down لتنظيف الحاويات والشبكات ، ثم up مرة أخرى ومعرفة ما إذا كان ذلك سيؤدي إلى إصلاح الأشياء.

واجهت نفس المشكلة اليوم (مع حاوية postgres ) ، وعلى الرغم من تجربة docker-compose down ثم up مرة أخرى ، لا تزال المشكلة قائمة.

يظهر لي كل من docker-compose ps و docker ps ناتجًا فارغًا.

ربما وجدت حلاً ، على الرغم من:

هذه هي الطريقة التي يتم بها تحديد خدمة postgres الخاصة بي

version: '2.1'

services:

  postgres:
    image: postgres:9.5.4
    env_file:
      - docker-compose.env
    ports:
      - 5432:5432

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

    ports:
      - 5432

لست متأكدًا مما إذا كان هذا هو الحل الصحيح ، ولا إذا كان يمكن تطبيقه بشكل عام على جميع حالات الاستخدام.

قد تكون مشكلة مع docker-compose نفسها؟
كمرجع:

$ docker-compose --version
docker-compose version 1.12.0, build b31ff33

الحل أعلاه هو ما أحتاجه ، شكرًا جزيلاً على @ lorenzo-pasa!

كنت أواجه نفس المشكلة بعد تحديث docker-compose إلى الإصدار 3.3.
يعمل حل @ lorenzo-pasa محليًا بالنسبة لي (ما زلت بحاجة إلى المحاولة في المنتج)

أدناه _ part_ من docker-compose الخاص بي كمرجع:

nginx:
    image: nginx:1.12.2-alpine
    volumes:
      - .:/usr/share/nginx/app
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
    ports:
      - "80"
    depends_on:
      - web

كان لدي هذا وكذلك أشياء مثل Cannot start service mysql: network 4b8e7a23e3724fd351e428be30cdf7a9294d142ac23959ca9092278fc81e96c1 not found . لقد قمت بحلها باستخدام --build --force-recreate flags لأمر up.

هذا 👇 يعمل بالنسبة لي !!

docker-compose down
docker rm -fv $(docker ps -aq)
sudo lsof -i -P -n | grep 5432

• لل ماك

kill -9 <process id>

• لينكس

sudo kill <process id>

خطأ: من أجل iky_gateway لا يمكن بدء الخدمة iky_gateway: فشل b'driver في برمجة الاتصال الخارجي على نقطة النهاية iky_gateway (47d83edbbc1568eae6d26f5e75931797b7e23c6528ff7cc8140f50811fb44922): فشل بدء تشغيل وكيل Userland: 0.080

لقد حاولت docker-compose down ، ولم أصلحه.

هناك حل آخر قد يكون مفيدًا للقراء في المستقبل وهو: تحقق مرة أخرى من ملف docker-compose.yml الخاص بك وتحقق للتأكد من عدم وجود عنصرين يحاولان تشغيلهما على المنفذ 8080.

إذا كان لديك عنصران تم تكوينهما للتشغيل على المنفذ 8080 ، فيمكنك الحصول على رسالة خطأ "تم تخصيص المنفذ بالفعل" للخدمة / الحاوية التي لا تسبب المشكلة - مما يسبب لك الارتباك عند محاولة إيقاف الخدمة / الحاوية والحصول على لا يوجد حل لرسالة الخطأ.

نجح حل kill -9 {pid} استمر في إعادة تشغيل العملية. كان هذا بسبب تشغيل MySQL Server. في OSX كان علي أن:

1. تفضيلات النظام
2. ابحث عن mysql
3. اضغط على الزر Stop MySQL Server

لقد قمت بإزالة ربط المنفذ وعمل معي ، بدلاً من القيام به
mysql:الموانئ:- 3306: 3306
كان علي أن أتغير إلى
mysql:الموانئ:- 3306
وكان كل شيء على ما يرام.

توقف عامل ميناء $ (docker ps -a -q)
عامل ميناء rm $ (عامل ميناء ps -a -q)
ثم قم بإزالة أي بيانات موجودة مثل حجم عامل الإرساء rm docker_db_data
عامل الميناء يؤلف

نفس المشكلة هنا. أنا أستخدم إصدار عامل الإرساء 17.05.0-ce ، وبناء 8965be ، مع تكوين عامل الإرساء 1.13.0 و 1.22.0. ملف compose-yml هو 3.2.

مع الاعتذار لـ KazibweStephen ، هذا ليس حلاً مفيدًا. أنت تطلب من عامل الإرساء اختيار منفذ _abritrary_ للعملاء للاتصال بخدمة mysql الخاصة بالحاوية. يمكنك أيضًا إخبار mysql بعدم الاستماع إلى أي منفذ أو إزالة تكوين المنفذ تمامًا.

لقد جربت العديد من الحلول أعلاه ، بما في ذلك _إعادة تشغيل الخادم_. لا توجد حاويات أخرى قيد التشغيل ، ولا توجد تعارضات في ملف yml. أتذكر أن هذا كان يعمل في إصدار أقدم بكثير من عامل الإرساء / التأليف. يظهر netstat -anp على المضيف لا شيء يستمع على المنافذ.

إذا قمت بإعادة إنشاء أقسام ports بالكامل ، فستبدأ العمليات بشكل جيد. ثم أستخدم nsenter ... netstat للتحقق من أن الحاوية تستمع عبر المنفذ الصحيح (في مساحة الاسم الخاصة بها). ثم تحقق مع netstat للتحقق من عدم وجود تعارض في مساحة الاسم الافتراضية. يمكنني بعد ذلك استخدام أداة مساعدة مثل nc للاستماع على نفس المنفذ.

لا أرى أي سبب فيما يتعلق بالوثائق التي تجعل التهيئة لا تعمل. الاستنتاج هو أن هناك خطأ ما في إعداد الوكيل الخاص بـ docker-compose.

_لا يصدق_. في الواقع ، كان لدي خطأ بسيط تسبب في المشكلة. احتاج التكوين الخاص بي إلى منفذين ، وكان أحدهما يحتوي على خطأ مطبعي ، مما يؤدي إلى تكرار الآخر. راحة اليد

netstat | grep 5432 ؟

مرحبًا ، عندما أقوم بتشغيل هذا ، تلقيت هذه الرسالة ..

98808d86b49cff5d تيار 0 0 98808d86b6dd9be5 0 0 0 /tmp/.s.PGSQL.5432. هل يمكنك مساعدتي من فضلك ماذا أفعل؟ شكرا

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

    ports:
      - 5432

لست متأكدًا مما إذا كان هذا هو الحل الصحيح ، ولا إذا كان يمكن تطبيقه بشكل عام على جميع حالات الاستخدام.

قد تكون مشكلة مع docker-compose نفسه؟
كمرجع:

$ docker-compose --version
docker-compose version 1.12.0, build b31ff33

هذا الإصلاح يعمل معي.

docker-compose -version
docker-compose version 1.23.1, build b02f1306

كان لدي موقف مختلف قليلاً ، أنشر هنا لتسجيل حالة أخرى من هذا الحدوث.

عند استخدام ملف docker-compose.yml و docker-compose.override.yml ، وكلاهما يحتوي على تعيين منفذ ، حيث يكون منفذ المضيف هو نفسه لكل من التعيينات ، ولكن يختلف منفذ الحاوية ، فإن هذا يتسبب في محاولة عامل الشحن والتخصيص المنفذ المضيف مرتين.

docker-compose.yml:

ports:
  - 8080:8080

docker-compose.override.yml:

ports:
  - 8080:8181

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

لقد نجح حل @ lorenzo-pasa بالنسبة لي! أنا أستخدم docker-compose و nginx ، وتشغيل نظام التشغيل ubuntu OS ، شكرًا يا صاح.

لدي فضول: لماذا تم إغلاق هذه المشكلة ، بينما يبدو أن العديد من الأشخاص يواجهون مشكلة (بمن فيهم أنا)؟ هل الإصلاح الرسمي هو عدم كتابة (على سبيل المثال) 8080:8080 والكتابة دائمًا بدلاً من ذلك ببساطة 8080 ؟ فقط لأكون واضحًا ، هذه ليست شكوى ، فأنا أشعر بالفضول بصدق.

Ezwen توافق
لقد جربت جميع الاقتراحات المنشورة أعلاه ولكن لا تزال تعمل في الأخطاء.
أنا أقوم بتشغيل PHPstorm وأحاول Xdebug تطبيقي في dockerbox. عند بدء تشغيل dockerbox الخاص بي ، أستخدم عامل الإرساء مع ملف

الموانئ:
- "9001: 9001"

مما يفضح المنفذ بشكل صحيح. (vpnkit.exe جزء من Docker)

أرى أن vpnkit.exe يستمع إلى المنفذ 9001. لذلك عندما أحاول الآن بدء تشغيل Xdebug في PHPstorm ، تظهر رسالة الخطأ

لا أعرف لماذا لا يمكنني إخبار مصحح أخطاء PHPstorm بالاستماع إلى المنفذ 9001 أثناء استخدامه دائمًا بواسطة vpnkit.exe عند بدء تشغيل حاوية عامل الإرساء؟

شكرا @ lorenzo-pasa! كانت هذه بالضبط مشكلتي وعملت الحلول الخاصة بك. لقد حاولت الكثير من الأشياء لحل هذا بدون نتيجة. شكرا مرة اخرى!

واجهت نفس المشكلة اليوم (مع حاوية postgres ) ، وعلى الرغم من تجربة docker-compose down ثم up مرة أخرى ، لا تزال المشكلة قائمة.

يظهر لي كل من docker-compose ps و docker ps ناتجًا فارغًا.

ربما وجدت حلاً ، على الرغم من:

هذه هي الطريقة التي يتم بها تحديد خدمة postgres الخاصة بي

version: '2.1'

services:

  postgres:
    image: postgres:9.5.4
    env_file:
      - docker-compose.env
    ports:
      - 5432:5432

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

    ports:
      - 5432

لست متأكدًا مما إذا كان هذا هو الحل الصحيح ، ولا إذا كان يمكن تطبيقه بشكل عام على جميع حالات الاستخدام.

قد تكون مشكلة مع docker-compose نفسها؟
كمرجع:

$ docker-compose --version
docker-compose version 1.12.0, build b31ff33

بالنسبة لي ، كانت المشكلة هي أن حاوية عامل إرساء أخرى لا تزال تعمل في الخلفية من مشروع مختلف.

أصلحت عن طريق الجري:

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

لدي نفس المشكلة التي ذكرتها maritaria .

freesoft ربما يكون من الأفضل فتح عدد جديد لهذا الغرض.

لقد جربت كل شيء هنا ولكن لا شيء يبدو أنه يعمل ، ثم فعلت هذا:

sudo lsof -i -P -n | جريب 5432

قتل كل العمليات
سودو قتل

ثم عملت بالنسبة لي.

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

 Version:           18.09.3
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        774a1f4
 Built:             Thu Feb 28 06:53:11 2019
 OS/Arch:           linux/amd64
 Experimental:      false

كانت إحدى عمليات docker-proxy معلقة ، لذا قتلها وحل المشكلة systemctl restart docker .

قمت بتشغيل docker system prune (كن حذرًا مع هذا الأمر) ثم أعدت تشغيل عامل الإرساء ، لقد نجحت معي.

يبدو أن docker network prune يحل المشكلة بالنسبة لي

sudo lsof -i -P -n | جريب 5432

عملت لي مثيل EC2 لينكس

sudo lsof -i -P -n | grep

يعمل معي ولكن هل علي الاستمرار في قتل العمليات بين الحين والآخر؟

في حالتي ، كان لدي مثيل قيد التشغيل بالفعل من node.js على محلي بنفس المنفذ.

عندما أوقفته ، بدأ العمل docker-compose up --build !

في حالتي ، أعيد تشغيل SO

@ Rub21 's

sudo lsof -i -P -n | grep <port number>

شجب استخدام البرنامج ليكون docker-pr .

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

شكرا.

بالمناسبة:
في حالتي ، أعتقد أن مصدر خطئي هو أنني أقوم بإغلاق صارم أثناء تنفيذ docker network prune .
أعتقد أن cli لم يكن قادرًا على إنهاء المهمة ، لذلك كان لدي كل تلك البقايا "غير الموجودة" في مسار عامل الإرساء / الشبكة.

في حالتي ، نجح هذا https://github.com/docker/for-mac/issues/205#issuecomment -250856158

On linux users have reported that after remove local-kv.db with all containers stoped the problem gets solved.

الملف موجود في /var/lib/docker/network/files/local-kv.db

kill -9 $(sudo lsof -i -P -n | grep 8888 | awk '{print $2}') فعل الحيلة بالنسبة لي

للأسف ، خدعة "kill -9 .." لا تعمل.
حصلت على الزومبي بدلاً من عملية وكيل عامل ميناء:

عامل ميناء -it -p 50000: 50000 hello-world
عامل الإرساء: استجابة خطأ من البرنامج الخفي: فشل برنامج التشغيل في برمجة الاتصال الخارجي على نقطة النهاية musing_dijkstra (2afd0e53bb80223bc07650e59bd16b43c6d971828a589db6f43dfa50a7a1ab42): فشل الربط لـ 0.0.0.0:50000: تم تخصيص المنفذ بالفعل.

docker run -it -p 80:80 hello-world
عامل الإرساء: استجابة خطأ من البرنامج الخفي: فشل برنامج التشغيل في برمجة الاتصال الخارجي على نقطة النهاية cocky_goldberg (8dab653c7575c298efea1b808ef2ff16f19bb6c23f51612787e19a434ceeb2ff): فشل ربط 0.0.0.0:80: تم تخصيص المنفذ بالفعل.

أعلى | غريب غيبوبة
المهام: 319 مجموع ، 1 جري ، 181 نائم ، 0 متوقف ، 2 زومبي

uname -r
4.14.35-1844.4.5.el7uek.x86_64

@ lorenzo-pasa لقد واجهت نفس المشكلة لخدمة القنصل وعملت خدعتك بالنسبة لي. شكرا على الحل.

توقف عامل ميناء $ (docker ps -a -q)
عامل ميناء rm $ (عامل ميناء ps -a -q)
ثم قم بإزالة أي بيانات موجودة مثل حجم عامل الإرساء rm docker_db_data
عامل الميناء يؤلف

هذا الحل بواسطة @ joseph-luketelo (شكرًا!) يعمل على MacOS Mojave. لا تحتاج حتى إلى "إزالة أي بيانات موجودة ...". مجرد تشغيل الأمرين الأولين حلها.

• حذف /var/lib/docker/network/files/local-kv.db (مع إيقاف تشغيل كل شيء وإيقاف تشغيله) لم ينجح
• لم تنجح شبكات التقليم
• حذف جميع المجلدات والحاويات لم ينجح
• لم ينجح القيام بكل ما سبق معًا
• قتل مثيلات docker-proxy تشغل المنافذ لم تعمل (لا شيء يظهر في إخراج netstat لهذا المنفذ ، ولكن لا تزال رسالة الخطأ هذه).
• إذا قمت بما ورد أعلاه ، فأعد تشغيل خدمة عامل الإرساء ، فإن docker-compose up يتوقف فقط إلى أجل غير مسمى.

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

كل الحلول المذكورة لم تعمل بالنسبة لي.

يعمل هذا:

sudo rm -rf /var/lib/docker
sudo service docker restart # to re-create the db again

حاولت أيضًا إعادة تثبيت docker and docker-compose ، لكن ليس لدي أي فكرة عما إذا كانت هذه الخطوة تساعد. لم ينجح الأمر حتى قمت بالخطوات المذكورة أعلاه.

واجهت نفس المشكلة اليوم (مع حاوية postgres ) ، وعلى الرغم من تجربة docker-compose down ثم up مرة أخرى ، لا تزال المشكلة قائمة.

يظهر لي كل من docker-compose ps و docker ps ناتجًا فارغًا.

ربما وجدت حلاً ، على الرغم من:

هذه هي الطريقة التي يتم بها تحديد خدمة postgres الخاصة بي

version: '2.1'

services:

  postgres:
    image: postgres:9.5.4
    env_file:
      - docker-compose.env
    ports:
      - 5432:5432

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

    ports:
      - 5432 (this also solve my problem)

لست متأكدًا مما إذا كان هذا هو الحل الصحيح ، ولا إذا كان يمكن تطبيقه بشكل عام على جميع حالات الاستخدام.

قد تكون مشكلة مع docker-compose نفسها؟
كمرجع:

$ docker-compose --version
docker-compose version 1.12.0, build b31ff33

أدى تعطيل ربط المنفذ أيضًا إلى حل مشكلتي

كنت أحصل على نفس الخطأ بعد إعادة بناء تكوين عامل الإرساء.

ハ➜ docker-compose up

حاولت:
ハ➜ docker-compose down
لكن ما زلت تواجه نفس المشكلة ....

ef18b3f0f2864b22e102): Bind for 0.0.0.0:10002 failed: port is already allocated

ERROR: for db  Cannot start service db: driver failed programming external connectivity on endpoint eeschenck_db_1 (a7caadb27e327b901df83bb42fd19bd704224aa03a75ef18b3f0f2864b22e102): Bind for 0.0.0.0:10002 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.

ثم حاولت إعادة تشغيل تطبيق Docker وخرجت من IDE الخاص بي "Visual Studio Code" الذي يحتوي على ملحق docker ...

ثم حاولت مرة أخرى وحاولت الاتصال بشبكة الإنترنت في الميناء ..
ハ➜ netstat -n | grep 10002
لم يتم العثور على شيء لهذا المنفذ ... كان ينبغي تجربة هذا من قبل.

ハ➜ docker-compose up

يبدو أن امتداد Visual Studio Code Docker قد يكون هو المشكلة بالنسبة لي.

هل يمكنك مشاركة تكوين ملف docker-compose الخاص بك
أنت بحاجة إلى إزالة انعكاس المنفذ

عملت من أجلي

docker-compose down
docker network prune
sudo service docker restart
docker-compose up

واجهت نفس المشكلة اليوم (مع حاوية postgres ) ، وعلى الرغم من تجربة docker-compose down ثم up مرة أخرى ، لا تزال المشكلة قائمة.

يظهر لي كل من docker-compose ps و docker ps ناتجًا فارغًا.

ربما وجدت حلاً ، على الرغم من:

هذه هي الطريقة التي يتم بها تحديد خدمة postgres الخاصة بي

version: '2.1'

services:

  postgres:
    image: postgres:9.5.4
    env_file:
      - docker-compose.env
    ports:
      - 5432:5432

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

    ports:
      - 5432

لست متأكدًا مما إذا كان هذا هو الحل الصحيح ، ولا إذا كان يمكن تطبيقه بشكل عام على جميع حالات الاستخدام.

قد تكون مشكلة مع docker-compose نفسها؟
كمرجع:

$ docker-compose --version
docker-compose version 1.12.0, build b31ff33

@ lorenzo-pasa شكرًا لك ، لقد نجح هذا الحل بالنسبة لي.

ببساطة إعادة تشغيل البرنامج الخفي لسطح المكتب Docker على نظام Mac هو الحيلة بالنسبة لي (Docker Desktop 2.2.0.4).
يبدو وكأنه شيء أسيء التصرف عند بدء التشغيل.

توقف عامل ميناء $ (docker ps -a -q)
قم بتشغيل هذا الأمر قبل محاولة إجراء إصلاحات أخرى مثل -8080: 8080 إلى -8080 أو حتى docker rm $ (...)

لقد أعدت ضبط جهازي وبدأ العمل مرة أخرى. ربما ليس حلا دقيقا لكنه نجح

إذا لم يخرج docker ps أي شيء ولم يساعد docker-compose down / up ، فتحقق مما إذا كان المنفذ مستخدمًا مع هذا الأمر:
sudo lsof -i -P -n | grep 9200

إذا كان الأمر كذلك ، فما عليك سوى تشغيل:
sudo service docker restart

لديك نفس المشكلة. أفعل :

docker-compose down
docker-compose build
docker-compose up -d

لكن في بعض الأحيان يحدث خطأ

ERROR: for xxxxxx  Cannot start service web: driver failed programming external connectivity on endpoint xxxxx (xxxx): Bind for 0.0.0.0:22000 failed: port is already allocated

لا أستطيع إعادة تشغيل عامل الإرساء لأن هناك حاويات أخرى تعمل هناك

mogadanez على النحو الذي اقترحه KorossGame ، يمكنك محاولة العثور على العملية التي تستخدم هذا المنفذ بالفعل.

اتمنى لك يوم جيد،

تضمين التغريدة
عامل الإرساء الخاص به ، ولكنه لا يساعد ، لا يمكنني إعادة تشغيل عامل الإرساء بالكامل.

mogadanez إذا لم تتمكن من إعادة تشغيل عامل
sudo lsof -i -P -n | grep 9200
تحقق أيضًا مما إذا كانت حاويات عامل الإرساء لا تستخدم نفس منافذ الإدخال مع:
docker ps

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

مرحبا،
تحتاج فقط إلى التحقق مما إذا كانت هناك خدمة أخرى تستخدم نفس المنفذ ،

إذا كنت تستخدم Windows ، فأنت بحاجة إلى تشغيل الأمر التالي:

1. docker-compose down
2. netstat -ano | findstr :port (على سبيل المثال netstat -ano | findstr :18080 )
3. taskkill /pid the_pid_of_the_port /f
4. docker-compose up

وهذا كل شيء 😄

olfamoussaoui لقد جربت كل ذلك ولكن لنظام mac. لا يوجد حل يعمل.

gabrielhpugliese هل حاولت معرفة ما إذا كان المنفذ قيد الاستخدام؟

olfamoussaoui لقد جربت كل ذلك ولكن لنظام mac. لا يوجد حل يعمل.

كان لدي سلوك تأليف مشابه على Ubuntu. كان أثرًا جانبيًا ، بناءً على إعدادات iptables الخاطئة. يجب فحص ترجمة المنفذ وتحريرها يدويًا. لا تتذكر بناء جملة corect لنظام التشغيل MacOS. لا ينبغي أن يكون من الصعب العثور عليه بالحجر الوردي.

لا أفهم لماذا أحتاج كل ذلك والمشكلة ما زالت بعيدة. هو - هي
ليس إعدادًا جديدًا أقوم ببنائه ولم أنشئ جديدًا
حاويات / خدمات. لقد قمت للتو بإعادة إنشاء حاوية الخادم الخاصة بي باستخدام up -d
--يبني. غريب حقا.

Vitaly-zverev [email protected] schrieb am Mi. ، 19. آب (أغسطس) 2020 ،
17:27:

olfamoussaoui https://github.com/olfamoussaoui حاولت كل ذلك لكن
لل ماك. لا يوجد حل يعمل.

كان لدي سلوك تأليف مشابه على Ubuntu. كان من الآثار الجانبية ، على أساس
إعدادات iptables الخاطئة. يجب فحص ترجمة المنفذ وتحريرها
يدويا. لا تتذكر بناء جملة corect لنظام التشغيل MacOS. لا ينبغي أن يكون الأمر بهذه الصعوبة
للعثور عليه بحجر الوردة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/compose/issues/4950#issuecomment-676495723 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAJR3UTBMGLV2ECW5GCNQDTSBPVNXANCNFSM4DQLFGPQ
.

لا أفهم لماذا أحتاج كل ذلك والمشكلة ما زالت بعيدة. إنه ليس إعدادًا جديدًا أقوم ببنائه ولم أقوم بإنشاء حاويات / خدمات جديدة. لقد قمت للتو بإعادة إنشاء حاوية الخادم الخاصة بي باستخدام up -d --build. غريب حقا. Vitaly-zverev [email protected] schrieb am Mi. ، 19. آب (أغسطس) 2020 ، الساعة 17:27:
...
olfamoussaoui https://github.com/olfamoussaoui جربت كل ذلك لكن لنظام mac. لا يوجد حل يعمل. كان لدي سلوك تأليف مشابه على Ubuntu. كان أثرًا جانبيًا ، بناءً على إعدادات iptables الخاطئة. يجب فحص ترجمة المنفذ وتحريرها يدويًا. لا تتذكر بناء جملة corect لنظام التشغيل MacOS. لا ينبغي أن يكون من الصعب العثور عليه بالحجر الوردي. - أنت تتلقى هذا لأنه تم ذكرك. قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub < # 4950 (تعليق) > ، أو قم بإلغاء الاشتراك https://github.com/notifications/unsubscribe-auth/AAJR3UTBMGLV2ECW5GCNQDTSBPVNXANCNFSM4DQLFGPQ .

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

لقد كان الكثير من الإجابات الجيدة. لقد وجدت أن المشكلة كانت تطبيقًا آخر قمت بتثبيته (Sky Go) على Catalina والذي تسبب بطريقة ما في تعارض في المنفذ على الرغم من إغلاقه.
يجدر التحقق من أن هذه التطبيقات (بما في ذلك Skype) لا تسبب المشكلة.

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

• عامل ميناء - يؤلف أسفل (لإيقاف الحاوية الخاصة بي)
• docker ps (للتحقق من تشغيل أي حاوية في حالتي ، وجدت أن hasura Graphql قيد التشغيل)
• إيقاف حاوية عامل الإرساء [Container_ID]
• docker container rm [Container_ID] (في حالتي ، أزلت الحاوية أيضًا)
  وبعد اتباع العملية المذكورة أعلاه ، عمل عامل الإرساء الخاص بي

إذا كنت تستخدم WSL2 ، فتحقق لمعرفة ما إذا كان Hyper-V ممكّنًا أم لا. إذا لم يكن كذلك ، فقط قم بتمكينه ، فسيقوم بذلك.

إعادة تشغيل نظام التشغيل ساعدني