Container, Kubernetes ও CI/CD

তুমি Docker দিয়ে app কে container এ ভরেছো, আর CI/CD দিয়ে deploy করেছো। বড় system এ শত শত container চালাতে হয়, কয়েকটা machine জুড়ে, আর কেউ নষ্ট হলে নিজে থেকে আবার চালু, চাপ বাড়লে নিজে থেকে বাড়ানো। এই কাজটা করে container orchestrator, যার মধ্যে সবচেয়ে প্রচলিত Kubernetes। এই অধ্যায়ে এর মূল ধারণা, আর আধুনিক deploy এর কৌশলগুলো। লক্ষ্য Kubernetes এর বিশেষজ্ঞ হওয়া না, বরং কথাবার্তা বোঝা আর কখন এটা লাগে সেটা জানা।

#Kubernetes কী সমস্যা সমাধান করে

তুমি বলো কী চাও ("order-api এর ৪টা copy সবসময় চালু থাকুক, প্রতিটা ৫০০MB memory"), Kubernetes নিজেই ঠিক করে কীভাবে (কোন machine এ, নষ্ট হলে কোথায় আবার)। একে বলে declarative ব্যবস্থা।

#মূল ধারণা

# deployment.yaml (সংক্ষেপে)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-api
spec:
  replicas: 4
  selector:
    matchLabels: {app: order-api}
  template:
    metadata:
      labels: {app: order-api}
    spec:
      containers:
        - name: api
          image: ghcr.io/you/order-api:1.8.3
          ports: [{containerPort: 8000}]
          envFrom: [{secretRef: {name: order-api-secrets}}]
          resources:
            requests: {cpu: "250m", memory: "256Mi"}
            limits: {memory: "512Mi"}
          readinessProbe:
            httpGet: {path: /health/ready, port: 8000}
          livenessProbe:
            httpGet: {path: /health/live, port: 8000}

#Kubernetes কি তোমার লাগবে?

#Deploy এর কৌশল

#Rolling deploy এ database migration

কিছুক্ষণ পুরনো আর নতুন code একসাথে চলে, দুজনেই একই database ব্যবহার করে। তাই migration কে backward compatible হতে হয় (expand-contract):

1. Expand: নতুন column/table যোগ (পুরনো code এতে বিরক্ত হয় না)
2. নতুন code deploy, যেটা দুই জায়গাতেই লেখে
3. পুরনো data নতুন জায়গায় copy
4. নতুন code শুধু নতুন জায়গা থেকে পড়ে
5. Contract: পরের release এ পুরনো column মোছা

একবারে column এর নাম বদলালে rolling deploy এর মাঝখানে পুরনো code ভেঙে পড়বে।

#Feature flag

Code deploy আর feature চালু করা আলাদা করো: নতুন feature code এ থাকে কিন্তু flag বন্ধ; পরে admin panel থেকে প্রথমে নিজের team, তারপর ১০% user, তারপর সবার জন্য চালু। সমস্যা হলে flag বন্ধ, deploy ফেরানো লাগে না।

#Infrastructure as Code

Server, database, network, DNS হাতে cloud console এ click করে বানালে কেউ জানে না কী কীভাবে বানানো, আর আবার বানানো প্রায় অসম্ভব। IaC এ সব কিছু code এ লেখা (Terraform/OpenTofu, Pulumi), Git এ থাকে, review হয়, আর একই code দিয়ে staging আর production হুবহু বানানো যায়।

# Terraform উদাহরণ (সংক্ষেপে)
resource "aws_db_instance" "orders" {
  engine              = "postgres"
  instance_class      = "db.t4g.medium"
  allocated_storage   = 100
  multi_az            = true                 # অন্য zone এ standby
  backup_retention_period = 14
  publicly_accessible = false
}

#GitOps

Cluster এর কাঙ্ক্ষিত অবস্থা একটা Git repo তে; Argo CD বা Flux এর মতো tool সারাক্ষণ cluster কে সেই repo এর সাথে মেলায়। Deploy মানে একটা PR merge; ফেরানো মানে revert। কে কখন কী বদলালো, Git এর ইতিহাসে সব লেখা।

#অনুশীলন

#নিজেকে যাচাই করো