Infrastructure as Code — declarative, idempotent আর drift

১ · ClickOps: হাতে বানানোর তিনটি দাম

একটি কাল্পনিক অনলাইন বাজার অ্যাপের কথা ভাবুন। ছয় মাস আগে রিফাত console খুলে server, firewall আর database বানিয়েছেন। সব ঠিকই চলছে। এখন একই রকম একটি staging environment দরকার, আর রিফাত চাকরি ছেড়ে গেছেন। Firewall-এ কোন port খোলা ছিল? Database-এর কোন setting বদলানো হয়েছিল? কেউ জানে না।

Web console-এ ক্লিক করে infrastructure বানানোকে মজা করে বলা হয় ClickOps. শেখার জন্য, বা একটি নতুন service চেখে দেখার জন্য console চমৎকার। সমস্যা শুরু হয় যখন ক্লিকই production বানানোর একমাত্র পথ হয়ে যায়। দাম তিনটি:

CFEngine থেকে Terraform: দুই দশকের পথ

IaC-র ভাবনা cloud-এর চেয়ে পুরোনো। প্রথম প্রশ্ন ছিল, একশোটি Unix machine-কে একই রকম রাখব কীভাবে? Cloud আসার পরে প্রশ্ন বদলাল: machine-টাই যদি API ডেকে বানানো যায়, তাহলে পুরো data center কোডে লেখা যাবে না কেন?

এখান থেকে দুটি পরিবার চিনে নিন। Configuration management (Puppet, Chef, Ansible) একটি চলমান server-এর ভেতরে package আর ফাইল ঠিক রাখে। Provisioning tool (CloudFormation, Terraform) server, network আর database-এর মতো জিনিসটাই বানায়। সীমারেখা পুরোপুরি কঠিন নয়, Ansible দিয়েও cloud resource বানানো যায়। এই মডিউলের বেশিরভাগ অংশ provisioning নিয়ে। Configuration management আসবে পর্ব ৫৬-এ।

২ · Imperative বনাম declarative: একই কাজ দুইবার

মতিঝিল যাবেন, CNG-তে উঠলেন। চালককে দুইভাবে বলা যায়। “সোজা যান, দ্বিতীয় মোড়ে বামে, তারপর ডানে।” এটি imperative: আপনি ধাপ বলছেন। অথবা “মতিঝিল শাপলা চত্বর।” এটি declarative: আপনি গন্তব্য বলছেন, পথ চালকের দায়িত্ব। আপনি যদি আগে থেকেই শাপলা চত্বরে থাকেন? প্রথম ধরনের নির্দেশ মানলে অন্য কোথাও চলে যাবেন। দ্বিতীয় ধরনে চালক বলবেন, “এসেই তো গেছি।”

নিচের script-এ লক্ষ্য একটাই: site ফোল্ডার আর একটি config লাইন। প্রথম function ধাপ চালায়। দ্বিতীয়টি আগে দেখে, পার্থক্য থাকলেই কেবল কিছু করে। দুটিই দুইবার চলবে। চালিয়ে দেখুন:

#!/usr/bin/env bash
# One goal: folder + one config line. Each style runs twice.
set -u
cd "$(mktemp -d)"
WANT="port=8080"

imperative() {            # a list of steps
  mkdir site 2>&1
  echo "$WANT" >> site/app.conf
  echo "  lines in file: $(wc -l < site/app.conf)"
}

converge() {              # check first, act only on a difference
  if [ -d site2 ]; then echo "  folder: ok"
  else mkdir site2; echo "  folder: created"; fi

  if [ "$(cat site2/app.conf 2>/dev/null)" = "$WANT" ]; then
    echo "  file: ok, no change"
  else
    echo "$WANT" > site2/app.conf; echo "  file: written"
  fi
  echo "  lines in file: $(wc -l < site2/app.conf)"
}

echo "== imperative, run 1"; imperative
echo "== imperative, run 2"; imperative
echo "== converge, run 1";   converge
echo "== converge, run 2";   converge

এবার একই লক্ষ্য Terraform-এ। এখানে কোনো ধাপ নেই, শুধু শেষ ফলের বর্ণনা:

terraform {
  required_version = ">= 1.6"
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.5"
    }
  }
}

resource "local_file" "app_conf" {
  filename = "${path.module}/site/app.conf"
  content  = "port=8080\n"
}

$ terraform apply -auto-approve
…
  # local_file.app_conf will be created
  + resource "local_file" "app_conf" {
      + content              = <<-EOT
            port=8080
        EOT
      …
      + filename             = "./site/app.conf"
      …
    }

Plan: 1 to add, 0 to change, 0 to destroy.
local_file.app_conf: Creating...
local_file.app_conf: Creation complete after 0s [id=b652360b0632ca0f81fbcbad647a5761d4a68b53]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

$ terraform apply -auto-approve
local_file.app_conf: Refreshing state... [id=b652360b0632ca0f81fbcbad647a5761d4a68b53]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

৩ · এক জিনিসের তিন রূপ: desired, recorded আর real

একটি গুদামঘরের কথা ভাবুন। মালিকের তালিকায় লেখা, তাকে ৫০ বস্তা চাল থাকবে। হিসাবের খাতায় লেখা, গত সপ্তাহে ৫০ বস্তা তোলা হয়েছে। আর আসল তাকে আছে ৪৮ বস্তা। তিনটি আলাদা তথ্য, আর তিনটি নিয়েই কাজ করতে হয়। IaC-তেও তাই:

Kubernetes-এর desired state আর reconciliation loop পর্ব ৪২-এ দেখেছেন। সেখানে কথা ছিল দুটি অবস্থার। Terraform-এ তৃতীয়টি কেন লাগে? কারণ তিনটি:

• নাম থেকে আসল জিনিস: code-এ শুধু local_file.app_conf লেখা। State জানে, এই নামের সাথে কোন আসল id বাঁধা।
• মোছা: code থেকে একটি resource সরালে code তো আর তার কথা জানে না। State-এ নাম আছে, code-এ নেই, এই অমিল থেকেই Terraform বোঝে জিনিসটি মুছতে হবে।
• মেটাডেটা: dependency-র ক্রম আর হাজার resource-এর হিসাব রাখা, যাতে প্রতিবার সব কিছু নতুন করে জানতে না হয়।

Terraform-এর কাজের ধারা তাই এমন: state-এ যা আছে, তার আসল অবস্থা API থেকে পড়ে (এটি refresh), তারপর সেটি code-এর সাথে তুলনা করে। State ফাইলে সব attribute-এর মান থাকে, password-ও। তাই একে গোপন তথ্য হিসেবে সামলাতে হয়। Backend, lock আর import-এর বিস্তারিত পর্ব ৫৩-এ।

Plan আসলে একটি diff

Plan হলো কাঙ্ক্ষিত আর আসল অবস্থার পার্থক্যের তালিকা। Git-এর diff যেমন লাইনের পার্থক্য দেখায়, plan দেখায় infrastructure-এর পার্থক্য। প্রতিটি resource-এর জন্য ফল পাঁচটির একটি:

এই পুরো ধারণাটি কয়েক লাইনে লেখা যায়। নিচের খেলনা engine-এ known হলো refresh-এর পরের অবস্থা। চালান, তারপর known-এ deploy/web-এর replicas 1 করে দেখুন, config/old মুছে দেখুন, বা forcesNew ফাঁকা করে দেখুন:

// A toy plan engine. Change desired or known, then run again.
// desired = your code. known = state after refresh (what really exists).
const desired = {
  "config/site": { greeting: "Salam" },
  "deploy/web":  { replicas: 1, image: "nginx:1.27" },
  "db/main":     { engine: "postgres", size: "small" },
  "service/web": { port: 80 },
};
const known = {
  "config/site": { greeting: "Salam" },
  "deploy/web":  { replicas: 3, image: "nginx:1.27" },
  "db/main":     { engine: "mysql", size: "small" },
  "config/old":  { greeting: "Hi" },
};
// Changing these fields cannot be done in place.
const forcesNew = ["engine"];

function plan(want, have) {
  const count = { add: 0, change: 0, destroy: 0 };
  for (const name of Object.keys({ ...have, ...want }).sort()) {
    const w = want[name], h = have[name];
    if (!h) { count.add++; console.log("  +   " + name + "  create"); continue; }
    if (!w) { count.destroy++; console.log("  -   " + name + "  delete"); continue; }
    const diffs = Object.keys(w).filter((k) => w[k] !== h[k]);
    const text = diffs.map((k) => k + ": " + h[k] + " -> " + w[k]).join(", ");
    if (diffs.length === 0) console.log("  =   " + name + "  no-op");
    else if (diffs.some((k) => forcesNew.includes(k))) {
      count.add++; count.destroy++;
      console.log("  -/+ " + name + "  replace (" + text + ")");
    } else { count.change++; console.log("  ~   " + name + "  update (" + text + ")"); }
  }
  console.log(`Plan: ${count.add} to add, ${count.change} to change, ${count.destroy} to destroy.`);
}
plan(desired, known);

৪ · Dependency graph: কে আগে, কে পরে

বাড়ি বানাতে আগে ভিত, তারপর দেয়াল, তারপর ছাদ। ভাঙতে হলে উল্টো ক্রম। Declarative ফাইলে কিন্তু ক্রম লেখা হয় না। তাহলে tool ক্রম জানে কীভাবে? উত্তর: একটি resource যখন অন্যটির মান ব্যবহার করে, সেখান থেকেই একটি dependency graph তৈরি হয়। নিচের config-এ Deployment-এর config_map_ref ConfigMap-এর নাম পড়ছে:

resource "kubernetes_config_map_v1" "site" {
  metadata {
    name      = "site-config"
    namespace = "abcl-ia"
  }
  data = {
    GREETING = "Salam"
  }
}

resource "kubernetes_deployment_v1" "web" {
  metadata {
    name      = "web"
    namespace = "abcl-ia"
  }
  spec {
    replicas = 1
    selector {
      match_labels = { app = "web" }
    }
    template {
      metadata {
        labels = { app = "web" }
      }
      spec {
        container {
          name  = "web"
          image = "nginx:1.27-alpine"
          env_from {
            config_map_ref {
              name = kubernetes_config_map_v1.site.metadata[0].name
            }
          }
          resources {
            requests = { cpu = "10m", memory = "16Mi" }
            limits   = { memory = "48Mi" }
          }
        }
      }
    }
  }
}

$ terraform graph
digraph G {
  rankdir = "RL";
  node [shape = rect, fontname = "sans-serif"];
  "kubernetes_config_map_v1.site" [label="kubernetes_config_map_v1.site"];
  "kubernetes_deployment_v1.web" [label="kubernetes_deployment_v1.web"];
  "kubernetes_deployment_v1.web" -> "kubernetes_config_map_v1.site";
}

$ terraform apply tfplan
kubernetes_config_map_v1.site: Creating...
kubernetes_config_map_v1.site: Creation complete after 0s [id=abcl-ia/site-config]
kubernetes_deployment_v1.web: Creating...
kubernetes_deployment_v1.web: Creation complete after 4s [id=abcl-ia/web]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

$ terraform destroy -auto-approve
…
Plan: 0 to add, 0 to change, 2 to destroy.
kubernetes_deployment_v1.web: Destroying... [id=abcl-ia/web]
kubernetes_deployment_v1.web: Destruction complete after 0s
kubernetes_config_map_v1.site: Destroying... [id=abcl-ia/site-config-v3]
kubernetes_config_map_v1.site: Destruction complete after 0s

Destroy complete! Resources: 2 destroyed.

একই ধারণা একটু বড় graph-এ চালিয়ে দেখুন। প্রতিটি key-এর পাশে লেখা, সে কার ওপর নির্ভর করে। এবার network-এর তালিকায় "balancer" বসিয়ে চালান। একটি বৃত্ত তৈরি হবে:

const needs = {
  network:  [],
  subnet:   ["network"],
  firewall: ["network"],
  database: ["subnet", "firewall"],
  server:   ["subnet", "firewall", "database"],
  balancer: ["subnet", "server"],
};

function levels(graph) {
  const level = {}, visiting = new Set();
  function visit(name, path) {
    if (level[name] !== undefined) return level[name];
    if (visiting.has(name)) throw new Error("Cycle: " + [...path, name].join(" -> "));
    if (!graph[name]) throw new Error("Unknown resource: " + name);
    visiting.add(name);
    const below = graph[name].map((d) => visit(d, [...path, name]));
    visiting.delete(name);
    return (level[name] = 1 + Math.max(0, ...below));
  }
  Object.keys(graph).forEach((n) => visit(n, []));
  return level;
}

try {
  const level = levels(needs);
  const depth = Math.max(...Object.values(level));
  const at = (d) => Object.keys(level).filter((n) => level[n] === d).sort().join(", ");
  console.log("CREATE (same line = can run in parallel)");
  for (let d = 1; d <= depth; d++) console.log("  step " + d + ": " + at(d));
  console.log("DESTROY (the same steps, reversed)");
  for (let d = depth; d >= 1; d--) console.log("  step " + (depth - d + 1) + ": " + at(d));
} catch (e) {
  console.log("Error: " + e.message);
}

৫ · Drift: code বলে এক, আসল অবস্থা আরেক

রাত দুইটায় traffic বেড়ে গেল। On-call engineer দ্রুত kubectl scale দিয়ে replica বাড়ালেন। ঠিক কাজই করলেন। কিন্তু code-এ এখনো replicas = 1. কাঙ্ক্ষিত আর আসল অবস্থার এই অমিলই drift. এটি আসল run-এ করে দেখা যাক:

$ kubectl scale deployment web --replicas=3 -n abcl-ia
deployment.apps/web scaled

$ terraform plan -detailed-exitcode
kubernetes_config_map_v1.site: Refreshing state... [id=abcl-ia/site-config]
kubernetes_deployment_v1.web: Refreshing state... [id=abcl-ia/web]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # kubernetes_deployment_v1.web will be updated in-place
  ~ resource "kubernetes_deployment_v1" "web" {
        id               = "abcl-ia/web"
        # (1 unchanged attribute hidden)

      ~ spec {
          ~ replicas                  = "3" -> "1"
            # (4 unchanged attributes hidden)

            # (3 unchanged blocks hidden)
        }

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.
…
$ echo $?
2

নিচের ডায়াগ্রামে তিন জায়গার মান ধাপে ধাপে দেখুন। প্রশ্নটি হলো, এখন apply করা কি নিরাপদ?

Drift মেটানোর পথ তাই একটি নয়:

Plan সব কিছু দেখে না। Terraform শুধু সেই জিনিস পরীক্ষা করে, যা তার state-এ আছে। আমরা হাতে আলাদা একটি ConfigMap manual-note বানিয়ে plan চালিয়েছিলাম। ফল: No changes. অর্থাৎ code-এর বাইরে হাতে বানানো জিনিস এই drift পরীক্ষায় ধরা পড়ে না। অন্যদিকে Deployment-এ হাতে বসানো label আর environment variable, আর হাতে মোছা ConfigMap, তিনটিই আসল run-এ plan ধরেছে। মোছা ConfigMap-এর ক্ষেত্রে plan বলেছে will be created.

৬ · Replace: বদল নয়, মুছে নতুন বানানো

সব মান জায়গায় বদলানো যায় না। লঞ্চের রং নতুন করা যায়, কিন্তু কাঠামো বদলাতে হলে নতুন লঞ্চই বানাতে হয়। Cloud-এও তাই। Kubernetes-এ object-এর নাম, আর cloud-এ VM-এর availability zone বা database-এর কিছু setting সাধারণত এমন। Provider-এর schema বলে দেয় কোন field replacement ঘটাবে। ConfigMap-এর নাম বদলে আসল plan:

$ terraform plan
…
Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # kubernetes_config_map_v1.site must be replaced
-/+ resource "kubernetes_config_map_v1" "site" {
      …
      ~ metadata {
          …
          ~ name             = "site-config" -> "site-config-v2" # forces replacement
          …
        }
    }

  # kubernetes_deployment_v1.web will be updated in-place
  ~ resource "kubernetes_deployment_v1" "web" {
      …
                          ~ config_map_ref {
                              ~ name     = "site-config" -> "site-config-v2"
      …
    }

Plan: 1 to add, 1 to change, 1 to destroy.

দুটি শব্দ খুঁজে নিতে শিখুন: must be replaced আর # forces replacement. দ্বিতীয়টি বলে দেয়, ঠিক কোন লাইনটির জন্য replace হচ্ছে। ধাপগুলো দেখুন:

resource "local_file" "keep" {
  filename = "${path.module}/keep.txt"
  content  = "important\n"
  lifecycle {
    prevent_destroy = true
  }
}

prevent_destroy থাকলে এই resource মোছার plan আটকে যায়। আসল run-এ error ছিল Error: Instance cannot be destroyed. Database-এর মতো জিনিসে এটি একটি সস্তা সিটবেল্ট। তবে resource block-টাই code থেকে সরালে এই রক্ষাও চলে যায়। পুরো রক্ষা নয়, তাই সাথে backup আর provider-এর deletion protection রাখুন।

৭ · Code থেকে cloud: Git, review আর apply

IaC-র আসল শক্তি আসে Git-এ রাখলে। Code পরিবর্তন একটি pull request হয়। সেখানে CI plan চালায়, মানুষ plan পড়ে, আর merge-এর পরে apply চলে। Code review-এর অভ্যাসটিই infrastructure-এ আসে।

এবার একটি ছোট বদল পুরো পথে হাঁটিয়ে দেখি: web-এর replica ১ থেকে ২।

$ git switch -c scale-web
  spec {
-    replicas = 1
+    replicas = 2

terraform fmt -check
terraform validate
terraform plan -out=tfplan

  # kubernetes_deployment_v1.web will be updated in-place
          ~ replicas = "1" -> "2"

Plan: 0 to add, 1 to change, 0 to destroy.

terraform apply tfplan

Error: Saved plan is stale

The given plan file can no longer be applied because the state was changed by
another operation after the plan was created.

No changes. Your infrastructure matches the configuration.

কয়েকটি নিয়ম এই পথকে নিরাপদ রাখে। .tf ফাইল আর .terraform.lock.hcl Git-এ থাকে। *.tfstate আর .terraform/ ফোল্ডার থাকে না, কারণ state-এ গোপন মান থাকতে পারে। Secret code-এ লেখা হয় না (পর্ব ৩৩)। আর production apply করার অধিকার মানুষের হাতে না রেখে pipeline-কে দিলে হাতে বদলের পথও কমে। এই Git-কেন্দ্রিক ভাবনার পরের রূপ GitOps, পর্ব ৬০-এ।

৮ · Blast radius আর plan পড়ার অভ্যাস

IaC ভুলকেও দ্রুত আর বড় করে। হাতে একটি server মুছতে কয়েকটি ক্লিক লাগে। এক লাইনের ভুল code শত resource ছুঁতে পারে। একটি stack (যে resource-গুলো একসাথে একটি state বা একটি apply-এ চলে) যত বড়, তার blast radius-ও তত বড়।

ধরুন network, database, app আর DNS সব একটি stack-এ, আর dev আর prod-ও একসাথে। তখন app-এর ছোট বদলের plan-এ network-ও পড়া হয়, lock-এ সবাই আটকে থাকে, আর একটি ভুল সবকিছুকে ছুঁতে পারে। সাধারণ নিয়ম:

• Environment আলাদা: dev আর prod-এর state ও অনুমতি আলাদা (পর্ব ৫৪)।
• বদলের গতি অনুযায়ী ভাগ: network আর database কম বদলায়, app বেশি বদলায়। তাই stack আলাদা।
• মালিকানা অনুযায়ী ভাগ: যে দল চালায়, stack তার।
• সীমিত অনুমতি: প্রতিটি stack-এর পরিচয়ে শুধু দরকারি অনুমতি, অর্থাৎ least privilege.

তবে খুব বেশি ভাগ করলে আবার stack-এর মধ্যে নির্ভরতা সামলানো কঠিন হয়, আর একটি কাজের জন্য অনেক PR লাগে। ভারসাম্যই আসল। Plan পড়ার অভ্যাসটি প্রতিবার এই ক্রমে করুন:

1. শেষ লাইন আগে: Plan: x to add, y to change, z to destroy. সংখ্যাগুলো কি আপনার বদলের সাথে মেলে?
2. সতর্ক-শব্দ খুঁজুন: destroy, must be replaced, # forces replacement.
3. বিপজ্জনক ধরন দেখুন: database, storage, DNS, IAM, firewall.
4. অপরিচিত পরিবর্তন খুঁজুন: আপনি যা বদলাননি, তা plan-এ এলে সেটি drift বা version বদলের চিহ্ন হতে পারে।
5. known after apply বুঝুন: সেখানে মান এখনো অজানা, তাই plan পুরো নিশ্চয়তা দেয় না।
6. সন্দেহ হলে থামুন: Plan বোঝা না গেলে apply নয়।

৯ · Tool-এর মানচিত্র আর IaC-র সীমা

নাম অনেক, কিন্তু প্রশ্ন কয়েকটি: কোন ভাষায় লিখবেন, কোন cloud-এ চলবে, আর state কে রাখবে?

Google Cloud-এ Terraform খুবই প্রচলিত, আর লেখার সময়ে Google-এর Infrastructure Manager সেবাটিও Terraform-ভিত্তিক। Tool-এর সুবিধা আর licence বদলাতে থাকে, তাই বাছাইয়ের আগে সেই tool-এর বর্তমান ডকুমেন্টেশন দেখুন।

IaC যা সমাধান করে না

IaC জাদু নয়। এই সীমাগুলো জানা থাকলে প্রত্যাশা ঠিক থাকে:

• ভুল নকশা: ভুল architecture-কে IaC দ্রুত আর হুবহু বারবার বানায়।
• ডেটা: Code database আবার বানাতে পারে, ভেতরের ডেটা নয়। সে জন্য পর্ব ২৪-এর backup লাগে।
• নিরাপত্তা: 0.0.0.0/0 লেখা থাকলে tool ঠিক সেটিই বসাবে। Policy আর scan আসবে পর্ব ৫৫-এ।
• চলমান system-এর ভেতরের কাজ: schema migration, data backfill আর ধীরে ধীরে rollout-এর জন্য আলাদা পদ্ধতি লাগে।
• Plan-এর সীমা: Plan বলে কী বদলাবে, কিন্তু বদলের পরে app ঠিক চলবে কি না, তা বলে না। Quota বা অনুমতির সমস্যাও অনেক সময় apply-এর সময়েই ধরা পড়ে।
• মাঝপথের ব্যর্থতা: Terraform-এর apply কোনো transaction নয়। অর্ধেক কাজের পরে থামলে যা হয়েছে, তা থেকে যায়। আবার plan করে এগোতে হয়।
• মানুষের শৃঙ্খলা: সবাই console-এ হাত দিলে যত ভালো code-ই হোক, drift থামবে না।

১০ · AI-এর যুগে IaC

AI কয়েক সেকেন্ডে শত লাইন HCL লিখে দিতে পারে, আর দেখতে তা নিখুঁত লাগে। কিন্তু AI আপনার state, আসল account বা বিল দেখতে পায় না। IaC-তে ভুলের ফল একটি resource-এ থামে না, তাই এখানে যাচাই আরও জরুরি।

AI-এর লেখা IaC হাতে পেলে — যাচাইয়ের চেকলিস্ট

• terraform fmt -check আর terraform validate পাস করেছে
• একটি throwaway environment-এ plan চালিয়ে প্রতিটি লাইন পড়েছি
• প্রতিটি argument provider-এর ডকুমেন্টেশনে মিলিয়েছি
• Plan-এ কোনো অপ্রত্যাশিত destroy বা replace নেই
• * অনুমতি, 0.0.0.0/0, public storage আর hardcoded secret নেই
• Provider আর image-এর version বাঁধা, আর budget alert চালু