ilə işləməyə başladım bulud formalaşması 4 il əvvəl. O vaxtdan bəri mən bir çox infrastrukturu, hətta istehsalda olanları da sındırdım. Amma hər dəfə nəyisə qarışdıranda yeni bir şey öyrənirdim. Bu təcrübə vasitəsilə mən öyrəndiyim ən vacib dərslərdən bəzilərini paylaşacağam.
Dərs 1: Dəyişiklikləri yerləşdirməzdən əvvəl sınaqdan keçirin
Bu dərsi işə başlayandan sonra öyrəndim bulud formalaşması. O zaman dəqiq nəyi pozduğumu xatırlamıram, amma əmrdən istifadə etdiyimi mütləq xatırlayıram aws bulud formatı yeniləməsi. Bu əmr sadəcə olaraq şablonu tətbiq ediləcək dəyişikliklərin heç bir təsdiqi olmadan yayır. Düşünürəm ki, bütün dəyişiklikləri yerləşdirməzdən əvvəl niyə sınaqdan keçirməyiniz barədə izahata ehtiyac yoxdur.
Bu uğursuzluqdan sonra dərhal dəyişdim yerləşdirmə boru kəməri, yeniləmə əmrini əmrlə əvəz etmək yaratmaq-dəyişiklik-dəst
# 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"
Dəyişikliklər dəsti yaradıldıqdan sonra onun mövcud yığına heç bir təsiri yoxdur. Yeniləmə əmrindən fərqli olaraq, dəyişikliklər dəsti yanaşması faktiki yerləşdirməni işə salmır. Bunun əvəzinə, yerləşdirmədən əvvəl nəzərdən keçirə biləcəyiniz dəyişikliklərin siyahısını yaradır. Dəyişikliklərə aws konsol interfeysində baxa bilərsiniz. Ancaq bacardığınız hər şeyi avtomatlaşdırmağa üstünlük verirsinizsə, onları CLI-də yoxlayın:
# 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 tableBu əmr aşağıdakı kimi bir nəticə çıxarmalıdır:
--------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+Fəaliyyətin olduğu yerdə dəyişikliklərə xüsusi diqqət yetirin Dəyişdirmək, Sil və ya harada Replacement Needed - Doğrudur. Bunlar ən təhlükəli dəyişikliklərdir və adətən məlumat itkisinə səbəb olur.
Dəyişikliklər nəzərdən keçirildikdən sonra onlar yerləşdirilə bilə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"Dərs 2: Vəziyyəti olan resursların dəyişdirilməsinin və ya silinməsinin qarşısını almaq üçün yığın siyasətindən istifadə edin
Bəzən dəyişikliklərə sadəcə baxmaq kifayət etmir. Biz hamımız insanıq və hamımız səhv edirik. Dəyişiklik dəstlərindən istifadə etməyə başladıqdan qısa müddət sonra komanda yoldaşım bilmədən verilənlər bazası yeniləməsi ilə nəticələnən yerləşdirmə həyata keçirdi. Sınaq mühiti olduğu üçün pis heç nə baş vermədi.
Skriptlərimiz dəyişikliklərin siyahısını göstərsə də və təsdiqlənməsini istəsə də, Dəyişikliklər siyahısı ekrana sığmadığı üçün çox böyük olduğuna görə dəyişdirilməsi atlandı. Və bu, sınaq mühitində normal bir yeniləmə olduğundan, dəyişikliklərə çox diqqət yetirilmədi.
Heç vaxt dəyişdirmək və ya silmək istəmədiyiniz resurslar var. Bunlar RDS verilənlər bazası nümunəsi və ya elasticsearch klasteri və s. kimi statuslu xidmətlərdir. Əgər yerinə yetirilən əməliyyat belə resursun silinməsini tələb edərsə, aws avtomatik olaraq yerləşdirmədən imtina etsə, yaxşı olardı. Xoşbəxtlikdən, bulud formasının bunu etmək üçün daxili yolu var. Bu yığın siyasəti adlanır və bu barədə ətraflı oxuya bilərsiniz :
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"Dərs 3: Gizli parametrlərlə yığını yeniləyərkən UsePreviousValue-dan istifadə edin
RDS mysql obyekti yaratdığınız zaman AWS sizdən MasterUsername və MasterUserPassword təqdim etməyi tələb edir. Mənbə kodunda sirr saxlamamaq daha yaxşı olduğu üçün və mən tamamilə hər şeyi avtomatlaşdırmaq istədiyim üçün mən “ağıllı mexanizm” tətbiq etdim, burada yerləşdirmədən əvvəl etimadnamələr s3-dən alınacaq və etimadnamələr tapılmazsa, yeni etimadnamələr yaradılır və s3-də saxlanılır.
Bu etimadnamələr daha sonra buludformasiya yaratmaq-dəyişiklik qurmaq əmrinə parametrlər kimi ötürüləcək. Skriptlə təcrübə apararkən elə oldu ki, s3 ilə əlaqə itdi və mənim “ağıllı mexanizmim” bunu yeni etimadnamələr yaratmaq üçün bir siqnal kimi qəbul etdi.
Bu skripti istehsalda istifadə etməyə başlasam və əlaqə problemi yenidən baş versə, bu, yığını yeni etimadnamələrlə yeniləyəcəkdi. Bu vəziyyətdə pis bir şey olmayacaq. Bununla belə, mən bu yanaşmadan imtina etdim və başqa birini istifadə etməyə başladım, etimadnamələri yalnız bir dəfə - yığın yaratarkən təqdim etdim. Və sonra, yığının yenilənməsi lazım olduqda, parametrin gizli dəyərini təyin etmək əvəzinə, sadəcə istifadə edərdim. 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"Dərs 4: Geri qaytarma konfiqurasiyasından istifadə edin
İşlədiyim başqa bir komanda funksiyadan istifadə etdi bulud formalaşmasıçağırdı geri qaytarma konfiqurasiyası. Əvvəllər buna rast gəlməmişdim və tez başa düşdüm ki, bu, yığınlarımı yerləşdirməyi daha da sərinləşdirəcək. İndi mən hər dəfə kodumu bulud formatından istifadə edərək lambda və ya ECS-də yerləşdirəndə istifadə edirəm.
Necə işləyir: siz müəyyənləşdirin CloudWatch siqnalı parametrdə --geri qaytarma-konfiqurasiyadəyişiklik dəsti yaratdığınız zaman. Daha sonra, siz bir sıra dəyişiklikləri həyata keçirdiyiniz zaman aws ən azı bir dəqiqə həyəcan siqnalını izləyir. Siqnal bu müddət ərzində ALARM vəziyyətinə keçərsə, yerləşdirməni geri qaytarır.
Aşağıda bir şablon nümunəsi verilmişdir bulud formalaşmasımən yaratdığım bulud saatı siqnalı, bulud istifadəçisi metrikasını bulud qeydlərindəki səhvlərin sayı kimi izləyir (metrika vasitəsilə yaradılır Metrik Filtr):
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: yesIndi həyəcan kimi istifadə oluna bilər geriyə qaytarmaq alətlər qutusunu icra edərkən tetikleyin:
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"Dərs 5: Şablonun ən son versiyasını yerləşdirdiyinizə əmin olun
Bulud formatı şablonunun ən son versiyasını yerləşdirmək asandır, lakin bunu etmək çoxlu ziyana səbəb olacaq. Bu bir dəfə başımıza gəldi: bir tərtibatçı Git-dən ən son dəyişiklikləri təkan vermədi və bilmədən yığının əvvəlki versiyasını yerləşdirdi. Bu, bu yığından istifadə edən tətbiqin dayanması ilə nəticələndi.
Filialın aktual olub-olmadığını yoxlamaq üçün bir çek əlavə etmək kimi sadə bir şey, onu yerinə yetirməzdən əvvəl yaxşı olardı (get versiyaya nəzarət alətinizdir):
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
fiDərs 6: Təkəri yenidən kəşf etməyin
ilə yerləşdirmək kimi görünə bilər bulud formalaşması - asandır. Sadəcə aws cli əmrlərini yerinə yetirən bir dəstə bash skriptinə ehtiyacınız var.
4 il əvvəl mən aws cloudformation create-stack əmri adlanan sadə skriptlərlə başladım. Tezliklə ssenari artıq sadə deyildi. Öyrənilən hər dərs ssenarini getdikcə daha da mürəkkəbləşdirirdi. Bu, təkcə çətin deyil, həm də səhvlərlə dolu idi.
Hazırda kiçik bir İT şöbəsində işləyirəm. Təcrübə göstərir ki, hər bir komandanın buludformasiya yığınlarını yerləşdirmək üçün öz yolu var. Və bu pisdir. Hamıya eyni yanaşma olsa daha yaxşı olar. Xoşbəxtlikdən, bulud formatı yığınlarını yerləşdirməyə və konfiqurasiya etməyə kömək edəcək bir çox alət var.
Bu dərslər səhvlərdən qaçmağa kömək edəcək.
Mənbə: www.habr.com