ຂ້າພະເຈົ້າໄດ້ຮຽນຮູ້ 6 ບົດຮຽນນີ້ຂອງການເຮັດວຽກກັບ cloudformation ສໍາລັບສ່ວນທີ່ເຫຼືອຂອງຊີວິດຂອງຂ້າພະເຈົ້າ.

ຂ້ອຍເລີ່ມເຮັດວຽກກັບ ຂໍ້ມູນຂ່າວສານຟັງ 4 ປີກ່ອນ. ຕັ້ງ​ແຕ່​ນັ້ນ​ມາ​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ທໍາ​ລາຍ​ຫຼາຍ​ໂຄງ​ລ່າງ​ພື້ນ​ຖານ, ແມ່ນ​ແຕ່​ທີ່​ມີ​ການ​ຜະ​ລິດ​ແລ້ວ. ແຕ່​ທຸກ​ຄັ້ງ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ messed ເຖິງ, ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ຮຽນ​ຮູ້​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ໃຫມ່. ໂດຍຜ່ານປະສົບການນີ້, ຂ້າພະເຈົ້າຈະແບ່ງປັນບາງບົດຮຽນທີ່ສໍາຄັນທີ່ສຸດທີ່ຂ້າພະເຈົ້າໄດ້ຮຽນຮູ້.

ບົດຮຽນທີ 1: ທົດສອບການປ່ຽນແປງກ່ອນທີ່ຈະນຳໃຊ້ພວກມັນ

ຂ້າພະເຈົ້າໄດ້ຮຽນຮູ້ບົດຮຽນນີ້ທັນທີຫຼັງຈາກທີ່ຂ້າພະເຈົ້າໄດ້ເລີ່ມຕົ້ນເຮັດວຽກກັບ ຂໍ້ມູນຂ່າວສານຟັງ. ຂ້ອຍບໍ່ຈື່ສິ່ງທີ່ຂ້ອຍແຕກຫັກໃນເວລານັ້ນ, ແຕ່ຂ້ອຍຈື່ໄດ້ຢ່າງແນ່ນອນວ່າຂ້ອຍໃຊ້ຄໍາສັ່ງ Aws cloudformation update. ຄໍາ​ສັ່ງ​ນີ້​ພຽງ​ແຕ່ rolls ອອກ​ແມ່​ແບບ​ໂດຍ​ບໍ່​ມີ​ການ​ກວດ​ສອບ​ການ​ປ່ຽນ​ແປງ​ທີ່​ຈະ​ຖືກ​ນໍາ​ໃຊ້​. ຂ້ອຍບໍ່ຄິດວ່າຄໍາອະທິບາຍໃດໆແມ່ນຈໍາເປັນສໍາລັບວ່າເປັນຫຍັງທ່ານຄວນທົດສອບການປ່ຽນແປງທັງຫມົດກ່ອນທີ່ຈະນໍາໃຊ້ພວກມັນ.

ຫຼັງຈາກຄວາມລົ້ມເຫລວນີ້, ຂ້ອຍໄດ້ປ່ຽນທັນທີ 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"

ເມື່ອຊຸດການປ່ຽນແປງຖືກສ້າງຂື້ນ, ມັນບໍ່ມີຜົນຕໍ່ stack ທີ່ມີຢູ່ແລ້ວ. ບໍ່ເຫມືອນກັບຄໍາສັ່ງການປັບປຸງ, ວິທີການ changeset ບໍ່ໄດ້ກະຕຸ້ນໃຫ້ມີການນໍາໃຊ້ຕົວຈິງ. ແທນທີ່ຈະ, ມັນສ້າງບັນຊີລາຍຊື່ຂອງການປ່ຽນແປງທີ່ທ່ານສາມາດທົບທວນຄືນກ່ອນທີ່ຈະນໍາໃຊ້. ທ່ານສາມາດເບິ່ງການປ່ຽນແປງໃນການໂຕ້ຕອບຂອງ aws console. ແຕ່ຖ້າທ່ານຕ້ອງການອັດຕະໂນມັດທຸກຢ່າງທີ່ທ່ານສາມາດເຮັດໄດ້, ຫຼັງຈາກນັ້ນກວດເບິ່ງພວກມັນຢູ່ໃນ 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: ໃຊ້ນະໂຍບາຍ stack ເພື່ອປ້ອງກັນບໍ່ໃຫ້ຊັບພະຍາກອນຂອງລັດຖືກປ່ຽນແທນ ຫຼືເອົາອອກ

ບາງຄັ້ງພຽງແຕ່ເບິ່ງການປ່ຽນແປງແມ່ນບໍ່ພຽງພໍ. ພວກເຮົາທຸກຄົນແມ່ນມະນຸດແລະພວກເຮົາທຸກຄົນເຮັດຜິດພາດ. ຫຼັງ​ຈາກ​ທີ່​ພວກ​ເຮົາ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ການ​ນໍາ​ໃຊ້​ການ​ປ່ຽນ​ແປງ​ບໍ່​ດົນ, ເພື່ອນ​ຮ່ວມ​ທີມ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ຮູ້​ຈັກ​ການ​ນໍາ​ໃຊ້​ທີ່​ເຮັດ​ໃຫ້​ມີ​ການ​ປັບ​ປຸງ​ຖານ​ຂໍ້​ມູນ. ບໍ່ມີຫຍັງທີ່ບໍ່ດີເກີດຂຶ້ນເພາະວ່າມັນເປັນສະພາບແວດລ້ອມການທົດສອບ.

ເຖິງແມ່ນວ່າສະຄິບຂອງພວກເຮົາໄດ້ສະແດງລາຍຊື່ການປ່ຽນແປງແລະຮ້ອງຂໍການຢືນຢັນ, ການປ່ຽນແປງ Replace ໄດ້ຖືກຂ້າມໄປເພາະວ່າບັນຊີລາຍຊື່ຂອງການປ່ຽນແປງມີຂະຫນາດໃຫຍ່ທີ່ມັນບໍ່ເຫມາະສົມກັບຫນ້າຈໍ. ແລະນັບຕັ້ງແຕ່ນີ້ແມ່ນການປັບປຸງປົກກະຕິໃນສະພາບແວດລ້ອມການທົດສອບ, ບໍ່ໄດ້ເອົາໃຈໃສ່ຫຼາຍຕໍ່ການປ່ຽນແປງ.

ມີຊັບພະຍາກອນທີ່ທ່ານບໍ່ເຄີຍຕ້ອງການທີ່ຈະທົດແທນຫຼືເອົາອອກ. ເຫຼົ່ານີ້ແມ່ນການບໍລິການ statefull, ເຊັ່ນ: ຖານຂໍ້ມູນ RDS ຫຼືກຸ່ມ elasticsearch, ແລະອື່ນໆ. ມັນຈະດີຖ້າ aws ຈະປະຕິເສດການນໍາໄປໃຊ້ໂດຍອັດຕະໂນມັດຖ້າການດໍາເນີນງານທີ່ກໍາລັງປະຕິບັດແມ່ນຕ້ອງການລຶບຊັບພະຍາກອນດັ່ງກ່າວ. ໂຊກດີ, ຮູບແບບ cloudformation ມີວິທີການທີ່ສ້າງຂຶ້ນເພື່ອເຮັດສິ່ງນີ້. ນີ້ເອີ້ນວ່ານະໂຍບາຍ stack, ແລະທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບມັນຢູ່ໃນ ເອກະສານ:

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 ເມື່ອອັບເດດ stack ທີ່ມີພາລາມິເຕີລັບ

ເມື່ອທ່ານສ້າງ RDS mysql entity, AWS ຮຽກຮ້ອງໃຫ້ທ່ານໃຫ້ MasterUsername ແລະ MasterUserPassword. ເນື່ອງຈາກວ່າມັນດີກວ່າທີ່ຈະບໍ່ຮັກສາຄວາມລັບໃນລະຫັດແຫຼ່ງແລະຂ້ອຍຕ້ອງການອັດຕະໂນມັດທຸກຢ່າງ, ຂ້ອຍໄດ້ປະຕິບັດ "ກົນໄກທີ່ສະຫຼາດ" ເຊິ່ງກ່ອນທີ່ຈະນໍາໃຊ້ຂໍ້ມູນປະຈໍາຕົວຈະໄດ້ຮັບຈາກ s3, ແລະຖ້າບໍ່ພົບຂໍ້ມູນປະຈໍາຕົວ, ຂໍ້ມູນປະຈໍາຕົວໃຫມ່ຈະຖືກສ້າງຂຶ້ນ. ເກັບໄວ້ໃນ s3.

ຫຼັງຈາກນັ້ນ, ຂໍ້ມູນປະຈໍາຕົວເຫຼົ່ານີ້ຈະຖືກສົ່ງຜ່ານເປັນພາລາມິເຕີໄປຫາຄໍາສັ່ງສ້າງ - ການປ່ຽນແປງ - ຊຸດ cloudformation. ໃນຂະນະທີ່ການທົດລອງກັບສະຄິບ, ມັນເກີດຂຶ້ນວ່າການເຊື່ອມຕໍ່ກັບ s3 ໄດ້ສູນເສຍໄປ, ແລະ "ກົນໄກທີ່ສະຫລາດ" ຂອງຂ້ອຍໄດ້ປະຕິບັດມັນເປັນສັນຍານທີ່ຈະສ້າງຂໍ້ມູນປະຈໍາຕົວໃຫມ່.

ຖ້າຂ້ອຍເລີ່ມໃຊ້ script ນີ້ໃນການຜະລິດແລະບັນຫາການເຊື່ອມຕໍ່ເກີດຂຶ້ນອີກເທື່ອຫນຶ່ງ, ມັນຈະປັບປຸງ stack ດ້ວຍຂໍ້ມູນປະຈໍາຕົວໃຫມ່. ໃນກໍລະນີນີ້, ບໍ່ມີຫຍັງທີ່ບໍ່ດີຈະເກີດຂຶ້ນ. ຢ່າງໃດກໍຕາມ, ຂ້າພະເຈົ້າໄດ້ປະຖິ້ມວິທີການນີ້ແລະເລີ່ມຕົ້ນໃຊ້ອີກອັນຫນຶ່ງ, ສະຫນອງຂໍ້ມູນປະຈໍາພຽງແຕ່ຄັ້ງດຽວ - ເມື່ອສ້າງ stack. ແລະຕໍ່ມາ, ເມື່ອ stack ຕ້ອງການການປັບປຸງ, ແທນທີ່ຈະລະບຸຄ່າລັບຂອງພາລາມິເຕີ, ຂ້ອຍພຽງແຕ່ໃຊ້ 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: ໃຊ້ການກຳນົດຄ່າ rollback

ທີມງານອື່ນທີ່ຂ້ອຍເຮັດວຽກກັບໃຊ້ຫນ້າທີ່ ຂໍ້ມູນຂ່າວສານຟັງ, ເອີ້ນວ່າ ການຕັ້ງຄ່າ rollback. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ໄດ້​ພົບ​ເຫັນ​ມັນ​ມາ​ກ່ອນ​ແລະ​ຢ່າງ​ວ່ອງ​ໄວ​ໄດ້​ຮັບ​ຮູ້​ວ່າ​ມັນ​ຈະ​ເຮັດ​ໃຫ້​ການ​ນໍາ​ໃຊ້ stacks ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ເຖິງ​ແມ່ນ​ເຢັນ. ຕອນນີ້ຂ້ອຍໃຊ້ມັນທຸກຄັ້ງທີ່ຂ້ອຍໃຊ້ລະຫັດຂອງຂ້ອຍໃສ່ lambda ຫຼື ECS ໂດຍໃຊ້ cloudformation.

ມັນເຮັດວຽກແນວໃດ: ທ່ານລະບຸ ຟັງຊັນປຸກ CloudWatch ໃນພາລາມິເຕີ --rollback-configurationເມື່ອທ່ານສ້າງຊຸດການປ່ຽນແປງ. ຕໍ່ມາ, ເມື່ອທ່ານປະຕິບັດຊຸດຂອງການປ່ຽນແປງ, Aws ຕິດຕາມສັນຍານເຕືອນຢ່າງຫນ້ອຍຫນຶ່ງນາທີ. ມັນ​ຈະ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ການ​ນໍາ​ໃຊ້​ຖ້າ​ຫາກ​ວ່າ​ປຸກ​ປ່ຽນ​ສະ​ຖາ​ນະ​ເປັນ ALARM ໃນ​ລະ​ຫວ່າງ​ເວ​ລາ​ນີ້.

ຂ້າງລຸ່ມນີ້ແມ່ນຕົວຢ່າງຂອງແມ່ແບບ excerpt ຂໍ້ມູນຂ່າວສານຟັງໃນ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ສ້າງ​ ໂມງປຸກ cloudwatch, ເຊິ່ງຕິດຕາມ metric ຜູ້ໃຊ້ຄລາວເປັນຈໍານວນຄວາມຜິດພາດໃນບັນທຶກຂອງຄລາວ (metric ແມ່ນສ້າງຜ່ານ 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

ໃນປັດຈຸບັນ ປຸກ ສາມາດໃຊ້ເປັນ rollback ກະຕຸ້ນໃນເວລາທີ່ປະຕິບັດກ່ອງເຄື່ອງມື:

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 ແລະນໍາໃຊ້ stack ຮຸ່ນທີ່ຜ່ານມາໂດຍບໍ່ຮູ້ຕົວ. ອັນນີ້ເຮັດໃຫ້ການຢຸດເຮັດວຽກຂອງແອັບພລິເຄຊັນທີ່ໃຊ້ stack ນີ້.

ບາງສິ່ງບາງຢ່າງທີ່ງ່າຍດາຍຄືການເພີ່ມການກວດສອບເພື່ອເບິ່ງວ່າສາຂາແມ່ນທັນສະໄຫມກ່ອນທີ່ຈະດໍາເນີນການກັບມັນຈະດີ (ສົມມຸດວ່າ 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: ຢ່າປະດິດລໍ້ໃໝ່

ມັນ​ອາດ​ຈະ​ເບິ່ງ​ຄື​ວ່າ​ການ​ປະ​ຕິ​ບັດ​ກັບ​ ຂໍ້ມູນຂ່າວສານຟັງ - ມັນງ່າຍ. ທ່ານພຽງແຕ່ຕ້ອງການສະຄິບ bash ຫຼາຍໆອັນທີ່ປະຕິບັດຄໍາສັ່ງ aws cli.

ເມື່ອ 4 ປີກ່ອນຂ້ອຍເລີ່ມຕົ້ນດ້ວຍ scripts ງ່າຍໆທີ່ເອີ້ນວ່າຄໍາສັ່ງ aw cloudformation create-stack. ບໍ່ດົນ script ແມ່ນບໍ່ງ່າຍດາຍອີກຕໍ່ໄປ. ແຕ່ລະບົດຮຽນທີ່ຖອດຖອນໄດ້ເຮັດໃຫ້ script ມີຄວາມຊັບຊ້ອນຫຼາຍຂຶ້ນ. ມັນບໍ່ພຽງແຕ່ມີຄວາມຫຍຸ້ງຍາກ, ແຕ່ຍັງເຕັມໄປດ້ວຍແມງໄມ້.

ໃນປັດຈຸບັນຂ້າພະເຈົ້າເຮັດວຽກຢູ່ໃນພະແນກ IT ຂະຫນາດນ້ອຍ. ປະສົບການໄດ້ສະແດງໃຫ້ເຫັນວ່າແຕ່ລະທີມມີວິທີການຂອງຕົນເອງໃນການນໍາໃຊ້ stackformation cloud. ແລະນັ້ນກໍ່ບໍ່ດີ. ມັນຈະດີກວ່າຖ້າທຸກຄົນໃຊ້ວິທີດຽວກັນ. ໂຊກດີ, ມີຫຼາຍເຄື່ອງມືທີ່ມີຢູ່ເພື່ອຊ່ວຍໃຫ້ທ່ານນຳໃຊ້ ແລະກຳນົດຄ່າ stackformation cloud.

ບົດຮຽນເຫຼົ່ານີ້ຈະຊ່ວຍໃຫ້ທ່ານຫຼີກເວັ້ນຄວາມຜິດພາດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com