ខ្ញុំបានរៀនមេរៀនទាំង 6 នេះនៃការធ្វើការជាមួយ cloudformation ពេញមួយជីវិតរបស់ខ្ញុំ។

ខ្ញុំចាប់ផ្តើមធ្វើការជាមួយ ព័ត៌មានពពក 4 ឆ្នាំ​កន្លងទៅ។ តាំងពីពេលនោះមក ខ្ញុំបានបំបែកហេដ្ឋារចនាសម្ព័ន្ធជាច្រើន សូម្បីតែកន្លែងផលិតរួចហើយក៏ដោយ។ ប៉ុន្តែរាល់ពេលដែលខ្ញុំរញ៉េរញ៉ៃអ្វីមួយ ខ្ញុំបានរៀនអ្វីថ្មី។ តាមរយៈបទពិសោធន៍នេះ ខ្ញុំនឹងចែករំលែកមេរៀនសំខាន់ៗមួយចំនួនដែលខ្ញុំបានរៀន។

មេរៀនទី១៖ សាកល្បងការផ្លាស់ប្តូរមុននឹងដាក់ឱ្យប្រើប្រាស់

ខ្ញុំបានរៀនមេរៀននេះភ្លាមៗបន្ទាប់ពីខ្ញុំចាប់ផ្តើមធ្វើការជាមួយ ព័ត៌មានពពក. ខ្ញុំ​មិន​ចាំ​ថា​អ្វី​ដែល​ខ្ញុំ​ខូច​នោះ​ទេ ប៉ុន្តែ​ខ្ញុំ​ច្បាស់​ជា​ចាំ​ថា​ខ្ញុំ​បាន​ប្រើ​ពាក្យ​បញ្ជា Aws cloudformation update. ពាក្យ​បញ្ជា​នេះ​គ្រាន់​តែ​ដាក់​ចេញ​នូវ​គំរូ​ដោយ​មិន​មាន​ការ​បញ្ជាក់​ពី​ការ​ផ្លាស់​ប្តូរ​ដែល​នឹង​ត្រូវ​ដាក់​ឱ្យ​ប្រើ​ប្រាស់​ឡើយ។ ខ្ញុំ​មិន​គិត​ថា​ការ​ពន្យល់​ណា​មួយ​គឺ​ត្រូវ​ការ​សម្រាប់​មូល​ហេតុ​ដែល​អ្នក​គួរ​សាកល្បង​ការ​ផ្លាស់​ប្តូរ​ទាំង​អស់​មុន​ពេល​ដាក់​ឱ្យ​ប្រើ​ប្រាស់។

បន្ទាប់ពីបរាជ័យនេះ ខ្ញុំបានផ្លាស់ប្តូរភ្លាមៗ បំពង់បង្ហោះការដាក់ពង្រាយជំនួសពាក្យបញ្ជាអាប់ដេតដោយពាក្យបញ្ជា បង្កើត-ផ្លាស់ប្តូរ-កំណត់

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

យកចិត្តទុកដាក់ជាពិសេសចំពោះការផ្លាស់ប្តូរកន្លែងដែលសកម្មភាព ជំនួស, Delete ឬកន្លែងណា ត្រូវការជំនួស - ពិត. ទាំងនេះគឺជាការផ្លាស់ប្តូរដ៏គ្រោះថ្នាក់បំផុត ហើយជាធម្មតានាំឱ្យបាត់បង់ព័ត៌មាន។

នៅពេលដែលការផ្លាស់ប្តូរត្រូវបានពិនិត្យ ពួកគេអាចត្រូវបានគេដាក់ពង្រាយ

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 ឬក្រុមស្វែងរកយឺត។ សំណាងល្អ ការបង្កើតពពកមានវិធីដែលភ្ជាប់មកជាមួយដើម្បីធ្វើរឿងនេះ។ នេះត្រូវបានគេហៅថា គោលនយោបាយជង់ ហើយអ្នកអាចអានបន្ថែមអំពីវានៅក្នុង ឯកសារ:

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 entity AWS តម្រូវឱ្យអ្នកផ្តល់ MasterUsername និង MasterUserPassword ។ ដោយសារវាជាការប្រសើរជាងកុំរក្សាការសម្ងាត់នៅក្នុងកូដប្រភព ហើយខ្ញុំចង់ធ្វើអ្វីៗគ្រប់យ៉ាងដោយស្វ័យភាព ខ្ញុំបានអនុវត្ត "យន្តការឆ្លាតវៃ" ដែលមុនពេលដាក់ឱ្យប្រើប្រាស់ លិខិតសម្គាល់នឹងត្រូវបានទទួលពី s3 ហើយប្រសិនបើព័ត៌មានសម្ងាត់មិនត្រូវបានរកឃើញ លិខិតសម្គាល់ថ្មីត្រូវបានបង្កើត និង រក្សាទុកក្នុង s3 ។

បន្ទាប់មកលិខិតសម្គាល់ទាំងនេះនឹងត្រូវបានបញ្ជូនជាប៉ារ៉ាម៉ែត្រទៅកាន់ពាក្យបញ្ជាបង្កើត-ផ្លាស់ប្តូរ-កំណត់បង្កើតពពក។ ខណៈពេលកំពុងពិសោធន៍ជាមួយស្គ្រីប វាបានកើតឡើងថាការភ្ជាប់ទៅ s3 ត្រូវបានបាត់បង់ ហើយ "យន្តការឆ្លាតវៃ" របស់ខ្ញុំបានចាត់ទុកវាជាសញ្ញាមួយដើម្បីបង្កើតព័ត៌មានសម្ងាត់ថ្មី។

ប្រសិនបើខ្ញុំចាប់ផ្តើមប្រើស្គ្រីបនេះនៅក្នុងការផលិត ហើយបញ្ហានៃការតភ្ជាប់បានកើតឡើងម្តងទៀត វានឹងធ្វើបច្ចុប្បន្នភាពជង់ជាមួយនឹងលិខិតសម្គាល់ថ្មី។ ក្នុងករណីពិសេសនេះគ្មានអ្វីអាក្រក់នឹងកើតឡើងទេ។ ទោះយ៉ាងណាក៏ដោយ ខ្ញុំបានបោះបង់ចោលវិធីសាស្រ្តនេះ ហើយចាប់ផ្តើមប្រើមួយផ្សេងទៀត ដោយផ្តល់ព័ត៌មានបញ្ជាក់អត្តសញ្ញាណតែម្តងគត់ - នៅពេលបង្កើតជង់។ ហើយក្រោយមក នៅពេលដែលជង់ត្រូវការការអាប់ដេត ជំនួសឱ្យការបញ្ជាក់តម្លៃសម្ងាត់នៃប៉ារ៉ាម៉ែត្រ ខ្ញុំនឹងប្រើយ៉ាងសាមញ្ញ UsePreviousValue=ពិត:

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: ប្រើការកំណត់រចនាសម្ព័ន្ធ rollback

ក្រុមមួយទៀតដែលខ្ញុំបានធ្វើការជាមួយបានប្រើមុខងារ ព័ត៌មានពពក, បានហៅ ការកំណត់រចនាសម្ព័ន្ធ rollback. ខ្ញុំមិនបានឆ្លងកាត់វាពីមុនមកទេ ហើយបានដឹងថាវានឹងធ្វើឱ្យការដាក់ពង្រាយជង់របស់ខ្ញុំកាន់តែត្រជាក់ជាងមុន។ ឥឡូវនេះខ្ញុំប្រើវារាល់ពេលដែលខ្ញុំដាក់ពង្រាយលេខកូដរបស់ខ្ញុំទៅ lambda ឬ ECS ដោយប្រើ cloudformation ។

របៀបដែលវាដំណើរការ: អ្នកបញ្ជាក់ សំឡេងរោទិ៍ CloudWatch នៅក្នុងប៉ារ៉ាម៉ែត្រ --rollback-ការកំណត់រចនាសម្ព័ន្ធនៅពេលអ្នកបង្កើតសំណុំផ្លាស់ប្តូរ។ ក្រោយមក នៅពេលអ្នកប្រតិបត្តិសំណុំនៃការផ្លាស់ប្តូរ នោះ aws តាមដានសំឡេងរោទិ៍យ៉ាងហោចណាស់មួយនាទី។ វា​បង្វិល​ការ​ដាក់​ឱ្យ​ប្រើ​វិញ ប្រសិនបើ​ម៉ោងរោទ៍​ប្តូរ​ស្ថានភាព​ទៅ ALARM ក្នុងអំឡុងពេល​នេះ។

ខាងក្រោមនេះជាឧទាហរណ៍នៃការដកស្រង់គំរូ ព័ត៌មានពពកដែលខ្ញុំបង្កើត សំឡេងរោទិ៍ cloudwatchដែលតាមដាន cloud user metric ជាចំនួននៃកំហុសក្នុង cloud logs (ម៉ែត្រត្រូវបានបង្កើតតាមរយៈ តម្រងម៉ែត្រ):

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

មេរៀនទី៦៖ កុំបង្កើតកង់ឡើងវិញ

វាអាចហាក់ដូចជាដាក់ពង្រាយជាមួយ ព័ត៌មានពពក - វា​ងាយស្រួល។ អ្នកគ្រាន់តែត្រូវការស្គ្រីប bash ជាច្រើនដែលប្រតិបត្តិពាក្យបញ្ជា aws cli ។

កាលពី 4 ឆ្នាំមុន ខ្ញុំបានចាប់ផ្តើមជាមួយ scripts សាមញ្ញហៅថា aws cloudformation create-stack command។ មិនយូរប៉ុន្មានស្គ្រីបមិនសាមញ្ញទៀតទេ។ មេរៀននីមួយៗដែលរៀនបានធ្វើឱ្យស្គ្រីបកាន់តែស្មុគស្មាញ។ វា​មិន​ត្រឹម​តែ​ពិបាក​ប៉ុណ្ណោះ​ទេ ប៉ុន្តែ​ក៏​ពោរពេញ​ទៅ​ដោយ​កំហុស​ដែរ។

បច្ចុប្បន្នខ្ញុំធ្វើការនៅផ្នែក IT តូចមួយ។ បទពិសោធន៍បានបង្ហាញថាក្រុមនីមួយៗមានវិធីផ្ទាល់ខ្លួនក្នុងការដាក់ពង្រាយបណ្តុំបង្កើតពពក។ ហើយនោះជារឿងអាក្រក់។ វា​នឹង​ល្អ​ជាង​ប្រសិន​បើ​អ្នក​រាល់​គ្នា​បាន​ប្រើ​វិធី​ដូច​គ្នា។ ជាសំណាងល្អ មានឧបករណ៍ជាច្រើនដែលអាចរកបានដើម្បីជួយអ្នកក្នុងការដាក់ពង្រាយ និងកំណត់រចនាសម្ព័ន្ធបណ្តុំបង្កើតពពក។

មេរៀនទាំងនេះនឹងជួយអ្នកជៀសវាងកំហុស។

ប្រភព: www.habr.com