Ik begon te wurkjen mei wolkfoarming 4 jier lyn. Sûnt dy tiid haw ik in protte ynfrastruktuer ferbrutsen, sels dy't al yn produksje wiene. Mar elke kear as ik wat fernielde, learde ik wat nijs. Troch dizze ûnderfining sil ik guon fan 'e wichtichste lessen diele dy't ik haw leard.
Les 1: Test feroarings foardat se ynsette
Ik learde dizze les koart nei't ik begon te wurkjen mei wolkfoarming. Ik wit net mear wat ik krekt bruts doe, mar ik wit wis dat ik brûkte it kommando aws cloudformation update. Dit kommando rôlet it sjabloan gewoan út sûnder validaasje fan 'e wizigingen dy't sille wurde ynset. Ik tink net dat der in ferklearring nedich is foar wêrom't jo alle wizigingen moatte testen foardat jo se ynsette.
Nei dizze mislearring feroare ik fuortendaliks ynstallaasje pipeline, it ferfangen fan it update kommando mei it kommando meitsje-feroarje-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"
Sadree't in feroaringset is oanmakke, it hat gjin effekt op de besteande stapel. Oars as it fernijingskommando, triggert de feroaringset-oanpak de eigentlike ynset net. Ynstee makket it in list mei wizigingen dy't jo kinne besjen foardat jo ynset wurde. Jo kinne de wizigingen besjen yn 'e aws-konsole-ynterface. Mar as jo leaver alles wat jo kinne automatisearje, kontrolearje se dan yn 'e 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 tableDit kommando moat útfier produsearje lykas it folgjende:
--------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+Jou spesjaal omtinken oan feroarings wêr't Aksje is Ferfange, wiskje of wêr Ferfanging nedich - wier. Dit binne de gefaarlikste feroarings en liede normaal ta ferlies fan ynformaasje.
Sadree't de wizigingen binne hifke, kinne se ynset wurde
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"Les 2: Brûk stackbelied om foar te kommen dat steatlike boarnen wurde ferfongen of fuortsmiten
Soms is it gewoan besjen fan de wizigingen net genôch. Wy binne allegear minsken en wy meitsje allegear flaters. Koart nei't wy feroaringsets begûnen te brûken, die myn teammaat ûnbewust in ynset dy't resultearre yn in database-update. Der barde neat min, om't it in testomjouwing wie.
Alhoewol't ús skripts in list mei wizigingen werjûn en om befêstiging fregen, waard de feroaring Ferfange oerslein, om't de list mei wizigingen sa grut wie dat it net op it skerm paste. En om't dit in normale update wie yn in testomjouwing, waard net folle omtinken jûn oan de feroarings.
D'r binne boarnen dy't jo noait wolle ferfange of ferwiderje. Dit binne statefull tsjinsten, lykas in RDS databank eksimplaar of in elasticsearch kluster, ensfh It soe moai wêze as aws soe automatysk wegerje ynset as de operaasje wurdt útfierd soe fereaskje wiskjen sa'n boarne. Gelokkich hat wolkfoarming in ynboude manier om dit te dwaan. Dit hjit stack belied, en do kinst lêze mear oer it yn :
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"Les 3: Brûk UsePreviousValue by it bywurkjen fan in stapel mei geheime parameters
As jo in RDS mysql-entiteit oanmeitsje, fereasket AWS dat jo in MasterUsername en MasterUserPassword leverje. Om't it better is om geheimen net yn 'e boarnekoade te hâlden en ik absolút alles automatisearje woe, haw ik in "tûke meganisme" ymplementearre wêr't foardat de ynset de bewiisbrieven wurde krigen fan s3, en as de bewiisbrieven net fûn wurde, wurde nije bewiisbrieven generearre en opslein yn s3.
Dizze referinsjes sille dan wurde trochjûn as parameters nei it cloudformation create-change-set kommando. By it eksperimintearjen mei it skript barde it dat de ferbining mei s3 ferlern gie, en myn "tûke meganisme" behannele it as in sinjaal om nije bewiisbrieven te generearjen.
As ik dit skript begon te brûken yn produksje en it ferbiningsprobleem barde wer, soe it de stapel bywurkje mei nije bewiisbrieven. Yn dit bysûndere gefal sil neat slim barre. Ik haw dizze oanpak lykwols ferlitten en begon in oare te brûken, mar ien kear referinsjes levere - by it meitsjen fan de stapel. En letter, as de stapel bywurke moat, ynstee fan de geheime wearde fan 'e parameter op te jaan, soe ik gewoan brûke UsePreviousValue=wier:
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"Les 4: Brûk rollback konfiguraasje
In oar team wêrmei ik wurke brûkte de funksje wolkfoarming, neamd rollback konfiguraasje. Ik wie it noch net earder tsjinkommen en realisearre gau dat it it ynsetten fan myn stapels noch koeler soe meitsje. No brûk ik it elke kear as ik myn koade ynsette nei lambda as ECS mei help fan cloudformation.
Hoe't it wurket: jo spesifisearje CloudWatch alarm arn v parameter --rollback-konfiguraasjeas jo in feroaringset meitsje. Letter, as jo in set wizigingen útfiere, kontrolearret aws it alarm op syn minst ien minút. It rôlet de ynset werom as it alarm yn dizze tiid de steat feroaret nei ALARM.
Hjirûnder is in foarbyld fan in sjabloan úttreksel wolkfoarmingdêr't ik skeppe wolkwatch alarm, dy't in wolk brûkersmetrik folget as it oantal flaters yn 'e wolklogboeken (de metrik wurdt generearre fia 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: yesNo alarm kin brûkt wurde as rollback trigger by it útfieren fan toolbox:
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"Les 5: Soargje derfoar dat jo de lêste ferzje fan it sjabloan ynsette
It is maklik om in minder-as-lêste ferzje fan it cloudformaasje-sjabloan yn te setten, mar it dwaan sil in soad skea feroarsaakje. Dit barde ús ienris: in ûntwikkelder hat de lêste feroarings net fan Git triuwd en ûnbewust in eardere ferzje fan 'e stack ynset. Dit resultearre yn downtime foar de applikaasje dy't dizze stapel brûkte.
Iets sa ienfâldich as it tafoegjen fan in sjek om te sjen oft de tûke aktueel is foardat jo derop ynsette soe goed wêze (oannommen dat git jo ferzjekontrôleark is):
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
files 6: Net opnij útfine it tsjil
It kin lykje as ynset mei wolkfoarming - it is maklik. Jo hawwe gewoan in bosk bash-skripts nedich dy't aws cli-kommando's útfiere.
4 jier lyn begon ik mei ienfâldige skripts neamd de aws cloudformation create-stack kommando. Al gau wie it skript net mear ienfâldich. Elke learde les makke it skript hieltyd komplekser. It wie net allinnich dreech, mar ek fol bugs.
Ik wurkje op it stuit yn in lytse IT-ôfdieling. Underfining hat sjen litten dat elk team syn eigen manier hat om wolkformaasjestacks yn te setten. En dat is slim. It soe better wêze as elkenien deselde oanpak naam. Gelokkich binne d'r in protte ark beskikber om jo te helpen ynsette en konfigurearje wolkformaasjestapels.
Dizze lessen sille jo helpe om flaters te foarkommen.
Boarne: www.habr.com