Alustasin koostööd pilve moodustumine 4 aastat tagasi. Sellest ajast alates olen lõhkunud palju infrastruktuure, isegi neid, mis olid juba tootmises. Aga iga kord, kui ma midagi sassi ajasin, õppisin midagi uut. Selle kogemuse kaudu jagan mõnda kõige olulisemat õppetundi, mille sain.
1. õppetund: testige muudatusi enne nende juurutamist
Õppisin selle õppetunni varsti pärast sellega töötamist pilve moodustumine. Ma ei mäleta, mida ma siis täpselt murdsin, aga kindlasti mäletan, et kasutasin käsku awsi pilvevormingu värskendus. See käsk lihtsalt käivitab malli ilma juurutatavate muudatuste kinnitamiseta. Ma arvan, et pole vaja selgitusi, miks peaksite kõiki muudatusi enne nende juurutamist testima.
Pärast seda ebaõnnestumist muutusin kohe kasutuselevõtuga torujuhe, asendades värskenduse käsu käsuga loo-muuda-komplekt
# 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 muudatuste komplekt on loodud, ei mõjuta see olemasolevat pinu. Erinevalt värskenduse käsust ei käivita muudatuste komplekt tegelikku juurutamist. Selle asemel loob see loendi muudatustest, mille saate enne juurutamist üle vaadata. Muudatusi saate vaadata awsi konsooli liideses. Kuid kui eelistate automatiseerida kõike, mida saate, 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 tableSee käsk peaks andma järgmisega sarnase väljundi:
--------------------------------------------------------------------
| 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 muutustele, kus on Action asendama, kustutama või kus ReplacementNeeded – tõsi. Need on kõige ohtlikumad muutused ja põhjustavad tavaliselt teabe kadu.
Kui muudatused on üle vaadatud, saab need kasutusele võtta
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. õppetund. Kasutage virnapoliitikat, et vältida olekupõhiste ressursside asendamist või eemaldamist
Mõnikord ei piisa lihtsalt muudatuste vaatamisest. Me kõik oleme inimesed ja me kõik teeme vigu. Vahetult pärast seda, kui hakkasime muudatuskomplekte kasutama, tegi mu meeskonnakaaslane teadmatult juurutuse, mille tulemuseks oli andmebaasi värskendus. Midagi hullu ei juhtunud, sest tegemist oli testimiskeskkonnaga.
Kuigi meie skriptid kuvasid muudatuste loendit ja küsisid kinnitust, jäeti muudatus Asenda vahele, kuna muudatuste loend oli nii suur, et see ei mahtunud ekraanile. Ja kuna tegemist oli tavalise uuendusega testimiskeskkonnas, siis muudatustele ei pööratud suurt tähelepanu.
On ressursse, mida te ei soovi kunagi asendada ega eemaldada. Need on olekutäielikud teenused, nagu RDS-i andmebaasi eksemplar või elasticsearchi klaster jne. Oleks tore, kui aws keelduks automaatselt juurutamisest, kui teostatav toiming nõuaks sellise ressursi kustutamist. Õnneks on pilvekujundusel selleks sisseehitatud viis. Seda nimetatakse virnapoliitikaks ja selle kohta saate lisateavet lugeda :
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. õppetund: salajaste parameetritega virna värskendamisel kasutage UsePreviousValue'i
RDS-i mysql-üksuse loomisel nõuab AWS, et sisestaksite MasterUsername ja MasterUserPassword. Kuna lähtekoodis on parem mitte saladusi hoida ja ma tahtsin absoluutselt kõike automatiseerida, siis rakendasin "targa mehhanismi", kus enne juurutamist hangitakse mandaadid s3-st ja kui mandaate ei leita, genereeritakse uued mandaadid ja salvestatud s3-sse.
Need mandaadid edastatakse seejärel parameetritena pilvekujundamise käsule Create-change-set. Skriptiga katsetades juhtus, et ühendus s3-ga katkes ja minu “tark mehhanism” käsitles seda kui signaali uute mandaatide genereerimiseks.
Kui hakkaksin seda skripti tootmises kasutama ja ühenduse probleem korduks, värskendaks see virna uute mandaatidega. Sel konkreetsel juhul ei juhtu midagi hullu. Siiski loobusin sellest lähenemisviisist ja hakkasin kasutama teist, andes mandaadi ainult üks kord - virna loomisel. Ja hiljem, kui pinu vajab värskendamist, kasutaksin parameetri salajase väärtuse määramise asemel 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"4. õppetund: kasutage tagasipööramise konfiguratsiooni
Teine meeskond, kellega ma töötasin, kasutas seda funktsiooni pilve moodustuminehelistas tagasipööramise konfiguratsioon. Ma polnud sellega varem kokku puutunud ja mõistsin kiiresti, et see muudaks mu virnade juurutamise veelgi lahedamaks. Nüüd kasutan seda iga kord, kui juurutan oma koodi lambda- või ECS-i pilvevormingu abil.
Kuidas see töötab: täpsustate CloudWatchi äratus parameetris -- tagasipööramise konfiguratsioonkui loote muudatuste komplekti. Hiljem, kui teete muudatuste komplekti, jälgib aws häiret vähemalt ühe minuti. Kui häire muudab selle aja jooksul oleku ALARM, võtab see kasutuselevõtu tagasi.
Allpool on näide malli väljavõttest pilve moodustuminemilles ma loon pilvekella äratus, mis jälgib pilvekasutaja mõõdikut pilvelogide vigade arvuna (mõõdik genereeritakse 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üüd alarm saab kasutada kui tagasipööramist päästik tööriistakasti käivitamisel:
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. õppetund: juurutage kindlasti malli uusim versioon
Pilvekujundamise malli vähem kui uusima versiooni juurutamine on lihtne, kuid see põhjustab palju kahju. See juhtus meiega üks kord: arendaja ei surunud Giti uusimaid muudatusi ja võttis teadmatult kasutusele virna eelmise versiooni. See põhjustas seda virna kasutanud rakenduse seisakuid.
Midagi nii lihtsat nagu kontrolli lisamine, et näha, kas haru on ajakohane, enne kui sellega pühenduda, oleks hea (eeldusel, et git on teie versioonihaldustööriist):
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
fi6. õppetund: ärge leiutage jalgratast uuesti
See võib tunduda nagu koos kasutuselevõtt pilve moodustumine - see on lihtne. Teil on vaja lihtsalt hunnikut bash-skripte, mis täidavad aws cli käske.
4 aastat tagasi alustasin lihtsate skriptidega, mida kutsuti käsuks aws cloudformation create-stack. Varsti polnud stsenaarium enam lihtne. Iga saadud õppetund muutis stsenaariumi järjest keerulisemaks. See polnud mitte ainult raske, vaid ka vigu täis.
Hetkel töötan väikeses IT osakonnas. Kogemused on näidanud, et igal meeskonnal on oma viis pilvekujundamise virnade juurutamiseks. Ja see on halb. Parem oleks, kui kõik võtaksid sama lähenemisviisi. Õnneks on saadaval palju tööriistu, mis aitavad teil pilvevormingu virnasid juurutada ja konfigureerida.
Need õppetunnid aitavad teil vigu vältida.
Allikas: www.habr.com