🥇 मैले जीवनको लागि क्लाउडफर्मेसनको साथ काम गर्ने यी 6 पाठहरू सिकें

साथमा काम गर्न थालें क्लाउडफॉर्मेशन ४ वर्ष पहिले । त्यसबेलादेखि मैले धेरै पूर्वाधारहरू भत्काएको छु, ती पनि जुन उत्पादनमा थिए। तर हरेक चोटि मैले केहि गडबड गरें, मैले केहि नयाँ सिके। यस अनुभव मार्फत, मैले सिकेका केही महत्त्वपूर्ण पाठहरू साझा गर्नेछु।

पाठ 1: तिनीहरूलाई प्रयोग गर्नु अघि परिवर्तनहरू परीक्षण गर्नुहोस्

मैले काम गर्न थालेपछि मैले यो पाठ सिकें क्लाउडफॉर्मेशन। मलाई याद छैन कि मैले त्यसबेला के तोडेको थिएँ, तर मलाई पक्कै याद छ कि मैले कमाण्ड प्रयोग गरें aws cloudformation अपडेट। यो आदेशले तैनाथ गरिने परिवर्तनहरूको कुनै प्रमाणीकरण बिना नै टेम्प्लेट रोल आउट गर्दछ। मलाई लाग्दैन कि तपाईंले तिनीहरूलाई तैनात गर्नु अघि सबै परिवर्तनहरू किन परीक्षण गर्नुपर्छ भनेर कुनै व्याख्या आवश्यक छ।

यो असफलता पछि, म तुरुन्तै परिवर्तन भयो तैनाती पाइपलाइन, कमाण्डको साथ अपडेट आदेश प्रतिस्थापन गर्दै सिर्जना-परिवर्तन-सेट

# 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"

पाठ २: स्टेटफुल स्रोतहरू प्रतिस्थापन वा हटाउनबाट रोक्न स्ट्याक नीति प्रयोग गर्नुहोस्

कहिलेकाहीँ मात्र परिवर्तनहरू हेर्न पर्याप्त छैन। हामी सबै मानव हौं र हामी सबैले गल्ती गर्छौं। हामीले परिवर्तनहरू प्रयोग गर्न थालेको केही समय पछि, मेरो टोलीले अनजानमा एक परिनियोजन प्रदर्शन गर्‍यो जसले गर्दा डाटाबेस अपडेट भयो। केही नराम्रो भएन किनभने यो परीक्षाको वातावरण थियो।

हाम्रा स्क्रिप्टहरूले परिवर्तनहरूको सूची देखाएर पुष्टिकरणको लागि सोधे तापनि, परिवर्तनहरूको सूची यति ठूलो भएकोले स्क्रिनमा फिट नहुने भएकाले बदल्नुहोस् परिवर्तन छोडियो। र यो परीक्षण वातावरणमा एक सामान्य अद्यावधिक भएकोले, परिवर्तनहरूमा धेरै ध्यान दिइएन।

त्यहाँ स्रोतहरू छन् जुन तपाईं कहिल्यै बदल्न वा हटाउन चाहनुहुन्न। यी स्टेटफुल सेवाहरू हुन्, जस्तै 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"

पाठ ३: गोप्य प्यारामिटरहरूको साथ स्ट्याक अद्यावधिक गर्दा UsePreviousValue प्रयोग गर्नुहोस्

तपाईंले RDS mysql एकाइ सिर्जना गर्दा, AWS ले तपाईंलाई MasterUsername र MasterUserPassword उपलब्ध गराउनुपर्छ। स्रोत कोडमा गोप्य कुराहरू नराख्नु राम्रो भएकोले र म सबै कुरा स्वचालित गर्न चाहन्थेँ, मैले "स्मार्ट मेकानिज्म" लागू गरें जहाँ परिनियोजन अघि प्रमाणहरू s3 बाट प्राप्त हुनेछन्, र यदि प्रमाणहरू फेला परेनन् भने, नयाँ प्रमाणहरू उत्पन्न हुन्छन् र s3 मा भण्डारण गरिएको छ।

यी प्रमाणहरू त्यसपछि क्लाउडफर्मेसन सिर्जना-परिवर्तन-सेट आदेशमा प्यारामिटरहरूको रूपमा पास गरिनेछ। स्क्रिप्टको साथ प्रयोग गर्दा, यो भयो कि s3 मा जडान हराएको थियो, र मेरो "स्मार्ट मेकानिज्म" ले यसलाई नयाँ प्रमाणहरू उत्पन्न गर्न संकेतको रूपमा व्यवहार गर्यो।

यदि मैले उत्पादनमा यो स्क्रिप्ट प्रयोग गर्न सुरु गरें र जडान समस्या फेरि भयो भने, यसले स्ट्याकलाई नयाँ प्रमाणहरूसँग अद्यावधिक गर्नेछ। यस विशेष अवस्थामा, केहि खराब हुनेछैन। यद्यपि, मैले यो दृष्टिकोण त्यागेको छु र अर्को प्रयोग गर्न थालेँ, एक पटक मात्र प्रमाणहरू प्रदान गर्दै - स्ट्याक सिर्जना गर्दा। र पछि, जब स्ट्याकलाई अद्यावधिक गर्न आवश्यक छ, प्यारामिटरको गोप्य मान निर्दिष्ट गर्नुको सट्टा, म केवल प्रयोग गर्नेछु। PreviousValue=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"

पाठ ४: रोलब्याक कन्फिगरेसन प्रयोग गर्नुहोस्

मैले काम गरेको अर्को टोलीले प्रकार्य प्रयोग गर्यो क्लाउडफॉर्मेशन, बोलाइयो रोलब्याक कन्फिगरेसन। मैले पहिले यो भेटेको थिइनँ र चाँडै महसुस गरें कि यसले मेरो स्ट्याकहरू थप कूलर बनाउँदछ। अब म क्लाउडफार्मेसन प्रयोग गरेर lambda वा ECS मा मेरो कोड डिप्लोय गर्दा हरेक पटक प्रयोग गर्छु।

यो कसरी काम गर्दछ: तपाइँ निर्दिष्ट गर्नुहोस् CloudWatch अलार्म प्यारामिटर मा --रोलब्याक कन्फिगरेसनजब तपाइँ परिवर्तनहरू सिर्जना गर्नुहुन्छ। पछि, जब तपाइँ परिवर्तनहरूको सेट कार्यान्वयन गर्नुहुन्छ, aws कम्तिमा एक मिनेटको लागि अलार्म निगरानी गर्दछ। यदि यो समयमा अलार्म स्थितिलाई ALARM मा परिवर्तन गर्छ भने यसले तैनातीलाई फिर्ता गर्छ।

तल टेम्प्लेट अंशको उदाहरण हो क्लाउडफॉर्मेशनजसमा म सिर्जना गर्छु क्लाउडवाच अलार्म, जसले क्लाउड लगहरूमा त्रुटिहरूको संख्याको रूपमा क्लाउड प्रयोगकर्ता मेट्रिकलाई ट्र्याक गर्दछ (मेट्रिक मार्फत उत्पन्न हुन्छ। मेट्रिकफिल्टर):

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"

पाठ ५: निश्चित गर्नुहोस् कि तपाईंले टेम्प्लेटको नवीनतम संस्करण प्रयोग गर्नुभयो

क्लाउडफर्मेसन टेम्प्लेटको पछिल्लो भन्दा कम संस्करण प्रयोग गर्न सजिलो छ, तर त्यसो गर्दा धेरै क्षति हुनेछ। यो हामीलाई एक पटक भयो: एक विकासकर्ताले Git बाट नवीनतम परिवर्तनहरू धक्का दिएन र अनजानमा स्ट्याकको अघिल्लो संस्करण तैनात गर्यो। यसले यो स्ट्याक प्रयोग गर्ने अनुप्रयोगको लागि डाउनटाइमको परिणाम हो।

यो गर्न अघि शाखा अप टु डेट छ कि छैन भनेर हेर्नको लागि चेक थप्न जत्तिकै सरल छ (गिट तपाईंको संस्करण नियन्त्रण उपकरण हो भनी मान्दै):

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

पाठ ६: पाङ्ग्रालाई पुन: आविष्कार नगर्नुहोस्

यो संग तैनाती जस्तो लाग्न सक्छ क्लाउडफॉर्मेशन - सजिलो छ। तपाईलाई केवल aws cli आदेशहरू कार्यान्वयन गर्ने bash स्क्रिप्टहरूको गुच्छा चाहिन्छ।

4 वर्ष पहिले मैले aws क्लाउडफर्मेशन सिर्जना-स्ट्याक आदेश भनिने साधारण स्क्रिप्टहरूसँग सुरु गरें। चाँडै पटकथा अब सरल थिएन। सिकेका प्रत्येक पाठले लिपिलाई थप जटिल बनायो। यो गाह्रो मात्र थिएन, तर बगहरूले भरिएको थियो।

म हाल एउटा सानो आईटी विभागमा काम गर्छु। अनुभवले देखाएको छ कि प्रत्येक टोलीसँग क्लाउडफॉर्मेशन स्ट्याकहरू प्रयोग गर्ने आफ्नै तरिका छ। र त्यो नराम्रो छ। सबैले एउटै तरिका अपनाए राम्रो हुन्थ्यो । सौभाग्य देखि, क्लाउडफर्मेशन स्ट्याकहरू डिप्लोय र कन्फिगर गर्न मद्दत गर्न धेरै उपकरणहरू उपलब्ध छन्।

यी पाठहरूले तपाईंलाई गल्तीहरूबाट बच्न मद्दत गर्नेछ।

स्रोत: www.habr.com

मैले मेरो बाँकी जीवनको लागि क्लाउडफर्मेसनको साथ काम गर्ने यी 6 पाठहरू सिकें।