🥇 मी जीवनासाठी क्लाउडफॉर्मेशनसह कार्य करण्याचे हे 6 धडे शिकले

सोबत काम करू लागलो ढग 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: गुप्त पॅरामीटर्ससह स्टॅक अपडेट करताना 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"

धडा 4: रोलबॅक कॉन्फिगरेशन वापरा

मी काम केलेल्या दुसर्‍या टीमने फंक्शन वापरले ढग, म्हणतात रोलबॅक कॉन्फिगरेशन. मी आधी ते पाहिले नव्हते आणि पटकन लक्षात आले की ते माझे स्टॅक तैनात करणे अधिक थंड करेल. आता मी प्रत्येक वेळी क्लाउडफॉर्मेशन वापरून माझा कोड lambda किंवा ECS वर उपयोजित करतो तेव्हा ते वापरतो.

ते कसे कार्य करते: आपण निर्दिष्ट करा क्लाउडवॉच अलार्म पॅरामीटर मध्ये --रोलबॅक-कॉन्फिगरेशनजेव्हा तुम्ही चेंजसेट तयार करता. नंतर, जेव्हा तुम्ही बदलांचा संच कार्यान्वित करता, तेव्हा aws किमान एक मिनिटासाठी अलार्मचे निरीक्षण करते. या वेळी अलार्मची स्थिती ALARM मध्ये बदलल्यास ते तैनाती परत आणते.

खाली टेम्पलेट उतारा एक उदाहरण आहे ढगज्यामध्ये मी तयार करतो क्लाउडवॉच अलार्म, जे क्लाउड लॉगमधील त्रुटींची संख्या म्हणून क्लाउड वापरकर्ता मेट्रिकचा मागोवा घेते (मेट्रिक याद्वारे व्युत्पन्न केले जाते MetricFilter):

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 मधील नवीनतम बदल पुश केले नाहीत आणि नकळतपणे स्टॅकची मागील आवृत्ती तैनात केली. यामुळे हा स्टॅक वापरणाऱ्या ऍप्लिकेशनसाठी डाउनटाइम झाला.

शाखा अद्ययावत आहे की नाही हे पाहण्यासाठी चेक जोडण्याइतके सोपे आहे (गिट हे तुमचे आवृत्ती नियंत्रण साधन आहे असे गृहीत धरून):

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: चाक पुन्हा शोधू नका

सह तैनात केल्यासारखे वाटू शकते ढग - हे सोपे आहे. तुम्हाला फक्त aws cli कमांड कार्यान्वित करणार्‍या बॅश स्क्रिप्ट्सची आवश्यकता आहे.

4 वर्षांपूर्वी मी aws क्लाउडफॉर्मेशन क्रिएट-स्टॅक कमांड नावाच्या सोप्या स्क्रिप्टसह सुरुवात केली. लवकरच स्क्रिप्ट सोपी राहिली नाही. शिकलेल्या प्रत्येक धड्यामुळे स्क्रिप्ट अधिकाधिक गुंतागुंतीची होत गेली. हे केवळ कठीणच नव्हते तर बगांनी भरलेले होते.

मी सध्या एका छोट्या आयटी विभागात काम करतो. अनुभवाने दर्शविले आहे की क्लाउडफॉर्मेशन स्टॅक तैनात करण्याचा प्रत्येक संघाचा स्वतःचा मार्ग आहे. आणि ते वाईट आहे. सर्वांनी समान दृष्टीकोन घेतला तर बरे होईल. सुदैवाने, क्लाउडफॉर्मेशन स्टॅक तैनात आणि कॉन्फिगर करण्यात मदत करण्यासाठी अनेक साधने उपलब्ध आहेत.

हे धडे तुम्हाला चुका टाळण्यास मदत करतील.

स्त्रोत: www.habr.com

मी माझ्या उर्वरित आयुष्यासाठी क्लाउडफॉर्मेशनसह कार्य करण्याचे हे 6 धडे शिकलो.