@ستيفن هناك ثغرة في حجتك: وصف الحاويات المتعددة مليء بالتحذيرات التي تنص على أنك تتحمل مسؤولية التحديثات وتفهم كيفية عملها، والوصف الطويل أعلاه غامض لدرجة أن أي شخص ينظر إليه على الأرجح سيتخلى عن الأمر. اذهب واقرأ مقالتي على Migrate quickly to separate web and data containers وأخبرني ألا تخيف الأشخاص الذين سيواجهون صعوبة في متابعته، أو أنه يفشل في التأكيد على ضرورة النسخ الاحتياطي والقدرة على العودة إلى النسخة الاحتياطية في حال حدوث أي خطأ!
كنت غير سعيد للغاية عندما نفذت الأمر ./launcher rebuild app بعد وقت قصير من الانتقال إلى خادم أكثر كفاءة (لتطبيق إصلاح أمني)، مما أدى إلى توقف موقعي لفترة طويلة بشكل فاضح، وكان جزء كبير من ذلك الوقت مخصصًا لإعادة بناء أجزاء postgres في الحاوية. كان ذلك هو الوقت الذي وجدت فيه وثائق الحاويتين ووثائق هذا الموقع، ولم أكن أريد حقًا تحمل فترة توقف أخرى مدتها 4 ساعات للانتقال، لذا استمريت في تحمل فترات توقف طويلة لتنفيذ ./launcher rebuild app لتجنب 4 ساعات من التوقف التي يتطلبها الاستعادة. كشخص يتمتع بكفاءة متوسطة، كنت منزعجًا لفترة طويلة لأن هذا التكوين كان مخفيًا فعليًا.
موضوع postgres 12 مرجع ممتاز، لأن الناس ينتهي بهم المطاف إلى توقف أطول لأنهم يضطرون إلى إعادة بناء التطبيق كاملًا عدة مرات، بينما كان بإمكانهم إعادة بناء حاوية postgres فقط مرتين. لا يمكنني القول إنني قرأت الموضوع بأكمله بسبب ميزة الحذف التلقائي بعد 6 أيام، لكنه ليس واضحًا على الإطلاق بالنسبة لي أن عمليات نشر الحاويات المتعددة غير الكفؤة هي المشكلة الكبيرة هناك، أو حتى مشكلة كبيرة.
(آسف، أحيانًا أتعب قليلاً من فكرة أن “جميع المستخدمين غير أكفاء” هنا.)