لانچر مصنوعات Bitnami دستاویزاتimaxe CLI بلاگ رابطہ

سروس روکے بغیر نئی AMI پر کیسے منتقل ہوں

جس امیج پر آپ کی سروس کھڑی ہے اسے اپ ڈیٹ کرنے کا مطلب رت جگا یا مرمت کا صفحہ نہیں ہونا چاہیے۔ درست حکمتِ عملی سے آپ صفر تعطل کے ساتھ AMI بدلتے ہیں، اور واپسی کا بٹن ہمیشہ ہاتھ میں رہتا ہے۔

ریل کی پٹری کے پاس کانٹا بدلنے کا لیور
ریل کی پٹری کے پاس کانٹا بدلنے کا لیور تصویر: W.carter · عوامی ملکیت · Wikimedia Commons

آپ کے انسٹینس جس AMI کو استعمال کرتے ہیں اسے بدلنا ایسا ہی ہے جیسے سروس چلتے چلتے اس کی بنیاد بدل دی جائے۔ غلط طریقے سے کریں تو تعطل؛ درست طریقے سے کریں تو صارف کو تقریباً نظر بھی نہیں آتا۔ خوش خبری یہ ہے کہ آزمودہ طرزیں موجود ہیں جو اس منتقلی کو محفوظ اور قابلِ واپسی بناتی ہیں۔

مشترکہ بنیاد یہ ہے کہ چلتے انسٹینس میں چھیڑ چھاڑ نہ کی جائے، بلکہ نئی AMI سے نئے انسٹینس چلائے جائیں اور ٹریفک کو قابو سے منتقل کیا جائے۔

منتقلی سے پہلے: زمین ہموار کریں

  • پروڈکشن جیسے اسٹیجنگ ماحول میں نئی AMI آزمائیں۔
  • قابلِ اعتماد ہیلتھ چیک: ایسی جانچیں طے کریں جو تصدیق کریں کہ نیا انسٹینس واقعی صحت مند ہے۔
  • واپسی کا منصوبہ: پچھلا ورژن اور اُس پر لوٹنے کا طریقہ تیار رکھیں۔
  • مشاہدہ پذیری: پیمانے اور انتباہات، تاکہ گراوٹ فوراً پکڑی جائے۔

صفر تعطل کی منتقلی حکمتِ عملیاں

حکمتِ عملیکیسے کام کرتی ہےکس کے لیے مثالی
رولنگ اپ ڈیٹانسٹینس کو ٹولیوں میں، آہستہ آہستہ بدلتی ہےAuto Scaling Group والی سروسز
بلیو/گریننیا ماحول کھڑا کر کے ایک ہی بار ٹریفک بدلتے ہیںفوری واپسی والی منتقلیاں
کینریٹریفک کا چھوٹا حصہ نئے ورژن کو بھیجتے ہیںکم خطرے میں پروڈکشن میں تصدیق

سروس روکے بغیر AMI بدلنے کی تین طرزیں۔

رولنگ اپ ڈیٹ

آپ Launch Template میں نئی AMI ڈالتے ہیں اور Auto Scaling Group انسٹینس کو لہروں میں بدلتا ہے: نئے چلاتا ہے، ان کے ہیلتھ چیک پاس ہونے کا انتظار کرتا ہے، پھر پرانے ہٹا دیتا ہے۔ سادہ اور بغیر اضافی انفراسٹرکچر، اگرچہ کچھ دیر دونوں ورژن ساتھ چلتے ہیں۔

بلیو/گرین

آپ نئی AMI کے ساتھ متوازی ماحول (green) کھڑا کرتے ہیں جبکہ موجودہ (blue) خدمت دیتا رہتا ہے۔ green کی تصدیق ہوتے ہی لوڈ بیلنسر یا DNS پر ٹریفک موڑ دیتے ہیں۔ کچھ خراب ہو تو سیکنڈوں میں blue پر لوٹ آتے ہیں۔ یہی سب سے تیز واپسی والی طرز ہے، بدلے میں وسائل کچھ دیر دگنے کرنے پڑتے ہیں۔

کینری

آپ ٹریفک کا چھوٹا حصہ نئی AMI والے انسٹینس کو بھیجتے ہیں اور دیکھتے ہیں۔ اگر پیمانے ثابت رہیں تو بتدریج تناسب 100 % تک بڑھاتے ہیں۔ اس سے کسی غیر متوقع مسئلے کا دائرۂ اثر کم سے کم رہتا ہے۔

منتقلی کے بعد

  • منتقلی کو کامیاب ماننے سے پہلے مناسب مدت تک پیمانے اور لاگ دیکھتے رہیں۔
  • پرانی AMI کو متروک قرار دیں تاکہ غلطی سے دوبارہ نہ چلے۔
  • تعینات ورژن اور تبدیلی کی وجہ دستاویز کریں۔
  • پچھلی امیج فوراً نہ مٹائیں: واپسی کی ضرورت پڑ سکتی ہے، اسے سنبھال رکھیں۔

اکثر پوچھے جانے والے سوالات

صفر تعطل کے لیے کون سی حکمتِ عملی بہترین ہے؟

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

کیا منتقلی کے لیے انفراسٹرکچر دگنا کرنا پڑتا ہے؟

صرف بلیو/گرین میں، اور وہ بھی عارضی طور پر۔ رولنگ اپ ڈیٹ یا کینری میں آپ وہی گروپ استعمال کر کے انسٹینس بدلتے جاتے ہیں، پورا ماحول دہرائے بغیر۔

واپس جا سکنے کی ضمانت کیسے دوں؟

پچھلی AMI اور اس کا Launch Template محفوظ رکھیں، قابلِ اعتماد ہیلتھ چیک طے کریں، اور منتقلی شروع کرنے سے پہلے واپسی کا طریقہ آزما لیں۔

imaxe.cloud میں ہم اپنی امیجز کی ورژن بندی کرتے ہیں تاکہ ورژنوں کے درمیان منتقلی قابلِ پیش بینی اور قابلِ واپسی رہے۔

بلیو/گرینرولنگ اپ ڈیٹکینریآٹو اسکیلنگتعیناتی
IM

imaxe ٹیم

ہم کیٹلاگ کی AMIs بناتے اور برقرار رکھتے ہیں۔ جب ہم کوئی ورژن شائع کرتے ہیں تو ہم اسے سب سے پہلے پروڈکشن میں استعمال کرتے ہیں۔

کیٹلاگ سے

اس مضمون سے متعلق AMI

پڑھتے رہیں

متعلقہ آرٹیکلز