Docker-mailman: पूर्ण स्टैक डॉकर लिखें

इसमें आपकी रुचि के लिए धन्यवाद, मैं ऐसा होना पसंद करूंगा!

• मुझे लगता है कि हमें फुल-स्टैक कंपोज़ को वर्तमान विकल्प के लिए एक अलग विकल्प के रूप में रखना चाहिए, ज्यादातर उन लोगों के लिए जिन्हें होस्ट पर अपने एमटीए/वेब सर्वर की आवश्यकता होती है ताकि वे मेलमैन की सेवा के अलावा अन्य काम कर सकें।
• पर्यावरण चर को .env फ़ाइल में ले जाना वास्तव में मेरे लिए बहुत मायने नहीं रखता है, मैं समझता हूं कि आप शायद अपने रहस्यों को सुरक्षित रखना चाहते हैं, लेकिन जब तक कोई .env तक पहुंच से इनकार करने के लिए कुछ लिनक्स अनुमतियों का उपयोग नहीं कर रहा है docker-compose.yaml , यह एक तरह से बेकार है ना? और मुझे यकीन नहीं है कि ऐसा करने के बारे में कोई कैसे जाएगा।
• एक पोस्टफिक्स कंटेनर जोड़ना एक बड़ी मदद होनी चाहिए, यह #282 से असंबंधित है, लेकिन हम इसे एक अलग एमआर में संभाल सकते हैं।
• मुझे लगता है कि एक Nginx कंटेनर जोड़ना जो mailman-web साथ वॉल्यूम साझा करता है, सबसे अच्छा होगा। मुझे इस समय #144 में बहुत दिलचस्पी नहीं है, खासकर क्योंकि यह वास्तव में हमें बहुत तेज या कुछ भी नहीं देता है। स्टार्टअप पर स्थिर फाइलें बनाना आमतौर पर ठीक होना चाहिए।
• स्टडआउट में लॉगिंग बहुत अच्छा होना चाहिए, Django शायद इसे आसानी से कर सकता है, कोर सक्षम हो सकता है।
• हम होस्टनाम, कंटेनर-नाम, लिंक के लिए डिफ़ॉल्ट प्रविष्टियों को क्यों हटाना चाहते हैं?
• हार्ड-कोडेड नेटवर्क सामग्री को हटाना कुछ ऐसा है जो मैं वास्तव में करना चाहता हूं, जिसमें हाइपरकिट्टी कोर से अनुरोधों को प्रमाणित करने के आधार पर कुछ चुनौतियां हो सकती हैं, लेकिन हम इसे अपस्ट्रीम में भी ठीक कर सकते हैं।

कुल मिलाकर, मुझे अधिकांश विचार पसंद हैं। आदर्श रूप से, हम चाहते हैं कि प्रत्येक परिवर्तन उनके अपने अलग पुल अनुरोध में हो और फिर हम उनके संबंधित पीआर में अधिक विवरण में चर्चा कर सकते हैं।

.env फ़ाइल के बारे में:

• यह एंड्यूसर को यह स्पष्ट करता है कि खोज के बिना कौन से वेरिएबल को बदला जाना चाहिए, पूरे docker-compose.yml threw
• यह डुप्लिकेट परिभाषाओं को हटा देता है (जैसे हाइपरकिट्टी एपीआई कुंजी)
• यह docker-compose.yml (चूंकि कोई अपस्ट्रीम का उपयोग कर रहा है) को अपग्रेड करना आसान बना सकता/सकती है और केवल स्थानीय .env में बदले गए चर को जोड़ना/संशोधित करना है
• एंड्यूसर अपने चल रहे docker-compose.yml को सोर्स कंट्रोल में बिना रहस्य उजागर किए चेक कर सकते हैं

मुझे लगता है कि एक पीआर इसे स्पष्ट कर देगा, यह ज्यादा काम नहीं है इसलिए अगर हम इसे छोड़ दें तो कोई परेशानी नहीं होगी।

लिंक एक बहिष्कृत विशेषता है, डिफ़ॉल्ट रूप से एक सेवा अनुभाग में सभी कंटेनर एक नेटवर्क में होते हैं इसलिए वैसे भी जुड़े होते हैं। होस्टनाम और कंटेनर-नाम सेवा परिभाषा में वर्तमान खंड के लिए डिफ़ॉल्ट है, इसलिए वर्तमान में स्पष्ट रूप से परिभाषित किया गया है और मुझे लगता है कि उन्हें हटाने से पूरी फ़ाइल छोटी हो जाती है और समझने में आसान हो जाती है।

कुछ हद तक संबंधित, मैंने इन कंटेनरों को मेलू (https://github.com/Mailu/Mailu) में एकीकृत किया जो शेष स्टैक प्रदान करता है। क्या इस तरह के सेटअप में कोई दिलचस्पी है?

@pgeorgi यदि आपके पास पहले से ही वह एकीकरण है जिसे आप इन छवियों का उपयोग करके बनाए रखना चाहते हैं, तो मुझे दस्तावेज़ीकरण में आपके भंडार/पोस्ट के लिए एक लिंक जोड़ने में खुशी होगी।

@pgeorgi निश्चित रूप से

देखें https://patrick.georgi.family/2019/01/12/combining-mailman-3-with-mailu/

मैं .env फ़ाइल के बारे में @morbidick से सहमत हूं, मुख्यतः क्योंकि यह अपडेट करना बहुत आसान बनाता है।
आप अपने रेपो को प्रदूषित किए बिना बस git pull कर सकते हैं।
साथ ही, .env फ़ाइल .gitignore में होनी चाहिए

उदाहरण : देखें कि संतरी यह कैसे करता है:
https://github.com/getsentry/onpremise

वे एक env.example फ़ाइल भी प्रदान करते हैं जिसे आप अपनी .env फ़ाइल में कॉपी कर सकते हैं।