শেখো / ডিপ্লয়মেন্ট ও ইনফ্রা

Infrastructure as Code

10 মিনিট Module 9 · Deployment & Infrastructure

এক নজরে

●IaC মানে server, network, database — সব infrastructure code দিয়ে সংজ্ঞায়িত ও পরিচালনা করা।
●Declarative পদ্ধতিতে তুমি 'কী চাও' বলো, tool নিজে থেকেই সেই অবস্থায় পৌঁছায়; idempotency নিশ্চিত করে বারবার চালালেও একই ফল।
●Infrastructure version-controlled হওয়ায় review, rollback ও reproducibility সহজ হয়; drift হলো বিপদ।

সমস্যাটা কী?

কল্পনা করো তোমার একটা নতুন server লাগবে। তুমি cloud console-এ গিয়ে মাউস ক্লিক করে একটা VM বানালে, firewall খুললে, database যোগ করলে, কিছু setting বদলালে। সব ঠিকঠাক চলছে।

এবার ছয় মাস পর তোমাকে আরেকটা একই রকম পরিবেশ (staging) বানাতে হবে। কিন্তু তুমি ঠিক মনে করতে পারছ না — কোন setting কী দিয়েছিলে, কোন firewall rule খুলেছিলে। আবার ক্লিক করে বানাতে গিয়ে কিছু একটা মিলল না, আর staging-এ অদ্ভুত bug দেখা দিল। এই "manually click করে infrastructure বানানো"-কে বলে ClickOps — যা ভুলপ্রবণ, অপুনরাবৃত্তিযোগ্য আর documentation-হীন।

আরও খারাপ — সেই VM-টা কেউ ভুলে delete করলে পুরো setup আবার শূন্য থেকে বানাতে হবে। সমাধান হলো — infrastructure-কেও code হিসেবে লেখা, যাকে বলে Infrastructure as Code (IaC)।

মূল ধারণা

Infrastructure as Code (IaC) হলো server, network, database ইত্যাদি infrastructure-কে human-readable configuration file (code) দিয়ে সংজ্ঞায়িত ও পরিচালনা করার পদ্ধতি, manually নয়।

মূল ধারণা — তোমার পুরো infrastructure একটা text file-এ লেখা থাকবে, যা তুমি Git-এ রাখবে। সেই file চালালে infrastructure তৈরি হবে। এর ফলে infrastructure হয়ে যায় reproducible (একই file থেকে বারবার একই পরিবেশ), version-controlled (কে কী বদলাল সব Git-এ), আর reviewable (deploy-এর আগে কেউ পরীক্ষা করতে পারে)।

কীভাবে কাজ করে

Declarative বনাম Imperative

দুটি ভিন্ন দর্শন:

বৈশিষ্ট্য	Imperative	Declarative
তুমি লেখো	ধাপে ধাপে "কী করতে হবে"	শেষ "কী অবস্থা চাও"
উদাহরণ	"VM তৈরি করো, তারপর IP দাও"	"একটি VM থাকবে এই config-এ"
বর্তমান অবস্থা সামলানো	নিজে করতে হয়	tool নিজে করে
টুল	shell script, Ansible (অংশত)	Terraform, CloudFormation

Declarative-এ তুমি শুধু লক্ষ্য বলো; tool বর্তমান অবস্থা দেখে কী যোগ/পরিবর্তন/মুছতে হবে নিজে ঠিক করে। আধুনিক IaC বেশিরভাগই declarative।

Idempotency

এটি IaC-র একটি প্রাণভোমরা ধারণা।

Idempotency মানে একই operation একবার বা একশবার চালালেও ফলাফল একই থাকে।

যেমন, "এই VM-টি থাকবে" — এটা প্রথমবার চালালে VM তৈরি হবে, কিন্তু পরের বার চালালে দেখবে VM ইতিমধ্যে আছে, তাই কিছুই করবে না (আরেকটা বানাবে না)। এর ফলে নিশ্চিন্তে বারবার চালানো যায়।

Terraform উদাহরণ

সবচেয়ে জনপ্রিয় IaC tool হলো Terraform (HashiCorp-এর)। তুমি .tf file-এ desired state লেখো:

resource "aws_instance" "web" {
  ami           = "ami-0abcd1234"
  instance_type = "t3.micro"
  tags = {
    Name = "web-server"
  }
}

Terraform-এর কাজের ধাপ:

terraform plan — কী পরিবর্তন হবে তা আগে দেখায় (preview)।
terraform apply — সেই পরিবর্তন বাস্তবে প্রয়োগ করে।
Terraform একটি state file-এ রাখে কী কী resource সে তৈরি করেছে, যাতে পরের বার তুলনা করতে পারে।

সহজ উদাহরণ

IaC-কে ভাবো একটা বাড়ির নকশা (blueprint) হিসেবে। আগে রাজমিস্ত্রি স্মৃতি থেকে বাড়ি বানাত — দ্বিতীয় বাড়িটা প্রথমটার মতো হতো না, আর কোথায় কী আছে কেউ মনে রাখত না। এখন নকশা থাকলে যেকোনো মিস্ত্রি হুবহু একই বাড়ি বানাতে পারে, নকশায় পরিবর্তন হলে সবাই দেখতে পায়। Terraform-এর plan হলো — নকশা পরিবর্তনের আগে "কী কী বদলাবে" দেখিয়ে দেওয়া, যাতে ভুল করে দেয়াল ভাঙা না হয়। আর কেউ যদি নকশা না দেখে নিজে নিজে দেয়ালে দরজা কেটে ফেলে, সেটাই drift।

কৌশল

পুরো infrastructure code Git-এ রাখো, প্রতিটি পরিবর্তন pull request-এ review করো।
State file নিরাপদ ও শেয়ারড জায়গায় (remote backend, যেমন S3) রাখো, যাতে পুরো দল একই state দেখে।
Module ব্যবহার করে পুনঃব্যবহারযোগ্য component বানাও (যেমন একটা "network" module)।
Secret কখনো .tf file-এ plain text-এ লিখো না।

কখন ব্যবহার করবে / করবে না

ব্যবহার করবে যখন:

একাধিক environment (dev, staging, production) একরকম রাখতে চাও।
দল বড়, infrastructure পরিবর্তন review করা দরকার।
দ্রুত নতুন পরিবেশ তৈরি বা ধ্বংস করতে হয়।

কম দরকার যখন:

একদম ছোট একটা single server, যা কখনো বদলায় না।

সাবধান

IaC ব্যবহার করার পর কখনো cloud console-এ গিয়ে manually পরিবর্তন করো না। তখন বাস্তব infrastructure আর code-এর মধ্যে drift তৈরি হয়। পরের বার Terraform চালালে সে তোমার manual পরিবর্তন মুছে আগের অবস্থায় ফিরিয়ে দিতে পারে — অথবা অপ্রত্যাশিত আচরণ করতে পারে। নিয়ম একটাই — সব পরিবর্তন code-এর মধ্য দিয়ে।

বাস্তব উদাহরণ

একটা startup তাদের পুরো AWS infrastructure Terraform-এ লিখেছে — VPC, EC2, RDS database, S3, load balancer। যখন তাদের নতুন একটা region-এ একই setup লাগল, তারা শুধু কয়েকটা variable বদলে terraform apply দিল — মিনিটেই হুবহু একই পরিবেশ তৈরি।

একবার একজন ডেভেলপার ভুলে production database delete করে ফেলল। আতঙ্কের বদলে, তারা Terraform চালিয়ে কয়েক মিনিটে আবার সম্পূর্ণ infrastructure দাঁড় করিয়ে ফেলল (data backup থেকে restore করে)। code-এ সব লেখা থাকায় কোনো জ্ঞান হারায়নি। আর প্রতিটি পরিবর্তন pull request-এ review হওয়ায় ভুল setting আগেই ধরা পড়ে।

টিপস

Interview-তে IaC নিয়ে প্রশ্নে "idempotency" আর "declarative vs imperative" — এই দুটো শব্দ ব্যবহার করো। আর Terraform-এর plan ও apply-র পার্থক্য জানা থাকলে বলো। সবচেয়ে শক্তিশালী point হলো — IaC infrastructure-কে disposable ও reproducible বানায়; পুরো পরিবেশ মুছে গেলেও code থেকে আবার দাঁড় করানো যায়। এটা বললে বোঝা যায় তুমি disaster recovery-ও ভাবো।

মূল শব্দ (Key Terms)

IaC Terraform Idempotency Drift

মিনি কুইজ

1. Infrastructure as Code-এর মূল সুবিধা কোনটি?

2. Declarative IaC বলতে কী বোঝায়?

3. Configuration drift কী?

আগের পাঠBlue-Green ও Canary Deploy পরের পাঠAutoscaling