በቀሪው ህይወቴ እነዚህን 6 ከክላውድ ፎርሜሽን ጋር የመስራትን ትምህርት ተምሬአለሁ።

አብሬው መስራት ጀመርኩ። የደመና አሠራር ከ 4 ዓመታት በፊት. ከዚያን ጊዜ ጀምሮ ብዙ መሠረተ ልማቶችን፣ በምርት ላይ የነበሩትንም ሳይቀር ሰብሬያለሁ። ነገር ግን አንድ ነገር ባበላሸሁ ቁጥር አዲስ ነገር ተምሬያለሁ። በዚህ ልምድ፣ የተማርኳቸውን በጣም ጠቃሚ ትምህርቶችን አካፍላለሁ።

ትምህርት 1፡ ለውጦቹን ከማሰማራትዎ በፊት ይሞክሩ

ይህን ትምህርት የተማርኩት አብሬ መስራት ከጀመርኩ ብዙም ሳይቆይ ነው። የደመና አሠራር. ያኔ በትክክል የሰበርኩትን አላስታውስም፣ ግን በእርግጠኝነት ትዕዛዙን እንደተጠቀምኩ አስታውሳለሁ። aws የደመና መረጃ ዝመና. ይህ ትዕዛዝ የሚሰማሩት ለውጦች ምንም ማረጋገጫ ሳይኖር በቀላሉ አብነቱን ያወጣል። ሁሉንም ለውጦች ከማሰማራትዎ በፊት ለምን መሞከር እንዳለቦት ምንም አይነት ማብራሪያ የሚያስፈልግ አይመስለኝም።

ከዚህ ውድቀት በኋላ, ወዲያውኑ ተለወጥኩ Deployment pipeline, የዝማኔ ትዕዛዙን በትእዛዙ በመተካት መፍጠር-ለውጥ-ስብስብ

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

አንድ ለውጥ አንዴ ከተፈጠረ፣ ባለው ቁልል ላይ ምንም ተጽእኖ አይኖረውም። እንደ ማሻሻያ ትዕዛዙ ሳይሆን፣ የለውጦ ማስተካከያ አቀራረብ ትክክለኛውን ስምሪት አያነሳሳም። በምትኩ፣ ከመሰማራቱ በፊት ሊገመግሟቸው የሚችሏቸውን ለውጦች ዝርዝር ይፈጥራል። ለውጦችን በአውስ ኮንሶል በይነገጽ ማየት ይችላሉ። ነገር ግን የምትችለውን ሁሉ በራስ ሰር ማድረግ ከመረጥክ በ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 ዳታቤዝ ለምሳሌ ወይም elasticsearch cluster፣ ወዘተ ያሉ ሙሉ አገልግሎቶች ናቸው። እየተካሄደ ያለው ክዋኔ ይህን የመሰለ ሃብት መሰረዝን የሚጠይቅ ከሆነ አውስ በራስ ሰር ማሰማራትን ቢቃወም ጥሩ ነበር። እንደ እድል ሆኖ, ይህንን ለማድረግ የክላውድ አሠራር አብሮ የተሰራ መንገድ አለው. ይህ ቁልል ፖሊሲ ይባላል፣ እና ስለሱ የበለጠ ማንበብ ይችላሉ። ሰነድ:

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 ውስጥ ተከማችቷል.

እነዚህ ምስክርነቶች ወደ Cloudformation መፍጠር-ለውጥ-ስብስብ ትዕዛዝ እንደ መለኪያዎች ይተላለፋሉ። ከስክሪፕቱ ጋር እየሞከርኩ እያለ፣ ከ s3 ጋር ያለው ግንኙነት ጠፋ፣ እና የእኔ “ስማርት ዘዴ” አዲስ ምስክርነቶችን ለመፍጠር እንደ ምልክት ወሰደው።

ይህንን ስክሪፕት በምርት ውስጥ መጠቀም ከጀመርኩ እና የግንኙነት ችግሩ እንደገና ከተከሰተ ቁልል በአዲስ ምስክርነቶች ያዘምነዋል። በዚህ ጉዳይ ላይ ምንም መጥፎ ነገር አይከሰትም. ሆኖም፣ ይህንን አካሄድ ትቼ ሌላ መጠቀም ጀመርኩ፣ አንድ ጊዜ ብቻ ምስክርነቶችን አቅርቤ - ቁልል ሲፈጠር። እና በኋላ፣ ቁልል ማዘመን ሲፈልግ፣ የመለኪያውን ሚስጥራዊ እሴት ከመግለጽ ይልቅ፣ በቀላሉ እጠቀማለሁ። ቀዳሚ እሴት=እውነትን ተጠቀም:

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 ማንቂያ በመለኪያ --የመመለሻ-ማዋቀርለውጦችን ሲፈጥሩ. በኋላ፣ የለውጦች ስብስብ ሲፈጽሙ፣ 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፡ የቅርብ ጊዜውን የአብነት ስሪት ማሰማራቱን ያረጋግጡ

ከቅርቡ ያነሰ የCloudformation አብነት ስሪት ማሰማራት ቀላል ነው፣ ነገር ግን ይህን ማድረግ ብዙ ጉዳት ያስከትላል። ይሄ አንድ ጊዜ ደርሶብናል፡ አንድ ገንቢ ከ 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 ትዕዛዞችን የሚያስፈጽም የ bash ስክሪፕት ብቻ ያስፈልግዎታል።

ከ 4 ዓመታት በፊት አውስ Cloudformation create-stack ትእዛዝ በሚባሉ ቀላል ስክሪፕቶች ጀመርኩ። ብዙም ሳይቆይ ስክሪፕቱ ቀላል አልነበረም። እያንዳንዱ የተማረው ትምህርት ስክሪፕቱን የበለጠ እና ውስብስብ አድርጎታል። አስቸጋሪ ብቻ ሳይሆን በትልችም የተሞላ ነበር።

በአሁኑ ጊዜ በትንሽ የአይቲ ዲፓርትመንት ውስጥ እሰራለሁ። ልምዱ እንደሚያሳየው እያንዳንዱ ቡድን የክላውድፎርሜሽን ቁልሎችን የሚያሰማራበት የራሱ መንገድ አለው። ያ ደግሞ መጥፎ ነው። ሁሉም ሰው ተመሳሳይ አካሄድ ቢወስድ ጥሩ ነበር። እንደ እድል ሆኖ፣ የደመና መረጃ ቁልሎችን ለማሰማራት እና ለማዋቀር የሚረዱዎት ብዙ መሳሪያዎች አሉ።

እነዚህ ትምህርቶች ስህተቶችን ለማስወገድ ይረዳሉ.

ምንጭ: hab.com