Need 6 õppetundi cloudformation'i kasutamisest jäävad mulle Igaveseks meelde.

Alustasin tööd cloudformation 4 aastat tagasi. Sellest ajast saiya murdnud palju infrastruktuure, sealhulgas neid, mis olid juba tootmises. Kuid iga kord, kui ma midagi rikkusin, õppisin uut. Selle kogemuse põhjal jagan mõningaid kõige olulisemaid õppetunde, mida olen õppinud.

Õppetund 1: kontrollige muudatusi enne nende rakendamist

Ma õppisin seda õppetundi üsna varsti pärast seda, kui alustasin tööd cloudformation. Ei mäleta täpselt, mida ma siis rikkusin, kuid mäletan, et kasutasin käsku aws cloudformation update. See käsk lihtsalt rakendab mallid ilma ühtegi muudatust eelnevalt kontrollimata, mis rakendatakse. Ma ei arva, et selgitusi oleks vaja, miks on oluline kõik muudatused enne nende rakendamist kontrollida.

Pärast seda ebaõnnestumist muutsin ma kohe deploymendi toru, asendades käsu update käsuga create-change-set

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

Kui muudatusete kogum on loodud, ei mõjuta see olemasolevat steeki. Erinevalt käskust update ei põhjusta muudatusete kogumi kasutamine tegelikku rakendamist. Selle asemel loob see muudatused, mida saate vaadata enne rakendamist. Saate muudatusi vaadata aws konsoolis. Kuid kui eelistate automatiseerida kõike, mis võimalik, kontrollige neid CLI-s:

# 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

See käsk peaks andma väljundi, mis sarnaneb järgmisega:

--------------------------------------------------------------------
|                         DescribeChangeSet                        |
+---------+--------------------+----------------------+------------+
| Action  | ReplacementNeeded  |      Resource        | ResourceId |
+---------+--------------------+----------------------+------------+
|  Modify | True               |  AWS::ECS::Cluster   |  MyCluster |
|  Replace| True               |  AWS::RDS::DBInstance|  MyDB      |
|  Add    | None               |  AWS::SNS::Topic     |  MyTopic   |
+---------+--------------------+----------------------+------------+

Pöörake erilist tähelepanu muudatustele, kus Action on Replace, Kustutage või kus ReplacementNeeded — True. Need on kõige ohtlikumad muudatused, mis tavaliselt toovad kaasa andmete kaotuse.

Kui muudatused on läbi vaadatud, saab neid rakendada

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"

Õppetund 2: kasutage steeki poliitikat, et vältida ressursside asendamist või kustutamist oleku säilitamisega

Mõnikord ei piisa lihtsalt muudatuste vaatamisest. Me kõik oleme inimesed ja teeme vigu. Peagi pärast seda, kui hakkasime kasutama muudatusetappe, tegi mu meeskonnakaaslane tahtmatult juurutuse, mis viis andmebaasi uuendamiseni. Midagi kohutavat ei juhtunud, sest see oli testimiskeskkond.

Kuigi meie skriptid näitasid muudatuste loendit ja küsisid kinnitust, jäi muutmine asendada tähelepanuta, sest muudatuste loetelu oli nii suur, et see ei mahtunud ekraanile. Ja kuna see oli tavaline uuendus testimiskeskkonnas, ei pööratud muutustele nii suurt tähelepanu.

On ressursse, mida te kunagi ei sooviks asendada ega kustutada. Need on olekuga teenused, nagu RDS andmebaasi eksemplar või elastichsearch klaster jne. Oleks hea, kui AWS keeldub automaatselt juurutamast, kui teostatav toiming nõuab sellise ressursi kustutamist. Õnneks on CloudFormationil selleks sisseehitatud meetod. Seda nimetatakse stack policy'ks ja sellest saab rohkem teada. dokumentatsioon:

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"

Õppetund 3: kasutage UsePreviousValue, kui värskendate steki saladuslike parameetritega

Kui loote RDS mysql üksuse, nõuab AWS, et te esitaksite MasterUsername ja MasterUserPassword. Kuna parem ei ole hoida saladusi lähtekoodis ja ma tahtsin automatiseerida absoluutselt kõik, rakendasin "nutikat mehhanismi", mille korral enne juurutamist saadakse sisselogimisandmed S3-st, ja kui andmeid ei leita, genereeritakse uued ja salvestatakse S3-sse.

Seejärel edastatakse need sisselogimisandmed parameetritena käsule cloudformation create-change-set. Skripti katsetuste ajal juhtus, et ühendus S3-ga katkestati ja minu "nutikas mehhanism" tõlgendas seda signaalina uute sisselogimisandmete genereerimiseks.

Kui ma hakkaksin seda skripti töökeskkonnas kasutama ja ühenduse loomise probleem esineks jälle, uuendaks see kuhja uutega mandaate. Antud juhul ei juhtu midagi halba. Ometi loobusin sellisest lähenemisviisist ja hakkasin kasutama teistsugust, andes mandaate ainult korra — kuhja loomisel. Ja hiljem, kui kuhja tuleb uuendada, kasutaksin ma selle asemel, et määrata parameetri salajast väärtust, lihtsalt 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"

Õppetund 4: kasutage rollback konfiguratsiooni

Teine käsk, millega ma töötasin, kasutas funktsiooni cloudformation, mida nimetatakse rollback konfiguratsioon. Ma polnud selle näinud varem ja taipasin kiiresti, et see muudab minu kuhjade levitamist veelgi paremaks. Nüüd kasutan seda iga kord, kui käitun oma koodi lambda või ECS abil cloudformationi kaudu.

Kuidas see töötab: määrate CloudWatch alarm arn parameetrisse —rollback-configuration, kui loote muudatuste komplekti. Hiljem, kui teete muudatuste komplekti, jälgib aws alarmi vähemalt ühe minuti. See tühistab levitamise tagasi, kui selle aja jooksul alarm muudetakse olekuks ALARM.

Allpool on näide mallilõigust cloudformation, kus ma loon cloudwatch alarm, mis jälgib kohandatud pilve metrikat, milleks on veateated pilve logides (metrika luuakse läbi MetricFilter):

Resources:
  # see metrika jälgib arvu vigu cloudwatch logides. Selles
  # konkreetses juhul eeldatakse, et logid on json formaadis ja vealogid on
  # tuvastatud taseme "error" järgi. Vaata 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 minut
      EvaluationPeriods: 1
      Threshold: 0
      TreatMissingData: notBreaching
      ActionsEnabled: yes

Praegu alarm võib olla kasutatud kui rollback käivitaja muudatuste komplekti täitmisel:

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"

Õppetund 5: veenduge, et te kasutate kõige värskemat malli versiooni

On lihtne juurutada mitte kõige värskemat cloudformation malli versiooni, kuid see võib põhjustada tõsiseid probleeme. Meil juhtus kunagi nii: arendaja ei saatnud viimaseid muudatusi Gitist ja juurutaski alateadlikult varasema versiooni. See tõi kaasa rakenduse seiske, mis kasutas seda virna.

Lihtne kontroll, näiteks kontrollimine, kas haru on ajakohane, enne juurutamise sooritamist, oleks hea mõte (eeldades, et git on teie versioonihaldustööriist):

git fetch
HEADHASH=$(git rev-parse HEAD)
UPSTREAMHASH=$(git rev-parse master@{upstream})

if [[ "$HEADHASH" != "$UPSTREAMHASH" ]] ; then
   echo "Haru ei ole ajakohane originaaliga. Tühistamine"
   exit 1
fi

Õppetund 6: ärge leiutage ratast

Võib tunduda, et juurutamine on cloudformation — see on lihtne. Teil on lihtsalt vaja rida bash skripte, mis täidavad aws cli käsklusi.

Neli aastat tagasi alustasin ma lihtsate skriptidega, mis kasutasid käsku aws cloudformation create-stack. Varsti ei olnud skripti enam lihtne. Iga õpitud õppetund muudab skripti üha keerulisemaks. See ei olnud mitte ainult keeruline, vaid ka täis vigu.

Praegu töötan ma väikeses IT-osakonnas. Kogemus näitab, et igal meeskonnal on oma viis cloudformation virnade juurutamiseks. Ja see on halb. Oleks parem, kui kõik kasutaksid ühtset lähenemist. Õnneks on palju tööriistu, mis aitavad juurutada ja seadistada cloudformation virnu.

Need õppetunnid aitavad teil vältida vigu.

Allikas: habr.com