প্রযুক্তি ও উদ্ভাবন

VM Extension Manager-এ script কমবে—ভুল policy পুরো fleet-এ ছড়াতে পারে

|লেখক: QUASA সম্পাদকীয় দল|5 মিনিটের পাঠ| 1
VM Extension Manager-এ script কমবে—ভুল policy পুরো fleet-এ ছড়াতে পারে

GA VM Extension Manager দিয়ে Compute Engine fleet-এর extension lifecycle declarative policy-তে আনা যায়; ফলে প্রতিটি VM-এর startup script বা আলাদা install command ধরে রাখার প্রয়োজন কমে। নিরাপদ setup-এর ক্রম হলো ছোট label-targeted zonal canary, নির্দিষ্ট version ও config, পর্যবেক্ষণযোগ্য health gate, তারপর একই desired state-এর ধীর global rollout।

Google Cloud-এর GA ঘোষণায় project-wide policy, continuous drift detection, self-healing, multi-zone phased rollout, rollout failure-এ automated rollback এবং Cloud Monitoring visibility নিশ্চিত করা হয়েছে। এই বিস্তৃত automation-ই ঝুঁকির কারণও: selector বাদ পড়লে বা অযাচাইকৃত config global policy-তে গেলে matching fleet জুড়ে সেটি প্রয়োগ হতে পারে।

১. আগে policy-র blast radius বেঁধে দিন

প্রথমে extension, target VM এবং desired version—এই তিনটি বিষয় স্থির করুন। VM Extension Manager-এর lifecycle documentation বলছে, policy নির্দিষ্ট label-সহ পুরোনো ও নতুন উভয় VM-এ প্রযোজ্য হতে পারে; policy থাকলে manager extension install ও run করে, আর policy মুছলে managed extension সরিয়ে দেয়। ফলে আজ fleet-এর বাইরে থাকা নতুন VM-ও পরে matching label পেলে scope-এ ঢুকবে।

প্রথম production policy-তে শুধু env=prod-এর মতো বিস্তৃত label ব্যবহার না করে আলাদা opt-in cohort রাখুন—যেমন extension-canary=true। এটি product requirement নয়; ভুল configuration-এর প্রভাব সীমিত রাখার operational control। Canary VM-এ production-এর OS, architecture, service account, network egress এবং resource constraint যতটা সম্ভব মিলিয়ে না নিলে সফল পরীক্ষা representative হবে না।

  • যে extension চালানো হবে, তার supported OS ও configuration requirement যাচাই করুন।
  • label inventory export করে অনিচ্ছাকৃত match আছে কি না peer review করুন।
  • policy creator-কে প্রয়োজনীয় VM Extension Policy Admin role দিন; পর্যবেক্ষকের জন্য Viewer role যথেষ্ট রাখুন।
  • config source control-এ রেখে revision বা checksum change record-এ ধরুন।

২. zonal canary-তে selector, version ও config স্থির করুন

extension-canary label মেলা VM-এ pinned Ops Agent version প্রয়োগ হচ্ছে, অন্য VM policy-র বাইরে আছে

একটি কম-ঝুঁকির zone-এ অল্প কয়েকটি representative VM নিয়ে zonal policy বানান। Google Cloud-এর policy creation reference অনুযায়ী একটি selector-এর সব label pair মিলতে হয়, কিন্তু একাধিক selector logical OR হিসেবে কাজ করে; selector বাদ দিলে zonal policy ওই zone-এর সব VM এবং global policy project-এর সব zone-এর VM target করতে পারে। একই reference-এ কম সংখ্যার priority-কে বেশি অগ্রাধিকার, Ops Agent-এর জন্য 2.58.0 বা পরের version pin করা এবং SAP ও Compute Workload extension-এর জন্য শুধু latest version ব্যবহারের সীমা দেওয়া আছে।

Ops Agent-এর version ফাঁকা রাখলে সর্বশেষ উপলভ্য release ব্যবহৃত হয় এবং নতুন release এলে automatic upgrade হতে পারে। Production canary-তে তাই পরিচিত কার্যকর version pin করুন; latest-only extension হলে সেই পরিবর্তনশীলতা আলাদা risk হিসেবে গ্রহণ ও পর্যবেক্ষণ করুন। Global policy-র default slow_rollout পাঁচ দিনে deployment ছড়ায়, আর fast_rollout সব target zone-এ তাৎক্ষণিকভাবে প্রয়োগ করে; custom plan-এ zone বা region-ভিত্তিক wave, অপেক্ষার সময় এবং concurrency limit নির্ধারণ করা যায়।

Copy-ready canary sequence:

  1. নির্বাচিত VM-এ extension-canary=true label দিন এবং label query-র ফল সংরক্ষণ করুন।
  2. gcloud compute zone-vm-extension-policies create command-এ policy name, project, zone, extension, version, config file, inclusion label ও priority স্পষ্টভাবে দিন।
  3. একই extension পরিচালনাকারী অন্য policy থাকলে priority সংঘাত আগেই যাচাই করুন।
  4. Policy describe output, resolved target list এবং config revision change record-এ রাখুন।
  5. Canary-র extension installed ও healthy না হওয়া পর্যন্ত global policy তৈরি করবেন না।

৩. command success নয়, health gate দিয়ে canary বিচার করুন

VM extension-এর enforcement ও health status দেখে ব্যর্থ canary-তে alert তৈরি এবং rollout বন্ধ হচ্ছে

Policy create command সফল হওয়া শুধু request গ্রহণের প্রমাণ; extension ঠিকভাবে চলছে কি না তা আলাদা করে দেখতে হবে। VM extension monitoring reference enforcement state হিসেবে INSTALLING, INSTALL_FAILED, INSTALLED, ROLLING_BACK, ROLLBACK_FAILED, ROLLED_BACK ও INCOMPATIBLE এবং health state হিসেবে STARTING, RUNNING, STOPPED ও CRASHED প্রকাশ করে। একই সঙ্গে extension-এর সর্বোচ্চ CPU usage ও ব্যবহৃত memory bytes পর্যবেক্ষণ করা যায়।

নিজেদের workload অনুযায়ী observation window ঠিক করুন। সেই সময়ে সব canary-র enforcement state INSTALLED, health state RUNNING এবং application-level smoke test সফল হওয়া উচিত। INSTALL_FAILED, INCOMPATIBLE, CRASHED বা ROLLBACK_FAILED দেখা গেলে promotion বন্ধ রেখে permission, disk space, network access, guest agent এবং config parsing পরীক্ষা করুন।

Cloud Monitoring alert-এ extension_name ও status label ব্যবহার করে ব্যর্থ state ধরুন। কিন্তু extension process চলাই application সুস্থ থাকার নিশ্চয়তা নয়; request error, latency, log-ingestion gap বা workload-specific health check-ও rollout stop condition করুন। Product-এর automated rollback rollout failure সামলাতে পারে, কিন্তু কোন application signal গ্রহণযোগ্য—সেই operational সিদ্ধান্ত administrator-কেই নির্ধারণ করতে হবে।

৪. canary থেকে global policy-তে একই desired state তুলুন

Canary পাস করলে নতুন করে config বানাবেন না; পরীক্ষিত extension version, config revision এবং selector logic global policy-তে তুলুন। প্রথমে canary cohort-এর বাইরের target VM তালিকা review করুন। তারপর production-এর জন্য slow rollout বা ছোট custom wave নিন; fast rollout কেবল এমন পরিবর্তনে ব্যবহার করুন যার তাৎক্ষণিক বিস্তারের ঝুঁকি দল বুঝেছে ও গ্রহণ করেছে।

Custom rollout-এ প্রথম wave-এ কম-ঝুঁকির zone, পরের wave-এ সীমিত production zone এবং শেষে বাকি location রাখুন। Wave-এর অপেক্ষার সময় application-এর স্বাভাবিক load cycle ধরার মতো দীর্ঘ করুন এবং একসঙ্গে কত location ও VM বদলাবে তা সীমিত রাখুন। এটি Google নির্ধারিত universal threshold নয়; fleet size, recovery time এবং service objective অনুযায়ী নির্ধারণযোগ্য change control।

Global rollout zonal policy তৈরি ও পরিচালনা করে। একই নামের zonal policy আলাদাভাবে বদলানো থাকলে conflict হতে পারে; default আচরণ সেই local value overwrite করে না। কারণ না বুঝে overwrite বেছে নিলে zone-specific exception হারাতে পারে, তাই conflict আগে inventory করে global ও local ownership পরিষ্কার করুন।

৫. rollback-এ policy delete নয়, known-good state পুনরায় দিন

ব্যর্থ update-এর পর Compute Engine VM আগের known-good version ও সম্পূর্ণ config-এ ফিরছে

খারাপ update ধরা পড়লে পরবর্তী promotion বন্ধ করুন এবং আগের known-good version, config ও selector দিয়ে policy update করুন। Policy management documentation সতর্ক করে যে gcloud update সম্পূর্ণ replacement হিসেবে কাজ করে—বাদ দেওয়া optional field default value-তে ফিরে যায়। একই documentation অনুযায়ী policy delete করলে managed VM থেকে extension uninstall হয়; তবে একই extension ঘোষণাকারী lower-priority active policy প্রযোজ্য থাকলে সেটি installed থাকে।

তাই rollback command-এ extensions, version, config, inclusion labels, priority এবং global policy হলে rollout plan—প্রয়োজনীয় সব field পুনরায় দিন। Delete কেবল extension সত্যিই সরানোর সিদ্ধান্ত হলে ব্যবহার করুন। সীমিত cohort ব্যর্থ হলে আলাদা recovery label ও known-good config-সহ temporary higher-priority zonal policy ব্যবহার করা যেতে পারে; recovery শেষে temporary policy ও label সরিয়ে মূল desired state-এ ফিরুন।

Production change অনুমোদনের আগে নিশ্চিত করুন: target query review হয়েছে, canary representative, Ops Agent হলে version pin করা, latest-only সীমা নথিভুক্ত, INSTALLED ও RUNNING state-এর সঙ্গে workload smoke test পাস, application alert সক্রিয় এবং আগের সম্পূর্ণ policy specification পুনঃপ্রয়োগের জন্য প্রস্তুত। এই নিয়ন্ত্রণগুলো থাকলে VM Extension Manager repetitive script কমায়, অথচ ভুল policy-র fleet-wide blast radius অনিয়ন্ত্রিত থাকে না।

আরও পড়ুন:

শেয়ার করুন:

আমাদের নিউজলেটার নিন

সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।

0