ile çalışmaya başladım bulut bilgisi 4 yıl önce. O zamandan bu yana pek çok altyapıyı, hatta halihazırda üretimde olan altyapıları bile kırdım. Ama ne zaman bir şeyi berbat etsem, yeni bir şey öğrendim. Bu deneyim sayesinde öğrendiğim en önemli derslerden bazılarını paylaşacağım.
Ders 1: Değişiklikleri dağıtmadan önce test edin
Bu dersi çalışmaya başladıktan kısa bir süre sonra öğrendim. bulut bilgisi. O zaman tam olarak neyi kırdığımı hatırlamıyorum ama komutu kullandığımı kesinlikle hatırlıyorum aws bulut bilgisi güncellemesi. Bu komut, dağıtılacak değişikliklerin herhangi bir şekilde doğrulanmasına gerek kalmadan şablonu basitçe kullanıma sunar. Tüm değişiklikleri dağıtmadan önce neden test etmeniz gerektiğine dair herhangi bir açıklamaya gerek olduğunu düşünmüyorum.
Bu başarısızlıktan sonra hemen değiştim dağıtım boru hattıgüncelleme komutunun şu komutla değiştirilmesi: değişiklik seti oluştur
# 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"
Bir değişiklik kümesi oluşturulduktan sonra mevcut yığın üzerinde hiçbir etkisi yoktur. Update komutunun aksine, değişiklik kümesi yaklaşımı gerçek dağıtımı tetiklemez. Bunun yerine dağıtımdan önce inceleyebileceğiniz değişikliklerin bir listesini oluşturur. Değişiklikleri aws konsol arayüzünde görüntüleyebilirsiniz. Ancak yapabileceğiniz her şeyi otomatikleştirmeyi tercih ediyorsanız bunları CLI'de kontrol edin:
# 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 komut aşağıdakine benzer bir çıktı üretmelidir:
--------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+Eylemin olduğu değişikliklere özellikle dikkat edin değiştirmek, Sil veya nerede DeğiştirmeGerekli - Doğru. Bunlar en tehlikeli değişikliklerdir ve genellikle bilgi kaybına yol açar.
Değişiklikler incelendikten sonra uygulamaya konulabilir
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"Ders 2: Durum bilgisi olan kaynakların değiştirilmesini veya kaldırılmasını önlemek için yığın ilkesini kullanın
Bazen sadece değişiklikleri görüntülemek yeterli değildir. Hepimiz insanız ve hepimiz hata yaparız. Değişiklik setlerini kullanmaya başladıktan kısa bir süre sonra ekip arkadaşım bilmeden bir dağıtım gerçekleştirdi ve bu da veritabanı güncellemesiyle sonuçlandı. Test ortamı olduğu için kötü bir şey olmadı.
Komut dosyalarımızda değişikliklerin bir listesi görüntülenip onay istenmesine rağmen, değişiklik listesi ekrana sığmayacak kadar büyük olduğundan Değiştir değişikliği atlandı. Bu, test ortamındaki normal bir güncelleme olduğundan, değişikliklere pek dikkat edilmedi.
Asla değiştirmek veya kaldırmak istemeyeceğiniz kaynaklar vardır. Bunlar, RDS veritabanı örneği veya elasticsearch kümesi gibi durum bilgisi olan hizmetlerdir. Gerçekleştirilen işlem böyle bir kaynağın silinmesini gerektiriyorsa, aws'nin dağıtımı otomatik olarak reddetmesi iyi olurdu. Neyse ki bulut oluşumunun bunu yapmanın yerleşik bir yolu var. Buna yığın politikası denir ve bununla ilgili daha fazla bilgiyi şurada bulabilirsiniz: :
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"Ders 3: Bir yığını gizli parametrelerle güncellerken UsePreciousValue kullanın
Bir RDS mysql varlığı oluşturduğunuzda AWS, bir MasterUsername ve MasterUserPassword sağlamanızı gerektirir. Kaynak kodunda sır saklamamak daha iyi olduğundan ve kesinlikle her şeyi otomatikleştirmek istediğimden, dağıtımdan önce kimlik bilgilerinin s3'ten alınacağı ve kimlik bilgileri bulunamazsa yeni kimlik bilgilerinin oluşturulacağı bir "akıllı mekanizma" uyguladım. s3'te saklanır.
Bu kimlik bilgileri daha sonra cloudformation create-change-set komutuna parametre olarak aktarılacaktır. Komut dosyasıyla denemeler yaparken, s3 ile bağlantı kesildi ve "akıllı mekanizmam" bunu yeni kimlik bilgileri oluşturmak için bir sinyal olarak değerlendirdi.
Bu betiği üretimde kullanmaya başlarsam ve bağlantı sorunu tekrar meydana gelirse, yığın yeni kimlik bilgileriyle güncellenecektir. Bu özel durumda kötü bir şey olmayacak. Ancak bu yaklaşımı terk ettim ve kimlik bilgilerini yalnızca bir kez - yığın oluştururken - sağlayarak başka bir yaklaşım kullanmaya başladım. Daha sonra yığının güncellenmesi gerektiğinde, parametrenin gizli değerini belirtmek yerine basitçe şunu kullanırdım: UsePreciousValue=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"Ders 4: Geri alma yapılandırmasını kullanın
Birlikte çalıştığım başka bir ekip bu işlevi kullandı bulut bilgisi, isminde geri alma yapılandırması. Daha önce buna rastlamamıştım ve yığınlarımı dağıtmayı daha da havalı hale getireceğini hemen fark ettim. Artık kodumu bulut oluşumunu kullanarak lambda veya ECS'ye her dağıttığımda bunu kullanıyorum.
Nasıl çalışır: siz belirtin CloudWatch alarm alarmı parametrede --geri alma-yapılandırmasıbir değişiklik kümesi oluşturduğunuzda. Daha sonra bir dizi değişikliği gerçekleştirdiğinizde, aws alarmı en az bir dakika boyunca izler. Bu süre içerisinde alarmın durumu ALARM olarak değişirse dağıtımı geri alır.
Aşağıda şablon alıntısının bir örneği verilmiştir bulut bilgisiiçinde yarattığım bulut gözlem alarmıBulut günlüklerindeki hataların sayısı olarak bir bulut kullanıcısı metriğini izleyen (metrik, Metrik Filtre):
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: yesŞimdi alarm olarak kullanılabilir geri alma araç kutusunu çalıştırırken 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"5. Ders: Şablonun en son sürümünü dağıttığınızdan emin olun
Bulut oluşumu şablonunun en son sürümünden daha düşük bir sürümünü dağıtmak kolaydır, ancak bunu yapmak çok fazla hasara neden olacaktır. Bu bizim başımıza bir kez geldi: Bir geliştirici Git'teki en son değişiklikleri göndermedi ve bilmeden yığının önceki bir sürümünü dağıttı. Bu durum, bu yığını kullanan uygulamanın aksama süresine neden oldu.
Taahhütte bulunmadan önce şubenin güncel olup olmadığını görmek için bir kontrol eklemek kadar basit bir şey iyi olurdu (git'in sürüm kontrol aracınız olduğunu varsayarsak):
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
fiDers 6: Tekerleği yeniden icat etmeyin
İle konuşlandırılıyor gibi görünebilir bulut bilgisi - bu kolay. Aws cli komutlarını çalıştıran bir sürü bash betiğine ihtiyacınız var.
4 yıl önce aws cloudformation create-stack komutu adı verilen basit komut dosyalarıyla başladım. Kısa süre sonra senaryo artık basit değildi. Öğrenilen her ders senaryoyu giderek daha karmaşık hale getirdi. Sadece zor değil aynı zamanda hatalarla da doluydu.
Şu anda küçük bir BT departmanında çalışıyorum. Deneyimler, her ekibin bulut oluşum yığınlarını dağıtma konusunda kendine özgü bir yöntemi olduğunu göstermiştir. Ve bu kötü. Herkesin aynı yaklaşımı benimsemesi daha iyi olur. Neyse ki bulut bilgi yığınlarını dağıtmanıza ve yapılandırmanıza yardımcı olacak birçok araç mevcut.
Bu dersler hatalardan kaçınmanıza yardımcı olacaktır.
Kaynak: habr.com