Saya mula bekerja dengan pembentukan awan 4 tahun lepas. Sejak itu saya telah memecahkan banyak infrastruktur, malah infrastruktur yang telah pun dalam pengeluaran. Tetapi setiap kali saya mengacaukan sesuatu, saya belajar sesuatu yang baru. Melalui pengalaman ini, saya akan berkongsi beberapa pengajaran terpenting yang saya pelajari.
Pelajaran 1: Uji perubahan sebelum menggunakannya
Saya mempelajari pelajaran ini sejurus selepas saya mula bekerja dengannya pembentukan awan. Saya tidak ingat apa sebenarnya yang saya pecahkan ketika itu, tetapi saya pasti ingat bahawa saya menggunakan arahan itu kemas kini bentuk awan aws. Perintah ini hanya melancarkan templat tanpa sebarang pengesahan perubahan yang akan digunakan. Saya tidak fikir apa-apa penjelasan diperlukan untuk mengapa anda perlu menguji semua perubahan sebelum menggunakannya.
Selepas kegagalan ini, saya segera berubah saluran paip penyebaran, menggantikan arahan kemas kini dengan arahan buat-ubah-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"
Sebaik sahaja set perubahan dibuat, ia tidak mempunyai kesan pada tindanan sedia ada. Tidak seperti arahan kemas kini, pendekatan set perubahan tidak mencetuskan penggunaan sebenar. Sebaliknya, ia mencipta senarai perubahan yang boleh anda semak sebelum penggunaan. Anda boleh melihat perubahan dalam antara muka konsol aws. Tetapi jika anda lebih suka mengautomasikan semua yang anda boleh, kemudian semaknya dalam 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 tablePerintah ini harus menghasilkan output yang serupa dengan yang berikut:
--------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+Beri perhatian khusus kepada perubahan di mana Tindakan berada Ganti, Padam atau di mana Diperlukan Penggantian - Benar. Ini adalah perubahan yang paling berbahaya dan biasanya membawa kepada kehilangan maklumat.
Setelah perubahan telah disemak, ia boleh digunakan
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"Pelajaran 2: Gunakan dasar tindanan untuk mengelakkan sumber berstatus daripada diganti atau dialih keluar
Kadang-kadang hanya melihat perubahan tidak mencukupi. Kita semua manusia dan kita semua melakukan kesilapan. Sejurus selepas kami mula menggunakan set perubahan, rakan sepasukan saya secara tidak sedar telah melakukan penempatan yang menghasilkan kemas kini pangkalan data. Tiada perkara buruk berlaku kerana ia adalah persekitaran ujian.
Walaupun skrip kami memaparkan senarai perubahan dan meminta pengesahan, perubahan Ganti telah dilangkau kerana senarai perubahan terlalu besar sehingga tidak muat pada skrin. Dan kerana ini adalah kemas kini biasa dalam persekitaran ujian, tidak banyak perhatian diberikan kepada perubahan.
Terdapat sumber yang anda tidak mahu ganti atau dialih keluar. Ini adalah perkhidmatan statefull, seperti contoh pangkalan data RDS atau kluster elasticsearch, dsb. Alangkah baiknya jika aws secara automatik menolak penggunaan jika operasi yang dijalankan memerlukan pemadaman sumber sedemikian. Nasib baik, cloudformation mempunyai cara terbina dalam untuk melakukan ini. Ini dipanggil dasar tindanan, dan anda boleh membaca lebih lanjut mengenainya :
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"Pelajaran 3: Gunakan UsePreviousValue apabila mengemas kini tindanan dengan parameter rahsia
Apabila anda mencipta entiti mysql RDS, AWS memerlukan anda menyediakan MasterUsername dan MasterUserPassword. Oleh kerana adalah lebih baik untuk tidak menyimpan rahsia dalam kod sumber dan saya mahu mengautomasikan sepenuhnya segala-galanya, saya melaksanakan "mekanisme pintar" di mana sebelum penggunaan kelayakan akan diperoleh daripada s3, dan jika bukti kelayakan tidak dijumpai, kelayakan baharu dijana dan disimpan dalam s3 .
Bukti kelayakan ini kemudiannya akan dihantar sebagai parameter kepada arahan create-change-set cloudformation. Semasa bereksperimen dengan skrip, kebetulan sambungan ke s3 terputus, dan "mekanisme pintar" saya menganggapnya sebagai isyarat untuk menjana kelayakan baharu.
Jika saya mula menggunakan skrip ini dalam pengeluaran dan masalah sambungan berlaku lagi, ia akan mengemas kini timbunan dengan kelayakan baharu. Dalam kes ini, tiada perkara buruk akan berlaku. Walau bagaimanapun, saya meninggalkan pendekatan ini dan mula menggunakan pendekatan yang lain, memberikan bukti kelayakan hanya sekali - semasa membuat timbunan. Dan kemudian, apabila timbunan memerlukan pengemaskinian, dan bukannya menentukan nilai rahsia parameter, saya hanya akan menggunakan 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"Pelajaran 4: Gunakan konfigurasi rollback
Pasukan lain yang saya bekerjasama menggunakan fungsi tersebut pembentukan awandipanggil konfigurasi rollback. Saya tidak pernah menemuinya sebelum ini dan dengan cepat menyedari bahawa ia akan menjadikan penggunaan tindanan saya lebih sejuk. Sekarang saya menggunakannya setiap kali saya menggunakan kod saya ke lambda atau ECS menggunakan cloudformation.
Cara ia berfungsi: anda tentukan Penggera CloudWatch arn dalam parameter --rollback-konfigurasiapabila anda membuat set perubahan. Kemudian, apabila anda melaksanakan satu set perubahan, aws memantau penggera selama sekurang-kurangnya satu minit. Ia melancarkan semula penggunaan jika penggera menukar keadaan kepada ALARM pada masa ini.
Di bawah ialah contoh petikan templat pembentukan awandi mana saya mencipta penggera jam awan, yang menjejaki metrik pengguna awan sebagai bilangan ralat dalam log awan (metrik dijana melalui 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: yesSekarang penggera boleh digunakan sebagai melakukan pengembalian pencetus apabila melaksanakan kotak alat:
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"Pelajaran 5: Pastikan anda menggunakan versi templat terbaharu
Mudah untuk menggunakan versi templat cloudformation yang kurang daripada terkini, tetapi berbuat demikian akan menyebabkan banyak kerosakan. Ini berlaku kepada kami sekali: pembangun tidak menolak perubahan terkini daripada Git dan secara tidak sedar menggunakan versi tindanan sebelumnya. Ini mengakibatkan masa henti bagi aplikasi yang menggunakan tindanan ini.
Sesuatu yang mudah seperti menambah semakan untuk melihat sama ada cawangan itu dikemas kini sebelum melakukannya adalah baik (dengan mengandaikan git ialah alat kawalan versi anda):
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
fiPelajaran 6: Jangan cipta semula roda
Ia mungkin kelihatan seperti menggunakan pembentukan awan - ia mudah. Anda hanya memerlukan sekumpulan skrip bash yang melaksanakan arahan aws cli.
4 tahun yang lalu saya mulakan dengan skrip mudah yang dipanggil arahan ciptaan awan bentuk awan aws. Tidak lama kemudian skripnya tidak lagi mudah. Setiap pelajaran yang dipelajari menjadikan skrip semakin kompleks. Ia bukan sahaja sukar, tetapi juga penuh dengan pepijat.
Saya kini bekerja di jabatan IT kecil. Pengalaman telah menunjukkan bahawa setiap pasukan mempunyai cara tersendiri untuk menggunakan timbunan pembentukan awan. Dan itu buruk. Adalah lebih baik jika semua orang mengambil pendekatan yang sama. Nasib baik, terdapat banyak alatan yang tersedia untuk membantu anda menggunakan dan mengkonfigurasi tindanan pembentukan awan.
Pelajaran ini akan membantu anda mengelakkan kesilapan.
Sumber: www.habr.com