Machine image আর cloud-init — একই server বারবার বানানো

১ · হাতে বানানো server কেন ফাঁদ

পর্ব ১৪-তে আপনি হাতে একটি server সাজিয়েছিলেন: package বসানো, Nginx-এর config, firewall, certificate. একটির জন্য এটি ঠিক আছে। এবার ভাবুন, একটি কাল্পনিক অনলাইন বাজার অ্যাপে ঈদের আগে ১০টি server লাগবে, আর একটি রাত তিনটায় নষ্ট হয়ে গেছে। কেউ কি ঠিক মনে করতে পারবেন, ছয় মাস আগে কোন কমান্ডগুলো কোন ক্রমে চালানো হয়েছিল?

এভাবে হাতে বদলাতে বদলাতে একটি server অনন্য হয়ে যায়। Martin Fowler ২০১২ সালে নিজের লেখায় একে বলেছেন snowflake server, কারণ দুটি তুষারকণা হুবহু এক হয় না। এমন server-এর সমস্যা তিনটি:

• নকল করা যায় না: নতুন server বানালে কোনো একটি ছোট setting বাদ পড়ে যায়।
• বদলাতে ভয় লাগে: কেউ জানেন না কোন ফাইলে কী বদলালে কী ভাঙবে।
• ধীরে ধীরে আলাদা হয়: একই কাজের server-গুলোর মধ্যে অমিল তৈরি হয়। একে বলে drift.

Pets vs cattle

এই পার্থক্য বোঝাতে cloud জগতে একটি তুলনা খুব চালু: pets vs cattle. পোষা প্রাণীর নাম থাকে, অসুখ হলে যত্ন করে সারানো হয়। খামারের পালের প্রতিটি প্রাণী নম্বরে চেনা, আর পালটিই আসল। পোষা server হলো db-rahim-01, যাকে সবাই চেনেন। পালের server হলো web-0417; সমস্যা হলে সরিয়ে নতুন একটি আনা হয়।

লক্ষ্যটি পরিষ্কার: server-এর জ্ঞান মানুষের মাথায় নয়, একটি নকশায় থাকবে। Cloud-এ এই নকশার দুটি অংশ: machine image আর user data. তবে যে server-এ data থাকে, সেটি অনেকটা পোষাই থেকে যায়। তাকে কীভাবে সামলাবেন, তা ভাবনার প্রশ্নে দেখব।

২ · Machine image-এর ভেতরে কী থাকে

Machine image হলো একটি boot করার মতো disk-এর সংরক্ষিত ছাঁচ, সাথে সেই disk চালাতে যা জানা দরকার তার তথ্য। পর্ব ১৫-তে যে VM চালু হয়েছিল, তার disk এমন একটি ছাঁচ থেকেই নকল হয়েছিল। ছাপাখানার প্লেটের মতো ভাবুন: একবার প্লেট তৈরি হলে হাজারটি কার্ড হুবহু ছাপা যায়।

Image আর snapshot এক নয়। Snapshot হলো একটি disk-এর একটি মুহূর্তের ছবি। Image সেই ছবির সঙ্গে boot করার তথ্য যোগ করে। AWS-এ একটি AMI সাধারণত ভেতরে এক বা একাধিক snapshot-এর ওপর দাঁড়িয়ে থাকে। ভেতরের virtual disk কীভাবে কাজ করে, তা পড়তে পারেন Operating Systems · Virtual machine পর্বে।

Image বানানোর আগে পরিষ্কার করা

একটি চলমান server থেকে image বানালে তার ব্যক্তিগত জিনিসও চলে যায় প্রতিটি নকলে। তাই আগে generalization লাগে, মানে একটি নির্দিষ্ট machine-এর পরিচয় মুছে ফেলা। সবচেয়ে জরুরি: SSH host key, /etc/machine-id, shell history, authorized_keys, log আর cloud-init-এর পুরোনো অবস্থা। Host key না মুছলে সব server একই পরিচয় দেখাবে, যা পর্ব ১২-র নিরাপত্তাকে দুর্বল করে।

# Run inside the build VM, just before making the image. Never on a live server.
sudo cloud-init clean --logs        # next boot behaves like a first boot
sudo rm -f /etc/ssh/ssh_host_*      # new host keys are made on first boot
sudo truncate -s 0 /etc/machine-id  # a new machine id is made on first boot
rm -f ~/.bash_history

৩ · Image কোথা থেকে নেবেন — বিশ্বাসের প্রশ্ন

Image মানে অন্য কারও disk দিয়ে আপনার server চালানো। ভেতরে যা আছে, তা root অধিকার নিয়েই চলবে। অচেনা লোকের রান্না করা খাবার আর দোকানের সিল করা প্যাকেটের মধ্যে যে পার্থক্য, এখানেও তাই।

নামে নয়, প্রকাশকের পরিচয়ে খুঁজুন

Image-এর নাম যে কেউ নকল করতে পারেন। “ubuntu-24.04-server” নামটি দেখে বিশ্বাস করা তাই ভুল। ২০২৫ সালে Datadog-এর গবেষকেরা “whoAMI” নামে একটি ঝুঁকি প্রকাশ করেন: কোনো script যদি শুধু নামের ধরন দিয়ে “সবচেয়ে নতুন” AMI খোঁজে আর প্রকাশক না বলে, তবে একই নামের অচেনা image বেছে নেওয়া সম্ভব। প্রতিরক্ষা সহজ:

• Owner দিন: খোঁজার সময় সবসময় প্রকাশকের account বা project বেঁধে দিন।
• ID pin করুন: Production-এ “latest” নয়, নির্দিষ্ট image ID ব্যবহার করুন।
• স্বাক্ষর মিলিয়ে নিন: Image ফাইল নিজে নামালে প্রকাশকের checksum আর digital signature যাচাই করুন। Ubuntu-র মতো প্রকল্প স্বাক্ষরিত checksum প্রকাশ করে।
• নিয়মে আটকে দিন: AWS-এর Allowed AMIs-এর মতো নিয়ম বা governance policy দিয়ে অনুমোদিত প্রকাশক ঠিক করে রাখুন (পর্ব ৩৫)।

# The owner filter is the important part. 123456789012 is a fake account id.
aws ec2 describe-images \
  --owners 123456789012 \
  --filters "Name=name,Values=shop-web-*" "Name=state,Values=available" \
  --query "sort_by(Images, &CreationDate)[-1].[ImageId,Name]" \
  --output text

৪ · Instance launch: image + user data

Image সব server-এর জন্য এক। কিন্তু প্রতিটি server-এর কিছু আলাদা কথা জানা দরকার: কোন environment, কোন app version, কোন নাম। এই আলাদা কথা পাঠানো হয় user data দিয়ে। বিয়ের কার্ডের মতো ভাবুন: ছাপা এক, শুধু খামে অতিথির নাম হাতে লেখা।

Instance নিজের user data পায় কীভাবে? প্রতিটি VM-এর ভেতর থেকে একটি বিশেষ ঠিকানায় instance metadata সেবা পাওয়া যায়, সাধারণত 169.254.169.254. এই link-local ঠিকানা VM-এর বাইরে থেকে পৌঁছানো যায় না। এখান থেকে VM জানে নিজের instance ID, region, network আর user data.

নিচে তিন provider-এ একই কাজ দেখুন। এগুলো শুধু উদাহরণ। চালালে খরচ হতে পারে, আর আপনার account না থাকলে চালানোর দরকার নেই। পরীক্ষা শেষে instance মুছে ফেলার কমান্ডও দেওয়া আছে।

aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type t3.micro \
  --user-data file://cloud-config.yaml \
  --dry-run        # checks permission only; remove it for a real launch

# clean up after a real launch
aws ec2 terminate-instances --instance-ids i-0123456789abcdef0

az group create --name rg-demo --location southeastasia

az vm create \
  --resource-group rg-demo \
  --name web-1 \
  --image Ubuntu2404 \
  --custom-data cloud-config.yaml \
  --generate-ssh-keys

# clean up (deletes every resource in the group)
az group delete --name rg-demo

gcloud compute instances create web-1 \
  --zone=asia-south1-a \
  --machine-type=e2-micro \
  --image-family=ubuntu-2404-lts-amd64 \
  --image-project=ubuntu-os-cloud \
  --metadata-from-file=user-data=cloud-config.yaml

# clean up
gcloud compute instances delete web-1 --zone=asia-south1-a

৫ · cloud-init: প্রথম boot-এর ভেতরে কী ঘটে

cloud-init হলো image-এর ভেতরে থাকা একটি প্রোগ্রাম, যা boot-এর সময় চলে আর user data পড়ে কাজ করে। Canonical-এর Ubuntu দিয়ে শুরু হলেও এখন বেশিরভাগ বড় Linux distribution আর cloud-এ এটি পাওয়া যায়। User data-র প্রথম লাইন দেখে সে বোঝে কী করতে হবে: #! দিয়ে শুরু হলে shell script, আর #cloud-config হলে YAML নির্দেশ। Cloud-config-এ আপনি কমান্ড নয়, চাওয়া অবস্থা লেখেন, তাই সাধারণত এটিই ভালো।

#cloud-config
# Fictional shop web server. No passwords or keys here.
hostname: shop-web
package_update: true
packages:
  - nginx
  - curl
write_files:
  - path: /etc/nginx/conf.d/health.conf
    owner: root:root
    permissions: '0644'
    content: |
      server {
          listen 8080;
          location = /healthz {
              default_type text/plain;
              return 200 "ok\n";
          }
      }
bootcmd:
  - echo "boot seen" >> /var/log/boot-seen.log
runcmd:
  - systemctl enable --now nginx
  - curl -fsS http://127.0.0.1:8080/healthz
final_message: "cloud-init finished in $UPTIME seconds"

প্রথম লাইনের #cloud-config লেখাটি বাধ্যতামূলক; এটি বাদ দিলে পুরো ফাইলটি কাজ না করেই পড়ে থাকতে পারে। ফাইলটি পাঠানোর আগে পরীক্ষা করা যায়: cloud-init schema --config-file cloud-config.yaml. Stage-গুলো নিচের ক্রমে চলে।

এই ক্রম থেকে একটি ফাঁদ আসে। write_files চলে package install-এর আগে। তাই owner: www-data লিখলে তখনো সেই user না থাকায় সমস্যা হতে পারে। সমাধান হলো ঐ entry-তে defer: true দেওয়া, যা ফাইল লেখাকে Final-এ পাঠায়। নিচে একটি instance-এর boot ধাপে ধাপে দেখুন। সময়গুলো ধরে নেওয়া, শুধু ক্রমটি বোঝার জন্য।

কোনটি একবার, কোনটি প্রতি boot-এ

cloud-init প্রতিটি কাজের একটি চিহ্ন রাখে /var/lib/cloud/instance/sem/ ফোল্ডারে। পরের boot-এ চিহ্ন দেখে কাজটি বাদ দেয়। এই হিসাব instance ID-র সঙ্গে বাঁধা। তাই সাধারণ reboot বা stop-start-এ ID একই থাকে, আর নতুন instance-এ ID নতুন হওয়ায় কাজগুলো আবার চলে।

সমস্যা হলে কোথায় দেখবেন

Boot-এর সমস্যা ধরতে এই কয়েকটি জায়গা মনে রাখুন। /var/log/cloud-init-output.log-এ আছে আপনার কমান্ডের আউটপুট, আর /var/log/cloud-init.log-এ cloud-init-এর নিজের বিস্তারিত log. নিচের আউটপুট নমুনা — version-ভেদে আলাদা হতে পারে।

$ cloud-init status --wait      # wait until finished, then report
status: done

$ sudo cloud-init analyze blame # which module took how long (sample output)
-- Boot Record 01 --
     46.81200s (modules-final/config-package_update_upgrade_install)
      2.34100s (init-network/config-growpart)
      1.10700s (init-local/search-Ec2Local)

$ sudo tail -n 20 /var/log/cloud-init-output.log
$ sudo cat /var/lib/cloud/instance/user-data.txt   # root only

runcmd-এর একটি কমান্ড ব্যর্থ হলেও পরের লাইনগুলো সাধারণত চলতে থাকে, কারণ সেটি একটি সাধারণ shell script. Script-এর শেষ ফলই ধরা হয়। তাই ফল নিশ্চিত হতে চাইলে নিজে set -e ব্যবহার করুন, অথবা শেষে যাচাইয়ের কমান্ড রাখুন। নতুন version-এ cloud-init status-এর exit code-ও সাহায্য করে: সফল হলে 0, ব্যর্থ হলে 1, আর আংশিক সমস্যায় 2.

৬ · User data-তে secret নয়, আর script হোক idempotent

User data দেখতে ব্যক্তিগত মনে হয়, কিন্তু আসলে তা নয়। এটি encrypted নয়; API-তে base64 আকারে থাকা মানে শুধু অন্য রকম করে লেখা। নিচের জায়গাগুলোতে এটি পড়া সম্ভব:

• VM-এর ভেতর থেকে: Metadata সেবা থেকে; সাধারণ user বা কোনো দুর্বল app-ও এটি পড়তে পারে।
• Cloud API থেকে: Instance-এর তথ্য পড়ার অনুমতি যাঁর আছে, তিনিও অনেক ক্ষেত্রে পড়তে পারেন।
• Disk আর log থেকে: cloud-init user data-র কপি রাখে, আর কমান্ড ছাপালে তা log-এ যায়।
• Launch template আর image থেকে: নকল হলে secret-ও নকল হয়।

ঠিক পথ হলো instance-কে পরিচয় দেওয়া, secret নয়। Instance-এর সঙ্গে একটি instance role যুক্ত করুন (পর্ব ৩১)। Boot-এর সময় বা app চালুর সময় সে নিজের অস্থায়ী পরিচয়ে secret manager থেকে শুধু নিজের secret পড়বে (পর্ব ৩৩)। User data-তে থাকবে শুধু secret-এর নাম, মান নয়।

# User data holds only the secret's NAME. The role gives permission at run time.
umask 077
aws secretsmanager get-secret-value \
  --secret-id shop/db-password \
  --query SecretString --output text > /run/shop/db-password
# Azure Key Vault and Google Secret Manager work the same way.
# Do not use "set -x" here: it would print commands into the log.

Idempotent script

User-data script আবার চলতে পারে: per-boot-এ রাখলে, image build পুনরায় চালালে, বা হাতে পরীক্ষা করলে। তাই script-কে idempotent করুন, মানে একবার চালালে যা হয়, দশবার চালালেও তাই হবে। পর্ব ১০-এর নিরাপদ script-এর নিয়ম এখানে কাজে লাগে। মূল কৌশল হলো “কাজটি করা” নয়, “এই অবস্থা নিশ্চিত করা”। নিচের script একটি temp ফোল্ডারের ভেতর ভুয়া /etc বানিয়ে কাজ করে, আসল /etc ছোঁয় না।

set -euo pipefail
ROOT=$(mktemp -d)                # a fake root, not the real /etc
trap 'rm -rf "$ROOT"' EXIT
changed=0
report() { printf '%-8s %s\n' "$1" "$2"; [ "$1" = ok ] || changed=$((changed + 1)); }

ensure_dir() {                   # create the folder only if missing
  if [ -d "$ROOT$1" ]; then report ok "$1"
  else mkdir -p "$ROOT$1"; report changed "$1"; fi
}
ensure_line() {                  # add the line only if absent
  touch "$ROOT$1"
  if grep -qxF "$2" "$ROOT$1"; then report ok "$1: $2"
  else echo "$2" >> "$ROOT$1"; report changed "$1: $2"; fi
}
ensure_file() {                  # rewrite only if the content differs
  if [ -f "$ROOT$1" ] && [ "$(cat "$ROOT$1")" = "$2" ]; then report ok "$1"
  else echo "$2" > "$ROOT$1.tmp"; mv "$ROOT$1.tmp" "$ROOT$1"; report changed "$1"; fi
}
provision() {
  changed=0
  ensure_dir  /etc/shop
  ensure_line /etc/shop/limits.conf "nofile 65535"
  ensure_file /etc/shop/health.conf "listen 8080"
  echo "result: $changed changed"
}
echo "== first run"; provision
echo "== second run"; provision
echo "== someone edits one file by hand"
echo "listen 9999" > "$ROOT/etc/shop/health.conf"
provision
for run in 1 2 3; do echo "nofile 65535" >> "$ROOT/naive.conf"; done
echo "a naive append, run 3 times: $(wc -l < "$ROOT/naive.conf") lines"

৭ · Bake বনাম bootstrap

একটি server-কে প্রস্তুত করার দুটি সময় আছে: launch-এর আগে, আর launch-এর পরে।

• Baking: সব কিছু আগেই image-এ ভরে রাখা। Boot-এ প্রায় কিছুই বসাতে হয় না।
• Bootstrapping: সাধারণ base image নিয়ে boot-এর সময় সব বসানো।
• Half-baked: ধীর ও কম বদলানো অংশ (OS patch, runtime, agent) image-এ, আর app-এর নতুন version boot-এ।

হিসাব: ধীর launch-এর দাম

ধরুন ঈদের আগে চাহিদা এমনভাবে বাড়ছে যে প্রতি মিনিটে ২টি বাড়তি instance লাগে। নতুন instance প্রস্তুত হতে যতক্ষণ লাগে, ততক্ষণের চাহিদা আগে থেকেই ফাঁকা ক্ষমতা হিসেবে রাখতে হবে।

• Bootstrap, ৪ মিনিট: ২ × ৪ = ৮টি বাড়তি instance সবসময় চালু রাখতে হবে।
• Bake, ১ মিনিট: ২ × ১ = ২টি।
• পার্থক্য: ৬টি। ধরে নিই প্রতিটির দাম ঘণ্টায় $০.১০, আর মাসে ৭২০ ঘণ্টা। তাহলে ৬ × ০.১০ × ৭২০ = মাসে $৪৩২ বাড়তি।

ব্যর্থতারও হিসাব আছে। Boot-এ n-টি স্বাধীন ধাপ থাকলে আর প্রতিটির ব্যর্থতার সম্ভাবনা p হলে, মোট ব্যর্থতা = ১ − (১ − p)ⁿ. প্রতিটিতে ০.৫% করে ৬টি ধাপে তা প্রায় ২.৯৬%. অর্থাৎ ১,০০০ launch-এ গড়ে প্রায় ৩০টি ব্যর্থ। আর স্বাধীনতার ধারণাটি বিপদের সময় খাটে না: Mirror বন্ধ থাকলে সব launch একসাথে ব্যর্থ হয়। নিচের সিমুলেটর দুটো প্রভাবই দেখায়। এখানে সব সংখ্যা ধরে নেওয়া, আসল সংখ্যা নয়।

// Bake vs bootstrap over 2000 launches. All numbers are assumed.
function mulberry32(a) { return () => { a = a + 0x6D2B79F5 | 0;
  let t = Math.imul(a ^ a >>> 15, 1 | a);
  t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
  return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const rnd = mulberry32(2026);
const between = (lo, hi) => lo + (hi - lo) * rnd();
const FAIL = 0.004, N = 2000, OUTAGE = [1200, 1300]; // mirror down: launch 1200-1299

// each step: [min s, max s, can fail?, needs package mirror?]
const boot = [35, 55, false, false], health = [10, 15, false, false];
const apt = [20, 40, true, true], pkgs = [60, 120, true, true];
const app = [10, 30, true, false], agent = [15, 35, true, true];
const plans = {
  "bootstrap ": [boot, apt, pkgs, agent, app, health],
  "half-baked": [boot, app, health],
  "full bake ": [boot, health],
};
for (const [name, steps] of Object.entries(plans)) {
  const ok = []; let fail = 0, inOutage = 0;
  for (let i = 0; i < N; i++) {
    const down = i >= OUTAGE[0] && i < OUTAGE[1];
    let t = 0, dead = false;
    for (const [lo, hi, risky, mirror] of steps) {
      t += between(lo, hi);
      if ((risky && rnd() < FAIL) || (mirror && down)) { dead = true; break; }
    }
    if (dead) { fail++; if (down) inOutage++; } else ok.push(t);
  }
  ok.sort((a, b) => a - b);
  const mean = ok.reduce((s, x) => s + x, 0) / ok.length;
  console.log(name, "failed", String(fail).padStart(3), "(" + (fail * 100 / N).toFixed(2) + "%)",
    "in outage", String(inOutage).padStart(3), " mean", mean.toFixed(0) + "s",
    " p99", ok[Math.floor(ok.length * 0.99)].toFixed(0) + "s");
}

বেছে নেওয়ার সহজ নিয়ম: যা ধীর আর কম বদলায়, তা bake করুন। যা environment-ভেদে আলাদা, তা boot-এ দিন। Secret কখনোই image-এ নয়। Autoscaling-এর পালের জন্য bake বা half-baked সাধারণত ভালো। অল্প দিন চলা পরীক্ষার server-এ bootstrap-ই যথেষ্ট।

মাঝপথে bootstrap ব্যর্থ হলে

এবার দেখা যাক boot-এর মাঝখানে package mirror বন্ধ হলে কী ঘটে। লক্ষ করুন, provider-এর চোখে VM সারাক্ষণ ঠিকই আছে। সময়গুলো ধরে নেওয়া।

এমন log পড়ার কাজে পর্ব ৯-এর হাতিয়ারই যথেষ্ট। নিচের script একটি নমুনা cloud-init-output.log নিজেই তৈরি করে, প্রথম error খুঁজে বের করে আর প্রতিটি stage কত সেকেন্ডে শুরু হয়েছে তা দেখায়।

set -euo pipefail
log=$(mktemp); trap 'rm -f "$log"' EXIT
cat > "$log" <<'EOF'
Cloud-init v. 24.4 running 'init-local' at Fri, 30 Oct 2026 04:12:03 +0000. Up 6.10 seconds.
Cloud-init v. 24.4 running 'init' at Fri, 30 Oct 2026 04:12:06 +0000. Up 9.02 seconds.
Cloud-init v. 24.4 running 'modules:config' at Fri, 30 Oct 2026 04:12:10 +0000. Up 13.21 seconds.
Cloud-init v. 24.4 running 'modules:final' at Fri, 30 Oct 2026 04:12:12 +0000. Up 15.44 seconds.
Reading package lists...
Err:1 http://mirror.example.net/ubuntu noble-updates/main amd64 nginx 1.24.0
  503  Service Unavailable [IP: 192.0.2.10 80]
E: Unable to fetch some archives, maybe run apt-get update
Failed to enable unit: Unit file nginx.service does not exist.
Cloud-init v. 24.4 finished at Fri, 30 Oct 2026 04:12:39 +0000. Up 42.07 seconds
EOF
echo "--- stage start times"
awk '/running/ { gsub(/[^a-z:-]/, "", $5); printf "%-16s %6.2f s\n", $5, $(NF-1) }' "$log"
echo "--- first real error"
grep -n -m1 -E '^(E:|Err:)' "$log" | cut -c1-60
echo "--- problem lines: $(grep -c -E '^(E:|Err:|Failed)' "$log")"
echo "--- finished at: $(awk '/finished at/ { print $(NF-1) }' "$log") s"

৮ · Golden image pipeline আর versioning

Golden image হাতে বানালে আপনি আবার snowflake বানাচ্ছেন, শুধু একধাপ পিছিয়ে। তাই image-ও বানাতে হয় একটি স্বয়ংক্রিয় pipeline-এ। ধারণাটি নিচের ছবিতে; আসল হাতিয়ার Packer আসবে পর্ব ৫৬-তে। AWS-এর EC2 Image Builder আর Azure-এর VM Image Builder-ও একই কাজ করে।

1. Base: বিশ্বস্ত প্রকাশকের নির্দিষ্ট image থেকে শুরু। পর্ব ৮-এর hardening এখানেই একবার করে দিলে প্রতিটি server জন্ম থেকেই শক্ত হয়।
2. Build: Patch, runtime, log ও monitoring agent বসানো; তারপর পরিষ্কার করা।
3. পরীক্ষা: নতুন image থেকে সত্যিই একটি instance চালিয়ে দেখা, boot হয় কি না আর service ওঠে কি না। সাথে CVE scan.
4. প্রকাশ: নাম, version আর উৎসের তথ্য লিখে রাখা। ব্যর্থ হলে image প্রকাশই হবে না।
5. Promote: Test-এ যে image পাস করল, হুবহু সেটিই production-এ যাবে। Production-এর জন্য নতুন করে build নয়। পর্ব ৫৮-র “একবার build, সব জায়গায় deploy” এখানেও খাটে।

Version আর tag

Image একবার প্রকাশ হলে আর বদলাবে না। বদলাতে হলে নতুন version. প্রতিটি image-এর সাথে এমন তথ্য রাখুন, যা পরে তদন্তে কাজে লাগে:

“সবচেয়ে নতুন image” বলে কিছু production-এ ব্যবহার করবেন না। Google Cloud-এর image family বা AWS-এর public parameter dev-এ সুবিধাজনক। কিন্তু production-এ নির্দিষ্ট ID থাকলে দুই সপ্তাহ পরের launch আজকের মতোই হবে, আর rollback মানে আগের ID-তে ফেরা।

৯ · Launch template, rollout আর image-এর অবসর

প্রতিবার হাতে দশটি setting দিলে ভুল হবেই। Launch template হলো instance চালুর একটি সংরক্ষিত ফর্ম: image, instance type, subnet, security group, instance role, user data, tag আর metadata-র নিয়ম। পর্ব ১৭-র autoscaling এই ফর্ম দেখেই নতুন instance বানায়। AWS-এর launch template-এ version থাকে। Google Cloud-এর instance template বদলানো যায় না, তাই নতুন একটি বানাতে হয়। Azure-এ scale set-এর model প্রায় এই কাজটিই করে।

# Version 8 = version 7 with only the image changed. Fake ids.
aws ec2 create-launch-template-version \
  --launch-template-name shop-web \
  --source-version 7 \
  --launch-template-data '{"ImageId":"ami-0fedcba9876543210"}'

aws ec2 modify-launch-template \
  --launch-template-name shop-web \
  --default-version 8

একটি গুরুত্বপূর্ণ কথা: Template বদলালে চলমান instance-এ কিছুই বদলায় না। সে শুধু পরের launch-এর ফর্ম। তাই পুরোনো server সরাতে আলাদা rollout লাগে। নিচে একটি জরুরি patch-এর পুরো যাত্রা দেখুন। ফ্লিটে আছে ৬টি instance, আর প্রতিবার ২টি করে বদলানো হবে।

এই পদ্ধতির নাম rolling replacement. Blue-green আর canary-র মতো অন্য কৌশল পর্ব ৫৯-এ। AWS Auto Scaling-এর instance refresh, Azure scale set-এর rolling upgrade আর Google-এর managed instance group-এর rolling update এই কাজটিই স্বয়ংক্রিয়ভাবে করে।

Patch-এর ছন্দ

• নিয়মিত: ধরুন প্রতি মাসে একটি নতুন image, base হালনাগাদ করে। ছন্দটি ঝুঁকি আর দলের সামর্থ্য দেখে ঠিক করুন।
• জরুরি: গুরুতর CVE-তে নিয়মিত সময়ের অপেক্ষা না করে একই pipeline চালান। সে জন্যই pipeline-টি দ্রুত আর স্বয়ংক্রিয় হওয়া দরকার।
• বয়সের সীমা: কোনো instance বেশি দিন চললে তাকে বদলে দিন। AWS Auto Scaling-এ maximum instance lifetime ঠিক এই কাজ করে।
• Boot-এ upgrade নয়: User data-তে package_upgrade: true দিলে মঙ্গলবারের instance আর বুধবারের instance আলাদা হতে পারে। Boot-ও ধীর হয়।

Image-এর অবসর

পুরোনো image জমতে থাকলে দুটি সমস্যা হয়: কেউ ভুলে অরক্ষিত পুরোনো image চালিয়ে দেন, আর তার storage-এর বিল আসে। ধরুন ৪০ GB-র ২৪টি image, আর প্রতি GB-র দাম মাসে ধরে নেওয়া $০.০৫। সবচেয়ে খারাপ অবস্থায় ২৪ × ৪০ × ০.০৫ = মাসে $৪৮। Snapshot incremental হলে বিল কম হতে পারে, তবে provider-এর দাম নিজে দেখে নিন।

Drift: হাতে রাখা বনাম image দিয়ে বদলানো

Image-ভিত্তিক বদলানোর আসল লাভ সময়ের সাথে বোঝা যায়। নিচের সিমুলেটরে ২০টি করে server-এর দুটি ফ্লিট, ১২ মাস। ধরে নেওয়া হয়েছে, প্রতি মাসে একটি patch আসে, হাতে রাখা ফ্লিটে প্রতিটি server-এ তা বাদ পড়ার সম্ভাবনা ১০%. আর দুই ফ্লিটেই প্রতিটি server-এ মাসে ৩৫% সম্ভাবনায় কেউ একটি জরুরি হাতের পরিবর্তন করেন। Image ফ্লিট প্রতি মাসের শেষে পুরোটা বদলে যায়।

// Drift over 12 months: 20 hand-kept servers vs 20 replaced from a monthly image.
function mulberry32(a) { return () => { a = a + 0x6D2B79F5 | 0;
  let t = Math.imul(a ^ a >>> 15, 1 | a);
  t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
  return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const rnd = mulberry32(16);
const SERVERS = 20, HOTFIX = 0.35, MISS = 0.10; // assumed monthly chances
let hand = Array.from({ length: SERVERS }, () => new Set());
let image = Array.from({ length: SERVERS }, () => new Set());
let wanted = new Set(), next = 0;
const diff = s => [...s].filter(k => !wanted.has(k)).length
  + [...wanted].filter(k => !s.has(k)).length;
const avg = fleet => fleet.reduce((sum, s) => sum + diff(s), 0) / fleet.length;
const kinds = fleet => new Set(fleet.map(s => [...s].sort().join())).size;

console.log("month | hand: kinds avg-diff | image: before replace -> after");
for (let m = 1; m <= 12; m++) {
  const patch = "patch" + m; wanted = new Set(wanted).add(patch);
  for (const s of hand) if (rnd() >= MISS) s.add(patch);  // someone may skip one
  for (const s of image) s.add(patch);                    // patch came in the image
  for (const fleet of [hand, image]) for (const s of fleet)
    if (rnd() < HOTFIX) s.add("hotfix" + next++);         // unique hand edit
  const before = [kinds(image), avg(image).toFixed(1)];
  image = image.map(() => new Set(wanted));               // replace all from image
  if (m % 2 === 0) console.log(String(m).padStart(5), "|",
    String(kinds(hand)).padStart(5), avg(hand).toFixed(1).padStart(8), "|",
    "kinds", String(before[0]).padStart(2), "diff", before[1], "-> kinds",
    kinds(image), "diff", avg(image).toFixed(1));
}

১০ · AI-এর যুগে image আর cloud-init

AI খুব দ্রুত cloud-config লিখে দিতে পারে। কিন্তু সেটি ভুল হলে ব্যর্থতা দেখা যাবে boot-এর সময়, প্রায়ই নিঃশব্দে। Image-এর ভুল আবার একশো server-এ একসাথে নকল হয়। এই কাজে AI সাধারণত যে ভুলগুলো করে:

AI-এর লেখা user data হাতে পেলে — চেকলিস্ট

• প্রথম লাইন #cloud-config, আর cloud-init schema পাস করেছে
• কোনো secret, আসল account ID বা key নেই; prompt-এও দিইনি
• Image-এর owner আর নির্দিষ্ট ID যাচাই করেছি, latest নেই
• প্রতিটি key official docs-এ মিলিয়েছি; কোন stage-এ চলে তা বলতে পারি
• Throwaway instance-এ চালিয়ে cloud-init status --wait আর log দেখেছি
• Budget alert চালু, আর পরীক্ষার পরে instance মুছে ফেলার ধাপ জানি
• মোছার যেকোনো কমান্ড চালানোর আগে ID নিজে পড়েছি, --dry-run করেছি