ما د خپل پاتې ژوند لپاره د کلاوډفارمیشن سره د کار کولو دا 6 درسونه زده کړل.

ما سره کار پیل کړ بادل جوړونه ۴ کاله وړاندې. له هغه وخت راهیسې ما ډیری زیربناوې مات کړې ، حتی هغه چې دمخه په تولید کې وې. مګر هرکله چې ما یو څه ګډوډ کړل، ما یو څه نوي زده کړل. د دې تجربې له لارې، زه به ځینې خورا مهم درسونه شریک کړم چې ما زده کړل.

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 ډیټابیس مثال یا د elasticsearch کلستر، او داسې نور. دا به ښه وي که چیرې 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 کې زیرمه شوی .

دا اسناد به بیا د کلاوډفارمیشن create-change-set کمانډ ته د پیرامیټونو په توګه لیږدول کیږي. پداسې حال کې چې د سکریپټ سره تجربه کول، داسې پیښ شوي چې د s3 سره اړیکه ورکه شوه، او زما "سمارټ میکانیزم" دا د نوي اسنادو تولید لپاره د سیګنال په توګه چلند وکړ.

که ما په تولید کې د دې سکریپټ کارول پیل کړل او د پیوستون ستونزه بیا رامنځ ته شوه، دا به د نوي اسنادو سره سټیک تازه کړي. په دې ځانګړي حالت کې، هیڅ شی به بد نه وي. په هرصورت، ما دا طریقه پریښوده او د بل بل کارول یې پیل کړل، یوازې یو ځل اسناد چمتو کول - کله چې د سټیک رامینځته کول. او وروسته ، کله چې سټیک تازه کولو ته اړتیا لري ، د دې پرځای چې د پیرامیټر پټ ارزښت مشخص کړي ، زه به په ساده ډول وکاروم PreviousValue = ریښتیا وکاروئ:

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"

څلورم لوست: د رول بیک ترتیب وکاروئ

بل ټیم ​​​​چې ما ورسره کار کاوه فنکشن کارولی بادل جوړونهبلل شوی د رول بیک ترتیب. ما مخکې دا نه و لیدلی او په چټکۍ سره پوه شوم چې دا به زما د سټیکونو ځای په ځای کول نور هم یخ کړي. اوس زه دا هرکله کاروم چې زه خپل کوډ لامبډا یا 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 ستاسو د نسخې کنټرول وسیله ده):

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 کمانډونه اجرا کوي.

4 کاله دمخه ما د ساده سکریپټونو سره پیل وکړ چې د aws cloudformation create-stack کمانډ په نوم یادیږي. ډیر ژر سکریپټ نور ساده نه و. هر زده شوی درس سکریپټ ډیر پیچلی کړی. دا نه یوازې ستونزمنه وه، بلکې له کیچونو ډکه وه.

زه اوس مهال د معلوماتي ټکنالوجۍ په یوه کوچنۍ څانګه کې کار کوم. تجربې ښودلې چې هر ټیم د کلاوډفارمیشن سټیکونو ځای په ځای کولو خپله لاره لري. او دا بد دی. دا به ښه وي که هرڅوک ورته چلند وکړي. خوشبختانه ، دلته ډیری وسیلې شتون لري چې تاسو سره د کلاوډفارمیشن سټیکونو تنظیم او تنظیم کولو کې مرسته کوي.

دا درسونه به تاسو سره د غلطیو څخه مخنیوي کې مرسته وکړي.

سرچینه: www.habr.com