Би насан туршдаа үүлэн формацтай ажиллах эдгээр 6 сургамжийг сурсан.

Би хамтран ажиллаж эхэлсэн үүл үүсэх 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   |
+---------+--------------------+----------------------+------------+

Үйлдэл хаана байгаа өөрчлөлтөд онцгой анхаарал хандуулаарай Сэлгэх, устгах эсвэл хаана Солих шаардлагатай - Үнэн. Эдгээр нь хамгийн аюултай өөрчлөлтүүд бөгөөд ихэвчлэн мэдээлэл алдахад хүргэдэг.

Өөрчлөлтүүдийг хянаж үзсэний дараа тэдгээрийг байрлуулж болно

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=үнэн:

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: Буцах тохиргоог ашиглах

Миний ажиллаж байсан өөр нэг баг энэ функцийг ашигласан үүл үүсэхдуудсан буцаах тохиргоо. Би өмнө нь таарч байгаагүй бөгөөд энэ нь миний стекийг байрлуулах нь илүү сэрүүн байх болно гэдгийг хурдан ойлгосон. Одоо би Cloudformation ашиглан lambda эсвэл ECS-д кодоо байршуулах бүртээ үүнийг ашигладаг.

Энэ нь хэрхэн ажилладаг вэ: та зааж өгнө үү CloudWatch дохиолол параметрт --буцах тохиргооөөрчлөлтийн багц үүсгэх үед. Дараа нь та хэд хэдэн өөрчлөлтийг хийх үед aws дохиололыг дор хаяж нэг минутын турш хянадаг. Энэ хугацаанд дохиоллын төлөвийг ALARM болгон өөрчилсөн тохиолдолд энэ нь байршуулалтыг буцаана.

Загварын ишлэлийн жишээг доор харуулав үүл үүсэхдотор нь би бүтээдэг үүл ажиглагчийн дохиолол, энэ нь үүлэн хэрэглэгчийн хэмжигдэхүүнийг үүлэн лог дахь алдааны тоогоор хянадаг (хэмжээг ашиглан үүсгэгддэг. Метрийн шүүлтүүр):

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

Одоо дохиолол болгон ашиглаж болно буцаах хэрэгслийн хайрцагыг ажиллуулах үед гох:

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: Дугуйг дахин бүү зохион бүтээ

-тэй хамт байрлуулж байгаа юм шиг санагдаж магадгүй үүл үүсэх - Энэ нь амар хялбар юм. Танд зүгээр л aws cli командуудыг гүйцэтгэх олон тооны bash скриптүүд хэрэгтэй.

4 жилийн өмнө би aws cloudformation create-stack команд гэж нэрлэгддэг энгийн скриптүүдийг ашиглаж эхэлсэн. Удалгүй зохиол нь энгийн байхаа больсон. Сурсан хичээл бүр зохиолыг улам бүр төвөгтэй болгож байв. Энэ нь зөвхөн хэцүү төдийгүй алдаануудаар дүүрэн байсан.

Би одоогоор мэдээллийн технологийн жижиг хэлтэст ажилладаг. Туршлагаас харахад баг бүр үүлэн хэлбэрийн стекийг байрлуулах өөрийн гэсэн арга барилтай байдаг. Тэгээд ч муу. Хүн бүр адилхан хандвал дээр байх. Аз болоход, үүлэн форматын стекийг байршуулах, тохируулахад туслах олон хэрэгсэл байдаг.

Эдгээр хичээлүүд нь алдаа гаргахаас зайлсхийхэд тусална.

Эх сурвалж: www.habr.com