लिनक्स क्रोन नौकरियों को "अमेज़ॅन तरीके" में कैसे परिवर्तित किया जाए?


112

बेहतर या बदतर के लिए, हमने अपने संपूर्ण LAMP वेब एप्लिकेशन को समर्पित मशीनों से क्लाउड (Amazon EC2 मशीनों) पर माइग्रेट कर दिया है । यह अब तक बहुत अच्छा है लेकिन जिस तरह से हम क्रोन करते हैं वह उप-इष्टतम है। मेरे पास अमेज़ॅन-विशिष्ट प्रश्न है कि "अमेज़ॅन के रास्ते" का उपयोग करके क्लाउड में क्रोन नौकरियों का सर्वोत्तम प्रबंधन कैसे किया जाए।

समस्या : हमारे पास कई वेबसर्वर हैं, और बैच नौकरियों के लिए क्रोन चलाने की जरूरत है जैसे कि आरएसएस फीड्स बनाना, ईमेल ट्रिगर करना, वास्तव में कई अलग-अलग चीजें। लेकिन क्रोन जॉब्स को केवल एक मशीन पर चलने की आवश्यकता है क्योंकि वे अक्सर डेटाबेस में लिखते हैं इसलिए यदि कई मशीनों पर चलाया जाता है तो वे परिणाम को दोहराएंगे।

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

हम लिनक्स क्रोन नौकरियों को क्षणभंगुर कार्य वस्तुओं में परिवर्तित करने के लिए अपने आवेदन को कैसे नया कर सकते हैं जिसमें विफलता का एक भी बिंदु नहीं है?

मेरे विचार अब तक:

  • एक मशीन है जो केवल चल रहे क्रोन को समर्पित है। यह थोड़ा अधिक प्रबंधनीय होगा, लेकिन अभी भी एक एकल-बिंदु-विफलता होगी, और कुछ पैसे बर्बाद कर देगा एक अतिरिक्त उदाहरण।
  • कुछ कामों को निश्चित रूप से लिनक्स क्रोन से MySQL ईवेंट में ले जाया जा सकता है लेकिन मैं इस विचार का बहुत बड़ा प्रशंसक नहीं हूं क्योंकि मैं डेटाबेस लेयर में एप्लिकेशन लॉजिक नहीं डालना चाहता।
  • शायद हम सभी मशीनों पर सभी क्रोन चला सकते हैं लेकिन हमारी क्रोन लिपियों को बदल सकते हैं, इसलिए वे सभी तर्क के साथ शुरू करते हैं जो एक लॉकिंग तंत्र को लागू करता है इसलिए केवल एक सर्वर वास्तव में कार्रवाई करता है और अन्य सिर्फ छोड़ देते हैं। मैं इस विचार का प्रशंसक नहीं हूं क्योंकि यह संभावित रूप से छोटी गाड़ी लगती है और मैं अपने रोल को करने के बजाय अमेज़ॅन के सर्वोत्तम अभ्यास का उपयोग करना पसंद करूंगा।
  • मैं ऐसी स्थिति की कल्पना कर रहा हूं जहां नौकरियां कहीं निर्धारित हों, एक कतार में जोड़ा जाए और फिर वेबसर्वर प्रत्येक एक कार्यकर्ता हो सकते हैं, जो कह सकते हैं "अरे, मैं इसे ले जाऊंगा"। अमेज़ॅन सिंपल वर्कफ़्लो सर्विस वास्तव में इस तरह की बात लगती है, लेकिन मुझे वर्तमान में इसके बारे में ज्यादा जानकारी नहीं है, इसलिए कोई भी विवरण सहायक होगा। यह एक क्रोन के रूप में कुछ के लिए भारी वजन की तरह लगता है? क्या यह सही सेवा है या अधिक उपयुक्त अमेज़न सेवा है?

अद्यतन: प्रश्न पूछने के बाद से मैंने YouTube पर अमेज़ॅन सिंपल वर्कफ़्लो सर्विस वेबिनार देखा है और 34:40 पर देखा है ( http://www.youtube.com/watch?v=lBUQiek8Jqk#t=34m40s ) मैंने एक झलक देखी एक नमूना आवेदन के रूप में क्रोन नौकरियों का उल्लेख स्लाइड। अपने प्रलेखन पृष्ठ में, " एडब्ल्यूएस फ्लो फ्रेमवर्क सैंपल्स फॉर अमेज़ॅन एसडब्ल्यूएफ ", अमेज़ॅन का कहना है कि उनके पास क्रोन के लिए नमूना कोड है:

... > क्रोन नौकरियां इस नमूने में, एक लंबे समय तक चलने वाला वर्कफ़्लो समय-समय पर एक गतिविधि को निष्पादित करता है। नए निष्पादन के रूप में निष्पादन जारी रखने की क्षमता ताकि निष्पादन बहुत विस्तारित अवधि के लिए चल सके। ...

मैंने जावा ( http://aws.amazon.com/sdkforjava/ ) के लिए AWS SDK डाउनलोड किया और निश्चित रूप से फ़ोल्डरों की हास्यास्पद परतों के भीतर पर्याप्त दफन है कुछ जावा कोड ( aws-java-sdk-1.3.6/samples/AwsFlowFramework/src/com/amazonaws/services/simpleworkflow/flow/examples/periodicworkflow) है।

समस्या यह है, अगर मैं ईमानदार हूं, तो यह वास्तव में मदद नहीं करता है क्योंकि यह ऐसा कुछ नहीं है जिसे मैं अपने कौशल के साथ आसानी से पचा सकता हूं। पीएचपी एसडीके से एक ही नमूना गायब है और इस प्रक्रिया के बावजूद चलने वाला एक ट्यूटोरियल नहीं लगता है। इसलिए मूल रूप से, मैं अभी भी सलाह या सुझावों के लिए शिकार कर रहा हूं।


जवाबों:


38

मैंने उन्हें यह सवाल पूछने के लिए अमेज़न गोल्ड सपोर्ट के लिए साइन किया, यह उनकी प्रतिक्रिया थी:

टॉम

मैंने अपने कुछ सहयोगियों का त्वरित सर्वेक्षण किया और क्रोन पर खाली आया, लेकिन इस पर सोने के बाद मुझे एहसास हुआ कि महत्वपूर्ण कदम लॉकिंग तक सीमित हो सकता है। इसलिए मैंने "वितरित क्रोन जॉब लॉकिंग" की तलाश की और एक अपाचे परियोजना ज़ुकाइपर का संदर्भ पाया।

http://zookeeper.apache.org/doc/r3.2.2/recipes.html

http://highscalability.com/blog/2010/3/22/7-secrets-to-successfully-scaling-with-scalr-on-amazon-by-se.html

इसके अलावा, मैंने टीटीएल के साथ ताले बनाने के तरीके के रूप में मेम्केड या इसी तरह के कैशिंग तंत्र का उपयोग करने के लिए संदर्भ देखा है। इस तरह आप एक झंडा लगाते हैं, जिसमें 300 सेकंड का टीटीएल होता है और कोई अन्य क्रोन कर्मी नौकरी नहीं करेगा। TTL की समय सीमा समाप्त होने के बाद लॉक अपने आप रिलीज़ हो जाएगा। यह वैचारिक रूप से SQS विकल्प के समान है जिसकी हमने कल चर्चा की थी।

और देखें; Google की गलफ़ुला http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/chubby-osdi06.pdf

मुझे बताएं कि क्या यह मदद करता है, और सवाल पूछने के लिए स्वतंत्र महसूस करता है, हम बहुत जागरूक हैं कि हमारी सेवाएं शुरुआती और अनुभवी डेवलपर्स दोनों के लिए जटिल और चुनौतीपूर्ण हो सकती हैं। हम हमेशा वास्तुकला और सर्वोत्तम अभ्यास सलाह देने के लिए खुश हैं।

सादर,

Ronan G. Amazon वेब सेवाएँ


13

मुझे लगता है कि यह वीडियो आपके सटीक प्रश्न का उत्तर देता है - क्रोनोजर aws रास्ता (स्केलेबल और गलती सहिष्णु):

अमेज़न सरल वर्कफ़्लो के साथ क्लाउड में क्रोन का उपयोग करना

वीडियो क्रोनॉजर्स को लागू करने के विशिष्ट उपयोग के मामले का उपयोग करते हुए एसडब्ल्यूएफ सेवा का वर्णन करता है।

यदि आप एक क्रेस्टैब से सीधे आ रहे हैं, तो समाधान की सापेक्ष जटिलता को निगलना मुश्किल हो सकता है। अंत में एक केस स्टडी है जिसने मुझे यह समझने में मदद की कि अतिरिक्त जटिलता आपको क्या खरीदती है। मैं यह सुझाव दूंगा कि आप केस स्टडी को देखें और स्केलेबिलिटी और फॉल्ट टॉलरेंस के लिए आपकी आवश्यकताओं पर विचार करें कि क्या आपको अपने मौजूदा क्रॉस्टैब सॉल्यूशन से माइग्रेट करना चाहिए।


2
यह एक महान जवाब है क्योंकि यह AWS से एक अच्छी तरह से समर्थित उपकरण का उपयोग करता है, और SWF एक शक्तिशाली उत्पाद है। एकमात्र नकारात्मक, इमो, यह है कि SWF में एक महत्वपूर्ण सीखने की अवस्था है और इसके साथ जटिल चीजें करना कठिन हो सकता है। कम से कम जावा ट्यूटोरियल के साथ मेरा अनुभव था
डॉन चीडल

11

Cronjobs के लिए SQS का उपयोग करने के साथ सावधान रहें, क्योंकि वे गारंटी नहीं देते हैं कि केवल "एक काम केवल एक मशीन द्वारा देखा जाता है"। वे गारंटी देते हैं कि "कम से कम एक" संदेश मिलेगा।

प्रेषक: http://aws.amazon.com/sqs/faqs/#How_many_times_will_I_receive_each_message

प्रश्न: कितनी बार मैं प्रत्येक संदेश प्राप्त करूंगा?

Amazon SQS को अपनी कतारों में सभी संदेशों की "कम से कम एक बार" डिलीवरी प्रदान करने के लिए इंजीनियर बनाया गया है। यद्यपि अधिकांश समय प्रत्येक संदेश आपके एप्लिकेशन पर ठीक एक बार डिलीवर किया जाएगा, आपको अपने सिस्टम को डिज़ाइन करना चाहिए ताकि किसी भी संदेश को एक से अधिक बार संसाधित करने से कोई त्रुटि या असंगतता उत्पन्न न हो।

अब तक मैं उस समाधान के बारे में सोच सकता हूं जहां आपके पास गियरमैन जॉब सर्वर इंस्टेंस के साथ एक उदाहरण स्थापित है: http://gearman.org/ । उसी मशीन पर आप क्रॉन नौकरियों को कॉन्फ़िगर करते हैं जो पृष्ठभूमि में आपके क्रोनजॉब कार्य को निष्पादित करने के लिए कमांड का उत्पादन कर रहे हैं। फिर आपका एक वेब सर्वर (कार्यकर्ता) इस कार्य को निष्पादित करना शुरू कर देगा, यह गारंटी देता है कि केवल एक ही इसे ले जाएगा। इससे कोई फर्क नहीं पड़ता कि आपके पास कितने कर्मचारी हैं (विशेषकर जब आप ऑटो स्केलिंग का उपयोग कर रहे हैं)।

इस समाधान के साथ समस्याएं हैं:

  • गियरमैन सर्वर विफलता का एकल बिंदु है, जब तक कि आप इसे वितरित भंडारण के साथ कॉन्फ़िगर नहीं करते हैं, उदाहरण के लिए मेमकाटेड या कुछ डेटाबेस का उपयोग करते हुए
  • फिर कई गियरमैन सर्वरों का उपयोग करके आपको एक का चयन करना होगा जो क्रोनजोब के माध्यम से कार्य बनाता है, इसलिए फिर से हम उसी समस्या पर वापस आते हैं। लेकिन अगर आप गियरमैन का उपयोग करके इस तरह की एकल बिंदु विफलता के साथ रह सकते हैं तो यह काफी अच्छा समाधान है। विशेष रूप से इसके लिए आपको बड़े उदाहरण की आवश्यकता नहीं है (हमारे मामले में माइक्रो उदाहरण पर्याप्त है)।

खैर, संदेश प्राप्त होने के बाद सर्वर पर रहते हैं। इसके बाद उन्हें हटाने के लिए डेवलपर तक। जब उन्हें संसाधित किया जा रहा है, तो उन्हें किसी अन्य सर्वर द्वारा एक्सेस नहीं किया जा सकता है।
फ्रेडरिक वर्डेंस्कॉल्ड

2
@FrederikWordenskjold यह गलत है, एक ग्राहक को एक संदेश दिए जाने के बाद भी यह दूसरे को दिया जा सकता है, क्योंकि SQS राज्य की प्रतिकृति अतुल्यकालिक है। आपको एक संदेश की प्रतिलिपि भी दी जा सकती है "हटाए जाने के बाद"!
क्रिस पिटमैन

यह उत्तर पुराना है अब 2 प्रकार की कतारें हैं। सटीक-एक बार प्रसंस्करण प्राप्त करने के लिए FIFO का उपयोग करें: एक संदेश एक बार वितरित किया जाता है और तब तक उपलब्ध रहता है जब तक कोई उपभोक्ता प्रक्रिया और इसे हटा नहीं देता है। डुप्लिकेट को कतार में नहीं लाया जाता है। aws.amazon.com/sqs/features
लुकास लिसिस

10

Amazon ने Elastic Beanstalk के लिए नए फीचर्स जारी किए हैं । से डॉक्स :

AWS इलास्टिक बीनस्टॉक
एक समाधान स्टैक के साथ पूर्वनिर्धारित कॉन्फ़िगरेशन चलाने वाले वातावरण में श्रमिक पर्यावरण के स्तरों के लिए आवधिक कार्यों का समर्थन करता है जिसमें कंटेनर नाम में "v1.2.0" होता है। "

अब आप एक cron.yamlफाइल बनाने वाला वातावरण बना सकते हैं जो शेड्यूलिंग कार्यों को कॉन्फ़िगर करता है:

version: 1
cron:
- name: "backup-job"          # required - unique across all entries in this file
  url: "/backup"              # required - does not need to be unique
  schedule: "0 */12 * * *"    # required - does not need to be unique
- name: "audit"
  url: "/audit"
   schedule: "0 23 * * *"

मैं केवल एक बार ऑटोस्कॉल्ड वातावरण में संदेश कतार (SQS) के माध्यम से उपयोग किया जाता है इसे चलाने के बीमा की कल्पना करेंगे। जब क्रोन डेमॉन एक घटना को ट्रिगर करता है तो यह उस कॉल को SQS कतार में रखता है और कतार में संदेश केवल एक बार मूल्यांकन किया जाता है। डॉक्स का कहना है कि SQS के पास प्रक्रिया करने के लिए कई संदेश हैं, तो निष्पादन में देरी हो सकती है।


क्या आप लिंक की कुछ सामग्री भी शामिल कर सकते हैं?
राबर्ट

6

मैं तीसरी बार इस प्रश्न पर आया था और सोचा था कि मैं इसमें चिप लगाऊंगा। हमारे पास अभी थोड़ी देर के लिए यह दुविधा है। मैं अभी भी वास्तव में महसूस हो रहा है एडब्ल्यूएस यहाँ एक विशेषता याद आ रही है।

हमारे मामले में, संभव समाधानों को देखने के बाद, हमने तय किया कि हमारे पास दो विकल्प हैं:

  • एक क्रोनजॉब सर्वर सेट करें जो उन नौकरियों को चलाता है जिन्हें केवल एक बार एक बार चलाया जाना चाहिए, इसे ऑटो स्केल करें और सुनिश्चित करें कि यह तब बदल दिया जाता है जब कुछ CloudWatch आँकड़े वे नहीं होने चाहिए। हम cloud-initस्क्रिप्ट का उपयोग क्रोनॉजर्स को चलाने के लिए करते हैं। बेशक, यह एक डाउनटाइम के साथ आता है, मिस्ड क्रोनोजर के लिए अग्रणी (जब हम कुछ मिनटों में कुछ कार्य चलाते हैं, जैसे हम करते हैं)।
  • जो तर्क का rcronउपयोग करे। बेशक, जादू वास्तव में rcronअपने आप में नहीं है, यह उस तर्क में है जिसका उपयोग आप एक विफल नोड का पता लगाने के लिए करते keepalivedहैं (हम यहां उपयोग करते हैं) और मास्टर के लिए एक और नोड को "अपग्रेड" करते हैं।

हमने दूसरे विकल्प के साथ जाने का फैसला किया, बस इसलिए कि यह बहुत तेज़ी से आगे बढ़ रहा है और हमारे पास पहले से ही इन क्रॉन्बोजर (हमारे पूर्व-एडब्ल्यूएस युग में) चलाने वाले वेबसर्वर्स के साथ अनुभव था।

बेशक, यह समाधान विशेष रूप से पारंपरिक एक-नोड क्रोनजॉब दृष्टिकोण की जगह के लिए है, जहां समय तय करने वाला कारक है (उदाहरण के लिए "मैं नौकरी ए को रोजाना सुबह 5 बजे चलाना चाहता हूं" , या हमारे मामले में "मुझे नौकरी बी चाहिए" हर मिनट एक बार चलाने के लिए " )। यदि आप बैच-प्रोसेसिंग तर्क को ट्रिगर करने के लिए क्रोनॉजर्स का उपयोग करते हैं, तो आपको वास्तव में एक नज़र रखना चाहिए SQS। कोई सक्रिय-निष्क्रिय दुविधा नहीं है, जिसका अर्थ है कि आप अपनी कतार को संसाधित करने के लिए एकल सर्वर या संपूर्ण कार्यबल का उपयोग कर सकते हैं। मैं यह भी सुझाव SWFदूंगा कि आप अपने कर्मचारियों की संख्या बढ़ाना चाहते हैं (हालांकि auto scalingज्यादातर मामलों में चाल भी कर सकते हैं)।

एक और तीसरे पक्ष के आधार पर कुछ ऐसा था जिससे हम बचना चाहते थे।


6

12 / फरवरी / 16 को अमेज़ॅन ने एडब्ल्यूएस लैम्ब्डा का उपयोग करके अनुसूचित एसएसएच नौकरियों के बारे में ब्लॉग किया । मुझे लगता है कि यह सवाल का जवाब देता है।


1
क्या AWS लैम्ब्डा का उपयोग करके गतिशील क्रोनोजर या शेड्यूल जोड़ना संभव है?
संजय कुमार एनएस

हाँ, आप मेघवाच की घटनाओं के द्वारा लैंबडा का आह्वान कर सकते हैं। समय के रूप में आप फिट देखते हैं।
माइकल क्ले


4

"अमेज़ॅन" तरीका वितरित किया जाना है, जिसका अर्थ है कि भारी क्रोन को कई छोटे कामों में विभाजित किया जाना चाहिए और सही मशीनों को सौंप दिया जाना चाहिए।

FIFO के लिए सेट प्रकार के साथ SQS कतार का उपयोग करके, यह सुनिश्चित करने के लिए कि प्रत्येक कार्य को केवल एक मशीन द्वारा निष्पादित किया जाए। यह भी विफलता को सहन करता है क्योंकि कतारें तब तक बफ़र करेंगी जब तक कोई मशीन वापस नहीं आती।

FIFO बिल्कुल-एक बार प्रसंस्करण : एक संदेश एक बार वितरित किया जाता है और तब तक उपलब्ध रहता है जब तक कि कोई उपभोक्ता प्रक्रिया और इसे हटा नहीं देता है। डुप्लिकेट को कतार में नहीं लाया जाता है।

यह भी विचार करें कि क्या आपको वास्तव में इन ऑपरेशनों को 'बैच' करने की आवश्यकता है। अगर एक रात का अपडेट उम्मीद से काफी बड़ा हो तो क्या होगा? यहां तक ​​कि डायनामिक रिसोर्सिंग के साथ, आपके प्रसंस्करण में पर्याप्त मशीनों के इंतजार में देरी हो सकती है। इसके बजाय, एसडीबी में अपना डेटा स्टोर करें, एसक्यूएस के माध्यम से अपडेट की मशीनों को सूचित करें, और फ्लाई (कैशिंग के साथ) पर अपना आरएसएस फ़ीड बनाएं।

बैच नौकरियां ऐसे समय से हैं जब संसाधन संसाधन सीमित थे और 'लाइव' सेवाओं ने पूर्वता ले ली थी। बादल में, यह मामला नहीं है।


धन्यवाद - मुझे वह दिशा पसंद है जिसका आप वर्णन कर रहे हैं।
टॉम

5
सचेत रहें कि SQS केवल इस बात की गारंटी देता है कि एक मशीन को अंततः एक संदेश दिखाई देगा, न कि संदेश केवल एक सर्वर द्वारा देखा जाएगा। आप एक SQS कतार में जो कुछ भी डालते हैं वह निष्प्राण होना चाहिए।
रिचर्ड हर्ट

मेरा क्रॉन जॉब रोजाना चलना चाहिए और SQS के साथ आप केवल 15 मिनट तक की देरी कर सकते हैं। एक विकल्प यह हो सकता है कि संदेश पर कस्टम टैग जोड़कर उसे निष्पादित करने के लिए लक्ष्य समय के साथ कतार में वापस रखा जाए, यदि वह समय अभी तक नहीं पहुंचा है - लेकिन यह वास्तव में एक गूंगी चीज है। शुरू में कतार को आबाद करने के लिए मुझे अभी भी एक क्रॉन जॉब की जरूरत है। यह एक चिकन-अंडे की समस्या लगती है :) लेकिन मुझे अभी भी लगता है कि एसक्यूएस का उपयोग करना सही है, क्योंकि यह स्केलेबिलिटी और दोष-सहिष्णुता की गारंटी देता है
राफेल रोसी

"बैच नौकरियां ऐसे समय से हैं जब संसाधन संसाधन सीमित थे और 'लाइव' सेवाओं ने पूर्वता ले ली थी। बादल में, यह मामला नहीं है।" यह कुछ के लिए सही है लेकिन सभी गतिविधि के लिए नहीं। उदाहरण के लिए, ट्रैफ़िक लॉग को संसाधित करना कुछ ऐसा है जो लाइव की तुलना में बैच प्रक्रिया के रूप में बेहतर है।
जॉर्डन रेइटर

1

आप अपना निर्माण क्यों करेंगे? क्‍वार्ट्ज (क्‍लस्‍टरेड शेड्यूलिंग के साथ) जैसी किसी चीज का उपयोग क्‍यों नहीं किया गया। प्रलेखन देखें।

http://quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigJDBCJobStoreClustering


मैंने एक सास समाधान में Quartz.NET का उपयोग किया जो अनुसूचित कार्यों पर बहुत अधिक निर्भर करता था। कुछ जहां सिस्टम रखरखाव कार्य करते हैं, लेकिन अधिकांश जहां गतिविधियां अंतिम उपयोगकर्ताओं द्वारा निर्धारित की जाती हैं। हमारे सभी कार्यों ने संदेश कतारों (एमक्यू) को लिखा था, जिसके लिए हमारे पास कोई भी संख्याहीन सेवा थी। एपीआई बहुत अच्छा है और शक्तिशाली शेड्यूल के लिए अनुमति देता है। हमने कई क्वार्ट्ज उदाहरणों को क्लस्टर नहीं किया, लेकिन यह समर्थन करता है।
जेरिको सैंडहॉर्न

1

हम क्या करते हैं, हमारे पास एक विशेष सर्वर है जो एक ईएलबी के पीछे हमारे वेब एप्लिकेशन क्लस्टर का हिस्सा है, एक विशिष्ट डीएनएस नाम भी सौंपा गया है ताकि हम उस एक विशिष्ट सर्वर पर नौकरियों को चला सकें। इसका यह भी लाभ है कि यदि वह नौकरी उस सर्वर को धीमा कर देती है, तो ईएलबी इसे क्लस्टर से हटा देगा और फिर नौकरी समाप्त होने पर उसे वापस कर देगा और यह फिर से स्वस्थ हो जाएगा।

चंपा की तरह काम करता है।


1

यह सत्यापित करने का एक तरीका है कि आपकी क्रोन अभिव्यक्ति अमेज़ॅन तरीके से काम करती है, इसे ईवेंट कमांड के माध्यम से चलाना है। उदाहरण के लिए:

aws events put-rule --name "DailyLambdaFunction" --schedule-expression "<your_schedule_expression>

यदि आपका शेड्यूल एक्सप्रेशन अमान्य है, तो, यह विफल हो जाएगा।

अधिक संसाधन: https://docs.aws.amazon.com/cli/latest/reference/events/put-rule.html



0

चूंकि किसी ने CloudWatch इवेंट का उल्लेख नहीं किया है , मैं कहूंगा कि यह क्रॉन जॉब्स करने का AWS तरीका है। यह कई कार्यों को चला सकता है, जैसे कि लैम्ब्डा फ़ंक्शन, ईसीएस कार्य।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.