મેં મારા બાકીના જીવન માટે ક્લાઉડફોર્મેશન સાથે કામ કરવાના આ 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 ડેટાબેઝ ઇન્સ્ટન્સ અથવા ઇલાસ્ટિકસર્ચ ક્લસ્ટર, વગેરે. જો ઑપરેશન કરવામાં આવી રહ્યું હોય તો આવા સંસાધનને કાઢી નાખવાની જરૂર હોય તો 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 માં સંગ્રહિત.

આ ઓળખપત્રો પછી ક્લાઉડફોર્મેશન 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 એલાર્મ પરિમાણમાં --રોલબેક-રૂપરેખાંકનજ્યારે તમે ચેન્જસેટ બનાવો છો. બાદમાં, જ્યારે તમે ફેરફારોનો સમૂહ ચલાવો છો, ત્યારે 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: ખાતરી કરો કે તમે નમૂનાનું નવીનતમ સંસ્કરણ જમાવ્યું છે

ક્લાઉડફોર્મેશન ટેમ્પલેટનું લેટેસ્ટ વર્ઝન કરતાં ઓછું જમાવવું સરળ છે, પરંતુ આમ કરવાથી ઘણું નુકસાન થશે. આ અમારી સાથે એકવાર થયું: વિકાસકર્તાએ ગિટમાંથી નવીનતમ ફેરફારોને આગળ ધપાવ્યો ન હતો અને અજાણતાં સ્ટેકના અગાઉના સંસ્કરણને જમાવ્યું હતું. આના પરિણામે આ સ્ટેકનો ઉપયોગ કરતી એપ્લિકેશન માટે ડાઉનટાઇમ થયો.

શાખાને પ્રતિબદ્ધ કરતા પહેલા તે અપ ટુ ડેટ છે કે કેમ તે જોવા માટે ચેક ઉમેરવા જેટલું સરળ છે (ગિટ તમારું સંસ્કરણ નિયંત્રણ સાધન છે એમ ધારી રહ્યા છીએ):

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 ક્લાઉડફોર્મેશન ક્રિએટ-સ્ટૅક કમાન્ડ તરીકે ઓળખાતી સરળ સ્ક્રિપ્ટો સાથે શરૂઆત કરી હતી. ટૂંક સમયમાં સ્ક્રિપ્ટ હવે સરળ રહી ન હતી. શીખેલા દરેક પાઠે સ્ક્રિપ્ટને વધુ ને વધુ જટિલ બનાવી છે. તે માત્ર મુશ્કેલ જ નહીં, પણ ભૂલોથી ભરેલું હતું.

હું હાલમાં એક નાનકડા આઈટી વિભાગમાં કામ કરું છું. અનુભવ દર્શાવે છે કે દરેક ટીમ પાસે ક્લાઉડફોર્મેશન સ્ટેક્સ જમાવવાની પોતાની રીત છે. અને તે ખરાબ છે. દરેક વ્યક્તિ સમાન અભિગમ અપનાવે તો સારું રહેશે. સદભાગ્યે, ક્લાઉડફોર્મેશન સ્ટેક્સને ગોઠવવામાં અને ગોઠવવામાં તમારી સહાય કરવા માટે ઘણા સાધનો ઉપલબ્ધ છે.

આ પાઠ તમને ભૂલો ટાળવામાં મદદ કરશે.

સોર્સ: www.habr.com