मैं अपने पीएचपी एफपीएम कंटेनर के लिए क्रोनजॉब्स चलाने के बारे में सर्वोत्तम प्रथाओं की तलाश कर रहा हूं ।
अभी चल रहा है:
NGINX कंटेनर
PHP FPM कंटेनर
MySQL कंटेनर
अब मुझे "क्रोनजॉब कंटेनर" नामक एक और कंटेनर चलाना अच्छा लगेगा, जो मेरे पीएचपी एफपीएम कंटेनर के भीतर एक स्क्रिप्ट निष्पादित करता है ( मुझे पीएचपी की कुछ निर्भरता की आवश्यकता है) ।
तो तीन संभावित समाधान:
1.) एक कंटेनर चल रहा है
मैं इस समाधान का उपयोग करना पसंद करूंगा!
यह अच्छा होगा के लिए एक कंटेनर चल क्रॉन, जहां मैं कर रहा हूँ करने के लिए ( किसी भी तरह ) कॉल डोकर exec पर मेरे php fpm कंटेनर... या एक और तरीका है ।
2.) पीएचपी कंटेनर के अंदर क्रॉन चल रहा है
यह ठीक होगा, लेकिन सबसे अच्छा अभ्यास नहीं है । मैं क्रॉन चलाने वाले अपने पीएचपी एफपीएम कंटेनर के अंदर दूसरी प्रक्रिया शुरू कर सकता था । यह काम करेगा लेकिन मुझे यकीन नहीं है कि यह वह है जो आपको डॉकर के साथ काम करना चाहिए ।
3.) रनिंग होस्ट क्रॉन
यह क्रूर होगा । मुझे किसी दिए गए पथ के प्रोसेसिड और कंटेनरआईडी को ढूंढना होगा और फिर डॉकर निष्पादन चलाना होगा । लेकिन यह कमोबेश मेरा आखिरी तरीका है । .. और मुझे तैनाती के बिना क्रोनजॉब्स का प्रबंधन करने से नफरत है ।
मैंने एक डेमॉन लिखा है जो कंटेनरों और शेड्यूल नौकरियों को देखता है, उनके मेटाडेटा में परिभाषित किया गया है, उन पर । यह आपके 1) समाधान के सबसे करीब आता है । उदाहरण:
क्रॉन स्वयं अग्रभूमि में स्थापित और चलाया जा सकता है (cron -f) कंटेनर में स्थापित करना बहुत आसान है । अन्य कंटेनरों तक पहुंचने के लिए, आप क्लाइंट सीएलआई (डेमॉन चलाने के लिए नहीं) के लिए उसी कंटेनर में डॉकर स्थापित करेंगे । फिर होस्ट डॉकर वातावरण तक पहुंचने के लिए, सबसे आम समाधान डॉकर सॉकेट को माउंट करना है (-v /var/run/docker.sock:/var/run/docker.sock). केवल गोचा यह है कि आपको होस्ट जीआईडी से मेल खाने के लिए अपने कंटेनर के अंदर डॉकर जीआईडी सेटअप करना होगा, और फिर कंटेनर के अंदर उपयोगकर्ताओं को डॉकर समूह में जोड़ना होगा ।
इसका मतलब यह है कि उन उपयोगकर्ताओं के पास होस्ट पर किसी भी डॉकर उपयोगकर्ता की समान पहुंच है, उदाहरण के लिए रूट स्तर पहुंच, इसलिए आपको या तो उन्हें सबमिट करने वाले उपयोगकर्ता पर पूरी तरह से भरोसा करने की आवश्यकता है, या उन आदेशों को सीमित करें जो वे किसी प्रकार के सुडो समकक्ष के साथ चला सकते हैं । अन्य नकारात्मक पक्ष यह है कि यह कम पोर्टेबल है, और सुरक्षा जागरूक व्यवस्थापक आपके कंटेनरों को उनके सिस्टम पर चलाने की मंजूरी देने की संभावना नहीं होगी ।
को fallback के लिए विकल्प एक बहुत आसान है के साथ एक उपकरण की तरह supervisord. जबकि आदर्श "प्रति कंटेनर एक प्रक्रिया" से कम है, यह काफी विरोधी पैटर्न नहीं है क्योंकि यह आपके पूरे कंटेनर और निर्भरता को एक साथ रखता है, और मेजबान को किसी भी सुरक्षा जोखिम को हटा देता है ।
चाहे आप पहले या दूसरे विकल्प के साथ जाएं, आपके पर्यावरण के लिए नीचे आता है, जो नौकरियों को जमा कर रहा है, कितने कंटेनरों को खुद के खिलाफ नौकरियों को जमा करने की आवश्यकता है, आदि । यदि यह एक व्यवस्थापक है जो बहुत सारे कंटेनरों के खिलाफ नौकरी जमा कर रहा है, तो एक क्रॉन कंटेनर समझ में आता है । लेकिन अगर आप एप्लिकेशन डेवलपर हैं जिन्हें पैकेज के रूप में अपने ऐप के साथ एक निर्धारित नौकरी शामिल करने की आवश्यकता है, तो दूसरे विकल्प के लिए जाएं ।
चलाने के लिए क्रॉन एक और कंटेनर में या यहां तक कि मेजबान पर लेकिन चलाने के लिए स्क्रिप्ट के माध्यम से php-fpm (उदाहरण के लिए । क्रॉन "कर्ल" या कुछ पीएचपी स्क्रिप्ट होगा) ।
सुनिश्चित करें कि आप इस तरह के सेटअप को सुरक्षा टोकन, नेटवर्क सीमाओं आदि के साथ सुरक्षित करते हैं । एक वृद्धि गतिशील प्रक्रियाओं के साथ एक अलग पीएचपी-एफपीएम पूल हो सकती है जो अधिकतम एक प्रक्रिया को स्पॉन करने में सक्षम है । यह पूल केवल क्रॉन द्वारा सुलभ होगा । यह भी लाभ के लिए यह है खुद के अलग-अलग सेटिंग्स के इस तरह के एक जिस तरह से बड़ा निष्पादन समय है, और अधिक या कम स्मृति आदि ।
पुनश्च: आप कुछ इस तरह का उपयोग कर सकते हैं यह स्क्रिप्ट को सीधे एफपीएम कंटेनर में कॉल करने के लिए और एनजीआईएनएक्स के माध्यम से न जाएं ।
तर्क: आप शायद एक ही पुस्तकालय, एक ही विन्यास आदि का उपयोग करना चाहते हैं । डॉकर में सिग्नल मैनेजर द्वारा बेतरतीब ढंग से पैदा की गई और नियंत्रित नहीं की गई प्रक्रिया को चलाना वास्तव में एक बुरा विचार है ।
मेरा प्रारंभिक विचार क्रॉन नौकरियों को अलग से शुरू करना था cron कंटेनर और वास्तव में उन्हें दूसरे कंटेनर के भीतर निष्पादित करें (php) यानी। एक होना crontab प्रत्येक के लिए रिकॉर्ड docker run -i t $containerName $scriptName ... कमांड के भीतर अलग स्क्रिप्ट चल रहा है php कंटेनर
नुकसान के कारण दृष्टिकोण वास्तव में अच्छा नहीं है @BMitch भी उल्लेख है । इसके अलावा मैं वास्तव में स्थापित करना पसंद नहीं करता docker कंटेनर को ।
मैं आपके तहत एक और समाधान फिटिंग की पेशकश करना चाहता हूं #1 श्रेणी: एक चला सकते हैं php-fpm सीधे। हालांकि यह दुनिया में सबसे सुरुचिपूर्ण समाधान नहीं है, यह लाभ प्रदान करता है:
सुरक्षा - कोई विशेष या विशेषाधिकार प्राप्त पहुंच नहीं, बस होस्ट और पोर्ट (जैसे) का उपयोग करें php-host:9000) जो पहले से ही खुला है nginx डॉकर वर्चुअल नेटवर्क के भीतर से
होने के cron प्रबंधन से अलग php कंटेनर - इसलिए स्केलिंग को नुकसान नहीं पहुंचाया जाता है
वास्तव में उपयोग कर cron क्रोनिश कार्यों के लिए-बस पौधे लगाएं crontab और विभिन्न अन्य कामों के माध्यम से क्रॉन को फिर से लागू करने के बजाय किया जाए
स्क्रिप्ट निष्पादन के माध्यम से नहीं जाता है nginx, इसलिए कोई भी उन्हें सीधे वेबसर्वर के माध्यम से नहीं चला सकता है, आपको किसी भी प्रमाणीकरण या ऐसे तंत्र को लागू करने की आवश्यकता नहीं है
अनुमतियों के साथ भी कम समस्याएं । मेरा पिछला क्रॉन डॉकराइजेशन हो रहा था cron दूसरे के भीतर स्थापित php कंटेनर और वॉल्यूम का उपयोग करके कोडबेस साझा करना। यह कुशल था, लेकिन अनुमतियों को कैश, डी, लॉग इत्यादि के रूप में सावधानी से संभाला जाना था । वेबसर्वर और ए दोनों द्वारा सुलभ और लिखने योग्य होना था cron उपयोगकर्ता। यह दृष्टिकोण समस्या को समाप्त करता है
अब तक मुझे जो एकमात्र नुकसान हुआ है, वह यह है कि पहली पंक्ति डब्ल्यू / हैशबैंग (#!/usr/local/bin/php) को वास्तविक आउटपुट माना जाता है और पहले से भेजे गए हेडर के बारे में पीएचपी चेतावनी उत्सर्जित होती है (Cannot modify header information - headers already sent by ...)- हैशबैंग को छोड़ने से यह ठीक हो जाता है ।
मैंने ऐसा किया (डॉकर के साथ कम या ज्यादा स्वचालित रूप से लिखें ) लेकिन आप किसी प्रकार के नेटवर्क कमांड के साथ किसी प्रकार का पीएचपी आधारित क्रोनजॉब कैसे शुरू करेंगे? अगर मैं पोर्ट 80 का उपयोग करता हूं तो मेरे पास मेरे खिलाफ काम करने वाले पीएचपी का सामान्य टाइमआउट है जिसका कोई मतलब नहीं है । … निश्चित नहीं है कि एक अच्छा समाधान क्या होगा!
ऐसा नहीं है कि मैं या समझ का परीक्षण कर सकते हैं इस के किसी भी है, लेकिन वहाँ एक उदाहरण है कि दस्तावेज़ में कहते हैं कि आप कर सकते हैं चलाने के लिए एक कमांड की तरह इस डोकर चलाने --आरएम --नाम web2 --लिंक db:db प्रशिक्षण/webapp commandname, इसलिए है कि अगर काम करता है आप के लिए, चलाने के लिए क्रॉन एक कंटेनर में है, और यह आदेश जारी उस तरह पर अन्य कंटेनर(एस).
#1! - क्षमा करें मैं वास्तव में नहीं जानता । क्या कंटेनरों की बात नहीं है ताकि वे "निहित"हों? जैसे, “सुरक्षित”? मैं डॉकर या एप्लिकेशन कंटेनर का उपयोग नहीं करता, इसलिए मुझे नहीं पता कि मैं वास्तव में क्या बात कर रहा हूं । …
आप पूरी तरह से सही हैं कि उन्हें “निहित” होना चाहिए, लेकिन आपको उनमें से कुछ को सॉफ्टवेयर के एक टुकड़े के रूप में एक साथ काम करना होगा । यदि आप अपने सॉफ़्टवेयर को एक प्रक्रिया के रूप में चलाने में सक्षम नहीं हैं ( और जैसे ही आप अपने स्वयं के डेटाबेस को खरोंच से लिखने में समर्थक नहीं हैं, तो आप ईमानदार नहीं हैं ) आपको एक साथ काम करने के लिए कुछ कंटेनरों की आवश्यकता है । और मुझे नहीं पता कि उनके साथ क्रोनजॉब्स कैसे चलाना है =/ ।