stop/rm هو الطريق الصحيح. قد تكون البيانات الموجودة في الأحجام مهمة ، لذلك نريد أن نجعل من الصعب إزالتها عن طريق الخطأ.

ربما يمكننا توثيق هذا بشكل أفضل قليلاً.

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

البيانات المستمرة عبر عمليات التشغيل هي حقًا السبب الوحيد لاستخدام وحدات التخزين. إذا كنت لا تريد البيانات المستمرة فلماذا تضعها في مجلد؟

أنا لا أقوم بإعداد وحدة تخزين. ليس لدي docker-compose.yml أي إعداد مجلدات وأنا لا أنقل أي شيء إلى docker-compose.yml لإرفاق أي مجلدات.

أمر:

docker-compose up --force-recreate --abort-on-container-exit --build foo

docker-compose.yml:

version: '2'
services:
  foo:
    build:
      context: .
      dockerfile: src/integration/foo/Dockerfile
    ports:
      - "3306:3306"
      - "33060:33060"

ملف Docker:

FROM mysql:5.7

COPY schema/foo/migration.sql /data/db_schema.sql
COPY src/integration/foo/create_test_db.sh /docker-entrypoint-initdb.d/create_test_db.sh
ENV MYSQL_ALLOW_EMPTY_PASSWORD true

EXPOSE 3306 33060

create_test_db.sh:

#!/bin/bash
set -e
mysql --no-defaults -u root -e "drop database if exists agent_state; create database foo"
mysql --no-defaults -u root foo < "/data/db_schema.sql"

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

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

في 19 أكتوبر 2016 ، 6:36 مساءً ، كتب "Micah Zoltu" [email protected] :

أنا لا أقوم بإعداد وحدة تخزين. لا يمتلك عامل ميناءي compose.yml أي شيء
إعداد وحدات التخزين وأنا لا أمرر أي شيء إلى docker-compose.yml
إرفاق أي مجلدات.

أمر:

إنشاء عامل ميناء - إعادة إنشاء - تنفيذ عند خروج حاوية - بناء فو

docker-compose.yml:

الإصدار 2'
خدمات:
فو:
بناء:
سياق الكلام: .
dockerfile: src / Integration / foo / Dockerfile
الموانئ:
- "3306: 3306"
- "33060: 33060"

ملف Docker:

من mysql: 5.7

نسخ مخطط / foo /igration.sql /data/db_schema.sql
COPY src / Integration / foo / create_test_db.sh /docker-entrypoint-initdb.d/create_test_db.sh
ENV MYSQL_ALLOW_EMPTY_PASSWORD صحيح

اكسبوس 3306 33060

create_test_db.sh:

! / بن / باش

مجموعة ه
mysql - no-defaults -u root -e "إسقاط قاعدة البيانات إن وجدت agent_state ؛ إنشاء قاعدة بيانات foo"
mysql - no-defaults -u root foo <"/data/db_schema.sql"

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/compose/issues/2127#issuecomment -254986952 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAa_RG_pJj0i-OSCfcBlG__8ToFDtGKMks5q1sWlgaJpZM4GHruC
.

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

لا يحتاج الحجم إلى مسار مضيف. هناك ثلاثة أنواع من المجلدات:

• حوامل ربط المضيف ( -v /host:/container )
• وحدات التخزين المسماة ( -v name:/container ، تم إنشاؤها باستخدام docker volume create )
• مجلدات مجهولة المصدر ( -v /container أو VOLUME داخل Dockerfile )

تستخدم صورة mysql مجلدًا مجهولاً. في وقت التشغيل ، يمكنك إخبار الحاوية باستخدام وحدة تخزين مختلفة لهذا المسار في الحاوية ، ولكن إذا لم تقم بذلك ، فسيظل المجلد المجهول موجودًا.

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

على الأقل بعض خيارات سطر الأوامر "--recreate-volumes" ستكون رائعة ...

حسنًا ، يا رفاق ، هذه هي الحالة التي يجب التفكير فيها:

1) أريد إعادة تحميل مجلدي العام في ريلز إلى حاوية nginx ، بحيث يمكن تقديم بعض العناصر الثابتة بواسطة nginx مباشرةً.
2) أعين وحدة تخزين "مجهول" (ليست محمولة على مضيف ، بدون اسم) إلى / usr / local / app / app / public ، وشاركتها مع nginx عبر "volumes_from"
3) غالبًا ما يتم تغيير المحتويات "العامة" عند إنشاء الصور - ليس فقط ملفات المستوى الأعلى ولكن بعض الملفات في الدلائل الفرعية (هذا مهم)

في الوقت الحالي ، إذا قمت بإعادة إنشاء الحاويات ، فسوف ينتهي بي الأمر بإصدار قديم من "عام" - يتم ببساطة تجاهل المحتويات في الصورة. نعم ، من المفترض أن يقوم Docker بنسخ الملفات المفقودة إلى المجلد المجهول ، ولكن لأسباب متنوعة لا يحدث ذلك دائمًا (أظن أنه لا يوجد فحص عميق لهيكل الدلائل الفرعية).

لذلك ، فأنا إما مجبر على تنفيذ تسلسل "stop-rm-up" (ليس ملائمًا في الإنتاج) ، أو استخدام دليل منفصل كوحدة تخزين مشتركة ، واستدعاء "rsync" بشكل صريح في حاوية التطبيق ، ابدأ في نشرها / تحديثها.

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

لا تستخدم وحدات التخزين للتعليمات البرمجية (أو الأصول الثابتة). وحدات التخزين مخصصة للبيانات التي تريد الاحتفاظ بها بين عمليات النشر ، وهو عكس ما تريده هنا. إما أن تبني صورة nginx باستخدام الأصول الثابتة ، أو توكيل بعض حاويات خادم الويب التي تحتوي عليها.

شكرا لوجهة النظر! لم أفكر من هذا المنظور بعد.

يبدو أنها إحدى المشكلات المفاهيمية مع بنية Docker (التي لا تزال قيد التطوير). لقد رأينا تطور مفهوم أحجام البيانات حتى الآن (على سبيل المثال من "حاويات البيانات" إلى "وحدات التخزين المسماة") وربما لم ينته بعد.

إذا نظرت إلى https://docs.docker.com/engine/tutorials/dockervolumes/#/data -volumes ، فسترى أن معظم الفوائد الموصوفة (تجاوز AUFS والمشاركة) ليست مرتبطة بالضرورة باستمرارية البيانات ( المجلدات التي تم تصميمها في الأصل).

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

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

مرة أخرى ، نشكرك على ردك وتوضيحك والعمل الرائع الذي تقوم به!

واجهت هذه المشكلة اليوم ، بفضل التفسيرات الرائعة هنا ، ساعدني الجميع بالتأكيد على فهم المشكلة.

كانت نقطة الارتباك الرئيسية بالنسبة لي هي فهم أن علامة VOLUME في ملف عامل ميناء تتسبب في إنشاء وحدة تخزين مجهولة متسقة. ربما فاتني ذلك في الوثائق ولكن لم أجد ذكرًا لها.

تضمين التغريدة

كما ذكر @ hleb-rubanau. تشغيل حاوية واحدة مع ريلز و Nginx هو الحل؟ (مثل هذا: https://docs.docker.com/engine/admin/multi-service_container/؟)

هل يجب أن أتخلص من أفضل الممارسات ("يجب أن يكون لكل حاوية مصدر قلق واحد فقط
") لمجرد تقديم الوجبات؟ :(

للمهتمين ، انتهى بي الأمر بما يلي:

1) في إعداداتي ، أستخدم دائمًا مجلدات مُثبتة بالربط (تُعرف أيضًا باسم المضيف) الآن. تحتوي المجلدات المجهولة والمسمّاة على الكثير من المنطق الخاص / غير الواضح / الشرطي / غير المتسق / الضمني الذي يجب مراعاته. نعم ، من السهل فهم تفاصيل دورة حياة كل نوع وإدارته ، لكنني وجدت أنه من الأسهل بالنسبة لي التفكير في الهندسة المعمارية عندما لا أشعر بالقلق إزاء كل تلك الاختلافات غير ذات الصلة. بالنسبة إلى FS Gluster الموزع ، يعمل بشكل جيد (لا يزال مثبتًا من منظور Docker).

2) وحدة التخزين المشتركة هي وحدة مُربوطة ، وليست الدليل حيث يتم تخزين الأصول في الصورة. في البداية (في نقطة الدخول) أقوم بتشغيل rsync المحلي ، بحيث يتم نسخ / مزامنة الأصول من دليل الصورة إلى مسار التخزين المشترك المُثبت.

شكرا @ hleb-rubanau

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

أفضل استخدام مجلدات مجهولة وتنظيف الأيتام في مرحلة ما.

هذا هو مكدس قضبان الإنتاج الخاص بي: https://github.com/brunocascio/AR-MTB/blob/master/docker-compose.prod.yml

تسبب هذا أيضًا في قدر كبير من الارتباك عندما كنت أختبر صورة jenkins / jenkins ولم تكن تحترم التغييرات التي أجريتها من الملفات الموجودة في / usr / share / jenkins / ref لأنها نسختها بالفعل.

هذه تجربة مستخدم غير متوقعة إلى حد كبير - إنشاء عامل الإرساء هو إنشاء مجلد "مخفي" لجميع المقاصد والأغراض. إذا كنت تستخدم docker run العادي ، فستحصل على حجم جديد في كل مرة. إنه مجلد مخفي بمعنى أنه لا يوجد شيء في docker-compose up يتحدث عنه ، لذلك ما لم تكن تعرف بالتفصيل ما تفعله الصورة ، عليك أن تذهب للحفر.

على الأقل _ يجب أن نطبع رسالة تقول "لا نعيد إنشاء مجلد x" حتى لا يضطر الآخرون في المستقبل إلى إضاعة الوقت في التساؤل عما يحدث.

مرحبًا dnephin ،

اتصل بـ sudo rm -rf /var/lib/docker/volumes/aa_dbdatavol والآن لا يمكنني إنشاء docker-compose up بعد الآن .

الحصول على هذا الخطأ

إنشاء شبكة "aa_default" مع برنامج التشغيل الافتراضي
إنشاء aa_postgres_1
خطأ: لـ postgres لا يمكن إنشاء حاوية لخدمة postgres: لا يوجد مثل هذا الملف أو الدليل
خطأ: تمت مواجهة أخطاء أثناء طرح المشروع.
استجابة خطأ من البرنامج الخفي: لا توجد مثل هذه الحاوية: aa_postgres_1

كما قد يكون لديك فكرة للالتفاف على ذلك ، يرجى المشاركة. شكرا لك!

https://github.com/docker/compose/issues/2127#issuecomment -347152650

مجرد إعادة إنشاء المجلد سيصلح مشكلتي.
/var/lib/docker/volumes/aa_dbdatavol/_data

شكراً جزيلاً لـ dnephin ، إجابتك على أكمل وجه ، في المرة الأولى. Muchos gracias.

dnephin قال:

البيانات المستمرة عبر عمليات التشغيل هي حقًا السبب الوحيد لاستخدام وحدات التخزين. إذا كنت لا تريد البيانات المستمرة فلماذا تضعها في مجلد؟

لمشاركة الملفات بين الحاويات. هل هناك طريقة أفضل للقيام بذلك دون استخدام وحدات التخزين؟

ماذا تقصد ب "مشاركة الملفات"؟

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

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

أنا أستخدم Docker version 18.06.1-ce, build e68fc7a ويمكنني استخدام الأمر التالي لإعادة إنشاء مجلدات مجهولة:

docker-compose up -d --build --force-recreate --renew-anon-volumes db

يبدو أن العلم --renew-anon-volumes قد أضيف مؤخرًا

أنا أستخدم Docker version 18.06.1-ce, build e68fc7a ويمكنني استخدام الأمر التالي لإعادة إنشاء مجلدات مجهولة:

docker-compose up -d --build --force-recreate --renew-anon-volumes db

يبدو أن العلم --renew-anon-volumes قد أضيف مؤخرًا

شكرا لترك هذا الخيار.