Мен өмүр бою булут түзүлүшү менен иштөөнүн ушул 6 сабагын үйрөндүм.

менен иштей баштадым булуттун пайда болушу 4 жыл мурун. Ошондон бери мен көптөгөн инфраструктураларды, атүгүл өндүрүштө болгондорду да талкаладым. Бирок мен бир нерсени бузуп алган сайын жаңы нерсени үйрөндүм. Бул тажрыйба аркылуу мен үйрөнгөн эң маанилүү сабактарымды бөлүшөм.

Мен өмүр бою булут түзүлүшү менен иштөөнүн ушул 6 сабагын үйрөндүм.

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   |
+---------+--------------------+----------------------+------------+

Аракет болгон жердеги өзгөрүүлөргө өзгөчө көңүл буруңуз алмаштыруу, жок кылуу же кайда Replacement Needed - Туура. Бул эң коркунучтуу өзгөрүүлөр жана адатта маалыматтын жоголушуна алып келет.

Өзгөртүүлөр каралып чыккандан кийин, аларды жайылтууга болот

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-сабак: Артка кайтаруу конфигурациясын колдонуңуз

Функцияны мен иштеген дагы бир команда колдонду булуттун пайда болушучакырды артка кайтаруу конфигурациясы. Мен буга чейин жолуккан эмесмин жана бул менин стектеримди жайылтуу ого бетер салкыныраак болорун тез түшүндүм. Азыр мен аны булут форматын колдонуп, lambda же ECSге кодумду жайгаштырган сайын колдоном.

Бул кантип иштейт: сиз белгилейсиз CloudWatch ойготкуч параметрде --rollback-конфигурацияөзгөртүүлөр топтомун түзгөндө. Кийинчерээк, сиз өзгөртүүлөр топтомун аткарганда, 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

азыр согуштук тревога катары колдонсо болот кетенчиктөө куралдар кутусун аткарууда триггер:

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 буйругу деп аталган жөнөкөй скрипттерден баштагам. Көп өтпөй сценарий жөнөкөй болбой калды. Ар бир үйрөнгөн сабак сценарийди ого бетер татаалдаштырды. Бул кыйын эле эмес, мүчүлүштүктөргө да толгон.

Учурда чакан IT бөлүмүндө иштейм. Тажрыйба көрсөткөндөй, ар бир команда булут түзүү стектерин жайылтуунун өз жолу бар. Жана бул жаман. Баары бирдей мамиле жасаса жакшы болмок. Бактыга жараша, булут түзүү стектерин жайгаштырууга жана конфигурациялоого жардам бере турган көптөгөн куралдар бар.

Бул сабактар ​​каталардан качууга жардам берет.

Source: www.habr.com

Комментарий кошуу