CloudFront के साथ ब्लू / ग्रीन तैनाती

Question

मैं CloudFront के साथ ब्लू / ग्रीन तैनाती करने का एक तरीका ढूंढ रहा हूं ।

क्या किसी के पास एक CloudFront वितरण से दूसरे में जाने के लिए एक अच्छा समाधान है या क्या हर कोई वास्तव में सिर्फ अपना वितरण बनाता है और फिर कभी इसे फिर से नहीं छूता है?

मेरे CloudFront वितरण में स्थैतिक सामग्री (जावास्क्रिप्ट, आदि) के लिए एक S3 मूल और AWS ELB की ओर इशारा करते हुए एक कस्टम मूल शामिल हैं।

CloudFront में कोई परिवर्तन नहीं

सामान्य परिस्थितियों में हम अपने CloudFront वितरण में कोई बदलाव नहीं करते हैं। हम S3 मूल में अपनी स्थैतिक सामग्री को S3 में स्थैतिक सामग्री फ़ाइलों का नाम बदलकर संस्करण बनाते हैं और लोचदार भार बैलेंसर (ELB) के तहत EC2 उदाहरणों के लिए तैनाती करते हैं। हालाँकि, ऐसे समय होते हैं जब हमें क्लाउडफ्रंट वितरण में स्वयं ही परीक्षण करने और बदलाव करने की आवश्यकता होती है या हमारे पर्यावरण में महत्वपूर्ण पर्याप्त परिवर्तन होते हैं जिन्हें हमें नए वातावरण में एक नए ईएलबी की ओर संकेत करने की आवश्यकता होती है।

दो CloudFront वितरण

मैंने जो पहला विकल्प चुना, वह था दो अलग-अलग क्लाउडफ्रंट वेब डिस्ट्रीब्यूशन , एक मेरे करंट के लिए, या ए, एनवायरनमेंट और एक मेरे नए या बी, एनवायरनमेंट के लिए। मैंने एक रूट -53 भारित रूटिंग नीति का उपयोग करने का प्रयास किया, जहां मैंने अपने www.domain.com रूट ५३ रिकॉर्ड के लिए दो रिकॉर्ड जोड़े, एक ने क्लाउडफ्रंट वितरण ए की ओर इशारा किया, जिसका वजन १ के वजन के साथ था और दूसरा ०.९ के वजन के साथ क्लाउडफ्रंट वितरण बी की ओर इशारा किया। योजना तब वज़न बदलने की होगी जब मैं वितरण ए से वितरण बी में जाना चाहता हूं। हालांकि, एक समय में केवल एक क्लाउडफ्रंट वितरण में www.domain.com वैकल्पिक डोमेन नाम (CNAME) पंजीकृत हो सकता है या आपको निम्न त्रुटि मिल सकती है:

com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a)

एक CloudFront वितरण

दूसरा विकल्प एक CloudFront वेब वितरण रखना है। मेरे पास S3 और कस्टम मूल हैं जो मेरे A और B दोनों परिवेशों की ओर इशारा करते हैं और फिर मैं CloudFront Cache व्यवहार को दूसरे मूल की ओर इंगित करने के लिए अद्यतन करता हूं जब मैं एक वातावरण से दूसरे वातावरण में जाना चाहता हूं। यह बेहद गड़बड़ है क्योंकि इन अद्यतनों में 15-60 मिनट लगते हैं, अपडेट की प्रगति में कोई दृश्यता नहीं होती है और आपके परिवर्तन की प्रकृति के आधार पर आपको क्लाउडफ्रंट अमान्यकरण के साथ पालन करने की आवश्यकता हो सकती है ताकि आप कैश्ड सामग्री नहीं परोसें नई सामग्री के साथ पुराने वातावरण से।

आपके सुझाव के लिए धन्यवाद!

Comments

क्या आपको कोई समाधान मिला? हमें अपनी परियोजना में समान समस्या है और हम इसे अभी करते हैं - हम अपने प्रोजेक्ट में मैन्युअल रूप से क्लाउडफ्रंट समापन बिंदु बदलते हैं।

— दिमित्री वोलोशिन

दुर्भाग्य से नहीं - मुझे नहीं लगता कि एक अच्छा है। सबसे अच्छा अभ्यास एक क्लाउडफ्रंट वितरण का उपयोग करना है, s3 बाल्टियों में किसी भी सामग्री को संस्करणित करना और डायनामिक सामग्री को इंगित करने वाले मूल के लिए मार्ग53 भारित डीएनएस रिकॉर्ड का उपयोग करना है। तब आप डायनामिक सामग्री को बदलने के लिए बस रूट 53 को अपडेट करते हैं और आपको क्लाउडफ्रंट को छूने की आवश्यकता नहीं है। हम देव और क्यूए के लिए अलग क्लाउडफ्रंट वितरण बनाए रखते हैं। EX: stackoverflow.com/questions/9130555/…

— पीटर एम

Answer 1

दो Cloudfront वितरण

चूंकि AWS एक ही AWS खाते में वाइल्डकार्ड वैकल्पिक CNAMEs के बीच ओवरलैप की अनुमति देता है, आप निम्न तरीके से दो क्लाउडफ्रंट वितरण के बीच स्विच कर सकते हैं:

• उत्पाद वितरण 1 के लिए वैकल्पिक CNAME के ​​रूप में www.domain.com का उपयोग करें
• उत्पादन वितरण 2 के लिए वैकल्पिक CNAME के ​​रूप में * .domain.com का उपयोग करें
• वितरण 1 या वितरण 2 के लिए अपने CNAME DNS www.domain.com को इंगित करें। (* .cloudfront.net)।
• उस वितरण से वैकल्पिक CNAME निकालें, जिसे आप अभी तक सामग्री नहीं परोसना चाहते हैं।

हालाँकि, दो अलग-अलग वितरण DNS (* .cloudfront.net) एक ही एज नोड्स की ओर संकेत कर सकते हैं, जिसका अर्थ है कि जिस तरह से आपकी सामग्री परोसी गई है, वह Cloudfront.net CNAME से मेल खाते हुए एज नोड्स में मिलती है जो इसे सर्व कर रही है और फिर मैच के लिए है। होस्ट नाम। इस स्थिति में, यदि आपके दोनों वितरण समान किनारे नोड्स का उपयोग कर रहे हैं (उदाहरण के लिए इसे चेक किया जा सकता है dig) तो कट साफ नहीं होगा।

उदाहरण यदि दोनों वितरण एक या अधिक एज नोड्स साझा करते हैं, तो Alt CNAME www.domain.com के साथ वितरण 1 को अधिक जेनेरिक * .domain.com के साथ वितरण 2 पर पूर्ववर्तीता प्राप्त होगी, जब तक कि CNAME सभी किनारे के नोड्स में वितरण 1 कॉन्फिगरेशन से हटा नहीं दिया जाता। । तो एक अनुरोध से पुनर्प्राप्त संस्करण संक्रमण अवधि के दौरान दूसरे से अलग हो सकता है।

Comments

CloudFront में विस्तारित परिवर्तन प्रसार समय के कारण, यह वास्तव में आपका एकमात्र विकल्प है।

— मेघवल्कर

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

— पीटर एम

Answer 2

यहां खेल में थोड़ी देर हो गई, लेकिन किसी और को इस की तलाश है। मेरा मानना ​​है कि यह lambda @ बढ़त का उपयोग करके किया जा सकता है। ए / बी परीक्षणों के समान। https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html । जब कोई उपयोगकर्ता एक url का अनुरोध करता है, तो आप एक लैम्बडा फ़ंक्शन को लागू कर सकते हैं। विभिन्न मूल या url उपसर्ग से नीले / हरे रंग की सामग्री परोसना चुनें। एक कुकी मान निर्धारित करेगा कि किस परिनियोजन को परोसा जाएगा। जब पहला अनुरोध आता है (कोई कुकी नहीं) तो कुकी को बेतरतीब ढंग से 95% नीला 5% हरा कहें।

Answer 3

कूल्हे से शूटिंग, एक क्लाउड सामने वितरण के भीतर मूल स्विच करने में कितना समय लगता है? 1) ईएलबी के पीछे नए कोड को तैनात करें, इसे 2 तक गर्म करें) पुराने ईएलबी को हटाते समय इस ईएलबी को अपने क्लाउड फ्रंट डिस्ट्रीब्यूशन के लिए एक नए मूल के रूप में जोड़ें) एक बार कटओवर करने के बाद, पुराने ईएलबी के पीछे पुराने कोड को फाड़ दें।

CloudFront अपडेट्स या DNS अपडेट्स से जुड़ी देरी से दूर रहने के लिए, आप अपने ELB के पीछे ऑटोस्केल ग्रुप को स्वैप कर सकते हैं। 1) नए ASG में नया कोड तैनात करें, इसे 2 वार्म करें) अपने मौजूदा ELB को इस नए ASG 3 के साथ पंजीकृत करें) अपने ASB से पुराने ASG को पंजीकृत करें 4) एक बार कटओवर करने के बाद, पुराने ASG को फाड़ दें।

Answer 4

मैं इस विषय पर शोध भी कर रहा हूं और काम के आसपास (नीचे देखें)।

पृष्ठभूमि:

CloudFront को आपके संपूर्ण खाते में अद्वितीय होने के लिए वितरण कॉन्फ़िगरेशन में CNAME की आवश्यकता होती है। इसलिए विभिन्न वितरणों के लिए DNS के माध्यम से नीले / हरे रंग को नियंत्रित करने से काम नहीं चलेगा। वहाँ एक हैक रोलिंग है जो वाइल्ड कार्ड का उपयोग करेगा लेकिन यह कोई गारंटी नहीं देता है कि सही फाइलें परोसी गई हैं। DNS और CloudFront के माध्यम से नीले / हरे रंग को नियंत्रित करना संभव नहीं है।

इसके अलावा, CloudFront (CNAME सहित) में किसी भी कॉन्फ़िगरेशन को बदलने के 15-60 मिनट के परिणाम की प्रतीक्षा की जाती है जबकि किनारे सर्वरों में परिवर्तन का प्रचार किया जाता है। इसके अलावा, एक आदर्श सेटअप नहीं।

आसपास काम करें:

एकल पृष्ठ एप्लिकेशन के लिए, यह कॉन्फ़िगरेशन जो चाल कर सकता है:

• ऐप URL: app.mydomain.com/app
• S3 संरचना:
  • एप्लिकेशन / (आपकी लाइव साइट)
  • app2 / (आपकी इतनी लाइव साइट नहीं)

अब फ़ाइलों की सेवा करने के लिए अपने बाल्टी का उपयोग करने के लिए CloudFront कॉन्फ़िगर करें। इस बिंदु पर, यह सब आपके लिए नीचे आता है कैश सेटिंग्स। चूंकि CloudFront हमेशा के लिए लेती है, हमारे S3 ऑब्जेक्ट्स पर CacheControl हैडर सेट करें। Index.html के लिए, हम 5 मिनट, बाकी सब, 1 दिन का उपयोग करते हैं। जब स्विच करने का समय आता है, तो S3 निर्देशिका नामों को स्वैप करें। 5 मिनट के भीतर, ऐप सभी इरादों और उद्देश्यों के लिए लाइव होगा।

पहले से चल रहे ऐप्स के लिए, हमारे पास कोड में निर्मित बिल्ड संस्करण और ऐप के रूट पर बिल्ड कॉन्फिग जोंस फाइल है। फिर ऐप कभी-कभार json फाइल के लिए अनुरोध करेगा, संस्करण की जाँच करें, यदि यह पुराना हो, तो ताज़ा करने के लिए संकेत दें।

सीमाएं

आप बहुत अच्छी तरह से परीक्षण नहीं कर सकते हैं। मुझे लगता है कि index.html का TTL कुछ घंटों या दिनों (आपकी ज़रूरत के आधार पर) को बढ़ाना संभव है, इससे ग्राहकों को यह सुनिश्चित करने में मदद मिलेगी कि उनके स्थानीय कैश समाप्त होने के बाद नए संस्करण प्राप्त होंगे।

Answer 5

में इस ब्लॉग पोस्ट : लेखक औजार अब लैम्ब्डा के माध्यम से परीक्षण @ एज एडब्ल्यूएस दस्तावेज में कोड पर कार्य करते हैं (आप उनके उदाहरण यहाँ देख सकते हैं https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- example.html )।

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