Ek het begin werk met wolkvorming 4 jaar gelede. Sedertdien het ek baie infrastruktuur gebreek, selfs dié wat reeds in produksie was. Maar elke keer as ek iets gemors het, het ek iets nuuts geleer. Deur hierdie ervaring sal ek van die belangrikste lesse wat ek geleer het deel.
Les 1: Toets veranderinge voordat dit ontplooi word
Ek het hierdie les geleer kort nadat ek begin werk het wolkvorming. Ek onthou nie presies wat ek toe gebreek het nie, maar ek onthou beslis dat ek die opdrag gebruik het aws wolkformasie-opdatering. Hierdie opdrag rol eenvoudig die sjabloon uit sonder enige validering van die veranderinge wat ontplooi sal word. Ek dink nie enige verduideliking is nodig vir hoekom jy alle veranderinge moet toets voordat jy dit ontplooi nie.
Na hierdie mislukking het ek dadelik verander ontplooiing pyplyn, die vervanging van die update-opdrag met die opdrag skep-verander-stel
# 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"
Sodra 'n veranderingstel geskep is, het dit geen effek op die bestaande stapel nie. Anders as die opdateringsbevel, veroorsaak die veranderingsetbenadering nie die werklike ontplooiing nie. In plaas daarvan skep dit 'n lys van veranderinge wat u kan hersien voor ontplooiing. U kan die veranderinge in die aws-konsole-koppelvlak sien. Maar as jy verkies om alles te outomatiseer wat jy kan, gaan dit dan na in die 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 tableHierdie opdrag moet uitvoer soortgelyk aan die volgende produseer:
--------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+Gee spesiale aandag aan veranderinge waar Aksie is Vervang, verwyder of waar Vervanging benodig - waar. Dit is die gevaarlikste veranderinge en lei gewoonlik tot verlies van inligting.
Sodra die veranderinge hersien is, kan hulle ontplooi word
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: Gebruik stapelbeleid om te verhoed dat staatkundige hulpbronne vervang of verwyder word
Soms is dit nie genoeg om bloot na die veranderinge te kyk nie. Ons is almal mense en ons maak almal foute. Kort nadat ons veranderingsstelle begin gebruik het, het my spanmaat onwetend 'n ontplooiing uitgevoer wat gelei het tot 'n databasisopdatering. Niks sleg het gebeur nie, want dit was 'n toetsomgewing.
Selfs al het ons skrifte 'n lys veranderinge vertoon en vir bevestiging gevra, is die Vervang-verandering oorgeslaan omdat die lys veranderinge so groot was dat dit nie op die skerm pas nie. En aangesien dit 'n normale opdatering in 'n toetsomgewing was, is daar nie veel aandag aan die veranderinge gegee nie.
Daar is hulpbronne wat jy nooit wil vervang of verwyder nie. Dit is statefull dienste, soos 'n RDS databasis instansie of 'n elasticsearch cluster, ens. Dit sal lekker wees as aws outomaties ontplooiing sou weier as die operasie wat uitgevoer word, sou vereis dat so 'n hulpbron uitvee. Gelukkig het wolkformasie 'n ingeboude manier om dit te doen. Dit word stapelbeleid genoem, en jy kan meer daaroor lees in :
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: Gebruik UsePreviousValue wanneer 'n stapel met geheime parameters opgedateer word
Wanneer jy 'n RDS mysql-entiteit skep, vereis AWS dat jy 'n MasterUsername en MasterUserPassword verskaf. Aangesien dit beter is om nie geheime in die bronkode te hou nie en ek absoluut alles wou outomatiseer, het ek 'n "slimmeganisme" geïmplementeer waar die geloofsbriewe voor ontplooiing van s3 verkry sal word, en as die geloofsbriewe nie gevind word nie, word nuwe geloofsbriewe gegenereer en gestoor in s3.
Hierdie geloofsbriewe sal dan as parameters aan die cloudformation create-change-set-opdrag deurgegee word. Terwyl ek met die skrif geëksperimenteer het, het dit gebeur dat die verbinding met s3 verloor is, en my "slimmeganisme" het dit as 'n sein behandel om nuwe geloofsbriewe te genereer.
As ek hierdie skrif in produksie begin gebruik en die verbindingsprobleem weer gebeur, sal dit die stapel met nuwe geloofsbriewe opdateer. In hierdie spesifieke geval sal niks sleg gebeur nie. Ek het egter hierdie benadering laat vaar en 'n ander een begin gebruik en slegs een keer geloofsbriewe verskaf - toe die stapel geskep word. En later, wanneer die stapel opgedateer moet word, in plaas daarvan om die geheime waarde van die parameter te spesifiseer, sal ek eenvoudig gebruik UsePreviousValue=waar:
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: Gebruik terugrol-konfigurasie
'n Ander span met wie ek gewerk het, het die funksie gebruik wolkvorming, genoem terugrol konfigurasie. Ek het dit nog nie tevore teëgekom nie en het vinnig besef dat dit die ontplooiing van my stapels nog koeler sou maak. Nou gebruik ek dit elke keer as ek my kode na lambda of ECS ontplooi deur wolkformasie te gebruik.
Hoe dit werk: jy spesifiseer CloudWatch alarm arn v parameter --terugrol-konfigurasiewanneer jy 'n veranderingstel skep. Later, wanneer jy 'n stel veranderinge uitvoer, monitor aws die alarm vir ten minste een minuut. Dit rol die ontplooiing terug as alarm gedurende hierdie tyd van toestand na ALARM verander.
Hieronder is 'n voorbeeld van 'n sjabloonuittreksel wolkvormingwaarin ek skep wolkhorlosie alarm, wat 'n wolkgebruikermetriek naspoor as die aantal foute in die wolklogboeke (die metriek word gegenereer via Metrieke filter):
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: yesNou alarm kan gebruik word as rollback sneller wanneer gereedskapkas uitgevoer word:
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: Maak seker dat jy die nuutste weergawe van die sjabloon ontplooi
Dit is maklik om 'n minder as nuutste weergawe van die wolkformasie-sjabloon te implementeer, maar dit sal baie skade veroorsaak. Dit het een keer met ons gebeur: 'n ontwikkelaar het nie die jongste veranderinge van Git af gedruk nie en het onwetend 'n vorige weergawe van die stapel ontplooi. Dit het tot stilstand gelei vir die toepassing wat hierdie stapel gebruik het.
Iets so eenvoudig soos om 'n kontrole by te voeg om te sien of die tak op datum is voordat jy daartoe verbind word, sal goed wees (met die veronderstelling dat git jou weergawebeheerinstrument 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: Moenie die wiel weer uitvind nie
Dit lyk dalk soos ontplooiing met wolkvorming - dit is maklik. Jy benodig net 'n klomp bash-skrifte wat aws cli-opdragte uitvoer.
4 jaar gelede het ek begin met eenvoudige skrifte genaamd die aws cloudformation create-stack opdrag. Gou was die draaiboek nie meer eenvoudig nie. Elke les wat geleer is, het die draaiboek meer en meer kompleks gemaak. Dit was nie net moeilik nie, maar ook vol goggas.
Ek werk tans in 'n klein IT-afdeling. Ervaring het getoon dat elke span sy eie manier het om wolkformasiestapels te ontplooi. En dis erg. Dit sal beter wees as almal dieselfde benadering volg. Gelukkig is daar baie gereedskap beskikbaar om u te help om wolkformasiestapels te ontplooi en op te stel.
Hierdie lesse sal jou help om foute te vermy.
Bron: will.com