Ég byrjaði að vinna með skýjamyndun fyrir 4 árum. Síðan þá hef ég brotið marga innviði, jafnvel þá sem voru þegar í framleiðslu. En í hvert skipti sem ég klúðraði einhverju lærði ég eitthvað nýtt. Í gegnum þessa reynslu mun ég deila nokkrum af mikilvægustu lexíunum sem ég lærði.
Lexía 1: Prófaðu breytingar áður en þær eru notaðar
Ég lærði þessa lexíu fljótlega eftir að ég byrjaði að vinna með skýjamyndun. Ég man ekki hvað ég braut nákvæmlega þá, en ég man örugglega að ég notaði skipunina aws cloudformation uppfærsla. Þessi skipun rúllar einfaldlega út sniðmátið án nokkurrar staðfestingar á breytingunum sem verða settar í notkun. Ég held að það þurfi enga skýringu á því hvers vegna þú ættir að prófa allar breytingar áður en þú setur þær í notkun.
Eftir þessa bilun breyttist ég strax dreifing leiðsla, skipta uppfærsluskipuninni út fyrir skipunina búa til-breyta-sett
# 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"
Þegar breytingasett er búið til hefur það engin áhrif á núverandi stafla. Ólíkt uppfærsluskipuninni kveikir breytingaaðferðin ekki raunverulega uppsetningu. Þess í stað býr það til lista yfir breytingar sem þú getur skoðað fyrir uppsetningu. Þú getur skoðað breytingarnar í viðmóti aws stjórnborðsins. En ef þú vilt frekar gera allt sem þú getur sjálfvirkt, athugaðu þá í 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Þessi skipun ætti að framleiða úttak svipað og eftirfarandi:
--------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+Gefðu sérstaka athygli á breytingum þar sem Action er Skipta, eyða eða hvar Skipta þarf - satt. Þetta eru hættulegustu breytingarnar og leiða venjulega til taps upplýsinga.
Þegar breytingarnar hafa verið skoðaðar er hægt að nota þær
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"Lexía 2: Notaðu staflastefnu til að koma í veg fyrir að staðbundin auðlind sé skipt út eða fjarlægð
Stundum er ekki nóg að skoða breytingarnar. Við erum öll mannleg og gerum öll mistök. Stuttu eftir að við byrjuðum að nota breytingarsett framkvæmdi liðsfélagi minn óafvitandi dreifingu sem leiddi til uppfærslu gagnagrunns. Ekkert slæmt gerðist vegna þess að þetta var prófunarumhverfi.
Jafnvel þó að forskriftirnar okkar sýndu lista yfir breytingar og beðið var um staðfestingu var Skipta út breytingunni sleppt vegna þess að listinn yfir breytingar var svo stór að hann passaði ekki á skjáinn. Og þar sem þetta var eðlileg uppfærsla í prófunarumhverfi var ekki mikið horft til breytinganna.
Það eru til úrræði sem þú vilt aldrei skipta út eða fjarlægja. Þetta eru fullkomnar þjónustur, eins og RDS gagnagrunnstilvik eða elasticsearch þyrping, osfrv. Það væri gaman ef aws myndi sjálfkrafa neita dreifingu ef aðgerðin sem er framkvæmd myndi krefjast þess að eyða slíkri auðlind. Sem betur fer hefur skýjamyndun innbyggða leið til að gera þetta. Þetta er kallað staflastefna og þú getur lesið meira um það í :
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"Lexía 3: Notaðu UsePreviousValue þegar þú uppfærir stafla með leynilegum breytum
Þegar þú býrð til RDS mysql einingu, krefst AWS að þú gefir upp MasterUsername og MasterUserPassword. Þar sem það er betra að geyma ekki leyndarmál í frumkóðann og ég vildi gera algjörlega allt sjálfvirkan, þá innleiddi ég "snjallmekanisma" þar sem skilríkin verða fengin frá s3 fyrir dreifingu, og ef skilríkin finnast ekki, eru ný skilríki búin til og geymt í s3.
Þessar persónuskilríki verða síðan sendar sem færibreytur í skýjamyndun create-change-set skipunina. Þegar ég var að gera tilraunir með handritið gerðist það að tengingin við s3 rofnaði og „snjallbúnaðurinn“ minn meðhöndlaði það sem merki um að búa til ný skilríki.
Ef ég byrjaði að nota þetta handrit í framleiðslu og tengingarvandamálið gerðist aftur, myndi það uppfæra staflann með nýjum skilríkjum. Í þessu tiltekna tilviki mun ekkert slæmt gerast. Hins vegar yfirgaf ég þessa nálgun og byrjaði að nota aðra og gaf aðeins upp skilríki einu sinni - þegar ég bjó til stafla. Og síðar, þegar staflan þarf að uppfæra, í stað þess að tilgreina leynilegt gildi færibreytunnar, myndi ég einfaldlega nota 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"Lexía 4: Notaðu stillingar fyrir afturköllun
Annað teymi sem ég vann með notaði aðgerðina skýjamyndun, kallaður stillingar til baka. Ég hafði ekki rekist á það áður og áttaði mig fljótt á því að það myndi gera uppsetningu stafla minn enn svalari. Nú nota ég það í hvert skipti sem ég sendi kóðann minn á lambda eða ECS með því að nota skýjamyndun.
Hvernig það virkar: þú tilgreinir CloudWatch viðvörun í færibreytu --rollback-stillingarþegar þú býrð til breytingarsett. Síðar, þegar þú framkvæmir sett af breytingum, fylgist aws með viðvöruninni í að minnsta kosti eina mínútu. Það afturkallar dreifinguna ef viðvörun breytir stöðu í ALARM á þessum tíma.
Hér að neðan er dæmi um sniðmátsútdrátt skýjamyndunsem ég skapa skýjaúr viðvörun, sem rekur skýnotendamælingu sem fjölda villna í skýjaskránum (mælingin er mynduð með 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: yesNú viðvörun hægt að nota sem rollback kveikja þegar verkfærakistan er keyrð:
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"Lexía 5: Gakktu úr skugga um að þú dreifir nýjustu útgáfunni af sniðmátinu
Það er auðvelt að nota minna en nýjustu útgáfu af skýjasniðmátinu, en það mun valda miklum skaða. Þetta gerðist einu sinni fyrir okkur: þróunaraðili ýtti ekki á nýjustu breytingunum frá Git og setti óafvitandi upp fyrri útgáfu af staflanum. Þetta leiddi til niðurtíma fyrir forritið sem notaði þennan stafla.
Eitthvað eins einfalt og að bæta við ávísun til að sjá hvort útibúið sé uppfært áður en þú skuldbindur þig til þess væri í lagi (að því gefnu að git sé útgáfustýringartólið þitt):
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
fiLexía 6: Ekki finna upp hjólið aftur
Það kann að virðast eins og að dreifa með skýjamyndun - það er auðvelt. Þú þarft bara fullt af bash forskriftum sem framkvæma aws cli skipanir.
Fyrir 4 árum byrjaði ég á einföldum skriftum sem kallast aws cloudformation create-stack skipunin. Fljótlega var handritið ekki lengur einfalt. Hver lærdómur gerði handritið sífellt flóknara. Það var ekki bara erfitt heldur líka fullt af pöddum.
Ég vinn núna í lítilli upplýsingatæknideild. Reynslan hefur sýnt að hvert lið hefur sína eigin leið til að dreifa skýjamyndunarstafla. Og það er slæmt. Betra væri að allir tækju sömu leið. Sem betur fer eru mörg verkfæri í boði til að hjálpa þér að dreifa og stilla skýjamyndunarstafla.
Þessar kennslustundir munu hjálpa þér að forðast mistök.
Heimild: www.habr.com