🥇Мен бұлтты қалыптастырумен өмір бойы жұмыс істеудің осы 6 сабағын үйрендім

мен жұмыс істей бастадым бұлттылық 4 жыл бұрын. Содан бері мен көптеген инфрақұрылымдарды, тіпті өндірісте болғандарды да бұздым. Бірақ мен бірдеңені бұзған сайын жаңа нәрсе үйрендім. Осы тәжірибе арқылы мен алған ең маңызды сабақтарыммен бөлісемін.

1-сабақ: Өзгерістерді қолданбас бұрын тексеріңіз

Мен бұл сабақты мен жұмыс істей бастағаннан кейін білдім бұлттылық. Мен дәл сол кезде нені бұзғаным есімде жоқ, бірақ пәрменді қолданғаным анық есімде aws бұлтты форматының жаңартуы. Бұл пәрмен жай ғана үлгіні орналастырылатын өзгерістерді тексерусіз шығарады. Барлық өзгертулерді қолданбас бұрын неге оларды сынау керек екеніне ешқандай түсініктеме қажет деп ойламаймын.

Осы сәтсіздіктен кейін мен бірден өзгердім орналастыру құбыры, жаңарту пәрменін пәрменмен ауыстыру құру-өзгерту-жинақ

# 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 автоматты түрде орналастырудан бас тартса жақсы болар еді. Бақытымызға орай, бұлтты форматта мұны істеудің кірістірілген жолы бар. Бұл стек саясаты деп аталады және ол туралы толығырақ мына жерден оқи аласыз құжаттама:

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 ішінде сақталады.

Содан кейін бұл тіркелгі деректері бұлттық пішінді құру-өзгерту-жинақтау пәрменіне параметрлер ретінде жіберіледі. Сценариймен тәжірибе жасау кезінде 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 дабылы параметрінде --қайтару-конфигурацияөзгертулер жинағын жасағанда. Кейінірек өзгертулер жинағын орындаған кезде, 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 бөлімінде жұмыс істеймін. Тәжірибе көрсеткендей, әр команданың бұлтты қалыптастыру стектерін орналастырудың өзіндік тәсілі бар. Және бұл жаман. Барлығы бірдей көзқараста болса жақсы болар еді. Бақытымызға орай, бұлтты қалыптастыру стектерін орналастыруға және конфигурациялауға көмектесетін көптеген құралдар бар.

Бұл сабақтар қателіктерден аулақ болуға көмектеседі.

Ақпарат көзі: www.habr.com

Мен бұлтты қалыптастырумен жұмыс істеудің осы 6 сабағын өмір бойы үйрендім.