მე ვისწავლე ეს 6 გაკვეთილი Cloudformation-თან მუშაობის მთელი ცხოვრების განმავლობაში.

დავიწყე მუშაობა ღრუბლის ფორმირება 4 წლის წინ. მას შემდეგ ბევრი ინფრასტრუქტურა დავარღვიე, თუნდაც ის, რაც უკვე წარმოებაში იყო. მაგრამ ყოველთვის, როცა რაღაცას ვაფუჭებდი, რაღაც ახალს ვსწავლობდი. ამ გამოცდილებიდან მე გაგიზიარებთ რამდენიმე ყველაზე მნიშვნელოვან გაკვეთილს, რაც ვისწავლე.

გაკვეთილი 1: შეამოწმეთ ცვლილებები მათ გამოყენებამდე

ეს გაკვეთილი მალევე ვისწავლე, რაც დავიწყე მუშაობა ღრუბლის ფორმირება. არ მახსოვს ზუსტად რა გავტეხე მაშინ, მაგრამ ნამდვილად მახსოვს, რომ ბრძანება გამოვიყენე aws cloudformation განახლება. ეს ბრძანება უბრალოდ ავრცელებს შაბლონს განლაგებული ცვლილებების ყოველგვარი ვალიდაციის გარეშე. არა მგონია, რაიმე ახსნა იყოს საჭირო, თუ რატომ უნდა შეამოწმოთ ყველა ცვლილება მათ გამოყენებამდე.

ამ წარუმატებლობის შემდეგ მაშინვე შევიცვალე განლაგების მილსადენი, განახლების ბრძანების ჩანაცვლება ბრძანებით შექმნა-შეცვლა-კომპლექტი

# 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"

ცვლილებების ნაკრების შექმნის შემდეგ, ის არ იმოქმედებს არსებულ სტეკზე. განახლების ბრძანებისგან განსხვავებით, ცვლილებების მიდგომა არ იწვევს რეალურ განლაგებას. ამის ნაცვლად, ის ქმნის ცვლილებების ჩამონათვალს, რომელთა გადახედვაც შეგიძლიათ განლაგებამდე. თქვენ შეგიძლიათ ნახოთ ცვლილებები aws კონსოლის ინტერფეისში. მაგრამ თუ გირჩევნიათ ყველაფრის ავტომატიზაცია, მაშინ შეამოწმეთ ისინი 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 table

ამ ბრძანებამ უნდა გამოიტანოს შემდეგი გამომავალი:

--------------------------------------------------------------------
|                         DescribeChangeSet                        |
+---------+--------------------+----------------------+------------+
| Action  | ReplacementNeeded  |      Resource        | ResourceId |
+---------+--------------------+----------------------+------------+
|  Modify | True               |  AWS::ECS::Cluster   |  MyCluster |
|  Replace| True               |  AWS::RDS::DBInstance|  MyDB      |
|  Add    | None               |  AWS::SNS::Topic     |  MyTopic   |
+---------+--------------------+----------------------+------------+

განსაკუთრებული ყურადღება მიაქციეთ ცვლილებებს, სადაც არის მოქმედება Replace, წაშლა ან სად ჩანაცვლება საჭიროა - მართალია. ეს არის ყველაზე საშიში ცვლილებები და ჩვეულებრივ იწვევს ინფორმაციის დაკარგვას.

ცვლილებების განხილვის შემდეგ, ისინი შეიძლება განთავსდეს

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"

გაკვეთილი 2: გამოიყენეთ სტეკის პოლიტიკა, რათა თავიდან აიცილოთ სახელმწიფო რესურსების შეცვლა ან წაშლა

ზოგჯერ ცვლილებების უბრალოდ ნახვა საკმარისი არ არის. ჩვენ ყველანი ადამიანები ვართ და ყველა ვუშვებთ შეცდომებს. მას შემდეგ, რაც ჩვენ დავიწყეთ ცვლილებების ნაკრების გამოყენება, ჩემმა თანაგუნდელმა გაუცნობიერებლად შეასრულა განლაგება, რამაც გამოიწვია მონაცემთა ბაზის განახლება. ცუდი არაფერი მომხდარა, რადგან ეს იყო სატესტო გარემო.

მიუხედავად იმისა, რომ ჩვენი სკრიპტები აჩვენებდნენ ცვლილებების სიას და ითხოვდნენ დადასტურებას, ჩანაცვლების ცვლილება გამოტოვებული იყო, რადგან ცვლილებების სია იმდენად დიდი იყო, რომ არ ჯდებოდა ეკრანზე. და რადგან ეს იყო ნორმალური განახლება ტესტირების გარემოში, ცვლილებებს დიდი ყურადღება არ მიუქცევია.

არის რესურსები, რომელთა შეცვლა ან წაშლა არასოდეს გსურთ. ეს არის სახელმწიფო სერვისები, როგორიცაა RDS მონაცემთა ბაზის მაგალითი ან elasticsearch კლასტერი და ა.შ. კარგი იქნება, თუ aws ავტომატურად უარს იტყვის განლაგებაზე, თუ შესრულებული ოპერაცია მოითხოვს ასეთი რესურსის წაშლას. საბედნიეროდ, cloudformation-ს აქვს ჩაშენებული გზა ამის გასაკეთებლად. ამას ჰქვია სტეკის პოლიტიკა და ამის შესახებ მეტი შეგიძლიათ წაიკითხოთ აქ დოკუმენტაცია:

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"

გაკვეთილი 3: გამოიყენეთ UsePreviousValue საიდუმლო პარამეტრებით დასტის განახლებისას

როდესაც თქვენ ქმნით RDS mysql ერთეულს, AWS მოითხოვს, რომ მიუთითოთ MasterUsername და MasterUserPassword. იმის გამო, რომ სჯობს არ შევინახოთ საიდუმლო კოდის წყაროში და მინდოდა აბსოლუტურად ყველაფერი ავტომატიზებულიყო, დავაყენე „ჭკვიანი მექანიზმი“, სადაც განლაგებამდე მიიღება სერთიფიკატები s3-დან და თუ რწმუნებათა სიგელები არ იქნა ნაპოვნი, გენერირდება ახალი სერთიფიკატები და ინახება s3-ში.

ეს სერთიფიკატები შემდეგ გადაეცემა როგორც პარამეტრები cloudformation create-change-set ბრძანებას. სკრიპტზე ექსპერიმენტების დროს მოხდა, რომ კავშირი s3-თან დაიკარგა და ჩემმა „ჭკვიანმა მექანიზმმა“ მას განიხილა როგორც ახალი სერთიფიკატების გენერირების სიგნალი.

თუ მე დავიწყებდი ამ სკრიპტის გამოყენებას წარმოებაში და კავშირის პრობლემა კვლავ განმეორდებოდა, ის განაახლებს დასტას ახალი სერთიფიკატებით. ამ კონკრეტულ შემთხვევაში ცუდი არაფერი მოხდება. თუმცა, მე მივატოვე ეს მიდგომა და დავიწყე მეორის გამოყენება, სერთიფიკატების მიწოდება მხოლოდ ერთხელ - სტეკის შექმნისას. და მოგვიანებით, როდესაც დასტის განახლებას საჭიროებს, პარამეტრის საიდუმლო მნიშვნელობის მითითების ნაცვლად, უბრალოდ გამოვიყენებდი 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"

გაკვეთილი 4: გამოიყენეთ rollback კონფიგურაცია

სხვა გუნდმა, ვისთანაც ვმუშაობდი, გამოიყენა ფუნქცია ღრუბლის ფორმირებადაურეკა უკან დაბრუნების კონფიგურაცია. აქამდე არ შემხვედრია და სწრაფად მივხვდი, რომ ეს კიდევ უფრო მაგარი გახდის ჩემს სტეკების განლაგებას. ახლა მე ვიყენებ მას ყოველ ჯერზე, როცა ჩემს კოდს ლამბდაზე ან ECS-ზე ვაყენებ ღრუბლოვანი ფორმირების გამოყენებით.

როგორ მუშაობს: თქვენ მიუთითეთ CloudWatch სიგნალიზაცია პარამეტრში --უკან-კონფიგურაციაროდესაც თქვენ შექმნით ცვლილებების კომპლექტს. მოგვიანებით, როდესაც თქვენ შეასრულებთ ცვლილებების კომპლექტს, aws აკონტროლებს სიგნალიზაციას მინიმუმ ერთი წუთის განმავლობაში. ის აბრუნებს განლაგებას, თუ ამ დროის განმავლობაში განგაშის მდგომარეობა შეიცვლება ALARM-ზე.

ქვემოთ მოცემულია შაბლონის ამონაწერის მაგალითი ღრუბლის ფორმირებარომელშიც ვქმნი ღრუბლოვანი საათის სიგნალიზაცია, რომელიც თვალს ადევნებს ღრუბლის მომხმარებლის მეტრიკას, როგორც შეცდომების რაოდენობას ღრუბლის ჟურნალებში (მეტრიკა გენერირებულია 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: yes

ახლა განგაში შეიძლება გამოყენებულ იქნას როგორც rollback ტრიგერი ხელსაწყოთა ყუთის შესრულებისას:

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: დარწმუნდით, რომ განათავსეთ შაბლონის უახლესი ვერსია

Cloudformation შაბლონის უახლესი ვერსიის დანერგვა მარტივია, მაგრამ ამის გაკეთება დიდ ზიანს გამოიწვევს. ეს ჩვენთან ერთხელ მოხდა: დეველოპერმა არ დააყენა უახლესი ცვლილებები Git-დან და გაუცნობიერებლად განათავსა სტეკის წინა ვერსია. ამან გამოიწვია აპლიკაციის შეფერხება, რომელიც იყენებდა ამ დასტას.

რაღაც ისეთი მარტივი, როგორიც არის ჩეკის დამატება იმის დასანახად, არის თუ არა ფილიალი განახლებული მასზე დადებამდე, კარგი იქნება (ვივარაუდოთ, რომ git არის თქვენი ვერსიის კონტროლის ინსტრუმენტი):

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
fi

გაკვეთილი 6: ნუ გამოიგონებთ ბორბალს

შეიძლება ჩანდეს, რომ განლაგებულია ღრუბლის ფორმირება - ადვილია. თქვენ უბრალოდ გჭირდებათ bash სკრიპტების თაიგული, რომლებიც ასრულებენ aws cli ბრძანებებს.

4 წლის წინ დავიწყე მარტივი სკრიპტებით, სახელწოდებით aws cloudformation create-stack ბრძანება. მალე სცენარი მარტივი აღარ იყო. თითოეული ნასწავლი გაკვეთილი სცენარს უფრო და უფრო ართულებდა. ეს არამარტო რთული იყო, არამედ სავსე იყო შეცდომებით.

ამჟამად ვმუშაობ მცირე IT განყოფილებაში. გამოცდილებამ აჩვენა, რომ თითოეულ გუნდს აქვს ღრუბლოვანი ფორმირების სტეკების განლაგების საკუთარი გზა. და ეს ცუდია. უკეთესი იქნება, თუ ყველა ერთნაირი მიდგომა იყო. საბედნიეროდ, არსებობს მრავალი ხელსაწყო, რომელიც დაგეხმარებათ ღრუბლოვანი ფორმირების სტეკების განლაგებასა და კონფიგურაციაში.

ეს გაკვეთილები დაგეხმარებათ თავიდან აიცილოთ შეცდომები.

წყარო: www.habr.com