Production ထဲက Containers

နားလည်ထားရမယ့် အချက်

Container တစ်ခုက app ကို runtime နဲ့ dependency အားလုံးနဲ့အတူ portable unit တစ်ခုအဖြစ် ထုတ်ပိုးပေးပြီး နေရာတိုင်းမှာ တစ်ပုံစံတည်း run နိုင်ပါတယ် — ဒီ portability ကပဲ အဓိက အချက်ပါ။

Container vs VM

VM က operating system တစ်ခုလုံးကို virtualize လုပ်ပါတယ်။ Container က host ရဲ့ kernel ကို share လုပ်ပြီး application layer ကိုပဲ isolate လုပ်ပါတယ် — ဒါကြောင့် container တွေက millisecond နဲ့ start ပြီး VM တွေက second/minute ကြာတတ်ပါတယ်။

Image — ဆောက်ပြီးသား၊ frozen, version ခွဲထားတဲ့ app + dependency snapshot။
Container — image ရဲ့ running instance တစ်ခု၊ image တစ်ခုကနေ container အများကြီး run နိုင်တယ်။
Flow: image ဆောက် -> registry ကို push -> deployment server က pull -> container(s) အဖြစ် run။

Version အသစ် ship လုပ်ဖို့ဆိုတာ image အသစ်ဆောက်ပြီး running container ကို အစားထိုးတာပါ — live server ထဲက file ကို patch လုပ်တာ မဟုတ်ပါဘူး။ ဒါက deployment ကို immutable ဖြစ်စေတာပါ။

Dockerfile syntax နဲ့ Docker Compose mechanics အတွက် ဒီ site ရဲ့ Docker tutorial ကို ကြည့်ပါ။ Machine အများကြီးမှာ container တွေကို orchestrate လုပ်ဖို့အတွက် Kubernetes tutorial ကို ကြည့်ပါ။

text

IMAGE TO RUNNING CONTAINER
--------------------------
IMAGE TO RUNNING CONTAINER
----------------------------

[ source code ]
      |
      | docker build
      v
[   IMAGE   ]  (frozen, versioned snapshot)
      |
      | docker push
      v
[  REGISTRY  ]
      |
      | deployment server: docker pull
      v
[ DEPLOY SERVER ]
      |
      | docker run  (can start many)
      v
[CONTAINER 1] [CONTAINER 2] [CONTAINER 3]
   (running instances of the same image)

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

ဒါက ဥပမာပြရုံသက်သက် snippet ပါ — တမင် တိုတိုထားတာပါ၊ run လုပ်ဖို့ ဒါမှမဟုတ် project အစစ်ထဲ ကူးဖို့ ရည်ရွယ်တာ မဟုတ်ပါဘူး။

Base image

Base runtime image တစ်ခုကနေ စတင်ပါ (ဥပမာ Node.js runtime)။

Copy + install

Dependency manifest ကို copy ကူးပြီး dependency တွေ install လုပ်ပါ။

App code copy

App source ကျန်တာကို image ထဲကို copy ကူးပါ။

Start command ကြေညာ

Container run တဲ့အခါ app ကို start ပေးမယ့် command ကို ကြေညာပါ။

Syntax အစစ်နဲ့ Docker Compose အတွက် dedicated Docker tutorial ကို သုံးပါ — ဒီ lesson က တမင်ကျော်ထားတဲ့ mechanics ကို ဒီမှာ သင်ပေးပါတယ်။

Image ဆိုတာ frozen, version ခွဲထားတဲ့ snapshot ပါ၊ container ဆိုတာ ဒီ image ရဲ့ running instance ပါ။
Production container တွေက build -> registry ကို push -> pull -> run ကို follow လုပ်ပါတယ်၊ version အသစ် ship လုပ်တာဆိုတာ image အသစ်ပါ၊ server ကို patch လုပ်တာ မဟုတ်ပါဘူး။
ဒီ lesson က orientation level ပါ — Dockerfile syntax အတွက် Docker tutorial၊ orchestration အတွက် Kubernetes tutorial ကို သွားပါ။

အတူတူ စမ်းရေးကြည့်မယ်

bash

FROM node:20-alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["node", "server.js"]

Run လုပ်လို့မရနိုင်ပါ

ဒီ code/config ဟာ illustrative ဖြစ်ပြီး ဒီ site ရဲ့ browser playground ထဲ တိုက်ရိုက် run လို့မရပါ — real cloud platform (သို့) real DNS/hosting setup တစ်ခု လိုအပ်ပါတယ်။ Docker, Terraform, AWS စတဲ့ dedicated tutorial တွေမှာ ပိုနက်ရှိုင်းစွာ လက်တွေ့ လုပ်ကြည့်နိုင်ပါတယ်။

You should see

ဒါက ဥပမာပြရုံသက်သက်ပါ၊ ဒီမှာ run လို့ မရပါဘူး။ Line တစ်ကြောင်းစီက build-time layer တစ်ခု ထပ်ထည့်ပေးပါတယ်၊ docker build run ရင် image ထွက်လာမယ်၊ docker run ကမှသာ ဒါကနေ container တစ်ခု start လုပ်ပါတယ်။ Build output အစစ်အတွက် Docker tutorial ကို ကြည့်ပါ။

၅ မိနစ် စမ်းကြည့်

Image ကို ပြန်မဆောက်ဘဲ production ထဲမှာ run နေတဲ့ container တစ်ခုအထဲက file တစ်ခုကို တိုက်ရိုက် edit လုပ်ရင် ဘာဖြစ်မလဲဆိုတာ ကိုယ့်စကားနဲ့ ရေးပါ။ Container ကို နောက်တစ်ခါ restart လုပ်ရင် ဒီပြောင်းလဲမှုက ဘာကြောင့် ပျောက်သွားလဲ။

သတိလေးတစ်ချက်

Production ထဲမှာ run နေတဲ့ container ထဲကို SSH ဝင်ပြီး file ကို လက်နဲ့ edit လုပ်ပြီး၊ container ကို နောက်တစ်ခါ restart/redeploy လုပ်တဲ့အခါ ဒီ fix ပျောက်သွားတာ။

Container ကို host kernel share လုပ်တဲ့ isolated process မဟုတ်ဘဲ VM ပေါ့ပေါ့ တစ်ခုပဲလို့ ထင်ထားပြီး isolation နဲ့ startup time အကြောင်း မှားတဲ့ assumption ယူထားတာ။

Docker docs — What is a container? — Cloud & Deployment