Ես սովորեցի այս 6 դասերը՝ աշխատելու cloudformation-ի հետ ամբողջ կյանքում:

Ես սկսեցի աշխատել ամպի ձևավորում 4 տարի առաջ. Այդ ժամանակվանից ես կոտրել եմ բազմաթիվ ենթակառուցվածքներ, նույնիսկ նրանք, որոնք արդեն արտադրվում էին: Բայց ամեն անգամ, երբ ինչ-որ բան խառնում էի, նոր բան էի սովորում: Այս փորձառության միջոցով ես կկիսվեմ իմ սովորած ամենակարևոր դասերից:

Դաս 1. Ստուգեք փոփոխությունները նախքան դրանք տեղակայելը

Ես այս դասը սովորեցի անմիջապես այն բանից հետո, երբ սկսեցի աշխատել ամպի ձևավորում. Ես չեմ հիշում, թե կոնկրետ ինչ եմ կոտրել այն ժամանակ, բայց հաստատ հիշում եմ, որ օգտագործել եմ հրամանը aws cloudformation-ի թարմացում. Այս հրամանը պարզապես դուրս է հանում ձևանմուշը՝ առանց կիրառվող փոփոխությունների վավերացման: Չեմ կարծում, որ որևէ բացատրություն պետք է, թե ինչու պետք է փորձարկեք բոլոր փոփոխությունները նախքան դրանք տեղակայելը:

Այս անհաջողությունից հետո ես անմիջապես փոխվեցի տեղակայման խողովակաշար, փոխարինելով թարմացման հրամանը հրամանով ստեղծել-փոխել-սահմանել

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

Փոփոխությունների հավաքածու ստեղծելուց հետո այն ոչ մի ազդեցություն չի թողնում գոյություն ունեցող կույտի վրա: Ի տարբերություն թարմացման հրամանի, changeset մոտեցումը չի առաջացնում իրական տեղակայումը: Փոխարենը, այն ստեղծում է փոփոխությունների ցանկ, որը կարող եք վերանայել նախքան տեղակայումը: Դուք կարող եք դիտել փոփոխությունները 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. Օգտագործեք stack-ի քաղաքականությունը՝ կանխելու պետական ​​ռեսուրսների փոխարինումը կամ հեռացումը

Երբեմն պարզապես փոփոխությունները դիտելը բավարար չէ։ Մենք բոլորս մարդ ենք և բոլորս էլ սխալներ ենք անում։ Շուտով այն բանից հետո, երբ մենք սկսեցինք օգտագործել փոփոխությունները, իմ թիմակիցն անգիտակցաբար կատարեց տեղակայում, որը հանգեցրեց տվյալների բազայի թարմացման: Ոչ մի վատ բան տեղի չի ունեցել, քանի որ դա փորձարկման միջավայր էր:

Թեև մեր սկրիպտները ցուցադրում էին փոփոխությունների ցանկ և պահանջում էին հաստատում, Փոխարինել փոփոխությունը բաց է թողնվել, քանի որ փոփոխությունների ցանկն այնքան մեծ էր, որ այն չէր տեղավորվում էկրանին: Եվ քանի որ սա սովորական թարմացում էր թեստավորման միջավայրում, փոփոխություններին մեծ ուշադրություն չդարձվեց։

Կան ռեսուրսներ, որոնք դուք երբեք չեք ցանկանում փոխարինել կամ հեռացնել: Սրանք պետական ​​ծառայություններ են, օրինակ՝ RDS տվյալների բազայի օրինակ կամ elasticsearch կլաստեր և այլն: Լավ կլիներ, եթե aws-ը ավտոմատ կերպով հրաժարվեր տեղակայումից, եթե կատարվող գործողությունը պահանջի ջնջել այդպիսի ռեսուրսը: Բարեբախտաբար, cloudformation-ը դա անելու ներկառուցված միջոց ունի: Սա կոչվում է stack policy, և դուք կարող եք ավելին կարդալ դրա մասին այստեղ փաստաթղթավորում:

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 create-change-set հրամանին: Սցենարը փորձարկելիս պատահեց, որ կապը 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. Օգտագործեք հետադարձ կոնֆիգուրացիա

Մեկ այլ թիմ, որի հետ ես աշխատել եմ, օգտագործել է գործառույթը ամպի ձևավորում, կանչեց հետադարձ կոնֆիգուրացիա. Ես նախկինում չէի հանդիպել դրան և արագ հասկացա, որ դա կդարձնի իմ կույտերի տեղակայումը ավելի սառը: Այժմ ես օգտագործում եմ այն ​​ամեն անգամ, երբ իմ կոդը տեղադրում եմ lambda կամ ECS՝ օգտագործելով cloudformation:

Ինչպես է այն աշխատում: Դուք նշեք CloudWatch ահազանգ պարամետրով - վերադարձ-կոնֆիգուրացիաերբ դուք ստեղծում եք փոփոխություններ: Ավելի ուշ, երբ դուք կատարում եք մի շարք փոփոխություններ, aws-ը վերահսկում է ահազանգը առնվազն մեկ րոպե: Այն հետ է գլորում տեղակայումը, եթե այս ընթացքում ահազանգի վիճակը փոխվի ALARM-ի:

Ստորև բերված է կաղապարի քաղվածքի օրինակ ամպի ձևավորումորում ես ստեղծագործում եմ cloudwatch ահազանգ, որը հետևում է ամպային օգտագործողի չափմանը որպես ամպի մատյաններում սխալների քանակի (չափանիշը ստեղծվում է միջոցով 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. Համոզվեք, որ տեղադրում եք կաղապարի վերջին տարբերակը

Հեշտ է տեղադրել ամպային ձևավորման ձևանմուշի ոչ վերջին տարբերակը, բայց դա մեծ վնաս կհասցնի: Սա մեզ հետ մեկ անգամ պատահեց. ծրագրավորողը չհրապարակեց Git-ի վերջին փոփոխությունները և անգիտակցաբար տեղադրեց 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 տարի առաջ ես սկսեցի պարզ սցենարներով, որոնք կոչվում են aws cloudformation create-stack հրաման: Շուտով սցենարն այլևս պարզ չէր։ Սովորած յուրաքանչյուր դաս ավելի ու ավելի բարդ էր դարձնում սցենարը: Դա ոչ միայն դժվար էր, այլեւ լի վրիպակներով։

Ներկայումս աշխատում եմ փոքր ՏՏ բաժնում։ Փորձը ցույց է տվել, որ յուրաքանչյուր թիմ ունի ամպի ձևավորման կույտերի տեղակայման իր ձևը: Եվ դա վատ է: Լավ կլիներ, որ բոլորը նույն մոտեցումն ունենային։ Բարեբախտաբար, կան բազմաթիվ գործիքներ, որոնք կօգնեն ձեզ տեղակայել և կարգավորել ամպային ձևավորման կույտերը:

Այս դասերը կօգնեն ձեզ խուսափել սխալներից։

Source: www.habr.com