Dechreuais weithio gyda ffurfio cwmwl 4 blynedd yn ôl. Ers hynny rwyf wedi torri llawer o seilwaith, hyd yn oed rhai a oedd eisoes yn cael eu cynhyrchu. Ond bob tro roeddwn i'n gwneud llanast o rywbeth, fe ddysgais i rywbeth newydd. Trwy’r profiad hwn, byddaf yn rhannu rhai o’r gwersi pwysicaf a ddysgais.
Gwers 1: Profwch newidiadau cyn eu defnyddio
Dysgais y wers hon yn fuan ar ôl i mi ddechrau gweithio gyda ffurfio cwmwl. Nid wyf yn cofio beth yn union dorrais bryd hynny, ond rwy'n bendant yn cofio fy mod wedi defnyddio'r gorchymyn diweddariad cloudformation. Yn syml, mae'r gorchymyn hwn yn cyflwyno'r templed heb unrhyw ddilysiad o'r newidiadau a fydd yn cael eu defnyddio. Dydw i ddim yn meddwl bod angen unrhyw esboniad pam y dylech chi brofi pob newid cyn eu defnyddio.
Ar ôl y methiant hwn, newidiais ar unwaith piblinell gosod, gan ddisodli'r gorchymyn diweddaru gyda'r gorchymyn creu-newid-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"
Unwaith y bydd set newid wedi'i chreu, nid yw'n cael unrhyw effaith ar y pentwr presennol. Yn wahanol i'r gorchymyn diweddaru, nid yw'r dull changeset yn sbarduno'r defnydd gwirioneddol. Yn lle hynny, mae'n creu rhestr o newidiadau y gallwch eu hadolygu cyn eu defnyddio. Gallwch weld y newidiadau yn y rhyngwyneb consol aws. Ond os yw'n well gennych awtomeiddio popeth y gallwch, yna gwiriwch nhw yn y 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 tableDylai'r gorchymyn hwn gynhyrchu allbwn tebyg i'r canlynol:
--------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+Rhowch sylw arbennig i newidiadau lle mae Gweithredu Disodli, Dileu neu ble Angen Amnewid - Gwir. Dyma'r newidiadau mwyaf peryglus ac maent fel arfer yn arwain at golli gwybodaeth.
Unwaith y bydd y newidiadau wedi'u hadolygu, gellir eu defnyddio
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"Gwers 2: Defnyddio polisi pentwr i atal adnoddau gwladwriaethol rhag cael eu disodli neu eu dileu
Weithiau nid yw edrych ar y newidiadau yn ddigon. Rydyn ni i gyd yn ddynol ac rydyn ni i gyd yn gwneud camgymeriadau. Yn fuan ar ôl i ni ddechrau defnyddio changeets, yn ddiarwybod i fy nghyd-dîm berfformio gosodiad a arweiniodd at ddiweddariad cronfa ddata. Ni ddigwyddodd dim drwg oherwydd ei fod yn amgylchedd profi.
Er bod ein sgriptiau'n dangos rhestr o newidiadau ac yn gofyn am gadarnhad, ni chafodd y newid Replace ei hepgor oherwydd bod y rhestr o newidiadau mor fawr fel nad oedd yn ffitio ar y sgrin. A chan fod hwn yn ddiweddariad arferol mewn amgylchedd profi, ni roddwyd llawer o sylw i'r newidiadau.
Mae yna adnoddau nad ydych chi byth eisiau eu disodli na'u dileu. Mae'r rhain yn wasanaethau gwladwriaethol, megis enghraifft cronfa ddata system RDS neu glwstwr chwiliad elastig, ac ati. Byddai'n braf pe bai Aws yn gwrthod defnyddio'r gwasanaeth yn awtomatig pe byddai angen dileu adnodd o'r fath ar gyfer y gweithrediad a gyflawnir. Yn ffodus, mae gan ffurfiant cymylau ffordd annatod o wneud hyn. Gelwir hyn yn bolisi stac, a gallwch ddarllen mwy amdano 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"Gwers 3: Defnyddiwch UsePreviousValue wrth ddiweddaru pentwr gyda pharamedrau cyfrinachol
Pan fyddwch chi'n creu endid mysql RDS, mae AWS yn ei gwneud yn ofynnol i chi ddarparu MasterUsername a MasterUserPassword. Gan ei bod yn well peidio â chadw cyfrinachau yn y cod ffynhonnell a'm bod eisiau awtomeiddio popeth, gweithredais "fecanwaith craff" lle cyn ei ddefnyddio, bydd y manylion yn dod o s3, ac os na chanfyddir y tystlythyrau, cynhyrchir tystlythyrau newydd a storio yn s3 .
Yna bydd y tystlythyrau hyn yn cael eu trosglwyddo fel paramedrau i'r gorchymyn creu-newid-set cloudformation. Wrth arbrofi gyda'r sgript, digwyddodd bod y cysylltiad â s3 wedi'i golli, ac roedd fy “mecanwaith clyfar” yn ei drin fel arwydd i gynhyrchu tystlythyrau newydd.
Pe bawn i'n dechrau defnyddio'r sgript hon wrth gynhyrchu a bod y broblem cysylltiad yn digwydd eto, byddai'n diweddaru'r pentwr gyda chymwysterau newydd. Yn yr achos penodol hwn, ni fydd unrhyw beth drwg yn digwydd. Fodd bynnag, rhoddais y gorau i'r dull hwn a dechreuais ddefnyddio un arall, gan ddarparu tystlythyrau unwaith yn unig - wrth greu'r pentwr. Ac yn ddiweddarach, pan fydd angen diweddaru'r pentwr, yn hytrach na nodi gwerth cyfrinachol y paramedr, byddwn yn syml yn defnyddio UsePreviousValue=gwir:
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"Gwers 4: Defnyddiwch ffurfwedd dychwelyd
Roedd tîm arall y bûm yn gweithio ag ef yn defnyddio'r swyddogaeth ffurfio cwmwl, a elwir cyfluniad dychwelyd. Nid oeddwn wedi dod ar ei draws o'r blaen a sylweddolais yn gyflym y byddai'n gwneud lleoli fy staciau hyd yn oed yn oerach. Nawr rwy'n ei ddefnyddio bob tro rwy'n defnyddio fy nghod i lambda neu ECS gan ddefnyddio cloudformation.
Sut mae'n gweithio: rydych chi'n nodi Larwm CloudWatch yn y paramedr --rollback-configurationpan fyddwch chi'n creu set newidiadau. Yn ddiweddarach, pan fyddwch chi'n gweithredu set o newidiadau, mae aws yn monitro'r larwm am o leiaf un munud. Mae'n rholio'r gosodiad yn ôl os bydd newidiadau larwm yn nodi i ALARM yn ystod yr amser hwn.
Isod mae enghraifft o ddyfyniad templed ffurfio cwmwlyn yr hwn yr wyf yn creu larwm cloudwatch, sy'n olrhain metrig defnyddiwr cwmwl fel nifer y gwallau yn y logiau cwmwl (cynhyrchir y metrig trwy Hidlydd Metrig):
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: yesNawr larwm gellir ei ddefnyddio fel rolio yn ol sbardun wrth weithredu blwch offer:
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"Gwers 5: Gwnewch yn siŵr eich bod yn defnyddio'r fersiwn diweddaraf o'r templed
Mae'n hawdd defnyddio fersiwn llai na'r diweddaraf o'r templed ffurfio cwmwl, ond bydd gwneud hynny'n achosi llawer o ddifrod. Digwyddodd hyn i ni unwaith: ni wnaeth datblygwr wthio'r newidiadau diweddaraf gan Git a defnyddio fersiwn flaenorol o'r pentwr yn ddiarwybod iddo. Arweiniodd hyn at amser segur ar gyfer y rhaglen a ddefnyddiodd y pentwr hwn.
Byddai rhywbeth mor syml ag ychwanegu siec i weld a yw'r gangen yn gyfredol cyn ymrwymo iddo yn iawn (gan dybio mai git yw eich offeryn rheoli fersiwn):
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
fiGwers 6: Peidiwch ag ailddyfeisio'r olwyn
Gall ymddangos fel defnyddio gyda ffurfio cwmwl - mae'n hawdd. 'Ch jyst angen criw o sgriptiau bash gweithredu aws cli gorchmynion.
4 blynedd yn ôl dechreuais gyda sgriptiau syml o'r enw'r gorchymyn creu-stack ffurf cwmwl aws. Yn fuan nid oedd y sgript yn syml mwyach. Roedd pob gwers a ddysgwyd yn gwneud y sgript yn fwy a mwy cymhleth. Roedd nid yn unig yn anodd, ond hefyd yn llawn chwilod.
Ar hyn o bryd rwy'n gweithio mewn adran TG fach. Mae profiad wedi dangos bod gan bob tîm ei ffordd ei hun o ddefnyddio staciau ffurfio cymylau. Ac mae hynny'n ddrwg. Byddai'n well pe bai pawb yn cymryd yr un dull. Yn ffodus, mae yna lawer o offer ar gael i'ch helpu chi i ddefnyddio a ffurfweddu staciau ffurfio cwmwl.
Bydd y gwersi hyn yn eich helpu i osgoi camgymeriadau.
Ffynhonnell: hab.com