ਮੈਂ ਆਪਣੀ ਬਾਕੀ ਦੀ ਜ਼ਿੰਦਗੀ ਲਈ ਕਲਾਉਡਫਾਰਮੇਸ਼ਨ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਇਹ 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"

ਇੱਕ ਵਾਰ ਇੱਕ ਤਬਦੀਲੀ ਸੈੱਟ ਬਣ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਇਸਦਾ ਮੌਜੂਦਾ ਸਟੈਕ 'ਤੇ ਕੋਈ ਪ੍ਰਭਾਵ ਨਹੀਂ ਹੁੰਦਾ। ਅੱਪਡੇਟ ਕਮਾਂਡ ਦੇ ਉਲਟ, changeset ਪਹੁੰਚ ਅਸਲ ਤੈਨਾਤੀ ਨੂੰ ਚਾਲੂ ਨਹੀਂ ਕਰਦੀ ਹੈ। ਇਸਦੀ ਬਜਾਏ, ਇਹ ਤਬਦੀਲੀਆਂ ਦੀ ਇੱਕ ਸੂਚੀ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਤੈਨਾਤੀ ਤੋਂ ਪਹਿਲਾਂ ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ 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 ਆਪਣੇ ਆਪ ਤੈਨਾਤੀ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦੇਵੇ ਜੇਕਰ ਕੀਤੇ ਜਾ ਰਹੇ ਓਪਰੇਸ਼ਨ ਲਈ ਅਜਿਹੇ ਸਰੋਤ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਕਲਾਉਡਫਾਰਮੇਸ਼ਨ ਵਿੱਚ ਅਜਿਹਾ ਕਰਨ ਦਾ ਇੱਕ ਬਿਲਟ-ਇਨ ਤਰੀਕਾ ਹੈ। ਇਸਨੂੰ ਸਟੈਕ ਪਾਲਿਸੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਦਸਤਾਵੇਜ਼:

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 ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਖਤਮ ਹੋ ਗਿਆ ਸੀ, ਅਤੇ ਮੇਰੀ "ਸਮਾਰਟ ਵਿਧੀ" ਨੇ ਇਸਨੂੰ ਨਵੇਂ ਪ੍ਰਮਾਣ ਪੱਤਰ ਬਣਾਉਣ ਲਈ ਇੱਕ ਸੰਕੇਤ ਵਜੋਂ ਮੰਨਿਆ।

ਜੇ ਮੈਂ ਇਸ ਸਕ੍ਰਿਪਟ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਅਤੇ ਕੁਨੈਕਸ਼ਨ ਸਮੱਸਿਆ ਦੁਬਾਰਾ ਹੋ ਗਈ, ਤਾਂ ਇਹ ਨਵੇਂ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨਾਲ ਸਟੈਕ ਨੂੰ ਅਪਡੇਟ ਕਰੇਗਾ। ਇਸ ਵਿਸ਼ੇਸ਼ ਸਥਿਤੀ ਵਿੱਚ, ਕੁਝ ਵੀ ਬੁਰਾ ਨਹੀਂ ਹੋਵੇਗਾ. ਹਾਲਾਂਕਿ, ਮੈਂ ਇਸ ਪਹੁੰਚ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਹੈ ਅਤੇ ਇੱਕ ਹੋਰ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ ਹੈ, ਸਿਰਫ ਇੱਕ ਵਾਰ ਪ੍ਰਮਾਣ ਪੱਤਰ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋਏ - ਸਟੈਕ ਬਣਾਉਣ ਵੇਲੇ. ਅਤੇ ਬਾਅਦ ਵਿੱਚ, ਜਦੋਂ ਸਟੈਕ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪੈਰਾਮੀਟਰ ਦੇ ਗੁਪਤ ਮੁੱਲ ਨੂੰ ਦਰਸਾਉਣ ਦੀ ਬਜਾਏ, ਮੈਂ ਬਸ ਵਰਤਾਂਗਾ PreviousValue=ਸਹੀ ਵਰਤੋਂ:

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: ਰੋਲਬੈਕ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰੋ

ਇੱਕ ਹੋਰ ਟੀਮ ਜਿਸ ਨਾਲ ਮੈਂ ਕੰਮ ਕੀਤਾ, ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਕਲਾਉਡਫਾਰਮੇਸ਼ਨ, ਬੁਲਾਇਆ ਰੋਲਬੈਕ ਸੰਰਚਨਾ. ਮੈਂ ਪਹਿਲਾਂ ਇਸ ਨੂੰ ਨਹੀਂ ਦੇਖਿਆ ਸੀ ਅਤੇ ਜਲਦੀ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਇਹ ਮੇਰੇ ਸਟੈਕ ਨੂੰ ਹੋਰ ਵੀ ਠੰਡਾ ਬਣਾ ਦੇਵੇਗਾ। ਹੁਣ ਮੈਂ ਇਸਨੂੰ ਹਰ ਵਾਰ ਵਰਤਦਾ ਹਾਂ ਜਦੋਂ ਮੈਂ ਕਲਾਉਡਫਾਰਮੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਆਪਣੇ ਕੋਡ ਨੂੰ ਲੈਂਬਡਾ ਜਾਂ ਈਸੀਐਸ 'ਤੇ ਤੈਨਾਤ ਕਰਦਾ ਹਾਂ।

ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ: ਤੁਸੀਂ ਨਿਸ਼ਚਿਤ ਕਰੋ 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 ਤੋਂ ਨਵੀਨਤਮ ਤਬਦੀਲੀਆਂ ਨੂੰ ਅੱਗੇ ਨਹੀਂ ਵਧਾਇਆ ਅਤੇ ਅਣਜਾਣੇ ਵਿੱਚ ਸਟੈਕ ਦੇ ਪਿਛਲੇ ਸੰਸਕਰਣ ਨੂੰ ਤੈਨਾਤ ਕੀਤਾ. ਇਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਇਸ ਸਟੈਕ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਡਾਊਨਟਾਈਮ ਹੋਇਆ।

ਇਹ ਦੇਖਣ ਲਈ ਕਿ ਕੀ ਬ੍ਰਾਂਚ ਅਪ ਟੂ ਡੇਟ ਹੈ, ਇਹ ਦੇਖਣ ਲਈ ਕਿ ਕੀ ਇਸ ਨੂੰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸਹੀ ਹੈ (ਇਹ ਮੰਨ ਕੇ ਕਿ ਗਿਟ ਤੁਹਾਡਾ ਸੰਸਕਰਣ ਕੰਟਰੋਲ ਟੂਲ ਹੈ) ਦੇ ਰੂਪ ਵਿੱਚ ਕੁਝ ਸਧਾਰਨ ਹੈ:

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 ਕਮਾਂਡਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਬੈਸ਼ ਸਕ੍ਰਿਪਟਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਦੀ ਲੋੜ ਹੈ।

4 ਸਾਲ ਪਹਿਲਾਂ ਮੈਂ ਸਧਾਰਨ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕੀਤੀ ਸੀ ਜਿਸਨੂੰ aws ਕਲਾਉਡਫਾਰਮੇਸ਼ਨ ਬਣਾਓ-ਸਟੈਕ ਕਮਾਂਡ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਜਲਦੀ ਹੀ ਸਕ੍ਰਿਪਟ ਸਧਾਰਨ ਨਹੀਂ ਰਹੀ। ਸਿੱਖੇ ਗਏ ਹਰ ਸਬਕ ਨੇ ਸਕ੍ਰਿਪਟ ਨੂੰ ਹੋਰ ਗੁੰਝਲਦਾਰ ਬਣਾ ਦਿੱਤਾ ਹੈ। ਇਹ ਨਾ ਸਿਰਫ਼ ਔਖਾ ਸੀ, ਸਗੋਂ ਬੱਗਾਂ ਨਾਲ ਵੀ ਭਰਿਆ ਹੋਇਆ ਸੀ।

ਮੈਂ ਵਰਤਮਾਨ ਵਿੱਚ ਇੱਕ ਛੋਟੇ IT ਵਿਭਾਗ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹਾਂ। ਤਜਰਬੇ ਨੇ ਦਿਖਾਇਆ ਹੈ ਕਿ ਹਰੇਕ ਟੀਮ ਕੋਲ ਕਲਾਉਡਫਾਰਮੇਸ਼ਨ ਸਟੈਕ ਨੂੰ ਤਾਇਨਾਤ ਕਰਨ ਦਾ ਆਪਣਾ ਤਰੀਕਾ ਹੈ। ਅਤੇ ਇਹ ਬੁਰਾ ਹੈ. ਚੰਗਾ ਹੋਵੇਗਾ ਜੇਕਰ ਹਰ ਕੋਈ ਇੱਕੋ ਜਿਹੀ ਪਹੁੰਚ ਅਪਣਾਵੇ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਕਲਾਉਡਫਾਰਮੇਸ਼ਨ ਸਟੈਕ ਨੂੰ ਤੈਨਾਤ ਅਤੇ ਕੌਂਫਿਗਰ ਕਰਨ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਟੂਲ ਉਪਲਬਧ ਹਨ।

ਇਹ ਸਬਕ ਗਲਤੀਆਂ ਤੋਂ ਬਚਣ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰਨਗੇ।

ਸਰੋਤ: www.habr.com