मैंने 4 साल पहले
क्लाउडफॉर्म के साथ काम करना शुरू कर दिया था। तब से, मैंने कई इन्फ्रास्ट्रक्चर को तोड़ दिया है, यहां तक कि जो पहले से ही उत्पादन में थे। लेकिन हर बार जब मैंने कुछ बिगाड़ा, तो मैंने नई चीजें सीखीं। इस अनुभव के लिए धन्यवाद, मैं कुछ सबसे महत्वपूर्ण सबक साझा करूंगा जो मैंने सीखा है।
पाठ 1: परिनियोजन से पहले मान्य परिवर्तन
जैसे ही मैंने
क्लाउडफॉर्म के साथ काम करना शुरू किया मैंने यह सबक सीख लिया। मुझे याद नहीं है कि मैंने तब क्या तोड़ा था, लेकिन मुझे ठीक से याद है कि मैंने
aws क्लाउडफॉर्म अपडेट कमांड का इस्तेमाल किया था। यह आदेश केवल उन परिवर्तनों के सत्यापन के बिना टेम्पलेट को रोल आउट करता है जिन्हें तैनात किया जाएगा। मुझे नहीं लगता कि स्पष्टीकरण की आवश्यकता है, जिसके लिए आपको उन्हें तैनात करने से पहले सभी परिवर्तनों की जांच करने की आवश्यकता है।
इस विफलता के बाद, मैंने तुरंत
अपॉइंटमेंट पाइपलाइन को बदल दिया, जिससे अपडेट
- कमांड को
सेट-चेंज-सेट कमांड के साथ
बदल दिया गया
# OPERATION is either "UPDATE" or "CREATE" changeset_id=$(aws cloudformation create-change-set \ --change-set-name "$CHANGE_SET_NAME" \ --stack-name "$STACK_NAME" \ --template-body "$TPL_PATH" \ --change-set-type "$OPERATION" \ --parameters "$PARAMETERS" \ --output text \ --query Id) aws cloudformation wait \ change-set-create-complete --change-set-name "$changeset_id"
जब कोई परिवर्तन सेट बनाया जाता है, तो यह मौजूदा स्टैक को प्रभावित नहीं करता है। अपडेट कमांड के विपरीत, परिवर्तन सेट दृष्टिकोण वास्तव में तैनात नहीं होता है। इसके बजाय, यह उन परिवर्तनों की सूची बनाता है जिन्हें आप परिनियोजन से पहले समीक्षा कर सकते हैं। आप aws कंसोल इंटरफ़ेस में परिवर्तन देख सकते हैं। लेकिन अगर आप हर चीज को स्वचालित करना पसंद करते हैं, तो उन्हें CLI में देखें:
# this command is presented only for demonstrational purposes. # the real command should take pagination into account aws cloudformation describe-change-set \ --change-set-name "$changeset_id" \ --query 'Changes[*].ResourceChange.{Action:Action,Resource:ResourceType,ResourceId:LogicalResourceId,ReplacementNeeded:Replacement}' \ --output table
इस कमांड को निम्न के समान आउटपुट का उत्पादन करना चाहिए:
-------------------------------------------------------------------- | DescribeChangeSet | +---------+--------------------+----------------------+------------+ | Action | ReplacementNeeded | Resource | ResourceId | +---------+--------------------+----------------------+------------+ | Modify | True | AWS::ECS::Cluster | MyCluster | | Replace| True | AWS::RDS::DBInstance| MyDB | | Add | None | AWS::SNS::Topic | MyTopic | +---------+--------------------+----------------------+------------+
एक्शन
रिप्लेस ,
डिलीट, या जहां
रिप्लेसमेंटनएड ट्रू है , वहां बदलाव पर विशेष ध्यान
दें । ये सबसे खतरनाक बदलाव हैं और आमतौर पर जानकारी का नुकसान होता है।
जब परिवर्तन देखे जाते हैं, तो उनका विस्तार किया जा सकता है
aws cloudformation execute-change-set --change-set-name "$changeset_id" operation_lowercase=$(echo "$OPERATION" | tr '[:upper:]' '[:lower:]') aws cloudformation wait "stack-${operation_lowercase}-complete" \ --stack-name "$STACK_NAME"
पाठ 2: राज्य के प्रतिस्थापन या संसाधनों को हटाने से रोकने के लिए स्टैक नीति का उपयोग करें
कभी-कभी केवल परिवर्तनों को देखना पर्याप्त नहीं होता है। हम सभी इंसान हैं और हम सभी गलतियाँ करते हैं। जब हमने परिवर्तन सेट का उपयोग करना शुरू किया, उसके तुरंत बाद, मेरे टीम के साथी ने अनजाने में एक तैनाती का प्रदर्शन किया, जिसके कारण डेटाबेस अपग्रेड हुआ। कुछ भी भयानक नहीं हुआ, क्योंकि यह एक परीक्षण का माहौल था।
इस तथ्य के बावजूद कि हमारी लिपियों ने परिवर्तनों की एक सूची प्रदर्शित की और पुष्टि के लिए कहा, बदलें परिवर्तन को छोड़ दिया गया था क्योंकि परिवर्तनों की सूची इतनी बड़ी थी कि यह स्क्रीन पर फिट नहीं हुई थी। और चूंकि यह परीक्षण वातावरण में एक नियमित अपडेट था, इसलिए बदलावों पर ज्यादा ध्यान नहीं दिया गया।
ऐसे संसाधन हैं जिन्हें आप कभी बदलना या हटाना नहीं चाहेंगे। ये राज्य की सेवाएं हैं, जैसे कि RDS डेटाबेस या एक इलास्टीचेज़ क्लस्टर, आदि। यह अच्छा होगा यदि aws अपने आप को तैनात करने से इंकार कर देंगे, यदि ऑपरेशन किया जा रहा है तो ऐसे संसाधन को हटाने की आवश्यकता होगी। सौभाग्य से, क्लाउडफॉर्म में ऐसा करने का एक अंतर्निहित तरीका है। इसे स्टैक पॉलिसी कहा जाता है, और आप इसके बारे में
प्रलेखन में अधिक पढ़ सकते हैं:
STACK_NAME=$1 RESOURCE_ID=$2 POLICY_JSON=$(cat <<EOF { "Statement" : [{ "Effect" : "Deny", "Action" : [ "Update:Replace", "Update:Delete" ], "Principal": "*", "Resource" : "LogicalResourceId/$RESOURCE_ID" }] } EOF ) aws cloudformation set-stack-policy --stack-name "$STACK_NAME" \ --stack-policy-body "$POLICY_JSON"
पाठ 3: गुप्त मापदंडों के साथ एक स्टैक को अपडेट करते समय UsePrepretValue का उपयोग करें
जब आप RDS इकाई बनाते हैं, तो mysql AWS को आपको MasterUsername और MasterUserPassword प्रदान करने की आवश्यकता होती है। चूंकि स्रोत कोड में रहस्य नहीं रखना बेहतर है, और मैं पूरी तरह से सब कुछ स्वचालित करना चाहता था, मैंने एक "स्मार्ट तंत्र" को लागू किया, जिसमें तैनाती से पहले s3 से क्रेडेंशियल्स प्राप्त किए जाते हैं, और यदि क्रेडेंशियल्स नहीं मिलते हैं, तो नए क्रेडेंशियल्स उत्पन्न होते हैं और s3 में संग्रहीत होते हैं। ।
इन क्रेडेंशियल्स को फिर क्लाउडफॉर्म क्रिएट-चेंज-सेट कमांड के मापदंडों के रूप में पारित किया जाएगा। स्क्रिप्ट के साथ प्रयोगों के दौरान, यह हुआ कि s3 का कनेक्शन खो गया था, और मेरे "स्मार्ट तंत्र" ने इसे नई साख बनाने के लिए एक संकेत के रूप में माना।
यदि मैंने इस स्क्रिप्ट का उत्पादन परिवेश में उपयोग करना शुरू कर दिया है, और कनेक्शन समस्या फिर से उत्पन्न हुई, तो यह नए क्रेडेंशियल्स के साथ स्टैक को अपडेट करेगा। इस विशेष मामले में, कुछ भी बुरा नहीं होगा। हालांकि, मैंने इस दृष्टिकोण को छोड़ दिया और दूसरे का उपयोग करना शुरू कर दिया, केवल एक बार क्रेडेंशियल्स प्रदान करते हुए - स्टैक बनाते समय। और बाद में, जब स्टैक को अपडेट करने की आवश्यकता होती है, तो पैरामीटर के गुप्त मूल्य को निर्दिष्ट करने के बजाय, मैं बस
UsePrepretValue = true का उपयोग
करूंगा :
aws cloudformation create-change-set \ --change-set-name "$CHANGE_SET_NAME" \ --stack-name "$STACK_NAME" \ --template-body "$TPL_PATH" \ --change-set-type "UPDATE" \ --parameters "ParameterKey=MasterUserPassword,UsePreviousValue=true"
पाठ 4: रोलबैक कॉन्फ़िगरेशन का उपयोग करें
मेरे साथ काम करने वाली एक अन्य टीम ने
क्लाउडबैक कॉन्फ़िगरेशन नामक एक
क्लाउडफॉर्मेशन फ़ंक्शन का उपयोग किया था। मैं उससे पहले नहीं मिला और जल्दी से महसूस किया कि यह मेरे ढेर को और भी बेहतर बना देगा। अब मैं हर बार मैं अपने कोड को लैम्ब्डा या ईसीएस में क्लाउडफॉर्मेशन का उपयोग करते हुए तैनात करता हूं।
यह कैसे काम करता है: जब आप परिवर्तन सेट बनाते हैं तो आप
CloudWatch अलार्म को
--rollback- कॉन्फ़िगरेशन पैरामीटर में निर्दिष्ट करते हैं। बाद में, जब आप परिवर्तन सेट को पूरा करते हैं, तो aws कम से कम एक मिनट के लिए अलार्म को ट्रैक करता है। यह परिनियोजन को वापस ले जाता है यदि इस समय के दौरान अलार्म राज्य को अलार्म में बदल देता है।
निम्नलिखित
क्लाउडफॉर्मेशन टेम्प्लेट का एक उदाहरण है, जिसमें मैं एक
क्लाउडवॉच अलार्म बनाता हूं जो उपयोगकर्ता के क्लाउड मीट्रिक को ट्रैक करता है क्योंकि क्लाउड लॉग्स में त्रुटियों की संख्या (मीट्रिक मीट्रिक के माध्यम से बनाई गई है):
Resources: # this metric tracks number of errors in the cloudwatch logs. In this # particular case it's assumed logs are in json format and the error logs are # identified by level "error". See FilterPattern ErrorMetricFilter: Type: AWS::Logs::MetricFilter Properties: LogGroupName: !Ref LogGroup FilterPattern: !Sub '{$.level = "error"}' MetricTransformations: - MetricNamespace: !Sub "${AWS::StackName}-log-errors" MetricName: Errors MetricValue: 1 DefaultValue: 0 ErrorAlarm: Type: AWS::CloudWatch::Alarm Properties: AlarmName: !Sub "${AWS::StackName}-errors" Namespace: !Sub "${AWS::StackName}-log-errors" MetricName: Errors Statistic: Maximum ComparisonOperator: GreaterThanThreshold Period: 1 # 1 minute EvaluationPeriods: 1 Threshold: 0 TreatMissingData: notBreaching ActionsEnabled: yes
अब उपकरणों के सेट को निष्पादित करते समय
अलार्म को
रोलबैक ट्रिगर के रूप में इस्तेमाल किया जा सकता है:
ALARM_ARN=$1 ROLLBACK_TRIGGER=$(cat <<EOF { "RollbackTriggers": [ { "Arn": "$ALARM_ARN", "Type": "AWS::CloudWatch::Alarm" } ], "MonitoringTimeInMinutes": 1 } EOF ) aws cloudformation create-change-set \ --change-set-name "$CHANGE_SET_NAME" \ --stack-name "$STACK_NAME" \ --template-body "$TPL_PATH" \ --change-set-type "UPDATE" \ --rollback-configuration "$ROLLBACK_TRIGGER"
पाठ 5: सुनिश्चित करें कि आप टेम्पलेट के नवीनतम संस्करण को नियुक्त करते हैं
क्लाउडफॉर्म टेम्प्लेट के नवीनतम संस्करण को तैनात करना आसान नहीं है, लेकिन यह बहुत नुकसान करेगा। एक बार यह हमारे साथ था: डेवलपर ने गिट से नवीनतम परिवर्तन नहीं भेजे और अनजाने में स्टैक के पिछले संस्करण को तैनात किया। इसने इस स्टैक का उपयोग करने वाले एक साधारण अनुप्रयोग का नेतृत्व किया।
कुछ सरल, जैसे कि चेक को जोड़ने के लिए कि क्या कोई शाखा आपके द्वारा तैनात होने से पहले प्रासंगिक है, ठीक होगा (मान लिया गया कि आपका वर्जन आपके वर्जन टूल है):
git fetch HEADHASH=$(git rev-parse HEAD) UPSTREAMHASH=$(git rev-parse master@{upstream}) if [[ "$HEADHASH" != "$UPSTREAMHASH" ]] ; then echo "Branch is not up to date with origin. Aborting" exit 1 fi
पाठ 6: पहिया को सुदृढ़ मत करो
क्लाउडफॉर्म के साथ तैनाती आसान लग सकती है। आपको बस bash स्क्रिप्ट का एक गुच्छा चाहिए जो aws cli कमांड को निष्पादित करता है।
4 साल पहले, मैंने सरल स्क्रिप्ट के साथ शुरुआत की, जिसे अवर्स क्लाउडफॉर्मेशन क्रैक-स्टैक कमांड कहा जाता है। जल्द ही, स्क्रिप्ट अब सरल नहीं थी। प्रत्येक सबक ने स्क्रिप्ट को अधिक से अधिक जटिल बना दिया। यह न केवल मुश्किल था, बल्कि बग का एक गुच्छा भी था।
अब मैं एक छोटे आईटी विभाग में काम करता हूँ। अनुभव से पता चला है कि प्रत्येक टीम के पास क्लाउड स्टैक को तैनात करने का अपना तरीका है। और यह बुरा है। हर कोई एक दृष्टिकोण का उपयोग करे तो बेहतर होगा। सौभाग्य से, कई उपकरण हैं जो आपको क्लाउड स्टैक को परिनियोजित और कॉन्फ़िगर करने में मदद करते हैं।
ये पाठ आपको गलतियों से बचने में मदद करेंगे।