میں نے اپنی باقی زندگی کلاؤڈ فارمیشن کے ساتھ کام کرنے کے یہ 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 آپ سے ماسٹر یوزر نام اور ماسٹر یوزر پاس ورڈ فراہم کرنے کا تقاضا کرتا ہے۔ چونکہ سورس کوڈ میں راز نہ رکھنا بہتر ہے اور میں ہر چیز کو خودکار بنانا چاہتا تھا، اس لیے میں نے ایک "سمارٹ میکانزم" نافذ کیا جہاں تعیناتی سے پہلے s3 سے اسناد حاصل کی جائیں گی، اور اگر اسناد نہیں ملیں گی، تو نئی اسناد تیار کی جائیں گی اور s3 میں محفوظ

اس کے بعد یہ اسناد کلاؤڈفارمیشن create-change-set کمانڈ کو پیرامیٹرز کے طور پر بھیجی جائیں گی۔ اسکرپٹ کے ساتھ تجربہ کرتے ہوئے، ایسا ہوا کہ s3 سے کنکشن ختم ہو گیا، اور میرے "سمارٹ میکانزم" نے اسے نئی اسناد پیدا کرنے کے لیے ایک سگنل کے طور پر سمجھا۔

اگر میں نے اس اسکرپٹ کو پروڈکشن میں استعمال کرنا شروع کیا اور کنکشن کا مسئلہ دوبارہ پیش آیا تو یہ اسٹیک کو نئی اسناد کے ساتھ اپ ڈیٹ کر دے گا۔ اس مخصوص صورت میں، کچھ بھی برا نہیں ہوگا. تاہم، میں نے اس نقطہ نظر کو ترک کر دیا اور ایک اور استعمال کرنا شروع کر دیا، صرف ایک بار اسناد فراہم کرتے ہوئے - اسٹیک بناتے وقت۔ اور بعد میں، جب اسٹیک کو اپ ڈیٹ کرنے کی ضرورت ہوتی ہے، پیرامیٹر کی خفیہ قدر بتانے کے بجائے، میں صرف استعمال کروں گا PreviousValue=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: رول بیک کنفیگریشن استعمال کریں۔

ایک اور ٹیم جس کے ساتھ میں نے کام کیا اس نے فنکشن کا استعمال کیا۔ بادل کی تشکیل، بلایا رول بیک ترتیب. میں نے اس سے پہلے اس کا سامنا نہیں کیا تھا اور جلدی سے احساس ہوا کہ یہ میرے ڈھیروں کی تعیناتی کو اور بھی ٹھنڈا کر دے گا۔ اب میں اسے ہر بار استعمال کرتا ہوں جب میں اپنے کوڈ کو کلاؤڈ فارمیشن کا استعمال کرتے ہوئے لیمبڈا یا ای سی ایس میں تعینات کرتا ہوں۔

یہ کیسے کام کرتا ہے: آپ بتاتے ہیں۔ CloudWatch الارم آرن پیرامیٹر میں --رول بیک کنفیگریشنجب آپ تبدیلی سیٹ بناتے ہیں۔ بعد میں، جب آپ تبدیلیوں کے ایک سیٹ پر عمل کرتے ہیں، تو aws کم از کم ایک منٹ کے لیے الارم کی نگرانی کرتا ہے۔ اگر الارم اس وقت کے دوران الارم کی حالت کو تبدیل کرتا ہے تو یہ تعیناتی کو واپس کر دیتا ہے۔

ذیل میں ٹیمپلیٹ کے اقتباس کی ایک مثال ہے۔ بادل کی تشکیلجس میں میں تخلیق کرتا ہوں۔ کلاؤڈ واچ کا الارم، جو کلاؤڈ لاگ میں غلطیوں کی تعداد کے طور پر کلاؤڈ صارف میٹرک کو ٹریک کرتا ہے (میٹرک اس کے ذریعے تیار کیا جاتا ہے میٹرک فلٹر):

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 کمانڈز پر عملدرآمد کرنے والے bash اسکرپٹس کے ایک گروپ کی ضرورت ہے۔

4 سال پہلے میں نے آسان اسکرپٹس کے ساتھ شروعات کی تھی جسے aws cloudformation create-stack کمانڈ کہا جاتا ہے۔ جلد ہی اسکرپٹ اب آسان نہیں رہا۔ سیکھے گئے ہر سبق نے اسکرپٹ کو مزید پیچیدہ بنا دیا۔ یہ نہ صرف مشکل تھا بلکہ کیڑوں سے بھی بھرا ہوا تھا۔

میں فی الحال ایک چھوٹے سے آئی ٹی ڈیپارٹمنٹ میں کام کرتا ہوں۔ تجربے نے دکھایا ہے کہ ہر ٹیم کے پاس کلاؤڈ فارمیشن اسٹیک کو تعینات کرنے کا اپنا طریقہ ہے۔ اور یہ بری بات ہے۔ بہتر ہو گا کہ سب یکساں طریقہ اختیار کریں۔ خوش قسمتی سے، کلاؤڈ فارمیشن اسٹیک کو تعینات اور ترتیب دینے میں آپ کی مدد کے لیے بہت سے ٹولز دستیاب ہیں۔

یہ اسباق آپ کو غلطیوں سے بچنے میں مدد کریں گے۔

ماخذ: www.habr.com