لا تحب الإعلانات؟ يذهب خالية من الإعلانات اليوم 

مُصَوّر YAML لـ Docker Compose

بياناتمطور

إعلان · حذف؟

مدخل

عملية تلقائية

انتاج

جانب العميل

إعلان · حذف؟

مرشد

اللصق ملف docker-compose.yml وتحصل فورًا على ملف نظيف ومُصاغ بشكل متسق مع الخدمات والشبكات والوحدات، مُرتّب وفقًا لمعايير داكر كومبوز

مُصَوّر YAML لـ Docker Compose

اللصق docker-compose.yml وتحصل فورًا على ملف نظيف ومُصاغ بشكل متسق مع خدمات وشبكات ووحدات التخزين، مُرتّب وفقًا لمعايير تكوين داكر كومبوز، حيث يتحقق المُصاغ من الملف ضد المعيار الحديث لـ تكوين داكر، ويُظهر المفاتيح المُستبعدة مثل المفتاح القديم version مفتاح links، ويُحذر من خيارات الخدمة غير المعروفة قبل أن تؤدي إلى فشل في التشغيل.

كيفية استخدام

ألصق docker-compose.yml إلى منطقة الإدخال، أو انقر على أحد روابط الأمثلة لتحميل مثال مُسبق.
اختر ترتيب المفتاح — مبدأ تكوين يُرتّب الخدمات وفقًا لترتيب ما يُتوقع من المستخدمين (الصورة، إعادة التشغيل، البيئة، الأبواب، الوحدات، …) أبجدي يُرتّب بشكل أبجدي من A إلى Z، أو الحفاظ يُحافظ على ترتيبك الأصلي.
اختر تجميل بمسافة 2 أو 4 مسافات، وقم بتشغيل التحقق من معايير تكوين أو إيقافه.
اقرأ لوحة التحقق للحصول على الأخطاء، والتحذيرات حول المفاتيح المُستبعدة، والتنبيهات حول المراجع غير المُعلنة تلقائيًا.
انسخ النتيجة أو احفظها كـ docker-compose.yml.

خصائص

تحقق من معايير تكوين – يُعرف المفتاح الرئيسي services, networks, volumes, configs, secrets, profiles, include، وحقول التمديد (x-*); ويُظهر أي شيء آخر.
تحذيرات التسريب – يُبرز المفتاح الرئيسي القديم version ، وحدود الموارد في العصر v2 التي يجب أن تُنقل تحت links, external_linksترتيب المفتاح المُدرك للخدمات deploy.resources.
– يُرتّب كل خدمة بحيث تأتي المفاتيح المُعرفة ( ) في البداية، ثم التكوين أثناء التشغيل (image, build, container_name) في المنتصف، ومشاكل التشغيل (environment, ports, volumes) في النهاية.healthcheck, logging, deployالتحقق من المراجع
– يكتشف الخدمات التي تعتمد على خدمات غير معرفة ويُحذر عند استخدام خدمة شبكة غير معلنة في مستوى الرأس. متطلبات الخدمة
– يتحقق من أن كل خدمة تحتوي على واحدة على الأقل من ، وأن image, build, extends، أو providerتستخدم واحدة من الأربعة سياسات المسموحة. restart التحقق من الأبواب + التحقق من الصحة
– يُكتشف سلاسل الأبواب غير المُصاغة، والغياب المُستبعد للـ في الأبواب الطويلة، والتحقق من الصحة بدون target ثلاثة أمثلة تعمل test.
– تطبيق نود + بستجرس، وسلسلة ووردبريس + ميكي + ريديس، وبناء متعدد الخدمات مع ملفات التحكم والحدود. محلية + خاصة
– تتم جميع عمليات التحليل، الترتيب، والتحقق داخل المتصفح. لا يغادر ملف تكوينك الصفحة. لماذا تم إلغاء المفتاح الرئيسي للنسخة؟

 التعليمات

كان المفتاح للنسخة يستخدم في الإصدارات القديمة من تكوين داكر (v1، v2، v3) لاختيار نموذج للواجهة الخاصة بـ داكر كومبوز. تم دمج هذه النماذج في معيار تكوين واحد مستمر، لذا لم يعد تغيير أي شيء — الإصدارات الحديثة لـ داكر كومبوز تتجاهله وتنشر تحذيرًا. إزالة هذا المفتاح تقلل من حجم الملف وتمنع الارتباك عند افتراض أن الميزات الخاصة بـ v3 مُحددة من خلال هذا التصريح.

ما هو معيار تكوين داكر وما الفرق بينه وبين التنسيقات القديمة؟
معيار تكوين داكر هو المعيار المفتوح والمحايد للشركات الذي استعاض عنه النماذج المُتخصصة التي استخدمها داكر كومبوز حتى عام 2020. ويُدار في github.com/compose-spec/compose-spec ويُستخدم من قبل داكر كومبوز، بودمان كومبوز، وغيرها من المُنفذين. مقارنة مع v2 وv3، يُحذف المفتاح للنسخة، ويُجعل الخدمات هي المفتاح المطلوب فقط على مستوى الرأس، ويُدمج حقول السوام في معلومات اختيارية يمكن أن يستفيد منها المُنظّمون.

لماذا نفضل الشبكة المشتركة على مفتاح الربط؟
كانت ميزة الربط موروثة من عصر داكر قبل الشبكات، وتم تعيين تسميات DNS فقط بين الأكواد على الشبكة الافتراضية. تُقدم الشبكات المُحددة حاليًا تحليلًا تلقائيًا للعنوان DNS لكل خدمة، وتُتيح تكوين شبكات مُفصّلة لكل سلسلة، وتُتيح التحكم في تسميات DNS عبر خيار الـ aliases. وبسبب ذلك، يُصنف مفتاح الربط كمُستبعد في معيار تكوين داكر ويُوصى بوضع عضوية صريحة في الشبكة بدلاً من ذلك.

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

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

اللصق هنا محتوى ملف docker-compose.yml