Google Cloud نے startup scripts ہٹا دیں—VM policy اب fleet سنبھالے گی
Google Cloud نے 4 ستمبر 2026 کی سرکاری ہفتہ وار اپ ڈیٹ میں VM Extension Manager کو عمومی طور پر دستیاب قرار دیا۔ سروس Compute Engine fleets میں supported guest OS extensions کے لیے project-wide declarative policies، مسلسل drift detection، automatic self-healing، مرحلہ وار multi-zone rollout اور ناکامی پر automated rollback فراہم کرتی ہے۔
GA کا ابتدائی اندراج 14 اگست کا ہے؛ 20 اگست کو شائع ہونے والے Qiita کے آزاد Google Cloud اپ ڈیٹ نے بھی zonal اور global extension policies کے ساتھ اس ریلیز کو GA درج کیا۔ اہم وضاحت یہ ہے کہ Google Cloud نے Compute Engine کی startup-script سہولت ختم یا deprecate نہیں کی: نئی سروس صرف supported extensions کو custom startup scripts کے ذریعے manage کرنے کی ضرورت دور کرتی ہے۔
GA کے بعد extension lifecycle کیسے بدلتا ہے
Startup script عموماً VM کے boot ہونے پر ایک مرتبہ ہدایات چلاتی ہے۔ اگر اس کے ذریعے نصب extension بعد میں حذف ہو جائے، خراب ہو یا مطلوبہ configuration سے ہٹ جائے تو صرف ابتدائی script مسلسل مطلوبہ حالت نافذ نہیں کرتی۔
VM Extension Manager میں منتظم extension، configuration، version اور target VMs کو policy میں بیان کرتا ہے۔ matching موجودہ اور نئی VMs اسی desired state کے تحت آتی ہیں، جبکہ سروس extension کی تنصیب اور health پر نظر رکھتی اور drift کی صورت میں حالت درست کرتی ہے۔ یوں lifecycle boot-time کارروائی سے مسلسل policy reconciliation میں منتقل ہوتا ہے۔
یہ فرق پورے machine bootstrap پر لاگو نہیں ہوتا۔ users بنانا، application code deploy کرنا، custom packages نصب کرنا، firewall بدلنا یا کسی غیر supported third-party daemon کو چلانا اب بھی startup script، image pipeline یا کسی دوسرے configuration-management نظام کا کام ہو سکتا ہے۔
کون سی startup scripts واقعی منتقل ہو سکتی ہیں
منتقلی اسی وقت مناسب ہے جب script کا متعلقہ حصہ Google کی supported extension نصب یا configure کرتا ہو۔ اگر ایک script Ops Agent کے ساتھ application dependencies اور مقامی system settings بھی بدلتی ہے تو صرف agent والا حصہ policy میں منتقل کیا جا سکتا ہے؛ پوری script فوراً ہٹانے سے باقی bootstrap رک سکتا ہے۔
عملی migration map میں پہلے script کے کام الگ کیے جاتے ہیں، پھر supported extension کی موجودہ version اور configuration درج کی جاتی ہے۔ اس کے بعد compatible VMs کو labels سے محدود policy میں شامل کیا جا سکتا ہے، policy enforcement اور telemetry کی تصدیق کی جاتی ہے، اور صرف کامیاب cutover کے بعد اسی extension کو manage کرنے والی script ہٹائی جاتی ہے۔
ایک ہی extension کی configuration کو policy اور startup script سے بیک وقت لکھوانا مستقل تضاد پیدا کر سکتا ہے۔ عبوری مدت میں دونوں mechanisms موجود رہ سکتے ہیں، لیکن extension کے لیے authoritative controller واضح ہونا چاہیے۔
Policy بنانے سے پہلے project کا preflight
VM Extension Manager کی سرکاری دستاویزات کے مطابق supported فہرست میں Ops Agent، Extension for SAP اور Extension for Compute Workload شامل ہیں۔ Ops Agent کے لیے Cloud Monitoring API اور Cloud Logging API، جبکہ دیگر دو extensions کے لیے Workload Manager API پہلے فعال ہونا ضروری ہے؛ مطلوبہ API بند ہو تو policy موجود ہونے کے باوجود installation ناکام ہو جاتی ہے۔
Policy scope صرف project level تک محدود ہے۔ zonal policy ایک project کے مخصوص zone میں کام کرتی ہے، جبکہ global policy اسی project کے متعدد zones تک rollout کر سکتی ہے؛ folder یا organization کے لیے ایک مشترک policy دستیاب نہیں۔ ہر project میں فی zone 100 extension policies کی حد ہے، البتہ ایک policy کے تحت منتخب VMs کی تعداد محدود نہیں۔
Labels اس scope کے اندر اصل change boundary بناتے ہیں۔ cutover سے پہلے project، zones، inclusion labels، extension-specific operating-system compatibility اور policy manage کرنے والی IAM permissions کا جائزہ لینا ضروری ہے۔ label selector چھوڑنے یا غلط لکھنے سے policy ارادے سے زیادہ یا کم VMs پر لاگو ہو سکتی ہے۔
Version pinning بھی یکساں نہیں: مخصوص version پر pin کرنے کی سہولت صرف Ops Agent کے لیے درج ہے۔ اسی لیے موجودہ package version کو policy کی desired state سے ملائے بغیر پہلی enforcement غیر ارادی update یا configuration replacement بن سکتی ہے۔
Phased rollout کے ساتھ rollback کی الگ تیاری
Global policy کئی zones میں مرحلہ وار پھیل سکتی ہے، اس لیے پوری fleet کو ایک ساتھ تبدیل کرنا ضروری نہیں۔ کم خطرے والی اور نمائندہ VMs کے لیے محدود labels پہلی wave بنا سکتے ہیں؛ وہاں extension health، مطلوبہ telemetry اور guest-agent logs دیکھنے کے بعد scope وسیع کیا جا سکتا ہے۔ یہ rollout guardrail ایک انتظامی انتخاب ہے، Google کی لازمی label taxonomy نہیں۔
Automatic rollback rollout کی ناکام wave کو سنبھالتا ہے، مگر اسے مکمل workload recovery نہیں سمجھنا چاہیے۔ extension کا healthy ہونا managed plugin کی حالت بتاتا ہے، پوری application، custom repository یا script کے دیگر اثرات کی کامیابی نہیں۔
Cutover کے لیے rollback checklist میں یہ نکات شامل ہونے چاہییں:
- پہلی wave کے لیے محدود اور نمائندہ VMs پہلے سے منتخب ہوں۔
- installation failure، missing telemetry اور unhealthy extension کے لیے rollout روکنے کی حد طے ہو۔
- پہلی policy سے پہلے والی extension configuration اور startup-script revision محفوظ ہو۔
- واپسی کی صورت میں policy enforcement روکنے، سابقہ configuration بحال کرنے اور پرانی script دوبارہ فعال کرنے کی ترتیب لکھی ہو۔
Ubuntu اور SLES والی fleet ابھی منتقل نہیں ہو سکتی
Ubuntu اور SUSE Linux Enterprise Server فی الحال VM Extension Manager کے supported operating systems میں شامل نہیں۔ mixed fleet میں supported systems کو واضح labels سے policy کے دائرے میں لانا ہوگا، جبکہ Ubuntu، SLES اور متعلقہ extension کی compatibility فہرست سے باہر دوسری VMs کے لیے موجودہ startup-script یا configuration-management راستہ برقرار رہے گا۔
اس وقت نتیجہ محدود مگر واضح ہے: VM Extension Manager GA ہے اور supported Google extensions کا lifecycle declarative fleet policy کے تحت لا سکتا ہے۔ یہ خودکار migration نہیں، startup scripts کی عمومی بندش نہیں اور organization-wide control plane بھی نہیں؛ آئندہ مزید extensions، Ubuntu یا SLES support اور بلند تر policy scope کے لیے کوئی تصدیق شدہ دستیابی تاریخ موجود نہیں۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔