నా జీవితాంతం క్లౌడ్‌ఫార్మేషన్‌తో పనిచేయడానికి ఈ 6 పాఠాలు నేర్చుకున్నాను.

నేను పని చేయడం ప్రారంభించాను మేఘాల నిర్మాణం 4 సంవత్సరాల క్రితం. అప్పటి నుండి నేను చాలా మౌలిక సదుపాయాలను విచ్ఛిన్నం చేసాను, ఇప్పటికే ఉత్పత్తిలో ఉన్న వాటిని కూడా. కానీ నేను ఏదో గందరగోళానికి గురైన ప్రతిసారీ, నేను కొత్తదాన్ని నేర్చుకున్నాను. ఈ అనుభవం ద్వారా, నేను నేర్చుకున్న కొన్ని ముఖ్యమైన పాఠాలను పంచుకుంటాను.

పాఠం 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"

పాఠం 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కి మీరు మాస్టర్‌యూజర్‌నేమ్ మరియు మాస్టర్‌యూజర్‌పాస్‌వర్డ్ అందించాల్సి ఉంటుంది. సోర్స్ కోడ్‌లో రహస్యాలను ఉంచకపోవడమే ఉత్తమం మరియు నేను ఖచ్చితంగా ప్రతిదీ ఆటోమేట్ చేయాలనుకున్నాను కాబట్టి, నేను "స్మార్ట్ మెకానిజం"ని అమలు చేసాను, ఇక్కడ విస్తరణకు ముందు ఆధారాలు s3 నుండి పొందబడతాయి మరియు ఆధారాలు కనుగొనబడకపోతే, కొత్త ఆధారాలు రూపొందించబడతాయి మరియు s3లో నిల్వ చేయబడుతుంది.

ఈ ఆధారాలు క్లౌడ్‌ఫార్మేషన్ క్రియేట్-ఛేంజ్-సెట్ కమాండ్‌కి పారామీటర్‌లుగా పాస్ చేయబడతాయి. స్క్రిప్ట్‌తో ప్రయోగాలు చేస్తున్నప్పుడు, s3కి కనెక్షన్ పోయింది మరియు నా “స్మార్ట్ మెకానిజం” కొత్త ఆధారాలను రూపొందించడానికి ఒక సిగ్నల్‌గా పరిగణించింది.

నేను ఈ స్క్రిప్ట్‌ని ప్రొడక్షన్‌లో ఉపయోగించడం ప్రారంభించి, కనెక్షన్ సమస్య మళ్లీ తలెత్తితే, అది కొత్త ఆధారాలతో స్టాక్‌ను అప్‌డేట్ చేస్తుంది. ఈ ప్రత్యేక సందర్భంలో, చెడు ఏమీ జరగదు. అయినప్పటికీ, నేను ఈ విధానాన్ని వదిలివేసి, మరొకదాన్ని ఉపయోగించడం ప్రారంభించాను, ఒకసారి మాత్రమే ఆధారాలను అందించాను - స్టాక్‌ను సృష్టించేటప్పుడు. మరియు తరువాత, స్టాక్‌కు నవీకరణ అవసరమైనప్పుడు, పరామితి యొక్క రహస్య విలువను పేర్కొనడానికి బదులుగా, నేను కేవలం ఉపయోగిస్తాను UsePreviousValue=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: రోల్‌బ్యాక్ కాన్ఫిగరేషన్‌ని ఉపయోగించండి

నేను పనిచేసిన మరొక బృందం ఫంక్షన్‌ను ఉపయోగించింది మేఘాల నిర్మాణంఅని పిలిచారు రోల్‌బ్యాక్ కాన్ఫిగరేషన్. నేను ఇంతకు ముందు దాన్ని చూడలేదు మరియు ఇది నా స్టాక్‌లను అమర్చడం మరింత చల్లగా చేస్తుందని త్వరగా గ్రహించాను. ఇప్పుడు నేను క్లౌడ్‌ఫార్మేషన్‌ని ఉపయోగించి లాంబ్డా లేదా ECSకి నా కోడ్‌ని అమలు చేసిన ప్రతిసారీ దాన్ని ఉపయోగిస్తాను.

ఇది ఎలా పని చేస్తుంది: మీరు పేర్కొనండి CloudWatch అలారం పరామితిలో --rollback-configurationమీరు మార్పులను సృష్టించినప్పుడు. తర్వాత, మీరు మార్పుల సమితిని అమలు చేసినప్పుడు, 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"

పాఠం 5: మీరు టెంప్లేట్ యొక్క తాజా వెర్షన్‌ని అమలు చేశారని నిర్ధారించుకోండి

క్లౌడ్‌ఫార్మేషన్ టెంప్లేట్ యొక్క తాజా వెర్షన్ కంటే తక్కువ-తక్కువ వెర్షన్‌ని అమలు చేయడం చాలా సులభం, కానీ అలా చేయడం వల్ల చాలా నష్టం జరుగుతుంది. ఇది మాకు ఒకసారి జరిగింది: డెవలపర్ Git నుండి తాజా మార్పులను ముందుకు తీసుకురాలేదు మరియు తెలియకుండానే స్టాక్ యొక్క మునుపటి సంస్కరణను అమలు చేసారు. దీని ఫలితంగా ఈ స్టాక్‌ని ఉపయోగించిన అప్లికేషన్‌కు పనికిరాని సమయం ఏర్పడింది.

బ్రాంచ్‌కు కట్టుబడి ఉండే ముందు అది తాజాగా ఉందో లేదో తెలుసుకోవడానికి చెక్‌ను జోడించడం చాలా సులభం (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 cloudformation create-stack command అనే సాధారణ స్క్రిప్ట్‌లతో ప్రారంభించాను. త్వరలో స్క్రిప్ట్ ఇకపై సాధారణ కాదు. నేర్చుకున్న ప్రతి పాఠం స్క్రిప్ట్‌ను మరింత క్లిష్టతరం చేసింది. ఇది కష్టమే కాదు, దోషాలతో కూడా నిండిపోయింది.

నేను ప్రస్తుతం చిన్న ఐటీ విభాగంలో పనిచేస్తున్నాను. క్లౌడ్‌ఫార్మేషన్ స్టాక్‌లను అమలు చేయడానికి ప్రతి బృందం దాని స్వంత మార్గాన్ని కలిగి ఉందని అనుభవం చూపించింది. మరియు అది చెడ్డది. అందరూ ఇదే విధానాన్ని అనుసరిస్తే మంచిది. అదృష్టవశాత్తూ, క్లౌడ్‌ఫార్మేషన్ స్టాక్‌లను అమర్చడంలో మరియు కాన్ఫిగర్ చేయడంలో మీకు సహాయపడే అనేక సాధనాలు అందుబాటులో ఉన్నాయి.

ఈ పాఠాలు తప్పులను నివారించడానికి మీకు సహాయపడతాయి.

మూలం: www.habr.com