എന്റെ ജീവിതകാലം മുഴുവൻ ക്ലൗഡ്‌ഫോർമേഷനുമായി പ്രവർത്തിക്കുന്നതിന്റെ ഈ 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-യിലേക്കുള്ള കണക്ഷൻ നഷ്ടപ്പെട്ടു, പുതിയ ക്രെഡൻഷ്യലുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു സിഗ്നലായി എന്റെ "സ്മാർട്ട് മെക്കാനിസം" അതിനെ കണക്കാക്കി.

ഞാൻ നിർമ്മാണത്തിൽ ഈ സ്ക്രിപ്റ്റ് ഉപയോഗിക്കാൻ തുടങ്ങിയാൽ, വീണ്ടും കണക്ഷൻ പ്രശ്നം സംഭവിക്കുകയാണെങ്കിൽ, അത് പുതിയ ക്രെഡൻഷ്യലുകൾ ഉപയോഗിച്ച് സ്റ്റാക്ക് അപ്ഡേറ്റ് ചെയ്യും. ഈ പ്രത്യേക സാഹചര്യത്തിൽ, മോശമായ ഒന്നും സംഭവിക്കില്ല. എന്നിരുന്നാലും, ഞാൻ ഈ സമീപനം ഉപേക്ഷിച്ച് മറ്റൊന്ന് ഉപയോഗിക്കാൻ തുടങ്ങി, ഒരിക്കൽ മാത്രം ക്രെഡൻഷ്യലുകൾ നൽകുന്നു - സ്റ്റാക്ക് സൃഷ്ടിക്കുമ്പോൾ. പിന്നീട്, സ്റ്റാക്കിന് അപ്‌ഡേറ്റ് ആവശ്യമുള്ളപ്പോൾ, പരാമീറ്ററിന്റെ രഹസ്യ മൂല്യം വ്യക്തമാക്കുന്നതിന് പകരം, ഞാൻ ലളിതമായി ഉപയോഗിക്കും 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: റോൾബാക്ക് കോൺഫിഗറേഷൻ ഉപയോഗിക്കുക

ഞാൻ കൂടെ പ്രവർത്തിച്ച മറ്റൊരു ടീം ഫംഗ്‌ഷൻ ഉപയോഗിച്ചു മേഘമാറ്റം, വിളിച്ചു റോൾബാക്ക് കോൺഫിഗറേഷൻ. ഞാൻ ഇത് മുമ്പ് കണ്ടിട്ടില്ല, അത് എന്റെ സ്റ്റാക്കുകൾ വിന്യസിക്കുന്നത് കൂടുതൽ തണുപ്പിക്കുമെന്ന് പെട്ടെന്ന് മനസ്സിലാക്കി. ക്ലൗഡ് ഫോർമേഷൻ ഉപയോഗിച്ച് ലാംഡയിലേക്കോ ഇസിഎസിലേക്കോ എന്റെ കോഡ് വിന്യസിക്കുമ്പോഴെല്ലാം ഞാൻ ഇപ്പോൾ ഇത് ഉപയോഗിക്കുന്നു.

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു: നിങ്ങൾ വ്യക്തമാക്കുക 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 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 കമാൻഡ് എന്ന ലളിതമായ സ്ക്രിപ്റ്റുകൾ ഉപയോഗിച്ചാണ് ആരംഭിച്ചത്. താമസിയാതെ തിരക്കഥ ലളിതമല്ലാതായി. പഠിച്ച ഓരോ പാഠവും തിരക്കഥയെ കൂടുതൽ സങ്കീർണ്ണമാക്കി. ഇത് ബുദ്ധിമുട്ട് മാത്രമല്ല, ബഗുകളും നിറഞ്ഞതായിരുന്നു.

ഞാൻ ഇപ്പോൾ ഒരു ചെറിയ ഐടി ഡിപ്പാർട്ട്മെന്റിൽ ജോലി ചെയ്യുന്നു. ഓരോ ടീമിനും ക്ലൗഡ് ഫോർമേഷൻ സ്റ്റാക്കുകൾ വിന്യസിക്കാൻ അതിന്റേതായ രീതിയുണ്ടെന്ന് അനുഭവം തെളിയിച്ചിട്ടുണ്ട്. അത് മോശമാണ്. എല്ലാവരും ഒരേ സമീപനം സ്വീകരിച്ചാൽ നന്നായിരിക്കും. ഭാഗ്യവശാൽ, ക്ലൗഡ് ഫോർമേഷൻ സ്റ്റാക്കുകൾ വിന്യസിക്കാനും കോൺഫിഗർ ചെയ്യാനും നിങ്ങളെ സഹായിക്കുന്ന നിരവധി ടൂളുകൾ ലഭ്യമാണ്.

തെറ്റുകൾ ഒഴിവാക്കാൻ ഈ പാഠങ്ങൾ നിങ്ങളെ സഹായിക്കും.

അവലംബം: www.habr.com