Fillova të punoj me formimi i reve 4 vjet me pare. Që atëherë kam thyer shumë infrastruktura, madje edhe ato që ishin tashmë në prodhim. Por sa herë që ngatërroja diçka, mësova diçka të re. Përmes kësaj përvoje, unë do të ndaj disa nga mësimet më të rëndësishme që kam mësuar.
Mësimi 1: Testoni ndryshimet përpara se t'i vendosni ato
E mësova këtë mësim menjëherë pasi fillova të punoja me formimi i reve. Nuk e mbaj mend se çfarë saktësisht kam thyer atëherë, por patjetër që mbaj mend që kam përdorur komandën Përditësimi i aws cloudformation. Kjo komandë thjesht nxjerr shabllonin pa ndonjë vërtetim të ndryshimeve që do të vendosen. Nuk mendoj se nevojitet ndonjë shpjegim se pse duhet të testoni të gjitha ndryshimet përpara se t'i vendosni ato.
Pas këtij dështimi, menjëherë ndryshova tubacionin e vendosjes, duke zëvendësuar komandën e përditësimit me komandën krijoj-ndryshoj-vendos
# 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"
Pasi të krijohet një grup ndryshimesh, ai nuk ka asnjë efekt në pirgun ekzistues. Ndryshe nga komanda e përditësimit, qasja e ndryshimeve nuk shkakton vendosjen aktuale. Në vend të kësaj, krijon një listë ndryshimesh që mund t'i rishikoni përpara vendosjes. Ju mund të shikoni ndryshimet në ndërfaqen e konsolës aws. Por nëse preferoni të automatizoni gjithçka që mundeni, atëherë kontrolloni ato në 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 tableKjo komandë duhet të prodhojë dalje të ngjashme me sa vijon:
--------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+Kushtojini vëmendje të veçantë ndryshimeve ku është Veprimi Zëvendësoj, Fshij ose ku Nevojitet zëvendësim - E vërtetë. Këto janë ndryshimet më të rrezikshme dhe zakonisht çojnë në humbje të informacionit.
Pasi të jenë shqyrtuar ndryshimet, ato mund të vendosen
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"Mësimi 2: Përdorni politikën e stivës për të parandaluar zëvendësimin ose heqjen e burimeve shtetërore
Ndonjëherë thjesht shikimi i ndryshimeve nuk mjafton. Të gjithë jemi njerëz dhe të gjithë bëjmë gabime. Menjëherë pasi filluam të përdorim grupet e ndryshimeve, shoku im i skuadrës kreu pa e ditur një vendosje që rezultoi në një përditësim të bazës së të dhënave. Asgjë e keqe nuk ndodhi sepse ishte një mjedis testimi.
Edhe pse skriptet tona shfaqnin një listë ndryshimesh dhe kërkuan konfirmim, ndryshimi Replace u anashkalua sepse lista e ndryshimeve ishte aq e madhe sa nuk përshtatej në ekran. Dhe duke qenë se ky ishte një përditësim normal në një mjedis testimi, nuk iu kushtua shumë vëmendje ndryshimeve.
Ka burime që nuk dëshironi t'i zëvendësoni ose hiqni kurrë. Këto janë shërbime të plota, të tilla si një shembull i bazës së të dhënave RDS ose një grup kërkimi elastics, etj. Do të ishte mirë nëse aws do të refuzonte automatikisht vendosjen nëse operacioni që po kryhet do të kërkonte fshirjen e një burimi të tillë. Për fat të mirë, cloudformation ka një mënyrë të integruar për ta bërë këtë. Kjo quhet politika e stivës dhe mund të lexoni më shumë rreth saj në :
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"Mësimi 3: Përdor UsePreviousValue kur përditëson një pirg me parametra sekretë
Kur krijoni një ent RDS mysql, AWS kërkon që ju të jepni një emër përdoruesi Master dhe Fjalëkalim MasterUser. Meqenëse është më mirë të mos mbash sekrete në kodin burimor dhe doja të automatizoja absolutisht gjithçka, zbatova një "mekanizëm inteligjent" ku para vendosjes kredencialet do të merren nga s3, dhe nëse kredencialet nuk gjenden, krijohen kredenciale të reja dhe ruajtur në s3.
Këto kredenciale më pas do t'i kalojnë si parametra komandës cloudformation create-change-set. Gjatë eksperimentimit me skriptin, ndodhi që lidhja me s3 humbi dhe "mekanizmi im i zgjuar" e trajtoi atë si një sinjal për të gjeneruar kredenciale të reja.
Nëse do të filloja ta përdorja këtë skript në prodhim dhe problemi i lidhjes do të ndodhte përsëri, ai do të përditësonte grupin me kredenciale të reja. Në këtë rast të veçantë, asgjë e keqe nuk do të ndodhë. Megjithatë, unë e braktisa këtë qasje dhe fillova të përdor një tjetër, duke siguruar kredencialet vetëm një herë - kur krijova pirgun. Dhe më vonë, kur pirgja ka nevojë për përditësim, në vend që të specifikoj vlerën sekrete të parametrit, unë thjesht do të përdorja UsePreviousValue=e vërtetë:
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"Mësimi 4: Përdorni konfigurimin e rikthimit
Një ekip tjetër me të cilin kam punuar e përdori funksionin formimi i reve, thirri konfigurimi i rikthimit. Nuk e kisha hasur më parë dhe kuptova shpejt se do ta bënte vendosjen e pirgjeve të mia edhe më të freskët. Tani e përdor sa herë që vendos kodin tim në lambda ose ECS duke përdorur cloudformation.
Si funksionon: ju specifikoni Alarmi CloudWatch në parametër ---riktheje-konfigurimkur krijoni një grup ndryshimesh. Më vonë, kur kryeni një sërë ndryshimesh, aws monitoron alarmin për të paktën një minutë. Ai e kthen mbrapsht vendosjen nëse alarmi ndryshon gjendjen në ALARM gjatë kësaj kohe.
Më poshtë është një shembull i një fragmenti shabllon formimi i revenë të cilën unë krijoj alarmi i orës së resë, e cila gjurmon një metrikë të përdoruesit të resë kompjuterike si numrin e gabimeve në regjistrat e resë kompjuterike (metrika krijohet nëpërmjet 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: yesTani alarm mund të përdoret si riktheje aktivizoni gjatë ekzekutimit të kutisë së veglave:
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"Mësimi 5: Sigurohuni që të vendosni versionin më të fundit të shabllonit
Është e lehtë të vendosësh një version më pak se më të fundit të shabllonit të formimit të cloud, por kjo do të shkaktojë shumë dëme. Kjo na ndodhi një herë: një zhvillues nuk i shtyu ndryshimet më të fundit nga Git dhe vendosi pa vetëdije një version të mëparshëm të pirgut. Kjo rezultoi në kohë joproduktive për aplikacionin që përdori këtë pirg.
Diçka aq e thjeshtë sa shtimi i një kontrolli për të parë nëse dega është e përditësuar përpara se të angazhoheni për të do të ishte mirë (duke supozuar se git është mjeti juaj i kontrollit të versionit):
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
fiMësimi 6: Mos e rishpikni rrotën
Mund të duket si vendosje me formimi i reve - është e lehtë. Ju duhet vetëm një grup skriptesh bash që ekzekutojnë komandat aws cli.
4 vjet më parë fillova me skriptet e thjeshta të quajtura komanda aws cloudformation create-stack. Së shpejti skenari nuk ishte më i thjeshtë. Çdo mësim i mësuar e bënte skenarin gjithnjë e më kompleks. Ishte jo vetëm e vështirë, por edhe plot me të meta.
Aktualisht punoj në një departament të vogël IT. Përvoja ka treguar se çdo ekip ka mënyrën e vet të vendosjes së pirgjeve të formimit të cloud. Dhe kjo është e keqe. Do të ishte më mirë nëse të gjithë do të kishin të njëjtën qasje. Për fat të mirë, ka shumë mjete të disponueshme për t'ju ndihmuar të vendosni dhe konfiguroni pirgjet e formimit të cloud.
Këto mësime do t'ju ndihmojnë të shmangni gabimet.
Burimi: www.habr.com